[Petsc-trilinos-discussion] Scope and requirements

[Barry Smith]

On Nov 22, 2013, at 12:32 PM, Bartlett, Roscoe A. <bartlettra at ornl.gov> wrote:

>>> 3) Before Hydra-TH get coupled into any other code, we need to remove
>>> the direct insertion of ML support in the PETSc lib and defer it to
>>> Hydra-TH or some other downstream lib that uses dependency injection
>>> to overcome the link order issue.
>> 
>> What is the "link order issue"?  AFAIK, ML never depends on PETSc, so
>> there is no dependency loop.  In any case, registering the ML plugin
>> later is a pure build system issue (no source code changes).
> 
> [Bartlett, Roscoe A.] 
> 
> ML gets built along with the rest of Trilinos as a TriBITS package in VERA where PETSc is treated as a pre-built static TPL.  This is done because changes are being made to Trilinos to drive CASL work but not for PETSc.  

    Building PETSc to use ML, obviously, requires ML to be built before PETSc since PETSc configure needs to link against the ML to verify it is correct and PETSc make needs to locate the ML includes to compile the ML wrapper. 

   There are two situations:

1) If PETSc depends on ML/Trilinos but Trilinos does not depend on PETSc then one simply needs to install ML/Trilinos first. Note that so long as you don’t change the ML interface you can interactively be updating the Trilinos build (as you add features to support the application) after PETSc has been installed.

2) PETSc depends on Trilinos and Trilinos depends on PETSc. This could be tough and we should sort this out, but we need enough flexibility to do this (as Jed mentioned we use to do this Prometheus, by basically having stages where each package builds its next set of parts before passing control to the other package for it to build its next set of parts).

> Building PETSc downstream from Trilinos would mean wrapping PETSc as a TriBITS package and we don't want to go there unless we are forced to do so.\
>  There are a lot of complexities and regrets when you have to do this (as our experience with MOOSE is showing).

   I am assuming in this case it is just 1. There must be something seriously wrong with the TriBITS system if it is so difficult to just tell the system that the PETSc build has an initial build dependence on the Trilinos build but that updates to Trilinos don’t require a rebuild of PETSc. In fact even if you don’t have a way to tell the system that updates to Trilinos don’t require a rebuild of PETSc that is no particular big deal, the system would just reconfigure and rebuild PETSc unnecessarily, which should take no more than 3 or 4 minutes on a laptop class machine, and this could be easily short-circuited out.

   I think it is unrealistic to expect that everyone will adopt your one true dependency system for building packages, instead we need to come up with a model where each packages dependency system can interact with others to generate the build of everything. This is important and we need to figure it out. 

   Barry

> 
> -Ross
> 
>