Address issues with the TriBITS update from PR #11380

[bartlettroscoe]

Description

There ware some possible errors caused by the recent snapshot of TriBITS into Trilinos from PR #11380. One definite case was a change in the behavior for disabling a TPL and having that disable downstream TPLs (which broke Albany Trilinos configures where HDF5 was explicitly disabled by they wanted Netcdf enabled, see #11426).

There may be other problems as well.

The revert PR #11428 was created and merged which reverted the merge of PR #11380.

Tasks

• Update TriBITS to make TPL dependencies optional to address Does NetCDF in Trilinos now require HDF5? #11426 (see Updated TriBITS is disabling downstream TPLs TriBITSPub/TriBITS#557 and Make TPL-to-TPL dependencies optional (#557) TriBITSPub/TriBITS#558)
• Bring back support for Trilinos_ASSERT_MISSING_PACKAGES and properly deprecate it with a deprecation warning to address below and Does NetCDF in Trilinos now require HDF5? #11426 (comment) (see Make TPL-to-TPL dependencies optional (#557) TriBITSPub/TriBITS#558)
• Create new Trilinos branch 'tribits-snapshot-2022-12-12-again' that starts with a revert of the revert commit from PR Revert "TriBITS Snapshot 2022-12-12 working toward TriBITSPub/TriBITS#63" #11428
• Update TriBITS snapshot and merge into branch 'tribits-snapshot-2022-12-12-again'
• Post new PR for 'tribits-snapshot-2022-12-12-again' ... See Bring back TriBITS snapshot from PR #11380 and address issues (#11429) #11458
• Ask Albany and Nalu developers to test branch 'tribits-snapshot-2022-12-12-again' if they want
• Merge PR Bring back TriBITS snapshot from PR #11380 and address issues (#11429) #11458
• Try to reproduce and address MueLu, Xpetra, Thyra: HAVE_MUELU_THYRA does not enable when Thyra is enabled by another package #11425
• Verify that no new errors are reported by customers

[rppawlo]

EMPIRE was also seeing a configure failure similar to what @spdomin noted in #11426 with the tribits push from last week:

02:06:42  Setting up major user options ...
02:06:42  
02:06:42  CMake Error at cmake/tribits/core/package_arch/TribitsGlobalMacros.cmake:744 (message):
02:06:42    Error, Trilinos_ASSERT_MISSING_PACKAGES= 'ON' is set and is no longer
02:06:42    supported! Please set Trilinos_ASSERT_DEFINED_DEPENDENCIES=FATAL_ERROR
02:06:42    instead!
02:06:42  Call Stack (most recent call first):
02:06:42    cmake/tribits/core/package_arch/TribitsProjectImpl.cmake:130 (tribits_define_global_options_and_define_extra_repos)
02:06:42    cmake/tribits/core/package_arch/TribitsProject.cmake:92 (tribits_project_impl)
02:06:42    CMakeLists.txt:144 (TRIBITS_PROJECT)
02:06:42  
02:06:42  
02:06:42  -- Configuring incomplete, errors occurred!

[bartlettroscoe]

@rppawlo, @spdomin,

Responding to above and #11426 (comment) for fatal error on setting Trilinos_ASSERT_MISSING_PACKAGES ...

This change was highlighted in the changelog here

I could bring back support for Trilinos_ASSERT_MISSING_PACKAGES and properly deprecate it with a deprecation warning. That would smooth upgrades. I will look into that. (But then you have to check for cases where the old option and new option are both set and perhaps to inconsistent values.)

[rppawlo]

@bartlettroscoe - you don't have to properly deprecate for empire. empire is not setting that flag anywhere. It is being set by the atdm build scripts and needs to be fixed in trilinos:

rppawlo@s1057859 cmake % git grep ASSERT_MISSING
std/atdm/ATDMDevEnvSettings.cmake:ATDM_SET_CACHE(Trilinos_ASSERT_MISSING_PACKAGES ON CACHE BOOL)

[bartlettroscoe]

It is being set by the atdm build scripts and needs to be fixed in trilinos

@rppawlo, that is good to know. (Not sure how that setting got in there.)

[bartlettroscoe]

@spdomin, what configuration of Trilinos is producing the Trilinos_ASSERT_MISSING_PACKAGES error you reported in #11426 (comment)? Is this the Spack configuration?

[spdomin]

@spdomin, what configuration of Trilinos is producing the Trilinos_ASSERT_MISSING_PACKAGES error you reported in #11426 (comment)? Is this the Spack configuration?

@bartlettroscoe, no, this was my standard Trilinos config using the config file noted in this push: NaluCFD/Nalu@c4f24d4

See line 83 build/do-configTrilinos_release

[bartlettroscoe]

@spdomin, are you okay with the solution to just remove -D Trilinos_ASSERT_MISSING_PACKAGES=OFF from you configure script in NaluCFD/Nalu@c4f24d4?

[bartlettroscoe]

@rppawlo, @spdomin, @ikalash, @GrahamBenHarper, @lxmota,

