lmod-users — A list to discuss using/deploying Lmod

Re: [Lmod-users] forbid{} issue with Lmod 8.7.65

[Robert M. <mc...@ta...>]

Currently there is no support for lua pattern match with forbid (or hide).  This might be possible. Please create an issue at github.com/TACC/Lmod which shows an example of what you are looking for.

Best,
Lmod Team

________________________________
From: Kearney, Lawrence via Lmod-users <lmo...@li...>
Sent: Tuesday, October 7, 2025 3:18 PM
To: lmo...@li... <lmo...@li...>
Cc: Barim, Deniz <DB...@au...>
Subject: [Lmod-users] forbid{} issue with Lmod 8.7.65


All,

New to the list and hopefully someone can assist. We’re running v8.7.6.5 and attempting to limit module availability by lua name pattern matching using the forbid{} function in a /etc/lmod/modulerc.lua file.



Our understanding is the “namepat” key should be available in this version but Lmod throws the following error.



“This is an unknown key: "namepat" for the forbid function”



What can we do to implement support for the “namepat” key?





-- lawrence





Lawrence Kearney

Information Technology

HPC and Research Computing Facilitator

HS 2137 | +1 706.721.5197

lke...@au...<mailto:lke...@gr...>

[Lmod-users] forbid{} issue with Lmod 8.7.65

[Kearney, L. <LKE...@au...>]

All,
New to the list and hopefully someone can assist. We're running v8.7.6.5 and attempting to limit module availability by lua name pattern matching using the forbid{} function in a /etc/lmod/modulerc.lua file.

Our understanding is the "namepat" key should be available in this version but Lmod throws the following error.

"This is an unknown key: "namepat" for the forbid function"

What can we do to implement support for the "namepat" key?


-- lawrence


Lawrence Kearney
Information Technology
HPC and Research Computing Facilitator
HS 2137 | +1 706.721.5197
lke...@au...<mailto:lke...@gr...>

Re: [Lmod-users] Tomorrow: Lmod Zoom Mtg Oct. 7th, 2025

[Robert M. <mc...@ta...>]

Cut and Paste error:  The meeting is tomorrow Oct. 7th at 9:30 Central (14:30 UTC)

Best
Lmod Team

________________________________
From: Robert McLay <mc...@ta...>
Sent: Monday, October 6, 2025 2:20 PM
To: Lmod Mailinglist <lmo...@li...>
Subject: [Lmod-users] Tomorrow: Lmod Zoom Mtg Oct. 7th, 2025

We will hold the Lmod Zoom meeting tomorrow August 5th at 9:30 US Central Time, (14:30 UTC).

The zoom link is:

https://utexas.zoom.us/j/2714596735

Beginners welcome.  You do not need to be an Lmod expert to attend the meeting.  New topics welcome.

The current agenda is:


  *
Q/A
  *
My Last Day at TACC is Oct. 10th
  *
This is my last meeting that I run
  *
Overview of Changes this year


Next Meeting will be in January with Matthew Cawood.  New Zoom link then.


Best,
Lmod Team

[Lmod-users] Tomorrow: Lmod Zoom Mtg Oct. 7th, 2025

[Robert M. <mc...@ta...>]

We will hold the Lmod Zoom meeting tomorrow August 5th at 9:30 US Central Time, (14:30 UTC).

The zoom link is:

https://utexas.zoom.us/j/2714596735

Beginners welcome.  You do not need to be an Lmod expert to attend the meeting.  New topics welcome.

The current agenda is:


  *
Q/A
  *
My Last Day at TACC is Oct. 10th
  *
This is my last meeting that I run
  *
Overview of Changes this year


Next Meeting will be in January with Matthew Cawood.  New Zoom link then.


Best,
Lmod Team

Re: [Lmod-users] Tracking on Alma 8.10: rsyslog forwarding partially fails

[Loris B. <lor...@fu...>]

"Loris Bennett" <lor...@fu...> writes:

> Hi Ward,
>
> Ward Poelmans <wpo...@gm...> writes:
>
>> Hi Loris,
>>
>> What got changed is the way to do logging from Lmod. It used to call
>> the 'logger' program to emit a line to syslog. Now the hook first
>> tries the native lua interface to syslog to emit a line to
>> syslog. This should be faster as you avoid a fork.
>>
>> Did it work before with the logger command and did it break when switch to the new posix.syslog?
>
> Things broke with the transition from CentOS 7 to Alma 8.  This
> entailed a switch from Python 2 to Python 3, which caused LMODdb.py to
> fail ('raw_input' having being changed to 'input'). 
>
>> You can test it by playing with the 'if (posix.syslog) then'
>> choice. Old style is "lmod_system_execute("logger -t
>> ModuleUsageTracking -p local0.info " .. msg)".
>
> So
>
>   posix.syslog
>
> evaluates to TRUE and 
>
>  type(posix.syslog) == "table"
>
> evaluates to FALSE, so the new style is used.
>
> However, the problem is that the message is logged locally and doesn't
> get rerouted to the admin node.  So it looks like the problem is not
> with Lmod as such, but rather with the rsyslog rule set, or maybe Lmod's
> description of what the rule set should be.

