[WIP] Add update and rebuild cardinal script - #143
Conversation
Add a SALAMANDER dependency build script, modeled on MOOSE's update_and_rebuild_libmesh.sh, that compiles Cardinal and its contrib libraries (OpenMC, MOAB, DagMC) without producing the cardinal-opt executable by overriding BUILD_EXEC=no. The script fetches only the contrib submodules SALAMANDER actually uses (skipping NekRS, Double-Down, Embree, and nek_ci) rather than calling Cardinal's get-dependencies.sh, defaults ENABLE_NEK=false and ENABLE_DAGMC=yes to match SALAMANDER's linking, and builds against SALAMANDER's MOOSE via MOOSE_DIR (respecting a developer-set value, then the submodule, then an adjacent checkout, and failing if none is found). It also supports --skip-submodule-update, --quiet-build, and --help. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add an opt-in --download-cross-sections flag that fetches the OpenMC ENDF/B-VII.1 cross section data by reusing Cardinal's idempotent download-openmc-cross-sections.sh. The data defaults to <parent-of-salamander>/cross_sections, placing it outside the SALAMANDER repository so it is not disturbed by git operations such as 'git clean', and the location is overridable via the CROSS_SECTIONS_DIR environment variable. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
cticenhour
changed the title
|
I’m a bit confused here. My original comment was on making an update and rebuild openmc script, in cardinal. How’d we get here? We shouldn’t need an update and rebuild Cardinal script. Cardinal should be built using the standard moose makefiles, the only difference being that its optional dependencies will be built with scripts. At least that was my original thought. |
|
Because I wholly misunderstood what you were talking about - it wasn't incredibly clear, as we've griped about the custom changes needed to get Cardinal built self-consistently which then causes brittle breakages over time. That's the context I came to your words with. Anyway, this actually worked quite well. I am having an issue with running the OpenMC test on Mac (after applying the current workaround for fmt), but Linux works quite well with this configuration. |
|
One more thing on my mind - even if we sorted out Cardinal dependencies and their own build process, I would still want to streamline dependency download on our side anyway, with some sort of script (denoting exactly what salamander currently supports). I think the previous makefile focused method made some of that harder to parse, and working with a script does reduce the number of install steps for salamander regardless. I don't necessarily mind shifting this around some more, but I think I'll still want a script for dependency management at the cardinal level that sits in scripts in salamander and clearly sets up what we want to download and build. Much smaller scope than this obviously. |
|
I also admit that I just wanted to see how it would work to do it this way 😄 |
|
@aprilnovak, I'm also interested in your take here. |
cticenhour
added
the
PR: AI assisted
3 participants
Closes #142
A bit more to do here before it is ready:
The latter doesn't seem to fail on a moose-dev apptainer environment on rod, so I will eventually need to kick-off testing here on Mac arm to get a second opinion. Before I can do that, I need to update some recipes. Will do that when I feel like this is mature enough to break app testing for try it.