Create our own `modulefile`?
Closed this issue · 3 comments
Right now, we are using . ./mfc.sh load
to set the environment on a specific computer, though it strikes me that modulefile
s are made to do exactly this. Does it somehow make more sense to have our own set of maintained module files that we can load in via module use MFC/toolchain/modulefiles/<computer name>
, which will provide module load MFC
as a viable command, auto-loading the correct modules, and setting environment variables and paths.
It is unclear to me that, if implemented, this would be any better or easier than what we currently have (other than being less "MFC idiosyncratic," but perhaps also less flexible since we are beholden to the capability of lmod
). Wondering what you all think... @henryleberre?
Some codes have these built into the system config., e.g.:
[I]br011: /opt/packages $ module show openfoam
----------------------------------------------------------------------------------------------------
/opt/modulefiles/production/openfoam/6.0:
----------------------------------------------------------------------------------------------------
whatis("openfoam/6.0.0 ")
conflict("openfoam")
setenv("FOAM_VERSION","6.0.0")
setenv("FOAM_DIR","OpenFOAM-6")
setenv("FOAM_INST_DIR","/opt/packages/openfoam/6.0.0/OpenFOAM-6")
help([[OpenFOAM 6.0.0
------------------------
Load the following module first
openmpi/3.1.6-gcc8.3.1
]])
I wrote a small thesis and then realized that I misunderstood what you trying to achieve.. To summarize, if we wanted to module load mfc
and enable users execute things like mfc run case.py -n 4
, we would:
mfc() { cd "/path/to/system/mfc/clone" && ./mfc.sh $@ }
To actually address this issue, you make a very good point. We would expect users to:
module use toolchain/modulefiles/<computer name>/
module load mfc/<cpu or gpu>
where toolchain/modulefiles/<computer name>/
is a directory. I see very little downside to moving to this.
I guess the downside is that the system would have to keep up with current MFC builds (seems impossible) -- or we would have to put MFC in the user's local dir rather than the system root dir.
The idea of being able to do
mfc() { cd "/path/to/system/mfc/clone" && ./mfc.sh $@ }
does seem attractive, since we could also automatically add tab completion and some other nice native features.
closed due to inactivity