Turns out I just added the forwarding rule to 'rsyslog.conf' on the
wrong machine :-(

The documentation refers to 'master' and the 'module_tracking_machine'.
However, 'master' is every machine one wants to track, so in my case it
is all the cluster nodes plus the login node.  I am collecting the
information on my cluster admin node.  Thus I find 'master' rather confusing.

@Robert: Wouldn't it be better to drop 'master' and just refer to, say,
'collector', where the log messages should end up, and 'module node',
where the 'module' command is called and creates the log message.  OK,
the latter is maybe not very good, but you get what I mean.

Sorry for the noise.

Cheers,

Loris

> Cheers,
>
> Loris
>
>> Ward
>>
>>
>> On 9/09/2025 10:45, Loris Bennett wrote:
>>> Hi,
>>> Some while ago I had module tracking working on a CentOS 7 system,
>>> such
>>> that loading of modules on the compute nodes was logged on an admin
>>> node.  I am now trying to set up tracking for Lmod 8.7.55 on an Alma
>>> 8.10 cluster.  However I have encountered the following issue.
>>> On the one hand, running 'logger' directly on a compute node creates
>>> a log entry in
>>> a dedicated log file on the admin node:
>>>    Sep  9 10:19:20 c001.curta.zedat.fu-berlin.de ModuleUsageTracking
>>> Some remote test message
>>> On the other hand, loading a module on the same compute node creates
>>> a
>>> log entry in '/var/log/messages' on the compute node:
>>>    Sep  9 10:34:08 c001 ModuleUsageTracking[625298]: user=loris
>>> module=Emacs/28.2-GCCcore-12.2.0
>>> path=/trinity/shared/easybuild/modules/all/Emacs/28.2-GCCcore-12.2.0.lua
>>> host=c001.curta.zedat.fu-berlin.de time=1757406848.886437
>>> The ruleset for rsyslog is as follows:
>>>    $Ruleset remote
>>>    if $programname contains 'ModuleUsageTracking' then @dadmin
>>>    $Ruleset RSYSLOG_DefaultRuleset
>>>    # provides UDP syslog reception
>>>    $ModLoad imudp
>>>    $InputUDPServerBindRuleset remote
>>>    $UDPServerRun 514
>>> Why might the ruleset not be being applied to the message generated
>>> by
>>> SitePackage.lua?
>>> Note that SitePackage.lua is taken from
>>>    https://lmod.readthedocs.io/en/stable/300_tracking_module_usage.html
>>> which seems to be for Lmod 8.7.64, but I had to add
>>>    local posix   = require("posix")
>>> to the top of the file to prevent an error about 'posix' being an
>>> unknown variable, so maybe the issue is related to some difference
>>> between 8.7.55 and 8.7.64.
>>> Any insights would be greatly appreciated.
>>> Cheers,
>>> Loris
>>> 
>>
>>
>>
>> _______________________________________________
>> Lmod-users mailing list
>> Lmo...@li...
>> https://lists.sourceforge.net/lists/listinfo/lmod-users
>>
-- 
Dr. Loris Bennett (Herr/Mr)
FUB-IT, Freie Universität Berlin

Re: [Lmod-users] Tracking on Alma 8.10: rsyslog forwarding partially fails

[Loris B. <lor...@fu...>]

Hi Ward,

Ward Poelmans <wpo...@gm...> writes:

> Hi Loris,
>
> What got changed is the way to do logging from Lmod. It used to call
> the 'logger' program to emit a line to syslog. Now the hook first
> tries the native lua interface to syslog to emit a line to
> syslog. This should be faster as you avoid a fork.
>
> Did it work before with the logger command and did it break when switch to the new posix.syslog?

Things broke with the transition from CentOS 7 to Alma 8.  This
entailed a switch from Python 2 to Python 3, which caused LMODdb.py to
fail ('raw_input' having being changed to 'input'). 

> You can test it by playing with the 'if (posix.syslog) then'
> choice. Old style is "lmod_system_execute("logger -t
> ModuleUsageTracking -p local0.info " .. msg)".

So

  posix.syslog

evaluates to TRUE and 

 type(posix.syslog) == "table"

evaluates to FALSE, so the new style is used.

However, the problem is that the message is logged locally and doesn't
get rerouted to the admin node.  So it looks like the problem is not
with Lmod as such, but rather with the rsyslog rule set, or maybe Lmod's
description of what the rule set should be.

Cheers,

Loris

> Ward
>
>
> On 9/09/2025 10:45, Loris Bennett wrote:
>> Hi,
>> Some while ago I had module tracking working on a CentOS 7 system,
>> such
>> that loading of modules on the compute nodes was logged on an admin
>> node.  I am now trying to set up tracking for Lmod 8.7.55 on an Alma
>> 8.10 cluster.  However I have encountered the following issue.
>> On the one hand, running 'logger' directly on a compute node creates
>> a log entry in
>> a dedicated log file on the admin node:
>>    Sep  9 10:19:20 c001.curta.zedat.fu-berlin.de ModuleUsageTracking
>> Some remote test message
>> On the other hand, loading a module on the same compute node creates
>> a
>> log entry in '/var/log/messages' on the compute node:
>>    Sep  9 10:34:08 c001 ModuleUsageTracking[625298]: user=loris
>> module=Emacs/28.2-GCCcore-12.2.0
>> path=/trinity/shared/easybuild/modules/all/Emacs/28.2-GCCcore-12.2.0.lua
>> host=c001.curta.zedat.fu-berlin.de time=1757406848.886437
>> The ruleset for rsyslog is as follows:
>>    $Ruleset remote
>>    if $programname contains 'ModuleUsageTracking' then @dadmin
>>    $Ruleset RSYSLOG_DefaultRuleset
>>    # provides UDP syslog reception
>>    $ModLoad imudp
>>    $InputUDPServerBindRuleset remote
>>    $UDPServerRun 514
>> Why might the ruleset not be being applied to the message generated
>> by
>> SitePackage.lua?
>> Note that SitePackage.lua is taken from
>>    https://lmod.readthedocs.io/en/stable/300_tracking_module_usage.html
>> which seems to be for Lmod 8.7.64, but I had to add
>>    local posix   = require("posix")
>> to the top of the file to prevent an error about 'posix' being an
>> unknown variable, so maybe the issue is related to some difference
>> between 8.7.55 and 8.7.64.
>> Any insights would be greatly appreciated.
>> Cheers,
>> Loris
>> 
>
>
>
> _______________________________________________
> Lmod-users mailing list
> Lmo...@li...
> https://lists.sourceforge.net/lists/listinfo/lmod-users
>
-- 
Dr. Loris Bennett (Herr/Mr)
FUB-IT, Freie Universität Berlin

Re: [Lmod-users] Tracking on Alma 8.10: rsyslog forwarding partially fails

[Ward P. <wpo...@gm...>]

Hi Loris,

What got changed is the way to do logging from Lmod. It used to call the 'logger' program to emit a line to syslog. Now the hook first tries the native lua interface to syslog to emit a line to syslog. This should be faster as you avoid a fork.

Did it work before with the logger command and did it break when switch to the new posix.syslog?
You can test it by playing with the 'if (posix.syslog) then' choice. Old style is "lmod_system_execute("logger -t ModuleUsageTracking -p local0.info " .. msg)".


Ward


On 9/09/2025 10:45, Loris Bennett wrote:
> Hi,
> 
> Some while ago I had module tracking working on a CentOS 7 system, such
> that loading of modules on the compute nodes was logged on an admin
> node.  I am now trying to set up tracking for Lmod 8.7.55 on an Alma
> 8.10 cluster.  However I have encountered the following issue.
> 
> On the one hand, running 'logger' directly on a compute node creates a log entry in
> a dedicated log file on the admin node:
> 
>    Sep  9 10:19:20 c001.curta.zedat.fu-berlin.de ModuleUsageTracking Some remote test message
> 
> On the other hand, loading a module on the same compute node creates a
> log entry in '/var/log/messages' on the compute node:
> 
>    Sep  9 10:34:08 c001 ModuleUsageTracking[625298]: user=loris module=Emacs/28.2-GCCcore-12.2.0 path=/trinity/shared/easybuild/modules/all/Emacs/28.2-GCCcore-12.2.0.lua host=c001.curta.zedat.fu-berlin.de time=1757406848.886437
> 
> The ruleset for rsyslog is as follows:
> 
>    $Ruleset remote
>    if $programname contains 'ModuleUsageTracking' then @dadmin
>    $Ruleset RSYSLOG_DefaultRuleset
> 
>    # provides UDP syslog reception
>    $ModLoad imudp
>    $InputUDPServerBindRuleset remote
>    $UDPServerRun 514
> 
> Why might the ruleset not be being applied to the message generated by
> SitePackage.lua?
> 
> Note that SitePackage.lua is taken from
> 
>    https://lmod.readthedocs.io/en/stable/300_tracking_module_usage.html
> 
> which seems to be for Lmod 8.7.64, but I had to add
> 
>    local posix   = require("posix")
> 
> to the top of the file to prevent an error about 'posix' being an
> unknown variable, so maybe the issue is related to some difference
> between 8.7.55 and 8.7.64.
> 
> Any insights would be greatly appreciated.
> 
> Cheers,
> 
> Loris
> 

[Lmod-users] Tracking on Alma 8.10: rsyslog forwarding partially fails

[Loris B. <lor...@fu...>]

Hi,

Some while ago I had module tracking working on a CentOS 7 system, such
that loading of modules on the compute nodes was logged on an admin
node.  I am now trying to set up tracking for Lmod 8.7.55 on an Alma
8.10 cluster.  However I have encountered the following issue.

On the one hand, running 'logger' directly on a compute node creates a log entry in
a dedicated log file on the admin node:

  Sep  9 10:19:20 c001.curta.zedat.fu-berlin.de ModuleUsageTracking Some remote test message

On the other hand, loading a module on the same compute node creates a
log entry in '/var/log/messages' on the compute node:

  Sep  9 10:34:08 c001 ModuleUsageTracking[625298]: user=loris module=Emacs/28.2-GCCcore-12.2.0 path=/trinity/shared/easybuild/modules/all/Emacs/28.2-GCCcore-12.2.0.lua host=c001.curta.zedat.fu-berlin.de time=1757406848.886437

The ruleset for rsyslog is as follows: 

  $Ruleset remote
  if $programname contains 'ModuleUsageTracking' then @dadmin
  $Ruleset RSYSLOG_DefaultRuleset

  # provides UDP syslog reception
  $ModLoad imudp
  $InputUDPServerBindRuleset remote
  $UDPServerRun 514

Why might the ruleset not be being applied to the message generated by
SitePackage.lua?

Note that SitePackage.lua is taken from 

  https://lmod.readthedocs.io/en/stable/300_tracking_module_usage.html

which seems to be for Lmod 8.7.64, but I had to add

  local posix   = require("posix")

to the top of the file to prevent an error about 'posix' being an
unknown variable, so maybe the issue is related to some difference
between 8.7.55 and 8.7.64.

Any insights would be greatly appreciated.

Cheers,

Loris

-- 
Dr. Loris Bennett (Herr/Mr)
FUB-IT, Freie Universität Berlin

[Lmod-users] Tomorrow: Lmod Zoom Mtg Sept. 9th, at 9:30 US Central (14:30 UTC)

[Robert M. <mc...@ta...>]

We will hold the Lmod Zoom meeting tomorrow Sept. 9th at 9:30 US Central Time, (14:30 UTC).

The zoom link is:

https://utexas.zoom.us/j/2714596735

Beginners welcome.  You do not need to be an Lmod expert to attend the meeting.  New topics welcome.

The current agenda is:


  *
Lmod 9.0 coming next week
  *
Issue #789: Hierarchical bug
  *
Issue #788: Support for markdown in help and whatis

Best,
Lmod Team

[Lmod-users] Lmod Zoom mtg sept 9th not sept 2nd

[Robert M. <mc...@ta...>]

See you next week

Best,
Lmod Team

Re: [Lmod-users] Strange behavior on Upgrade to Lmod 8.7.65; tells me to use spider for direct-load modules?

[Robert M. <mc...@ta...>]

What you are seeing is a bug but one that we can't reproduce:

% ml -v

Modules based on Lua: Version 8.7.65 2025-08-05 10:24 -06:00
    by Robert McLay mc...@ta...

% ml use ~/t/MF
% ml intel/oneapi_2022.3.1-sw1088
% ml list intel

Currently Loaded Modules Matching: intel
  1) intel/oneapi_2022.3.1-sw1088

