Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More powerful modules implementation. #311

Open
DavidPCoster opened this issue Feb 25, 2025 · 1 comment
Open

More powerful modules implementation. #311

DavidPCoster opened this issue Feb 25, 2025 · 1 comment

Comments

@DavidPCoster
Copy link
Contributor

For my workflow which mostly uses intel compiled codes, I have one requiring the use of gfortran and a FOSS environment.

For the implementation section, I have

implementations:
rabbit:
modules: PURGE EB IMAS/3.42.0-2024.09-foss-2023b netCDF-Fortran/4.6.1-gompi-2023b INTERPOS/9.2.0-gfbf-2023b XMLlib/3.3.2-GCC-13.2.0 MUSCLE3/0.7.2-foss-2023b iWrap-plugins-MUSCLE3/0.4.0-foss-2023b iWrap/1.0.0-GCCcore-13.2.0
executable: ../../../../bin/time_and_resources
args: ../../../../IWRAP_ACTORS_foss/rabbit/bin/rabbit.exe

where I have created a new module "PURGE" which does "module purge", and then the list of modules that are required (replacing their intel equivalents).

What I would like is a cleaner way of handling this -- with a built-in purge, and the choice of using "module switch" rather than "module load".

Are others using the "modules" feature? Is there a simpler already existing way of doing what I want (e.g. shell wrapper to setup the environment before calling the code)?

@LourensVeen
Copy link
Contributor

The next version of MUSCLE3 will have different shell base environments available, and I think base_env: clean will do just what you want for this particular code, and then you can use base_env: manager for the rest and start the manager with the intel modules loaded.

This doesn't use module switch, so you'd have to explicitly load everything you need from scratch. I'm not sure that's such a bad idea though, because it makes everything more reliable and self-documenting.

The new version of MUSCLE3 is almost there. My last bit of real-world testing before releasing the new version uncovered a mistake in the code that hadn't showed up before because my fake cluster wasn't quite realistic enough. I've fixed that now as well as one more fix for the SDCC gen9 core numbering (numbering parts of CPUs turns out to be a very deep rabbit hole), but ran into an issue with Spack, which I've hopefully fixed. I just need to rebuild all the images and test again. I'm a bit under the weather but I'll try to get it out the door as quickly as possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants