[Petsc-trilinos-discussion] Scope and requirements

Wed Nov 20 16:55:51 CST 2013

  My understanding is that a particular case that came to the attention of some DOE program managers was when there was a not insignificant funded research project that was to couple two distinct codes (presumably each of which did does separate physics that it was now time to solve coupled). One of the two codes used PETSc, the other Trilinos. The project team needed to decide how to proceed and for some reason discussions on how to proceed propagated up to program management. 

  Does/did this need to be an issue at all? Well, at the technical level maybe not, after all there is not specific technical reason that either 

   1) each separate physics continues to use its own PETSc or Trilinos library (should be almost trivial, but does require installing both libraries and if the same developers work on both sets of physics they need to be aware of how both libraries work)   or

   2) one of the separate physics codes gets refactored to use the selected common library (depending on the code it could be relatively straightforward or a real bear, and the decision about which of the two libraries to retain may be difficult to make) or 

  3) each separate physics code gets refactored to work with either library (more work, with or without any real benefit)

   Anyways, not the end of the world. But as we all know as soon as program management is involved simple things become complicated, technical decisions become “political” decisions, and mis-communication and mis-information dominate. And when program managers have questions/concerns, they may not turn to the right people for answers or even the right people may not “off the cuff” be able to provide coherent answers. Note that this is not an attack in anyway on program managers, they do a great job but it is the nature of their work that makes these situations difficult.

   I’m hoping that we can use this process to generate a good understanding of the issues and be able to produce a coherent set of answers that are both suitable for technical users and for “policy makers”.  Currently we are at the stage of being able to say “under certain circumstances using Trilinos is likely better for your situation, under other circumstances using PETSc would be likely better for you and sometimes, it really doesn’t matter that much”. So a possible end result of this process could be a flow chart that led the person to a suitable approach for their situation???

   Some possible starting questions are:

1)  I’m starting a new code that needs x, y, and z.   What package(s) should I use and how should I start?

2) I have a code that uses (for example) its own ODE integrators. What package(s) should I use and how should I start to get better quality integrators?

3)  I have two or more codes (may or may not use Trilinos/PETSc), that do different things,  that I would like to couple them. How should I proceed?

4)  I have two codes that do more or less the same thing (may or may not use Trilinos/PETSc), I’d like to merge them into one code that has the best capabilities of each. How should I proceed?

5) My code uses X (either PETSc or Trilinos), is it worth getting it to use Y as an alternative also?

   One “suggestion” is, could there be a “higher-level” interface that people could use that incorporated either PETSc or Trilinos underneath? A difficulty I see with that approach is that design decisions (either in C or C++) at one level of the stack permeate the entire stack and users have to see more then just the top level of the stack from our libraries. For example, 

   1)  say PETSc and Trilinos somehow share a common ODE solver interface, the user code still needs to provide Jacobians (let’s be reasonable and not pretend everything can be done completely matrix free :-)) which means users need to see the matrix API which is not common to both packages.  

   2) We could go even higher and say the user only provides weak forms of the operators and all the manipulations needed to set up and solve the equations is handled for the users by a library/tool, well in that case then maybe the differences between PETSc and Trilinos could be hidden. But is this a reasonable interface for DOE users and is this library level viable to provide and support in the near future?  Based on current users and technology I would say not.

  Barry

On Nov 20, 2013, at 1:01 PM, Bartlett, Roscoe A. <bartlettra at ornl.gov> wrote:

> Mike,
> 
> It might to facilitate the discussion if someone could construct a set of example use cases involving Trilinos and PETSc and demonstrate the problems associated with the status quo (which is very little coordination, common or compatible interfaces, etc.).  Have there been real application codes, university students, etc. that have complained or lamented that they have to chose Trilinos or PETSc and see a large investment in switching back and forth?  Note that a lot of application codes support Trilinos and PETSc data structures and solvers and can switch back and forth with just switches in their input files.  Obviously they have to do a lot of work to make this possible but they do it.  Are any of these people represented on this main list?
> 
> Also, if we are really serious about this, a mail list may not be sufficient for driving progress at some point.
> 
> -Ross
> 
>> -----Original Message-----
>> From: petsc-trilinos-discussion-bounces at lists.mcs.anl.gov [mailto:petsc-
>> trilinos-discussion-bounces at lists.mcs.anl.gov] On Behalf Of Heroux, Michael
>> A
>> Sent: Wednesday, November 20, 2013 1:46 PM
>> To: petsc-trilinos-discussion at lists.mcs.anl.gov
>> Subject: [Petsc-trilinos-discussion] Scope and requirements
>> 
>> It seems to me that we should start this discussion with scope and
>> requirements.
>> 
>> What needs are we addressing?  What are the requirements?
>> 
>> Are we restricting our efforts to solvers?  Linear, nonlinear, eigen, transient,
>> more?
>> 
>> What usage models are we supporting?
>> 
>> Mike
>> _______________________________________________
>> Petsc-trilinos-discussion mailing list
>> Petsc-trilinos-discussion at lists.mcs.anl.gov
>> https://lists.mcs.anl.gov/mailman/listinfo/petsc-trilinos-discussion
> _______________________________________________
> Petsc-trilinos-discussion mailing list
> Petsc-trilinos-discussion at lists.mcs.anl.gov
> https://lists.mcs.anl.gov/mailman/listinfo/petsc-trilinos-discussion