There must be something special about your setup.

Please create an issue at https://github.com/TACC/Lmod.

The quickest way to get a bug fixed is to use the bug reporting shell script provided.  We can only fix bugs that we can reproduce with the latest version of Lmod.

Best,
Lmod Team


________________________________
From: Ryan Novosielski via Lmod-users <lmo...@li...>
Sent: Thursday, August 21, 2025 12:20 PM
To: Lmod-users <lmo...@li...>
Subject: Re: [Lmod-users] Strange behavior on Upgrade to Lmod 8.7.65; tells me to use spider for direct-load modules?

We rolled back production and the old version is working normally and the new one is still doing this under the pre-install state, so we can do any troubleshooting we need to do if anyone has any ideas.

On Aug 19, 2025, at 16:34, Ryan Novosielski via Lmod-users <lmo...@li...> wrote:

Hi all,

Having something I’ve not seen before after upgrading from 8.7.32 to 8.7.65.

For especially compilers that are in a non-default module location (eg. you use “module use” to activate it), I’m getting this message, for example:

[novosirj@amarel1 ~]$ module load intel/oneapi_2022.3.1-sw1088
Lmod has detected the following error:  These module(s) or extension(s) exist but cannot be loaded as requested:
"intel/oneapi_2022.3.1-sw1088"
   Try: "module spider intel/oneapi_2022.3.1-sw1088" to see how to load the module(s).

