[Trilinos-Users] Teuchos MpiComm

[Heroux, Michael A]

Thanks Ross.  TrilinosUsability++ because of your efforts :)

On 12/23/14, 4:05 PM, "Bartlett, Roscoe A." <bartlettra at ornl.gov> wrote:

>Understood.   This access pattern is very reasonable.  I am surprised no
>one added a helper function like this sooner.
>
>The next release of Trilinos will have this function and the public clone
>will have it as soon as it is updated (I am pushing to Trilinos master
>right now).
>
>If other Trilinos users find common access patterns like this that are
>not well supported in Trilinos, please let us know.  It is very easy to
>add helper functions for these.
>
>Cheers,
>
>-Ross
>
>> -----Original Message-----
>> From: David Hysom [mailto:hysom1 at llnl.gov]
>> Sent: Tuesday, December 23, 2014 4:58 PM
>> To: Heroux, Michael A; Bartlett, Roscoe A.; trilinos-
>> users at software.sandia.gov
>> Subject: Re: [Trilinos-Users] Teuchos MpiComm
>> 
>> 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
>