Fix file path for Orion in module-setup

[MinsukJi-NOAA]

@BrianCurtis-NOAA reported that in src/conf/module-setup.*.inc, the file path for Orion is incorrect: Change /apps/lmod/init to /apps/lmod/lmod/init

[climbfuji]

We need to get rid of these two files and fix the logic that relies on them, now that the gnumake build is gone.

[junwang-noaa]

\We do need the two files to set up module. Do we want to move the two files to ufs-weather-model/test? We may need to update the path in rt.sh, run_test.sh and utest. But we still need to fix orion module-setup path to /apps/lmod/lmod/init.

@DusanJovic-NOAA Do you want to include this change in your ufs-weather-model PR#654? Thanks

[aerorahul]

@junwang-noaa
The only machines you need those files is on Cray (Gaea and WCOSS-Cray) where a module purge obliterates the system modules and cannot be recovered.

The env. variable $MODULESHOME is defined as soon as a shell is invoked, regardless of the type of terminal.
MODULESHOME contains the path to the lmod installation.

Depending on the shell, one should be able to do:

source $MODULESHOME/init/bash

instead of

/apps/lmod/lmod/init/bash

or any other variant of that lmod path.

[junwang-noaa]

When will cray go away? Maybe we have to add cray dependency in rt script if we remove the two files in NEMS?

…

On Thu, Jul 1, 2021 at 11:35 AM Rahul Mahajan ***@***.***> wrote: @junwang-noaa <https://github.com/junwang-noaa> The only machines you need those files is on Cray (Gaea and WCOSS-Cray) where a module purge obliterates the system modules and cannot be recovered. The env. variable $MODULESHOME is defined as soon as a shell is invoked, regardless of the type of terminal. MODULESHOME contains the path to the lmod installation. Depending on the shell, one should be able to do: source $MODULESHOME/init/bash instead of /apps/lmod/lmod/init/bash or any other variant of that lmod path. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#90 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI7D6TMWHQTVF7YHTDAT65DTVSDNNANCNFSM4YESYLIQ> .

[climbfuji]

Why do we need to run the module init command at all? I don't think that is needed.

What happens if we move the module purge command into the machine-dependent module files modulefiles/ufs_* on the machines where this works, and just don't add it for the cray machines?

[junwang-noaa]

I remember we had issues with "module purge" if it is a clean environment, or after "module purge", "module load" command does not work.

…

On Thu, Jul 1, 2021 at 12:06 PM Dom Heinzeller ***@***.***> wrote: Why do we need to run the module init command at all? I don't think that is needed. What happens if we move the module purge command into the machine-dependent module files modulefiles/ufs_* on the machines where this works, and just don't add it for the cray machines? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#90 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI7D6TJXO3L7YQMV2NZWIHTTVSHARANCNFSM4YESYLIQ> .

[climbfuji]

I want to give this a try.

[aerorahul]

Why do we need to run the module init command at all? I don't think that is needed.

What happens if we move the module purge command into the machine-dependent module files modulefiles/ufs_* on the machines where this works, and just don't add it for the cray machines?

@climbfuji
Please do not move module purge into the modulefiles for the machines. In operations, we load operational modules e.g. ecflow, datacom, etc. that load modules and sets paths at the beginning of the jobs.
Then in the job, the job specific modules are loaded -- ufs modules in the forecast script. If you add a module purge here, it will break operations.

If you do move it here, the workflows will have to maintain their own modulefiles for the ufs-weather-model, and I think we can all agree that is not desireable.

[climbfuji]

Why do we need to run the module init command at all? I don't think that is needed.
What happens if we move the module purge command into the machine-dependent module files modulefiles/ufs_* on the machines where this works, and just don't add it for the cray machines?

@climbfuji
Please do not move module purge into the modulefiles for the machines. In operations, we load operational modules e.g. ecflow, datacom, etc. that load modules and sets paths at the beginning of the jobs.
Then in the job, the job specific modules are loaded -- ufs modules in the forecast script. If you add a module purge here, it will break operations.

If you do move it here, the workflows will have to maintain their own modulefiles for the ufs-weather-model, and I think we can all agree that is not desireable.

That's good to know, thanks Rahul