Do any of you want to try to test against the update of TriBITS and Trilinos in the new PR #11458 with Nalu or Albany before this PR gets merged? The issues discovered in the previous TriBITS snapshot merge from PR #11380 should be addressed as listed in above. I will run some ATDM Trilinos builds before I try to merge but I was not going to test against APP codes. (But if there are easy up-to-date instructions on running a smoke test against a branch of Trilinos and the APP's suite against Trilinos 'develop' is clean, then I am willing to give it a try.)

[bartlettroscoe]

@rppawlo, @spdomin, @ikalash, @GrahamBenHarper, @lxmota,

FYI: PR #11458 just merged. Please comment here if you see any problems with your integration testing of Trilinos 'develop' with you codes.

[GrahamBenHarper]

@bartlettroscoe it looks like the TriBITS configure still doesn't pick up the MueLu/Xpetra dependency on Thyra properly for #11425. I'm letting it run a clean build again, but I suspect since the list of enabled packages has not changed and the build logic has not changed, the result is the same. Interestingly, it looks like it sets the Xpetra dependencies twice in a row.

Edit: the build indeed failed in the same place

-- Setting ThyraCore_ENABLE_TeuchosCore=ON since Trilinos_ENABLE_ThyraCore=ON AND Trilinos_ENABLE_TeuchosCore=ON
-- Setting ThyraCore_ENABLE_TeuchosParameterList=ON since Trilinos_ENABLE_ThyraCore=ON AND Trilinos_ENABLE_TeuchosParameterList=ON
-- Setting ThyraCore_ENABLE_TeuchosComm=ON since Trilinos_ENABLE_ThyraCore=ON AND Trilinos_ENABLE_TeuchosComm=ON
-- Setting ThyraCore_ENABLE_TeuchosNumerics=ON since Trilinos_ENABLE_ThyraCore=ON AND Trilinos_ENABLE_TeuchosNumerics=ON
-- Setting ThyraCore_ENABLE_RTOp=ON since Trilinos_ENABLE_ThyraCore=ON AND Trilinos_ENABLE_RTOp=ON
-- Setting ThyraTpetraAdapters_ENABLE_ThyraCore=ON since Trilinos_ENABLE_ThyraTpetraAdapters=ON AND Trilinos_ENABLE_ThyraCore=ON
-- Setting ThyraTpetraAdapters_ENABLE_Tpetra=ON since Trilinos_ENABLE_ThyraTpetraAdapters=ON AND Trilinos_ENABLE_Tpetra=ON
-- Setting Xpetra_ENABLE_Teuchos=ON since Trilinos_ENABLE_Xpetra=ON AND Trilinos_ENABLE_Teuchos=ON
-- Setting Xpetra_ENABLE_KokkosCore=ON since Trilinos_ENABLE_Xpetra=ON AND Trilinos_ENABLE_KokkosCore=ON
-- Setting Xpetra_ENABLE_KokkosContainers=ON since Trilinos_ENABLE_Xpetra=ON AND Trilinos_ENABLE_KokkosContainers=ON
-- Setting Xpetra_ENABLE_Tpetra=ON since Trilinos_ENABLE_Xpetra=ON AND Trilinos_ENABLE_Tpetra=ON
-- Setting Xpetra_ENABLE_KokkosKernels=ON since Trilinos_ENABLE_Xpetra=ON AND Trilinos_ENABLE_KokkosKernels=ON
-- NOT setting Xpetra_ENABLE_Thyra=ON since Thyra is NOT enabled at this point!
-- Setting Xpetra_ENABLE_BLAS=ON since Trilinos_ENABLE_Xpetra=ON AND TPL_ENABLE_BLAS=ON
-- Setting Xpetra_ENABLE_LAPACK=ON since Trilinos_ENABLE_Xpetra=ON AND TPL_ENABLE_LAPACK=ON
-- NOTE: Xpetra_ENABLE_Tpetra=ON is already set!
-- NOTE: Xpetra_ENABLE_KokkosKernels=ON is already set!
-- NOT setting Xpetra_ENABLE_Thyra=ON since Thyra is NOT enabled at this point!
...
-- NOT setting MueLu_ENABLE_Thyra=ON since Thyra is NOT enabled at this point!
-- Setting MueLu_ENABLE_ThyraTpetraAdapters=ON since Trilinos_ENABLE_MueLu=ON AND Trilinos_ENABLE_ThyraTpetraAdapters=ON

[bartlettroscoe]

@bartlettroscoe it looks like the TriBITS configure still doesn't pick up the MueLu/Xpetra dependency on Thyra properly for #11425.

Okay, let me give it another try to reproduce this failure.

[github-actions]

This issue has had no activity for 365 days and is marked for closure. It will be closed after an additional 30 days of inactivity.
If you would like to keep this issue open please add a comment and/or remove the MARKED_FOR_CLOSURE label.
If this issue should be kept open even with no activity beyond the time limits you can add the label DO_NOT_AUTOCLOSE.
If it is ok for this issue to be closed, feel free to go ahead and close it. Please do not add any comments or change any labels or otherwise touch this issue unless your intention is to reset the inactivity counter for an additional year.

[github-actions]

This issue was closed due to inactivity for 395 days.