[Petsc-trilinos-discussion] Status update, summary remarks

[Barry Smith]

   DOE ASCR has asked us to do two things:

    A) maintain a dynamic, future oriented research program in algorithm and software techniques for HPC that can quickly respond to hardware changes and 

    B) provide software stable (and quality) enough to be used by a variety of scientists/engineers on long term projects with very varying software skills and perverse predilections


   To first order I would say that PETSc and Trilinos have had slightly different user bases

    * Trilinos - largish groups that often have strict regression tests and that are cautious about “unneeded" change to the code base

    * PETSc - small teams, 1-5+ people that can afford to be a bit more adventurous and are often constantly refactoring their own code base

   Thus we have developed different techniques for issues such as back-ward compatibility and reproducibility. We have each developed approaches that are most in line with our perception of what our users need.  For example, our time line for change is different, for example in PETSc we think supporting an old API (that has since been updated) for a year is long enough for our users to “catch up”. 

    Now DOE ASCR would like us to also do:

    C) insure that several groups doing A and B each provide something that can be used TOGETHER by again "a variety of scientists/engineers on long term projects with very varying software skills and perverse predilections”.

     Given enough money we could certainly do C, but could we continue to do A within whatever strictures C induces? Or will doing C have to cause delays in A or be almost separate projects from A? 

     I personally think that the reason DOE ASCR HPC software libraries are fairly good at particular things is because DOE ASCR has taken a largely hands off approach and allowed each group to experiment with a variety of approaches and not imposed a one-size-fits-all model of software development on us. I would like us to come up with something that accomplishes A, B, and C but does not impose a one-size-fits-all model because I believe that as soon as the one-size-fits-all model is in place A goes out the window.

  Barry




On Nov 25, 2013, at 5:04 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> Lois Curfman McInnes <curfman at mcs.anl.gov> writes:
>> The recent discussions about concrete issues in the combined use of
>> PETSc and Trilinos are indeed a valuable exchange of information ---
>> useful for at a practical level for existing apps and future plans.
>> However, tackling current interoperability challenges in existing
>> codes and other near-term issues is not ASCR's priority in this
>> particular assignment (though of course those issues inform the vision
>> -- and we might want to pursue that to some extent as a separate
>> activity outside the scope of the longer-term vision project).
> 
> I don't understand how one can define a long-term vision without
> ensuring that it addresses the present-day challenges.
> 
> How does a document engage the community?  How about outlining the
> things that we (PETSc, Trilinos, and other library developers) could do
> to improve interoperability, the pros and cons from the application
> developers' perspective, and a rough estimate of the cost for us to
> maintain.  Then applications could say something about which of these
> strategies they think are important, and Thomas can make an informed
> decision about allocating funding.
> _______________________________________________
> Petsc-trilinos-discussion mailing list
> Petsc-trilinos-discussion at lists.mcs.anl.gov
> https://lists.mcs.anl.gov/mailman/listinfo/petsc-trilinos-discussion