Update Minimum System Requirements Libraries Documentation

[robtclay]

Motivation

Currently the Minimum System Requirements are listed here:
https://mooseframework.inl.gov/sqa/minimum_requirements.html
framework/doc/content/sqa/minimum_requirements.md

This includes a maximum version for multiple different libraries including GCC and Python. This page likely hasn't been updated in some time to reflect compatibility with more recent updates. GCC and Python both have multiple new versions available and some clusters are OS upgrades that force newer libraries.

The documentation should be updated to include any newer libraries that are compatible with MOOSE.

Design

The work for this varies depending on whether or not these new versions have been tested or not.

If not, then there would need to be checks to make sure MOOSE will work with newer libraries.

If MOOSE is known to work with newer libraries, then this is just an update to the documentation here:
framework/doc/content/sqa/minimum_requirements.md

Impact

Show that MOOSE is able to run with more updated libraries. This will make potential updates to cluster installs go smoother for users.

[milljm]

What you suggest may defeat the purpose of 'minimums' list of software, required to run MOOSE. e.g, I don't think it would be possible to maintain a 'bleeding-edge' page (it would always be failing our testing suite, a thus we shouldn't recommend it).

The higher version numbers you see, are versions 90% of our CI testing is performed with (https://civet.inl.gov). We are however, always bumping this (hah, or trying to: #22343). Its no small feat to bump the library stack. When we do, we definitely nudge the minimums a tad.

But, there is one mistake with this page though: Python. We certainly support Python 3.12, and it is the current default. I forgot to nudge this.

@loganharbour
I'll work with the PR I posted to fix the Python bits (we are moving to Python 3.10 - 3.13)

[robtclay]

I'm not really suggesting that we have the minimums reference the bleeding-edge software since I agree that wouldn't really be sustainable or in the spirit of a minimum list. I just think it might have been a few years since the last time those version numbers have been considered and so they're out of date.

GCC and Python were the main two that I was looking at in particular. You noticed that it was out of date for Python, but GCC 14.1 for example came out over a year ago and the minimum list still references 12.2.1 as the max version which came out nearly 3 years ago now. I know it can take a bit of time to test newer versions, especially with something complex like MOOSE. So this is more about checking to see if we've done any new testing at all that requires a documentation update, rather than suggesting an entirely new way of version control.

This came up because the cluster that I work on (Hipergator at University of Florida) is upgrading to RHEL-9 (which came out 3 years ago) and required that we switch over to GCC 14.2, Python 3.12, and OpenMpi 5.0.7. It looks like your commit also references the newer OpenMpi version. I'm not sure if it's specific to our cluster or not, but I wasn't able to load OpenMpi 5.0.7 and GCC 12.2.1 together since the newer OpenMpi only supports the newer GCC. Maybe that's just a way that the modules were created here, but probably worth checking if it hasn't been checked already.

I also think that if we're bumping up the minimums like you're referencing, it'd be good to look at the newer versions as well so that the min-max doesn't encompass an increasingly narrow range.

[milljm]

Maybe the wordage needs to change on that page. We don't have a "maximum" per say. Just versions that we can say to a very high degree works very well with MOOSE.

I am sure GCC 14.2 works. But I am also sure some tests are probably going to fail...

[loganharbour]

I'm glad to support this as well, it's been neglected. We can easily put together a list of the tested versions that we keep up to date with.

I'm not sure if it's specific to our cluster or not, but I wasn't able to load OpenMpi 5.0.7 and GCC 12.2.1 together since the newer OpenMpi only supports the newer GCC

This is an aside - but by this you mean your sys admins haven't built it right?

[milljm]

Note to self: while on Linux, Conda only supports GCC 13.x with MPICH. Though with OpenMPI I see support to GCC 15.1.

[robtclay]

I am sure GCC 14.2 works. But I am also sure some tests are probably going to fail...

From our tests so far it seems like everything works so far with no test errors, but I have no idea if it will continue that way as things in MOOSE change.

I'm not sure if it's specific to our cluster or not, but I wasn't able to load OpenMpi 5.0.7 and GCC 12.2.1 together since the newer OpenMpi only supports the newer GCC

This is an aside - but by this you mean your sys admins haven't built it right?

It's a bit black box to me since I mostly just load the modules that they create, but we have openmpi/4.1.6 and openmpi/5.0.7 along with gcc/14.2.0 and gcc/12.2.0 available to us. In our system, it states that openmpi/5.0.7 requires gcc/14.2.0 to be loaded first and will error if not. Similarly, openmpi/4.1.6 requires gcc/12.2.0 or some other older gcc module that they have available. This basically just means in our system, the newer gcc and older openmpi aren't compatible and similarly older gcc and newer openmpi aren't either. Whether or not that's unique to our system or not, I'm not sure, so that's why I only included it as an aside.

[milljm]

(WIP) PR Minimum Requirements page: https://mooseframework.inl.gov/docs/PRs/30774/site/sqa/minimum_requirements.html

HAH... there is a strange formatting issue with 3.10 --> 3.1