However I do not see a reason:

[novosirj@amarel1 ~]$ module spider intel/oneapi_2022.3.1-sw1088

------------------------------------------------------------------------------------------------------------------------------------------
  intel/oneapi_2022.3.1-sw1088: intel/oneapi_2022.3.1-sw1088
------------------------------------------------------------------------------------------------------------------------------------------
    Description:
      Intel oneAPI compiler


    This module can be loaded directly: module load intel/oneapi_2022.3.1-sw1088

    Help:
      This module loads the intel oneAPI compiler.

Did I miss something in the release notes? I’m still hunting around for a difference. These are user-generated module files, vs. our sysadmin-generated, but… they appear the same otherwise.

--
#BlackLivesMatter
____
|| \\UTGERS,     |---------------------------*O*---------------------------
||_// the State  |     Ryan Novosielski (he/him) - nov...@ru...
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
||  \\    of NJ  | Office of Advanced Research Computing - MSB A555B, Newark
     `'

_______________________________________________
Lmod-users mailing list
Lmo...@li...
https://lists.sourceforge.net/lists/listinfo/lmod-users

Re: [Lmod-users] Strange behavior on Upgrade to Lmod 8.7.65; tells me to use spider for direct-load modules?

[Ryan N. <nov...@ru...>]

We rolled back production and the old version is working normally and the new one is still doing this under the pre-install state, so we can do any troubleshooting we need to do if anyone has any ideas.

On Aug 19, 2025, at 16:34, Ryan Novosielski via Lmod-users <lmo...@li...> wrote:

Hi all,

Having something I’ve not seen before after upgrading from 8.7.32 to 8.7.65.

For especially compilers that are in a non-default module location (eg. you use “module use” to activate it), I’m getting this message, for example:

[novosirj@amarel1 ~]$ module load intel/oneapi_2022.3.1-sw1088
Lmod has detected the following error:  These module(s) or extension(s) exist but cannot be loaded as requested:
"intel/oneapi_2022.3.1-sw1088"
   Try: "module spider intel/oneapi_2022.3.1-sw1088" to see how to load the module(s).

However I do not see a reason:

[novosirj@amarel1 ~]$ module spider intel/oneapi_2022.3.1-sw1088

------------------------------------------------------------------------------------------------------------------------------------------
  intel/oneapi_2022.3.1-sw1088: intel/oneapi_2022.3.1-sw1088
------------------------------------------------------------------------------------------------------------------------------------------
    Description:
      Intel oneAPI compiler


    This module can be loaded directly: module load intel/oneapi_2022.3.1-sw1088

    Help:
      This module loads the intel oneAPI compiler.

Did I miss something in the release notes? I’m still hunting around for a difference. These are user-generated module files, vs. our sysadmin-generated, but… they appear the same otherwise.

--
#BlackLivesMatter
____
|| \\UTGERS,     |---------------------------*O*---------------------------
||_// the State  |     Ryan Novosielski (he/him) - nov...@ru...
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
||  \\    of NJ  | Office of Advanced Research Computing - MSB A555B, Newark
     `'

