Open johnomotani opened 2 years ago
There's now an 'archer' branch.
It could work to have main
contain just a README, and all the actual scripts, etc. in machine-specific branches?
I'm undecided! Having a flat structure with one branch would make things more discoverable, but having a pinned version of BOUT-dev as a submodule in each branch is quite appealing.
Also, I wonder if we should start trying to use CMake presets for common build configurations, and toolchains for machine-specific configurations.
I think at least the LLNL config scripts in this repo also encompass setting up the third party libraries we use, which are not really what presets/toolchains are for (as far as I understand things). Those could be set up with a "super-project" CMakeLists.txt
, which would also make propagating the dependencies much easier.
LLNL config scripts in this repo also encompass setting up the third party libraries we use
For the archer config also, I'm downloading/compiling PETSc (because I couldn't get the PETSc in ARCHER2's module to link correctly).
I had to set up BOUT++ on a new laptop, so there's now a generic-4.4
branch too, which aims to get BOUT++ and dependencies compiled on a standard Linux machine (tested on Linux Mint 20.2) with just a couple of commands (very similar to the archer
setup).
There is now also a marconi
branch, with configuration for gnu compilers with openmpi, intelmpi (2020 version), or intelmpi2018. I did not manage to get Intel compilers working (see #3).
Just to note, whatever we decide to do to resolve this, we should update the README.md
on main
to document it, as that is what most users will see as the front-page of BOUT-configs.
I would prefer a single branch, maybe with a top level machines
directory to keep it from getting cluttered. That would make PR, for instance, easier to manage.
Definitely advantages to having everything in a single branch.
If we go the single-branch route, how are we managing the version of BOUT-dev that goes with each config?
next
too (maybe in a separate branch?) I'm not so sure it's good to have a shared version of BOUT-dev - there's a significant possibility of updates to next
breaking things, so you'd want the BOUT-configs maintainer for each machine to check that the version compiles and passes tests, and to tweak the configs if necessary. That'd probably be annoying to coordinate across several machines (how would we decide when to move to a new version of next
?). If the different machines had separate branches, we avoid that issue as the maintainer for each machine decides independently when to update (when there's demand for it).git pull; ./<build script>
.
Maybe the best of both worlds would be to have the main
branch have a submodule with the latest release of BOUT-dev, and configs for next
be in (machine-specific) branches which can be merged when BOUT-dev/next
becomes the new BOUT-dev/master
?
Is this issue relevant anymore?
We've stayed so far with 'each machine is a separate branch', but I don't think that was an actual decision...
We decided on a per-folder structure instead of per-branch. We are hooking into spack now for building a reproducible environment across machines. Are you still working on marconi? Can you volunteer to create a PR for a marconi config modeled after the perlmutter one?
I'm planning to set up BOUT++ on ARCHER2 for a few users, am thinking it would be nice to add the config(s) here. Wondering how it's best to organise all the different configs.
One possibility that comes to mind would be to switch to having a different branch for each machine (or possibly for each group of machines). Pros:
Any thoughts, suggestions, other alternatives?