[Trilinos-Users] Teuchos MpiComm

[David Hysom]

Yes, that's correct.
In functions where I need an MPI_Comm, I'm always
passing a CrsMatrix and the call getComm() -- so
the MPI_Comm is only "visible" within the method.

On 12/23/2014 01:54 PM, Heroux, Michael A wrote:
> In my experience the typically situation (and maybe David can confirm this
> is his case or not) is that the Teuchos::Comm API does not support access
> to a function that is available in MPI and needed by the user.
>
> Therefore access to the raw MPI communicator is needed for accomplishing a
> particular task.  My situations have never required persistent access
> outside of the scope of a single function.  In fact we should advise
> against a persistent instance of the pointer since it is available via
> this helper function anytime it is needed.
>
> Mike
>
> On 12/23/14, 3:30 PM, "Bartlett, Roscoe A." <bartlettra at ornl.gov> wrote:
>
>>> Something this simple should not be so hard to do.  Can we introduce a
>>> helper function in Teuchos?
>> I am adding one now that will allow you to do:
>>
>> void someFunc(const Teuchos::Comm<int> &comm)
>> {
>>   MPI_Comm  rawMpiComm = getRawMpiComm(comm);
>>   ... use rawMpiComm and forget it ...
>>   return;
>> }
>>
>> In the above example you are assuming that the underlying implementation
>> is Teuchos::MpiComm.  If that is not true, it will throw an exception.
>> Also, be aware that the lifetime of the returned MPI_Comm is not
>> guaranteed.  It can go away at any time because the client is not
>> participating in reference counting of the underlying MPI_Comm object.
>>
>> Note that in general, when you use object oriented programming and object
>> composition in C++ (by the book), you will have object hierarchies and
>> object composite stacks.   If you are in code that works with the base
>> interfaces and you if you want to grab an embedded object in a derived
>> type, you *always* have to dynamic cast, then call access functions (and
>> sometimes several times if it is a deep stack of interfaces and objects).
>>   Where this gets "complicated" is combination the explicit dynamic
>> casting (i.e. rcp_dynamic_cast), the memory and lifetime management (i.e.
>> RCP), and the non-object behavior of MPI_Comm (i.e. OpaqueObject).  This
>> is C++ and that is what you have to do to write safe flexible
>> interoperable software.     Experienced C++ programmers are very
>> comfortable with this approach (because that is what you have to do in
>> C++).
>>
>> But we can (and do in many case) provide non-member helper functions for
>> common access patterns that do this dynamic casting for you.
>>
>> If we want everything to be simple, we would just use Python for
>> everything.  Python is weekly typed so there is no need for dynamic
>> casting.  Python has reference counting built in so there is no need for
>> RCP classes.  The problem is that Python is slow, Fortran is not a
>> general purpose modern programming language, and C is too low level and
>> no help with management memory, and so here we are back to C++.
>> Computational science is in a very bad place right now all things
>> considered.
>>
>> Cheers,
>>
>> -Ross
>>
>>
>>> On 12/23/14, 12:49 PM, "Bartlett, Roscoe A." <bartlettra at ornl.gov>
>>> wrote:
>>>
>>>>>> Teuchos::RCP<matrix_t> A...;
>>>>>>
>>>>>> //doesn't work:
>>>>>> Teuchos::RCP< const Teuchos::MpiComm< int > >  tr_comm = m_A-
>>>>>>> getComm();
>>>>>> //works, but I don't have an MpiComm:
>>>>>> Teuchos::RCP< const Teuchos::Comm< int > >  tr_comm = m_A-
>>>>>> getComm();
>>>>>>
>>>>>> //fails because I don't have an MpiComm
>>>>>> Teuchos::RCP<const Teuchos::OpaqueWrapper<int> > cmm =
>>>>>> tr_comm->getRawMpiComm();
>>>>> Teuchos::RCP<const Teuchos::OpaqueWrapper<int> >  cmm =
>>>>>     rcp_dynamic_cast<Teuchos::MpiComm<int> > (tr_comm, true)-
>>>>>> getRawMpiComm();
>>>> Forgot the const.
>>>>
>>>> Teuchos::RCP<const Teuchos::OpaqueWrapper<int> >  cmm =
>>>>    rcp_dynamic_cast<const Teuchos::MpiComm<int> > (tr_comm,
>>>> true)->getRawMpiComm();
>>>>
>>>> NOTE: You should not need Teuchos:: before the rcp_dynamic_cast due to
>>>> ADL.  The "true" is so that if the dynamic cast fails, you get a good
>>>> error message and not just a null pointer.
>>>>
>>>> -Ross
>>>>
>>>>
>>>> _______________________________________________
>>>> Trilinos-Users mailing list
>>>> Trilinos-Users at software.sandia.gov
>>>> https://software.sandia.gov/mailman/listinfo/trilinos-users