search

NOAA-EMC / NEMS

NEMS (NOAA Environmental Modeling System)
https://noaa-emc.github.io/NEMS_doc/index.html
Other
11 stars 46 forks source link

Fix file path for Orion in module-setup #90

Open MinsukJi-NOAA opened 3 years ago

MinsukJi-NOAA commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

\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 commented 3 years ago

@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 commented 3 years ago

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 https://github.com/NOAA-EMC/NEMS/issues/90#issuecomment-872346694, or unsubscribe https://github.com/notifications/unsubscribe-auth/AI7D6TMWHQTVF7YHTDAT65DTVSDNNANCNFSM4YESYLIQ .

climbfuji commented 3 years ago

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 commented 3 years ago

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 https://github.com/NOAA-EMC/NEMS/issues/90#issuecomment-872369603, or unsubscribe https://github.com/notifications/unsubscribe-auth/AI7D6TJXO3L7YQMV2NZWIHTTVSHARANCNFSM4YESYLIQ .

climbfuji commented 3 years ago

I want to give this a try.

aerorahul commented 3 years ago

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 commented 3 years ago

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