_______________________________________________
Lmod-users mailing list
Lmo...@li...
https://lists.sourceforge.net/lists/listinfo/lmod-users

[Lmod-users] Strange behavior on Upgrade to Lmod 8.7.65; tells me to use spider for direct-load modules?

[Ryan N. <nov...@ru...>]

Hi all,

Having something I’ve not seen before after upgrading from 8.7.32 to 8.7.65.

For especially compilers that are in a non-default module location (eg. you use “module use” to activate it), I’m getting this message, for example:

[novosirj@amarel1 ~]$ module load intel/oneapi_2022.3.1-sw1088
Lmod has detected the following error:  These module(s) or extension(s) exist but cannot be loaded as requested:
"intel/oneapi_2022.3.1-sw1088"
   Try: "module spider intel/oneapi_2022.3.1-sw1088" to see how to load the module(s).

However I do not see a reason:

[novosirj@amarel1 ~]$ module spider intel/oneapi_2022.3.1-sw1088

------------------------------------------------------------------------------------------------------------------------------------------
  intel/oneapi_2022.3.1-sw1088: intel/oneapi_2022.3.1-sw1088
------------------------------------------------------------------------------------------------------------------------------------------
    Description:
      Intel oneAPI compiler


    This module can be loaded directly: module load intel/oneapi_2022.3.1-sw1088

    Help:
      This module loads the intel oneAPI compiler.

Did I miss something in the release notes? I’m still hunting around for a difference. These are user-generated module files, vs. our sysadmin-generated, but… they appear the same otherwise.

