STK: snapshot does not import header

[lucbv]

Bug Report

The latest STK snapshot leads to failures in PR #14658 , @trilinos/stk @alanw0

Description

This build fails to build stk_util_doc_test with the following error:

/home/runner/_work/Trilinos/Trilinos/packages/stk/stk_doc_tests/stk_util/VersionHowTo.cpp:44:10: fatal error: Ioss_Version.h: No such file or directory
   44 | #include <Ioss_Version.h>
      |          ^~~~~~~~~~~~~~~~
compilation terminated.

Surprisingly that test was built in the STK snapshot PR #14651 so the build directory must have been dirty and already included the header file.
Additionally the gcc/14 build in the snapshot PR only tested 16 unit-tests, that looks pretty wrong to me! @sebrowne

Steps to Reproduce

1. SHA1: [insert here]
2. Configure script: [attach here]
3. Configure log: [attach here]
4. Build log: [attach here]
5. Input deck: [attach here]
6. Do this.
7. Do that.
8. Shake fist angrily at computer.
9. Run log: [attach here]

[alanw0]

@lucbv I'll fix this asap. I don't think the Ioss_Version.h header is in the build directory, it should be in the source directories for seacas. I may have a problem with the library dependencies for that stk_util_doc_test.

[alanw0]

Oh it looks like your failed build is using the combination where Seacas/Ioss is on, but MPI is off. I don't think I've built with that combination before, I may have wrong cmake stuff.

[jhux2]

Oh it looks like your failed build is using the combination where Seacas/Ioss is on, but MPI is off. I don't think I've built with that combination before, I may have wrong cmake stuff.

The AT should in theory have enabled that combination during testing of the STK snapshot PR, caught the error, and flagged the PR as not mergable.

[alanw0]

My attempted fix has merged into develop. Hopefully it's good...

[sebrowne]

I'm not sure what went wrong here. The test in question was built and did pass in that configuration as part of #14651 (see https://sems-cdash-son.sandia.gov/cdash/viewTest.php?onlypassed&buildid=904499). No idea why it worked in that iteration but not for later testing. Will try to run this to ground.

[sebrowne]

Okay, I'm getting somewhere (slowly). The PR that introduced the error did NOT enable SEACASIoss (which makes sense, it's not declared as an upstream dependency of stk_doc_tests in Trilinos). Immediate fix should include modifying packages/stk/stk_doc_tests/cmake/Dependencies.cmake

The PR that exposed the error DID turn it on, but it did so because the package-identifier-script decided to build ALL packages (not positive why at first look).

Even if we ignore the second thing (where I'm not sure why ALL_PACKAGES got enabled), I think this type of failure is inherent in our desire to restrict packages to only test that which has changed (and things downstream). If the dependency declarations in STK are incorrect, but there IS code that will respond to CMake-variable-guarded IFDEFs in STK, then that inconsistency will only ever be exposed by chance (usually by a build that turns on all packages). I think this is an appropriate and acceptable risk, seeing how often (rarely) it bites Trilinos. If we want to be safe from it, the best way is to build and test all Trilinos packages as part of a monolithic software product.

[alanw0]

Thanks for looking into this @sebrowne . In this case our stk_doc_tests executable was getting its SEACASIoss dependency indirectly through STKIO. For that build, STKIO was off because MPI was off, so then stk_doc_tests didn't get the include-path for the seacas header.

In general, I would say the biggest headache with the integration of stk into Trilinos is the fact that the Sierra builds for CI and nightly testing don't exercise stk's tribits/cmake support. So that's the most common source of errors when we update stk into Trilinos. No easy fix for that. Sierra's ongoing migration to spack/cmake still doesn't use tribits, so there will still be a testing hole there...

[jhux2]

@sebrowne Thank you for investigating this.

[lucbv]

This builds fine in my PR rebased on develop so I would say from the STK code point of view this works well for me.

Regarding the tribits integration if there are features not needed in Sierra maybe they should not exist in Trilinos either? Does STK build as a monolithic code in Sierra without ideas of subpackages?

[alanw0]

@lucbv Sierra builds STK as a monolith in the sense that it builds every sub-directory of stk, it never disables anything. But it does still build the separate stk libraries (lib*.a) separately.
But other applications, such as SPARC, get stk through Trilinos, and they get value from only building certain subpackages. For example they use stk_search and stk_transfer but they don't use stk_mesh. So the subpackage structure is necessary for them.