Compadre: Add New Package to Trilinos

[jmgate]

This issue is to track the insertion of Compadre into Trilinos, and is a part of the overall issue Compadre#164.

CC: @mperego, @kuberry

[jmgate]

@bartlettroscoe, I'm trying to figure out what all is needed if I have a package that currently builds with CMake that we want to snapshot into Trilinos. Compadre will continue to be developed in its own repository. When we snapshot it into Trilinos, we'll need to omit two directories from its source (Kokkos, plus another one). It should build via its own CMake build system when built on its own, but via TriBITS when built as part of Trilinos. It currently builds Kokkos for you before building itself against it.

I'm thinking we need something along the lines of

• How to insert a package into an upstream repo Sounds like this isn't the right thing to do.
• How to put a TriBITS and raw CMake build system side by side

for modifications to the build system, plus

• snapshot-dir.py

to snapshot it into Trilinos. Am I missing anything here? Do you have a guess as to how long it would take to integrate a package like this into Trilinos?

[bartlettroscoe]

Do you have a guess as to how long it would take to integrate a package like this into Trilinos?

@jmgate, how long integrating in an existing package into Trilinos depends on several factors.

Note that you would not both snapshot the package source into the Trilinos git repo and also deal with it as an inserted package. You would do either one or the other. The choice depends on the controlling use cases. But it sounds like your use case is very similar to SEACAS and therefore if you set up Compadre like SEACAS, the version control parts will be easy.

We should likely discuss this briefly offline over Skype.

[jmgate]

It sounds like "inserted package" probably means something in TriBITS I didn't realize. Yes, I think we're talking about snapshotting it in similar to SEACAS, KOKKOS, etc. I'll see if I can find a time for a quick Skype call.

[jmgate]

@rmmilewi, forgot to tag you on this earlier. Sorry about that.

[jmgate]

@trilinos/framework, I'm not sure what the current policies and procedures are for adding a new package to Trilinos. Can you please review this new package checklist and let me know if we can proceed?

[jmgate]

@trilinos/framework, if you're not the right folks to evaluate this, please let me know.

[mperego]

@jmgate I had already asked for approval for this package, both to product leads and Trilinos framework, and I got their approval

[mperego]

@jmgate I had already asked for approval for this package, both to product leads and Trilinos framework, and I got their approval

I also sent an email to Trlinos developers. So, please proceed.

[jwillenbring]

@bartlettroscoe Would this be a good first use case for the refactor that would make TPLs indistinguishable from packages? Then Compadre would not have to implement a second build system and it might give the effort a shot in the arm?

[bartlettroscoe]

Would this be a good first use case for the refactor that would make TPLs indistinguishable from packages? Then Compadre would not have to implement a second build system and it might give the effort a shot in the arm?

@jwillenbring, how would the refactorings/extensions in TriBITSPub/TriBITS#63 and TriBITSPub/TriBITS#299 help here? If you treat Compadre as a TPL w.r.t. Trilinos, someone else still has to build and install it. I think the goal here is to have Compadre built as part of the Trilinos CMake project and installed along with all of the other Trilinos packages.

[bartlettroscoe]

Just an FYI, but note that when #7241 got merged, it had the side-effect of enabling Compadre in all of the ATDM Trilinos builds. Therefore, those ran today and you can see how Compadre is doing on a number of different platforms in this query:

• https://testing-dev.sandia.gov/cdash/index.php?project=Trilinos&date=2020-04-27&filtercount=2&showfilters=1&filtercombine=and&field1=buildname&compare1=65&value1=Trilinos-atdm-&field2=subprojects&compare2=93&value2=Compadre

PR #7268 will disable Compadre in ATDM Trilinos testing going forward but I thought you might want to see what its portability looks like. (It looks to be failing to build in all of the CUDA builds as shown here).

[kuberry]

Just an FYI, but note that when #7241 got merged, it had the side-effect of enabling Compadre in all of the ATDM Trilinos builds. Therefore, those ran today and you can see how Compadre is doing on a number of different platforms in this query:

• https://testing-dev.sandia.gov/cdash/index.php?project=Trilinos&date=2020-04-27&filtercount=2&showfilters=1&filtercombine=and&field1=buildname&compare1=65&value1=Trilinos-atdm-&field2=subprojects&compare2=93&value2=Compadre

PR #7268 will disable Compadre in ATDM Trilinos testing going forward but I thought you might want to see what its portability looks like. (It looks to be failing to build in all of the CUDA builds as shown here).

Thanks for letting me know Ross. This is a result of those tests being run with TPL_ENABLE_CUDA set to ON, but with Compadre_USE_CUDA by default being set to OFF. I switched some CMake logic to resemble the suggestion you made in the original Compadre snapshot, and now these tests should pass if they were run again (no longer needing to set Compadre_USE_CUDA explicitly).

The fix is in PR #7271

[mperego]

@jmgate Have you guys checked if the Doxygen documentation builds correctly? I just tried to generate it but it looks empty.

[jmgate]

You know, I don't think we did anything about the Doxygen when we added Compadre to Trilinos. I can look into it, but it likely won't be till Monday.

[mperego]

Thanks. No rush. Paul is looking into it, so he will probably fix it.