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

[Barry Smith]

   A few of the issues we all know about, but I’m including here for completeness so text from this discussion can go directly into a document. 

   Customer base Languages:   

      * classic Fortran  — people who cling to F77 plus perhaps a few features from later versions but adopted very conservatively

      * modern Fortran — people who dive into features of later Fortran standards

      * C   —  (some issues with different versions)

      * C++  (some issues with people who adopted older or more modern standards)

      * CUDA, OpenCL, others?

      * Want to combine code from several “applications” each of which may have its own strange language standards

  Customer base Portability:

       * So long as their code builds on a couple of big machines they use they don’t care about portability

       * Want their codes to also work on Windows :-( 

   Customer base build-ability: closely related to Portability 

       * Always have THE code guru build their application so don’t care how impossible it is build and in fact brag about how difficult it is to build

       * Want more than three people in the world to be able to build their application without hand-holding

   Customer base competence: Sadly often and issue

   Finally another issue is that many customers have trouble working closely with one service provide (say petsc-maint) though they can manage; but they just cannot deal with interacting with two or three service providers (especially when they problems they face are foggy), say also the Visit folks, Trilinos and SuperLU.  They react by pulling back and not using all the packages they can and thus end up being much less functional and productive than they can be. 


   Side note: In our experience it is frustrating to work with people who don’t care about portability or build-ability because it is difficult to provide help in the abstract if the helper cannot build and run the code to determine problems.  When someone says “I’m having trouble building X, Y, and Z together" that is not an abstract problem with an abstract solution, it is a technical problem with a technical solution and finding technical solutions requires detailed technical information about that particular situation.
      
  Barry


On Nov 26, 2013, at 8:31 AM, Lois Curfman McInnes <curfman at mcs.anl.gov> wrote:

> 
> ASCR has stated that an outcome of the SWP4XS workshop 
>       http://www.orau.gov/swproductivity2014
> will be a report that summarizes challenges/opportunities in extreme-scale scientific software productivity and recommends short-term and long-term research directions. 
> 
> My understanding of what ASCR wants from our current small project is a document on ideas for addressing a subset of these challenges:  vision for next-generation interoperable HPC software -- not covering everything in software productivity and not providing immediate/short-term fixes for current codes.
> 
> There is a distinction between what ASCR wants as a deliverable for this current project (recognizing limited time/resources/scope), and what at least some of ASCR wants from us + the broader community over the longer term.   In particular, ASCR is not asking us to engage the broader community in this little project -- though they want that over the longer term.  And ASCR is not asking us to fix current interoperability issues within the scope of this little project.  
> 
> As Jed said, just writing a document does not engage the community in working toward long-term solutions.  But a document could be a starting point for a broader discussion.   And identifying current interoperability challenges + ideas for solutions is an important part of this.
> 
> I concur with Barry's point about the importance not imposing a 1-size-fits-all model so that the diversity of approaches can continue to thrive.
> 
> Lois
> 
> On Nov 25, 2013, at 8:15 PM, "Bartlett, Roscoe A." <bartlettra at ornl.gov> wrote:
> 
>> This sounds a lot like the focus of the SWP4XS workshop taking place in January.  How is the goal for this document not basically the scope of the workshop?  I would guess the workshop will have a broader scope however.
>>  
>> -Ross
>>  
>> From: petsc-trilinos-discussion-bounces at lists.mcs.anl.gov [mailto:petsc-trilinos-discussion-bounces at lists.mcs.anl.gov] On Behalf Of Lois Curfman McInnes
>> Sent: Monday, November 25, 2013 5:44 PM
>> To: Heroux, Michael A
>> Cc: Pawlowski, Roger P; petsc-trilinos-discussion at lists.mcs.anl.gov
>> Subject: Re: [Petsc-trilinos-discussion] Status update, summary remarks
>>  
>>  
>> My take-aways from today's chat with Thomas:
>>  
>> The main deliverable that ASCR wants from us in this current project is a (short) document that provides a long-term vision for interoperable use of a variety of high-performance scientific software.   ASCR's primary concern is for us to develop a document that could be used as a starting point for engaging the broader DOE/HPC community in determining approach that would enable the combined use of lots of different HPC software over the long term.  To get started, Mike and I will iterate with Thomas to come up with a set of basic requirements/principles at a sufficiently abstract level to help nail down the scope more specifically.  And then we can further evolve this and all contribute to fleshing out long-term vision ideas.
>>  
>> 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).
>>  
>> Best,
>> Lois
>>  
>> On Nov 25, 2013, at 11:43 AM, "Heroux, Michael A" <maherou at sandia.gov> wrote:
>> 
>> 
>> Lois McInnes and I are talking with Thomas Ndousse-Fetter today to see if
>> we can get a better sense of what he wants from these discussions.  He has
>> some app teams (unnamed) who are apparently driving the request for easier
>> access to DOE library capabilities.  Lois and I are arguing that we need
>> direct access to these people in order to make sure we are focusing on the
>> right issues.
>>  
> 
> _______________________________________________
> Petsc-trilinos-discussion mailing list
> Petsc-trilinos-discussion at lists.mcs.anl.gov
> https://lists.mcs.anl.gov/mailman/listinfo/petsc-trilinos-discussion