[Trilinos-Users] Teuchos MpiComm

[Bartlett, Roscoe A.]

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