--
#BlackLivesMatter
____
|| \\UTGERS,     |---------------------------*O*---------------------------
||_// the State  |     Ryan Novosielski (he/him) - nov...@ru...
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
||  \\    of NJ  | Office of Advanced Research Computing - MSB A555B, Newark
     `'

[Lmod-users] Tomorrow: Lmod Zoom Mtg August 5th at 9:30 US Central (14:30 UTC)

[Robert M. <mc...@ta...>]

We will hold the Lmod Zoom meeting tomorrow August 5th at 9:30 US Central Time, (14:30 UTC).

The zoom link is:

https://utexas.zoom.us/j/2714596735

Beginners welcome.  You do not need to be an Lmod expert to attend the meeting.  New topics welcome.

The current agenda is:


  *
Big Cache update
  *
Issue #780: Not rebuilding cache every time causes a problem with cached loads: Still working on this
  *
Nushell support
  *
Issue #778: Solved problem with N/V/V layout

Next Meeting Sept. 9th.

Best,
Lmod Team

[Lmod-users] Tomorrow: Lmod Zoom Mtg: July 1th at 9:30 US Central (14:30 UTC)

[Robert M. <mc...@ta...>]

We will hold the Lmod Zoom meeting tomorrow July 1th at 9:30 US Central Time, (14:30 UTC).

The zoom link is:

https://utexas.zoom.us/j/2714596735

Beginners welcome.  You do not need to be an Lmod expert to attend the meeting.  New topics welcome.

The current agenda is:


  *
Q/A
  *
Release of Lmod 8.7.63
  *
Big improvements in speed
  *
Results of Big Cache tests
  *
Lmod internal Code and overview released.
  *
Is Big Cache worth it?
  *
Issue #773: Adding more information to spider cache?

Best,
Lmod Team


  *

Re: [Lmod-users] lmod with different CPUs

[Grigory S. <gri...@um...>]

Hi Wadud,


Of the approaches, there seems to be at least two: 1) to have an “arch” module somewhere in a single hierarchy that acts like a parent (arch/avx2, arch/avx512, arch/sse); so that users  (and software builders) would be able to choose the CPU architecture.
Or 2) to have completely separate module hierarchies for each CPUs that would switch automatically based on the node’s hardware.

--
Grigory Shamov
Site Lead / HPC Specialist
University of Manitoba and DRI Alliance Canada


From: Wadud Miah via Lmod-users <lmo...@li...>
Reply-To: Wadud Miah <wad...@ku...>
Date: Tuesday, June 17, 2025 at 5:07 AM
To: "lmo...@li..." <lmo...@li...>
Subject: [Lmod-users] lmod with different CPUs

Caution! This message was sent from outside the University of Manitoba.

Hi,

We have AMD and Intel CPUs in our cluster and wanted some generic advice on how to organise lmod with applications built on different CPUs. Any advice will be appreciated.

Regards,




Dr. Wadud Miah
Scientific Computing Support Senior Specialist
Scientific Computing Support





[cid:image001.png@01DBDF64.5E676680]



    wad...@ku...
    T : +971 2 312 5531
    ku.ac.ae<http://www.ku.ac.ae/>

PO. Box 127788, Abu Dhabi, UAE
Khalifa University
[cid:image002.png@01DBDF64.5E676680]<http://www.ku.ac.ae/social>



"Disclaimer: This email and any attachments are intended solely for the use of the recipient(s) and may contain confidential or legally privileged information. If you are not the intended recipient, please notify the sender immediately and delete this email. Any unauthorized review, use, or distribution is prohibited. The views expressed in this email are those of the sender and may not reflect the official policies or position of Khalifa University of Science and Technology."

[Lmod-users] lmod with different CPUs

[Wadud M. <wad...@ku...>]

Hi,

We have AMD and Intel CPUs in our cluster and wanted some generic advice on how to organise lmod with applications built on different CPUs. Any advice will be appreciated.

Regards,




Dr. Wadud Miah
Scientific Computing Support Senior Specialist
Scientific Computing Support





[cid:image001.png@01DBDF84.10839EA0]



    wad...@ku...
    T : +971 2 312 5531
    ku.ac.ae<http://www.ku.ac.ae/>

PO. Box 127788, Abu Dhabi, UAE
Khalifa University
[cid:image002.png@01DBDF84.10839EA0]<http://www.ku.ac.ae/social>



"Disclaimer: This email and any attachments are intended solely for the use of the recipient(s) and may contain confidential or legally privileged information. If you are not the intended recipient, please notify the sender immediately and delete this email. Any unauthorized review, use, or distribution is prohibited. The views expressed in this email are those of the sender and may not reflect the official policies or position of Khalifa University of Science and Technology."

[Lmod-users] Tomorrow: Lmod Zoom Mtg: June 3th at 9:30 US Central (14:30 UTC)

[Robert M. <mc...@ta...>]

We will hold the Lmod Zoom meeting tomorrow June 3th at 9:30 US Central Time, (14:30 UTC).

The zoom link is:

https://utexas.zoom.us/j/2714596735

Beginners welcome.  You do not need to be an Lmod expert to attend the meeting.  New topics welcome.

The current agenda is:


  *
Q/A
  *
Progress on: generating spider cache files that contain the contents of each module file
  *
Is this going to improve performance on parallel file systems?
  *
LMOD_DYNAMIC_SPIDER_CACHE changes coming in 8.8
  *
Bug fixes:
     *
#764: source_sh() and LD_LIBRARY_PATH
     *
#761, #766: unreadable .modulerc* and other modulefiles
     *
#759: Aliases with "-" not being found

Best,
Lmod Team

Re: [Lmod-users] Best practice for managing multiple module versions with shared configuration?

[Hongyi Z. <hon...@gm...>]

On Thu, May 22, 2025 at 3:15 PM Hongyi Zhao <hon...@gm...> wrote:
>
> Hi,
>
> I have multiple VASP module versions (6.4.3, 6.5.0 and 6.5.1 in my
> case, as shown below) that share identical configurations. Currently
> using this approach:
>
> ```
> werner@x13dai-t:~/Public/repo/github.com/TACC/modulefiles/applications/vasp$
> ls -la |grep VASP.6.X.X
> lrwxrwxrwx  1 werner werner   27 May 22 14:58 6.4.3-oneapi.2024.2.0 ->
> .VASP.6.X.X-oneapi.2024.2.0
> lrwxrwxrwx  1 werner werner   27 May 22 14:59 6.5.0-oneapi.2024.2.0 ->
> .VASP.6.X.X-oneapi.2024.2.0
> lrwxrwxrwx  1 werner werner   27 May 22 14:59 6.5.1-oneapi.2024.2.0 ->
> .VASP.6.X.X-oneapi.2024.2.0
> -rw-rw-r--  1 werner werner 1845 May 22 14:54 .VASP.6.X.X-oneapi.2024.2.0
> ```
>
> All versions symlink to a hidden base file (dot-prefixed, doesn't show
> in `module avail`).
>
> My Questions are as follows:
> 1. Is this a recommended approach for managing shared configurations?
> 2. Are there better alternatives methods than the one used above by me?
> 3. Any potential issues with the symlink approach?
>
> Thanks for any insights.

Thanks everyone for any insights on this topic!

After diving deeper into Lmod's source code and testing the hidden
module functionality, I can now answer my own questions:

1. Is this approach recommended?
Yes! The symlink-to-hidden-modulefile pattern is actually well-aligned
with Lmod's design. The dot-prefix hiding is a core feature
implemented in Lmod's module discovery logic, not a hack.

2. Are there better alternatives?
For my use case (3 similar VASP versions), I explored alternatives but
they add complexity without significant benefits:

- Lua function approach: Create a shared Lua module with common
functions, then `require()` it in each modulefile. This needs proper
Lua module paths and is overkill for simple configuration sharing.

- Include/loadfile patterns: Use
`loadfile("/path/to/shared-config.lua")()` in each modulefile to
source common code. This creates additional file dependencies and path
management overhead.

- ModuleRC hierarchies: Use `.modulerc.lua` with `family()` or complex
inheritance. This is designed more for compiler/MPI toolchain
hierarchies than simple config sharing.

My current symlink approach hits the sweet spot of simplicity and
maintainability without the overhead.

3. Any potential issues?
Testing shows it works reliably:
```bash
$ module avail                        # Clean output, hidden file doesn't show
$ module --show_hidden avail          # Shows .VASP.6.X.X... (H) when needed
$ module load vasp/6.4.3-oneapi.2024.2.0  # Loads correctly via symlink
```

I'll stick with my current approach. Sometimes the straightforward
solution is the right one!

Thanks for this great community resource.

Best,
Zhao

>
> Best regards,
> Zhao
> --
> Assoc. Prof. Hongsheng Zhao <hon...@gm...>
> Theory and Simulation of Materials
> Hebei Vocational University of Technology and Engineering
> No. 473, Quannan West Street, Xindu District, Xingtai, Hebei province

[Lmod-users] Best practice for managing multiple module versions with shared configuration?

[Hongyi Z. <hon...@gm...>]

Hi,

I have multiple VASP module versions (6.4.3, 6.5.0 and 6.5.1 in my
case, as shown below) that share identical configurations. Currently
using this approach:

```
werner@x13dai-t:~/Public/repo/github.com/TACC/modulefiles/applications/vasp$
ls -la |grep VASP.6.X.X
lrwxrwxrwx  1 werner werner   27 May 22 14:58 6.4.3-oneapi.2024.2.0 ->
.VASP.6.X.X-oneapi.2024.2.0
lrwxrwxrwx  1 werner werner   27 May 22 14:59 6.5.0-oneapi.2024.2.0 ->
.VASP.6.X.X-oneapi.2024.2.0
lrwxrwxrwx  1 werner werner   27 May 22 14:59 6.5.1-oneapi.2024.2.0 ->
.VASP.6.X.X-oneapi.2024.2.0
-rw-rw-r--  1 werner werner 1845 May 22 14:54 .VASP.6.X.X-oneapi.2024.2.0
```

All versions symlink to a hidden base file (dot-prefixed, doesn't show
in `module avail`).

My Questions are as follows:
1. Is this a recommended approach for managing shared configurations?
2. Are there better alternatives methods than the one used above by me?
3. Any potential issues with the symlink approach?

Thanks for any insights.

Best regards,
Zhao
-- 
Assoc. Prof. Hongsheng Zhao <hon...@gm...>
Theory and Simulation of Materials
Hebei Vocational University of Technology and Engineering
No. 473, Quannan West Street, Xindu District, Xingtai, Hebei province

Re: [Lmod-users] Separate labels for metamodules and subdirectories

[Matthew C. <mc...@ta...>]

Hi Ron,

You are correct that categories apply to directories, not to files. To get different categories in the example, move genomics.lua to its own directory and assign a different category to that directory.
Let me know if you have any questions.

Best,
Matthew

From: Rahaman, Ronald O <rra...@ga...>
Date: Wednesday, May 14, 2025 at 18:15
To: Lmo...@li... <Lmo...@li...>
Subject: [Lmod-users] Separate labels for metamodules and subdirectories
We'd like to show some meta-modules in a named category.  Furthermore, we'd like the meta-modules' category to be different that their sibling directories' category.  How can we do that?

For example, using the example in the docs (https://lmod.readthedocs.io/en/latest/055_module_names.html#module-naming-scheme-category-name-version-c-n-v), we'd like to:

  *   Have the meta-module "genomics" appear in Category A

  *   Have "bowtie" and "tophat" appear in Category B

My attempts are failing, and I think it's because categories can be applied to a directory but not a lua file (https://lmod.readthedocs.io/en/latest/200_avail_custom.html#providing-custom-labels-for-avail).  Let me know if I'm mistaken.

Thanks,
Ron

--------

Ron Rahaman
Research Scientist II, Research Software Engineer
Partnership for an Advanced Computing Environment (PACE)
Open Source Programming Office (OSPO)
Georgia Institute of Technology

[Lmod-users] Separate labels for metamodules and subdirectories

[Rahaman, R. O <rra...@ga...>]

We'd like to show some meta-modules in a named category.  Furthermore, we'd like the meta-modules' category to be different that their sibling directories' category.  How can we do that?

For example, using the example in the docs (https://lmod.readthedocs.io/en/latest/055_module_names.html#module-naming-scheme-category-name-version-c-n-v), we'd like to:

  *
Have the meta-module "genomics" appear in Category A
  *
Have "bowtie" and "tophat" appear in Category B

My attempts are failing, and I think it's because categories can be applied to a directory but not a lua file (https://lmod.readthedocs.io/en/latest/200_avail_custom.html#providing-custom-labels-for-avail).  Let me know if I'm mistaken.

Thanks,
Ron

--------

Ron Rahaman
Research Scientist II, Research Software Engineer
Partnership for an Advanced Computing Environment (PACE)
Open Source Programming Office (OSPO)
Georgia Institute of Technology

Re: [Lmod-users] source_sh and LD_LIBRARY_PATH

[Jakob S. <jak...@fa...>]

Hi Robert,


thanks for the quick reply. Good to know that the sequence below is not 
intended


    $ cat .modules/test1.sh
    export TEST="foo${TEST:+:}${TEST}"
    $ echo $TEST

    $ $LMOD_DIR/sh_to_modulefile .modules/test1.sh
    setenv("TEST","foo")
    $ export TEST="BAR"
    $ $LMOD_DIR/sh_to_modulefile .modules/test1.sh
    prepend_path("TEST","foo")
    $ cat .modules/test2.sh
    export LD_LIBRARY_PATH="foo${LD_LIBRARY_PATH:+:}${LD_LIBRARY_PATH}"
    $ echo $LD_LIBRARY_PATH

    $ $LMOD_DIR/sh_to_modulefile .modules/test2.sh
    setenv("LD_LIBRARY_PATH","foo")
    $ export LD_LIBRARY_PATH="bar"
    $ $LMOD_DIR/sh_to_modulefile .modules/test2.sh
    setenv("LD_LIBRARY_PATH","foo")

I will open an issue shortly!


Regards,
Jakob



On 5/13/25 6:07 PM, Robert McLay wrote:
> Huh? There are no special variables w.r.t. 
> Source_sh/sh_to_modulefile.  What you found is where sh_to_modulefile 
> says to wipe-out almost all env. vars. It keeps the value of 
> LD_LIBRARY_PATH before running the script.  This is when 
> sh_to_modulefile is run with the --cleanEnv option.
>
> If a user has a value for any env. var. and then the script changes 
> it.  Then it appends or prepends the value.  If there is no previous 
> value, then Lmod uses setenv().
>
> If you have a case where LD_LIBRARY_PATH has a value in the 
> environment (and not a local variable) and Lmod uses setenv instead of 
> append_path() or prepend_path() then that is a bug. Please submit a 
> bug report that shows this.
>
> Using setenv() when there is no previous value it not a bug.
>
> Best,
> Robert
>
> ------------------------------------------------------------------------
> *From:* Jakob Stierhof <jak...@fa...>
> *Sent:* Tuesday, May 13, 2025 8:22 AM
> *To:* Lmo...@li... <Lmo...@li...>
> *Subject:* [Lmod-users] source_sh and LD_LIBRARY_PATH
> Dear Lmod users and developers,
>
> using the source_sh function or the sh_to_modulefile script to update an
> environment based on a script that is meant to be sourced behaves as
> expected except for LD_LIBRARY_PATH variable. When the script appends or
> prepends to this variable, the source_sh function always treats this
> variable as empty and therefore ends up in a 'setenv' instead of a
> 'append_path' or 'prepend_path'.
>
> Regardless of it being a bad idea to have modules set LD_LIBRARY_PATH,
> my expectation is that it is treated as any other environment variable,
> which it clearly is not.
>
> The only place that I could identify where behavior might be modified is
> in 'sh_to_modulefile', where LD_LIBRARY_PATH is in the the keepT table
> with a 'keep' value. But my understanding is that source_sh is not using
> sh_to_modulefile.
>
> Is this intentional behavior, and if so, is there a way to overwrite it
> such that it is treated as a normal variable?
>
> I am running Lmod v8.7.60
>
> I appreciate any hint!
>
> Kind regards,
> Jakob
>
>
>
>
> _______________________________________________
> Lmod-users mailing list
> Lmo...@li...
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flmod-users&data=05%7C02%7C%7C04bd2bbe0f234ddc7ae308dd922c279b%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C0%7C0%7C638827440530443501%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Kjd0w%2F4qIAxx%2BfIbsNfisiyDJkr4OzTDeDh9i8wN1JE%3D&reserved=0 
> <https://lists.sourceforge.net/lists/listinfo/lmod-users>

Re: [Lmod-users] source_sh and LD_LIBRARY_PATH

[Robert M. <mc...@ta...>]

Huh? There are no special variables w.r.t. Source_sh/sh_to_modulefile.  What you found is where sh_to_modulefile says to wipe-out almost all env. vars. It keeps the value of LD_LIBRARY_PATH before running the script.  This is when sh_to_modulefile is run with the --cleanEnv option.

If a user has a value for any env. var. and then the script changes it.  Then it appends or prepends the value.  If there is no previous value, then Lmod uses setenv().

If you have a case where LD_LIBRARY_PATH has a value in the environment (and not a local variable) and Lmod uses setenv instead of append_path() or prepend_path() then that is a bug.  Please submit a bug report that shows this.

Using setenv() when there is no previous value it not a bug.

Best,
Robert

________________________________
From: Jakob Stierhof <jak...@fa...>
Sent: Tuesday, May 13, 2025 8:22 AM
To: Lmo...@li... <Lmo...@li...>
Subject: [Lmod-users] source_sh and LD_LIBRARY_PATH

Dear Lmod users and developers,

using the source_sh function or the sh_to_modulefile script to update an
environment based on a script that is meant to be sourced behaves as
expected except for LD_LIBRARY_PATH variable. When the script appends or
prepends to this variable, the source_sh function always treats this
variable as empty and therefore ends up in a 'setenv' instead of a
'append_path' or 'prepend_path'.

Regardless of it being a bad idea to have modules set LD_LIBRARY_PATH,
my expectation is that it is treated as any other environment variable,
which it clearly is not.

The only place that I could identify where behavior might be modified is
in 'sh_to_modulefile', where LD_LIBRARY_PATH is in the the keepT table
with a 'keep' value. But my understanding is that source_sh is not using
sh_to_modulefile.

Is this intentional behavior, and if so, is there a way to overwrite it
such that it is treated as a normal variable?

I am running Lmod v8.7.60

I appreciate any hint!

Kind regards,
Jakob




_______________________________________________
Lmod-users mailing list
Lmo...@li...
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flmod-users&data=05%7C02%7C%7C04bd2bbe0f234ddc7ae308dd922c279b%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C0%7C0%7C638827440530443501%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Kjd0w%2F4qIAxx%2BfIbsNfisiyDJkr4OzTDeDh9i8wN1JE%3D&reserved=0<https://lists.sourceforge.net/lists/listinfo/lmod-users>

[Lmod-users] source_sh and LD_LIBRARY_PATH

[Jakob S. <jak...@fa...>]

Dear Lmod users and developers,

using the source_sh function or the sh_to_modulefile script to update an 
environment based on a script that is meant to be sourced behaves as 
expected except for LD_LIBRARY_PATH variable. When the script appends or 
prepends to this variable, the source_sh function always treats this 
variable as empty and therefore ends up in a 'setenv' instead of a 
'append_path' or 'prepend_path'.

Regardless of it being a bad idea to have modules set LD_LIBRARY_PATH, 
my expectation is that it is treated as any other environment variable, 
which it clearly is not.

The only place that I could identify where behavior might be modified is 
in 'sh_to_modulefile', where LD_LIBRARY_PATH is in the the keepT table 
with a 'keep' value. But my understanding is that source_sh is not using 
sh_to_modulefile.

Is this intentional behavior, and if so, is there a way to overwrite it 
such that it is treated as a normal variable?

I am running Lmod v8.7.60

I appreciate any hint!

Kind regards,
Jakob