if {{[info exists env(NERSC_HOST)]}} {{
set desi_root /global/cfs/cdirs/desi
setenv DESI_ROOT $desi_root
setenv DESI_MOCKS $desi_root/mocks
setenv DESI_SPECTRO_DATA $desi_root/spectro/data
...
}}
and then other desi product modules use $DESI_ROOT, but AFAIK not the other variables.
However, lmod (used on Perlmutter) no longer supports TCL-format module files having environment variables defined in one module propagating to another; see https://github.com/TACC/Lmod/issues/535 and https://lmod.readthedocs.io/en/latest/095_tcl2lua.html, so even this won't work. They present this as a feature rather than a bug, but it sounds like intermediate "too hard to implement properly so we won't".
I think we should switch to defining $DESI_ROOT external to desitree (e.g. in desimodules/desi_environment.[c]sh), and then desitree can use it as a "peer module" to the others rather than a way of propagating the environment from one module file to another. This has the benefit of making desitree site-agnostic, basing everything on a common externally defined $DESI_ROOT.
This requires coordination with both desitree and desimodules, and on the desimodules side I think the logic should be:
if $DESI_ROOT is defined:
use that
elif $NERSC_HOST is defined:
set DESI_ROOT=/global/cfs/cdirs/desi
else:
complain
Credit to @weaverba137 for debugging the original issue.
Currently desitree only works at NERSC due to
and then other desi product modules use $DESI_ROOT, but AFAIK not the other variables.
However, lmod (used on Perlmutter) no longer supports TCL-format module files having environment variables defined in one module propagating to another; see https://github.com/TACC/Lmod/issues/535 and https://lmod.readthedocs.io/en/latest/095_tcl2lua.html, so even this won't work. They present this as a feature rather than a bug, but it sounds like intermediate "too hard to implement properly so we won't".
I think we should switch to defining $DESI_ROOT external to desitree (e.g. in desimodules/desi_environment.[c]sh), and then desitree can use it as a "peer module" to the others rather than a way of propagating the environment from one module file to another. This has the benefit of making desitree site-agnostic, basing everything on a common externally defined $DESI_ROOT.
This requires coordination with both desitree and desimodules, and on the desimodules side I think the logic should be:
Credit to @weaverba137 for debugging the original issue.