lmod-users Mailing List for Lmod
A Lua based environment module system that reads TCL modulefiles.
Brought to you by:
rtmclay
You can subscribe to this list here.
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
(37) |
Dec
(9) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2013 |
Jan
(22) |
Feb
(9) |
Mar
(28) |
Apr
(13) |
May
(30) |
Jun
(49) |
Jul
(24) |
Aug
(20) |
Sep
(21) |
Oct
(71) |
Nov
(18) |
Dec
(26) |
2014 |
Jan
(57) |
Feb
(73) |
Mar
(39) |
Apr
(74) |
May
(55) |
Jun
(27) |
Jul
(25) |
Aug
(59) |
Sep
(43) |
Oct
(43) |
Nov
(38) |
Dec
(8) |
2015 |
Jan
(32) |
Feb
(38) |
Mar
(23) |
Apr
(15) |
May
(8) |
Jun
(45) |
Jul
(43) |
Aug
(6) |
Sep
(43) |
Oct
(58) |
Nov
(12) |
Dec
(31) |
2016 |
Jan
(21) |
Feb
(20) |
Mar
(12) |
Apr
(15) |
May
(18) |
Jun
(28) |
Jul
(3) |
Aug
(30) |
Sep
(31) |
Oct
(23) |
Nov
(49) |
Dec
(49) |
2017 |
Jan
(90) |
Feb
(57) |
Mar
(46) |
Apr
(35) |
May
(43) |
Jun
(23) |
Jul
(40) |
Aug
(51) |
Sep
(22) |
Oct
(21) |
Nov
(29) |
Dec
(29) |
2018 |
Jan
(7) |
Feb
(22) |
Mar
(16) |
Apr
(17) |
May
(18) |
Jun
(16) |
Jul
(16) |
Aug
(8) |
Sep
(29) |
Oct
(52) |
Nov
(24) |
Dec
(29) |
2019 |
Jan
(11) |
Feb
(13) |
Mar
(22) |
Apr
(43) |
May
(23) |
Jun
(7) |
Jul
(14) |
Aug
(27) |
Sep
(9) |
Oct
(8) |
Nov
(36) |
Dec
(58) |
2020 |
Jan
(29) |
Feb
(13) |
Mar
(49) |
Apr
(16) |
May
(7) |
Jun
(27) |
Jul
(12) |
Aug
(21) |
Sep
(11) |
Oct
(10) |
Nov
(12) |
Dec
(4) |
2021 |
Jan
(23) |
Feb
(10) |
Mar
(8) |
Apr
(16) |
May
(15) |
Jun
(19) |
Jul
(19) |
Aug
(11) |
Sep
(28) |
Oct
(25) |
Nov
(3) |
Dec
(18) |
2022 |
Jan
(17) |
Feb
(41) |
Mar
(19) |
Apr
(36) |
May
(40) |
Jun
(6) |
Jul
(17) |
Aug
(16) |
Sep
(12) |
Oct
(8) |
Nov
(12) |
Dec
(4) |
2023 |
Jan
(6) |
Feb
(7) |
Mar
(26) |
Apr
(9) |
May
(3) |
Jun
(6) |
Jul
(15) |
Aug
(11) |
Sep
(3) |
Oct
(4) |
Nov
(6) |
Dec
(17) |
2024 |
Jan
(13) |
Feb
(9) |
Mar
(5) |
Apr
(6) |
May
(6) |
Jun
(6) |
Jul
(12) |
Aug
(17) |
Sep
(14) |
Oct
(15) |
Nov
(20) |
Dec
(7) |
2025 |
Jan
(11) |
Feb
(1) |
Mar
(6) |
Apr
(14) |
May
(17) |
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Robert M. <mc...@ta...> - 2025-06-30 16:55:55
|
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 * |
From: Grigory S. <gri...@um...> - 2025-06-17 14:19:10
|
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." |
From: Wadud M. <wad...@ku...> - 2025-06-17 10:07:13
|
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." |
From: Robert M. <mc...@ta...> - 2025-06-02 15:39:34
|
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 |
From: Hongyi Z. <hon...@gm...> - 2025-05-23 02:08:50
|
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 |
From: Hongyi Z. <hon...@gm...> - 2025-05-22 07:16:07
|
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 |
From: Matthew C. <mc...@ta...> - 2025-05-15 19:06:26
|
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 |
From: Rahaman, R. O <rra...@ga...> - 2025-05-14 23:15:08
|
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 |
From: Jakob S. <jak...@fa...> - 2025-05-13 16:20:57
|
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> |
From: Robert M. <mc...@ta...> - 2025-05-13 16:07:28
|
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> |
From: Jakob S. <jak...@fa...> - 2025-05-13 14:39:56
|
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 |
From: Robert M. <mc...@ta...> - 2025-05-12 23:23:43
|
I have moved the discussion of this issue to Lmod's github site: https://github.com/TACC/Lmod/issues/763 [https://opengraph.githubassets.com/1d4f095a8eefc8602bb563d4dc6ac00dadaaad72cea89d425b1472a304e7a94d/TACC/Lmod/issues/763]<https://github.com/TACC/Lmod/issues/763> Empty msgHook fails with spider and msgHook is not active for overview · Issue #763 · TACC/Lmod<https://github.com/TACC/Lmod/issues/763> A user reported these bugs on the Lmod mailing list. I have moved it here for tracking. github.com I was able to reproduce your issue and fix it for me. Please see the discussion described above. Best, Robert |
From: Marcus W. <wa...@it...> - 2025-05-12 12:11:12
|
Once again, we have two issues with the msgHook. We are using Lmod 8.7.47. first: As soon as an even empty function doing nothing is registered as a msgHook, module spider does not work anymore: $> ml spider /usr/bin/lua: /opt/lmod/8.7.47/libexec/cmdfuncs.lua:1068: bad argument #1 to 'concatTbl' (table expected, got nil) stack traceback: [C]: in function 'table.concat' /opt/lmod/8.7.47/libexec/cmdfuncs.lua:1068: in function 'SpiderCmd' /opt/lmod/8.7.47/libexec/lmod:517: in function 'main' /opt/lmod/8.7.47/libexec/lmod:588: in main chunk [C]: in ? is that a known bug? second: the msgHook seems to not influence the output of module overview Is that intended or just missing? Best Marcus Am 05.05.2025 um 14:52 schrieb Marcus Wagner: > > Dear Lmod Team, > > > sorry for the double post, just saw that I did not answer to the list. > I also wanted to add something, thus: > > It seems, that > > ml ov > > does not use the msgHook > > > Is that intended? > > > btw.: > > $> module --version > > Modules based on Lua: Version 8.7.47 2024-07-22 10:04 -04:00 > by Robert McLay mc...@ta... > > It seems, that if the msgHook is registered, module spider does not > work anymore. Is that a known bug? > > > $> ml spider > /usr/bin/lua: /opt/lmod/8.7.47/libexec/cmdfuncs.lua:1068: bad argument > #1 to 'concatTbl' (table expected, got nil) > stack traceback: > [C]: in function 'table.concat' > /opt/lmod/8.7.47/libexec/cmdfuncs.lua:1068: in function > 'SpiderCmd' > /opt/lmod/8.7.47/libexec/lmod:517: in function 'main' > /opt/lmod/8.7.47/libexec/lmod:588: in main chunk > [C]: in ? > > > it suffices to create an empty function an register that for the msgHook > > > Best > Marcus > > > Am 03.05.2025 um 01:23 schrieb Robert McLay: >> As you have pointed out, you can change the order of avail output by >> ordering the directories in MODULEPATH. However changing the order >> of the directories in MODULEPATH also affects which modules are >> loaded when there are duplicates. By using append_path instead of >> prepend_path will change the order but it is probably not what want. >> >> Lmod does provide a hook called "msgHook" which gives you the name >> "avail", "spider" or "list". You could write your own hook to >> intercept the output of avail and re-order the output in whatever >> order you like. >> >> Best, >> Lmod Team >> >> >> >> > -- > Dipl.-Inf. Marcus Wagner > stellv. Gruppenleitung > > IT Center > Gruppe: Server, Storage, HPC > Abteilung: Systeme und Betrieb > RWTH Aachen University > Seffenter Weg 23 > 52074 Aachen > Tel: +49 241 80 24383 > wa...@it... > www.itc.rwth-aachen.de > > Social-Media-Kanäle des IT Centers: > https://blog.rwth-aachen.de/itc/ > https://www.facebook.com/itcenterrwth > https://www.instagram.com/itcenterrwthaachen/ > https://www.linkedin.com/company/itcenterrwth > https://www.youtube.com/c/ITCenterRWTHAachen -- Dipl.-Inf. Marcus Wagner stellv. Gruppenleitung IT Center Gruppe: Server, Storage, HPC Abteilung: Systeme und Betrieb RWTH Aachen University Seffenter Weg 23 52074 Aachen Tel: +49 241 80 24383 wa...@it... www.itc.rwth-aachen.de Social-Media-Kanäle des IT Centers: https://blog.rwth-aachen.de/itc/ https://www.facebook.com/itcenterrwth https://www.instagram.com/itcenterrwthaachen/ https://www.linkedin.com/company/itcenterrwth https://www.youtube.com/c/ITCenterRWTHAachen |
From: Damon M. <ma...@dm...> - 2025-05-10 02:26:20
|
Hi Matthew, Ok, if I'm understanding this correctly, the term 'dependency' has two meanings to Lmod: 1. the first meaning is entirely determined by where module files exist in the filesystem hierachy, and this dictates the behaviour of `module swap`; and 2. the second meaning is expressed by the "depends_on" Lmod function, and has nothing to do with `module swap`, it just tells Lmod to load the arguments passed to "depends_on" when `this` module is loaded. Is my understanding correct? Best wishes, Damon On Mon, 5 May 2025, at 11:51, Matthew Cawood wrote: > Hi Paul, > You're correct in pointing out that Lmod does support depends_on("A") > or ("A", "B") in modulefiles, but it's important to distinguish what > this means in the context of Lmod's hierarchy versus load-time > behavior. The statement: depends_on("A", "B") in a modulefile means: if > either A or B is not currently loaded, Lmod will attempt to load them > *automatically* when the current module is loaded. > However, this has nothing to do with module visibility or hierarchical > layout. The module still lives under a single parent in the hierarchy > (e.g., under A), so it only becomes visible *after* A is loaded. If B > is not part of the hierarchy (i.e., not a parent that reveals child > paths), it still must be loadable by name for depends_on() to succeed, > but it doesn't influence where the module appears in the module tree. > Also worth noting: Lmod tracks modules loaded via depends_on() using > reference counting. So if A was not previously loaded and gets loaded > as a dependency of X, it will be unloaded when X is unloaded—*unless* > something else also depends on A or the user had explicitly loaded A > beforehand (i.e, its reference counter != 0). > In short: > • depends_on() ensures that A and B are loaded when needed. > • But it doesn’t allow the module to appear in two places in the > hierarchy, nor does it change how visibility is governed by MODULEPATH. > • `depends_on()` influences what gets loaded, not where things appear. > Best, > Matthew > > *From: *Damon McDougall <ma...@dm...> > *Date: *Friday, May 2, 2025 at 18:40 > *To: *Matthew Cawood <mc...@ta...>, Paul Bauman <ptb...@gm...> > *Cc: *lmod-users <lmo...@li...> > *Subject: *Re: [Lmod-users] Modules with Multiple Dependencies > Hi Matthew, > >> What you're describing—having module C depend on both A and B—isn't supported directly in Lmod due to its hierarchical design > > In the Lmod > documentation<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flmod.readthedocs.io%2Fen%2Flatest%2F098_dependent_modules.html%23dependent-modules&data=05%7C02%7C%7C4a8cd53933e6441d149208dd89d2c465%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C0%7C0%7C638818260562923085%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=kMd3W9X9u7Q8nutshBUk6PKlYtPctF7qOac9lA8FlFQ%3D&reserved=0 > <https://lmod.readthedocs.io/en/latest/098_dependent_modules.html#dependent-modules>> > I see this statement: > > depends_on("A", "B") > > What does this statement mean if Lmod doesn't support a module > depending on both "A" and "B"? > > On Thu, 1 May 2025, at 12:56, Matthew Cawood wrote: >> Hi Paul, >> What you're describing—having module C depend on both A and B—isn't >> supported directly in Lmod due to its hierarchical design. Modules can >> only have a single parent in the hierarchy, meaning a module like C >> must reside under either A *or* B, but not both. This design simplifies >> environment resolution and prevents ambiguity, but it does limit >> support for multi-parent dependencies. >> At TACC, we’ve run into a similar challenge on our Vista system, which >> includes both CPU and Grace Hopper GPU nodes. Our hierarchy puts the >> compiler at the top level, with MPI and CUDA as sibling layers. We >> treat CUDA-aware MPI as a child of the CUDA module. So if a user loads >> a compiler and MPI, then loads CUDA, the MPI is automatically swapped >> for a CUDA-aware version. This keeps the environment consistent while >> preserving the one-parent rule. >> In your case, to support swapping A1 → A2 and have C and D reload >> accordingly, you'd need to enforce strict naming/version consistency >> and rely on Lmod’s automatic reloading of matching module names after a >> swap. But true dependency tracking across multiple roots isn’t possible >> with standard Lmod hierarchy. >> Hope this helps—happy to elaborate further if useful. >> Best, >> Matthew >> >> *From: *Paul T. Bauman <ptb...@gm...> >> *Date: *Thursday, April 24, 2025 at 10:50 >> *To: *lmod-users <lmo...@li...> >> *Cc: *Damon McDougall <dam...@gm...> >> *Subject: *[Lmod-users] Modules with Multiple Dependencies >> Greetings Lmod Users, >> >> I'd talked with Robert about something related over a decade ago now >> (sigh), but wanted to see if things have changed since then. Here is >> the kind of scenario I'm interested in at an abstract level. >> >> Consider modules A1, A2, B1, B2, C, and D. A and B have different >> versions, but are the same package and do not depend on each other. >> Module C depends on both A and B. Module D depends on C (and therefore >> implicitly A and B). >> >> A,B --> C --> D >> >> I would like to be able to "module swap A1 A2" or "module swap B1 B2" >> and have C and D be reloaded accordingly. >> >> Is this possible? >> >> The specific use-case I have in mind is that my MPI stack depends on >> both the compiler and the GPU compute stack (i.e. different CUDA or >> ROCm versions). I would like to be able to swap out the compiler >> version and/or the GPU software stack version and then have dependent >> modules reloaded accordingly. I would be curious to hear about others' >> solution to this specific pattern as I'm sure I'm not the first to have >> thought about this at this point. >> >> Thanks for your time. >> >> Best, >> >> Paul |
From: Robert M. <mc...@ta...> - 2025-05-05 17:03:05
|
We will hold the Lmod Zoom meeting tomorrow April 8th 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.60 * Debian releasing Lmod 8.7.60 package * 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 * TCL 9 support now in Lmod 8.7.60 Best, Lmod Team |
From: Matthew C. <mc...@ta...> - 2025-05-05 16:51:58
|
Hi Paul, You're correct in pointing out that Lmod does support depends_on("A") or ("A", "B") in modulefiles, but it's important to distinguish what this means in the context of Lmod's hierarchy versus load-time behavior. The statement: depends_on("A", "B") in a modulefile means: if either A or B is not currently loaded, Lmod will attempt to load them automatically when the current module is loaded. However, this has nothing to do with module visibility or hierarchical layout. The module still lives under a single parent in the hierarchy (e.g., under A), so it only becomes visible after A is loaded. If B is not part of the hierarchy (i.e., not a parent that reveals child paths), it still must be loadable by name for depends_on() to succeed, but it doesn't influence where the module appears in the module tree. Also worth noting: Lmod tracks modules loaded via depends_on() using reference counting. So if A was not previously loaded and gets loaded as a dependency of X, it will be unloaded when X is unloaded—unless something else also depends on A or the user had explicitly loaded A beforehand (i.e, its reference counter != 0). In short: * depends_on() ensures that A and B are loaded when needed. * But it doesn’t allow the module to appear in two places in the hierarchy, nor does it change how visibility is governed by MODULEPATH. * depends_on() influences what gets loaded, not where things appear. Best, Matthew From: Damon McDougall <ma...@dm...> Date: Friday, May 2, 2025 at 18:40 To: Matthew Cawood <mc...@ta...>, Paul Bauman <ptb...@gm...> Cc: lmod-users <lmo...@li...> Subject: Re: [Lmod-users] Modules with Multiple Dependencies Hi Matthew, > What you're describing—having module C depend on both A and B—isn't supported directly in Lmod due to its hierarchical design In the Lmod documentation<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flmod.readthedocs.io%2Fen%2Flatest%2F098_dependent_modules.html%23dependent-modules&data=05%7C02%7C%7C4a8cd53933e6441d149208dd89d2c465%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C0%7C0%7C638818260562923085%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=kMd3W9X9u7Q8nutshBUk6PKlYtPctF7qOac9lA8FlFQ%3D&reserved=0<https://lmod.readthedocs.io/en/latest/098_dependent_modules.html#dependent-modules>> I see this statement: depends_on("A", "B") What does this statement mean if Lmod doesn't support a module depending on both "A" and "B"? On Thu, 1 May 2025, at 12:56, Matthew Cawood wrote: > Hi Paul, > What you're describing—having module C depend on both A and B—isn't > supported directly in Lmod due to its hierarchical design. Modules can > only have a single parent in the hierarchy, meaning a module like C > must reside under either A *or* B, but not both. This design simplifies > environment resolution and prevents ambiguity, but it does limit > support for multi-parent dependencies. > At TACC, we’ve run into a similar challenge on our Vista system, which > includes both CPU and Grace Hopper GPU nodes. Our hierarchy puts the > compiler at the top level, with MPI and CUDA as sibling layers. We > treat CUDA-aware MPI as a child of the CUDA module. So if a user loads > a compiler and MPI, then loads CUDA, the MPI is automatically swapped > for a CUDA-aware version. This keeps the environment consistent while > preserving the one-parent rule. > In your case, to support swapping A1 → A2 and have C and D reload > accordingly, you'd need to enforce strict naming/version consistency > and rely on Lmod’s automatic reloading of matching module names after a > swap. But true dependency tracking across multiple roots isn’t possible > with standard Lmod hierarchy. > Hope this helps—happy to elaborate further if useful. > Best, > Matthew > > *From: *Paul T. Bauman <ptb...@gm...> > *Date: *Thursday, April 24, 2025 at 10:50 > *To: *lmod-users <lmo...@li...> > *Cc: *Damon McDougall <dam...@gm...> > *Subject: *[Lmod-users] Modules with Multiple Dependencies > Greetings Lmod Users, > > I'd talked with Robert about something related over a decade ago now > (sigh), but wanted to see if things have changed since then. Here is > the kind of scenario I'm interested in at an abstract level. > > Consider modules A1, A2, B1, B2, C, and D. A and B have different > versions, but are the same package and do not depend on each other. > Module C depends on both A and B. Module D depends on C (and therefore > implicitly A and B). > > A,B --> C --> D > > I would like to be able to "module swap A1 A2" or "module swap B1 B2" > and have C and D be reloaded accordingly. > > Is this possible? > > The specific use-case I have in mind is that my MPI stack depends on > both the compiler and the GPU compute stack (i.e. different CUDA or > ROCm versions). I would like to be able to swap out the compiler > version and/or the GPU software stack version and then have dependent > modules reloaded accordingly. I would be curious to hear about others' > solution to this specific pattern as I'm sure I'm not the first to have > thought about this at this point. > > Thanks for your time. > > Best, > > Paul |
From: Marcus W. <wa...@it...> - 2025-05-05 12:53:25
|
Dear Lmod Team, sorry for the double post, just saw that I did not answer to the list. I also wanted to add something, thus: It seems, that ml ov does not use the msgHook Is that intended? btw.: $> module --version Modules based on Lua: Version 8.7.47 2024-07-22 10:04 -04:00 by Robert McLay mc...@ta... It seems, that if the msgHook is registered, module spider does not work anymore. Is that a known bug? $> ml spider /usr/bin/lua: /opt/lmod/8.7.47/libexec/cmdfuncs.lua:1068: bad argument #1 to 'concatTbl' (table expected, got nil) stack traceback: [C]: in function 'table.concat' /opt/lmod/8.7.47/libexec/cmdfuncs.lua:1068: in function 'SpiderCmd' /opt/lmod/8.7.47/libexec/lmod:517: in function 'main' /opt/lmod/8.7.47/libexec/lmod:588: in main chunk [C]: in ? it suffices to create an empty function an register that for the msgHook Best Marcus Am 03.05.2025 um 01:23 schrieb Robert McLay: > As you have pointed out, you can change the order of avail output by > ordering the directories in MODULEPATH. However changing the order of > the directories in MODULEPATH also affects which modules are loaded > when there are duplicates. By using append_path instead of > prepend_path will change the order but it is probably not what want. > > Lmod does provide a hook called "msgHook" which gives you the name > "avail", "spider" or "list". You could write your own hook to > intercept the output of avail and re-order the output in whatever > order you like. > > Best, > Lmod Team > > > > -- Dipl.-Inf. Marcus Wagner stellv. Gruppenleitung IT Center Gruppe: Server, Storage, HPC Abteilung: Systeme und Betrieb RWTH Aachen University Seffenter Weg 23 52074 Aachen Tel: +49 241 80 24383 wa...@it... www.itc.rwth-aachen.de Social-Media-Kanäle des IT Centers: https://blog.rwth-aachen.de/itc/ https://www.facebook.com/itcenterrwth https://www.instagram.com/itcenterrwthaachen/ https://www.linkedin.com/company/itcenterrwth https://www.youtube.com/c/ITCenterRWTHAachen |
From: Marcus W. <wa...@it...> - 2025-05-05 08:36:12
|
Hi Lmod Team, thanks, i wasn't aware of the msgHook. For anyone being interested, here is my code: --- hook for sorting module avail local function msg_hook(kind, a) if (kind == "avail") then local mtype = "ga" local b = {} local sort = { "ga", "core", "pcore", "comp", "pcomp", "mpi", "pmpi", "cont", "rest" } for _,k in ipairs (sort) do b[k] = {} end --- put parts into new tables for k in pairs (a) do if a[k]:sub(1,4) == "----" then if a[k]:find("Your personal Core modules", 1, true ) ~= nil then mtype = "pcore" elseif a[k]:find("Your personal Compiler dependent modules", 1, true ) ~= nil then mtype = "pcomp" elseif a[k]:find("Your personal MPI dependent modules", 1, true ) ~= nil then mtype = "pmpi" elseif a[k]:find("Core Modules", 1, true ) ~= nil then mtype = "core" elseif a[k]:find("Compiler dependent Modules", 1, true ) ~= nil then mtype = "comp" elseif a[k]:find("MPI dependent Modules", 1, true ) ~= nil then mtype = "mpi" elseif a[k]:find("Container Image Modules", 1, true ) ~= nil then mtype = "cont" end elseif a[k]:find(" Where:", 1, true) ~= nil then mtype = "rest" end b[mtype][#b[mtype]+1] = a[k] end --- delete avail table for k in pairs (a) do a[k] = nil end --- fill table again with our sort order for _,k in ipairs (sort) do for v in pairs (b[k]) do a[#a+1] = b[k][v] end end end end hook.register("msgHook", msg_hook) Best Marcus Am 03.05.2025 um 01:23 schrieb Robert McLay: > As you have pointed out, you can change the order of avail output by > ordering the directories in MODULEPATH. However changing the order of > the directories in MODULEPATH also affects which modules are loaded > when there are duplicates. By using append_path instead of > prepend_path will change the order but it is probably not what want. > > Lmod does provide a hook called "msgHook" which gives you the name > "avail", "spider" or "list". You could write your own hook to > intercept the output of avail and re-order the output in whatever > order you like. > > Best, > Lmod Team > > > > -- Dipl.-Inf. Marcus Wagner stellv. Gruppenleitung IT Center Gruppe: Server, Storage, HPC Abteilung: Systeme und Betrieb RWTH Aachen University Seffenter Weg 23 52074 Aachen Tel: +49 241 80 24383 wa...@it... www.itc.rwth-aachen.de Social-Media-Kanäle des IT Centers: https://blog.rwth-aachen.de/itc/ https://www.facebook.com/itcenterrwth https://www.instagram.com/itcenterrwthaachen/ https://www.linkedin.com/company/itcenterrwth https://www.youtube.com/c/ITCenterRWTHAachen |
From: Damon M. <ma...@dm...> - 2025-05-03 00:06:34
|
Hi Matthew, > What you're describing—having module C depend on both A and B—isn't supported directly in Lmod due to its hierarchical design In the Lmod documentation<https://lmod.readthedocs.io/en/latest/098_dependent_modules.html#dependent-modules> I see this statement: depends_on("A", "B") What does this statement mean if Lmod doesn't support a module depending on both "A" and "B"? On Thu, 1 May 2025, at 12:56, Matthew Cawood wrote: > Hi Paul, > What you're describing—having module C depend on both A and B—isn't > supported directly in Lmod due to its hierarchical design. Modules can > only have a single parent in the hierarchy, meaning a module like C > must reside under either A *or* B, but not both. This design simplifies > environment resolution and prevents ambiguity, but it does limit > support for multi-parent dependencies. > At TACC, we’ve run into a similar challenge on our Vista system, which > includes both CPU and Grace Hopper GPU nodes. Our hierarchy puts the > compiler at the top level, with MPI and CUDA as sibling layers. We > treat CUDA-aware MPI as a child of the CUDA module. So if a user loads > a compiler and MPI, then loads CUDA, the MPI is automatically swapped > for a CUDA-aware version. This keeps the environment consistent while > preserving the one-parent rule. > In your case, to support swapping A1 → A2 and have C and D reload > accordingly, you'd need to enforce strict naming/version consistency > and rely on Lmod’s automatic reloading of matching module names after a > swap. But true dependency tracking across multiple roots isn’t possible > with standard Lmod hierarchy. > Hope this helps—happy to elaborate further if useful. > Best, > Matthew > > *From: *Paul T. Bauman <ptb...@gm...> > *Date: *Thursday, April 24, 2025 at 10:50 > *To: *lmod-users <lmo...@li...> > *Cc: *Damon McDougall <dam...@gm...> > *Subject: *[Lmod-users] Modules with Multiple Dependencies > Greetings Lmod Users, > > I'd talked with Robert about something related over a decade ago now > (sigh), but wanted to see if things have changed since then. Here is > the kind of scenario I'm interested in at an abstract level. > > Consider modules A1, A2, B1, B2, C, and D. A and B have different > versions, but are the same package and do not depend on each other. > Module C depends on both A and B. Module D depends on C (and therefore > implicitly A and B). > > A,B --> C --> D > > I would like to be able to "module swap A1 A2" or "module swap B1 B2" > and have C and D be reloaded accordingly. > > Is this possible? > > The specific use-case I have in mind is that my MPI stack depends on > both the compiler and the GPU compute stack (i.e. different CUDA or > ROCm versions). I would like to be able to swap out the compiler > version and/or the GPU software stack version and then have dependent > modules reloaded accordingly. I would be curious to hear about others' > solution to this specific pattern as I'm sure I'm not the first to have > thought about this at this point. > > Thanks for your time. > > Best, > > Paul |
From: Robert M. <mc...@ta...> - 2025-05-02 23:23:59
|
As you have pointed out, you can change the order of avail output by ordering the directories in MODULEPATH. However changing the order of the directories in MODULEPATH also affects which modules are loaded when there are duplicates. By using append_path instead of prepend_path will change the order but it is probably not what want. Lmod does provide a hook called "msgHook" which gives you the name "avail", "spider" or "list". You could write your own hook to intercept the output of avail and re-order the output in whatever order you like. Best, Lmod Team |
From: Matthew C. <mc...@ta...> - 2025-05-01 17:57:25
|
Hi Paul, What you're describing—having module C depend on both A and B—isn't supported directly in Lmod due to its hierarchical design. Modules can only have a single parent in the hierarchy, meaning a module like C must reside under either A or B, but not both. This design simplifies environment resolution and prevents ambiguity, but it does limit support for multi-parent dependencies. At TACC, we’ve run into a similar challenge on our Vista system, which includes both CPU and Grace Hopper GPU nodes. Our hierarchy puts the compiler at the top level, with MPI and CUDA as sibling layers. We treat CUDA-aware MPI as a child of the CUDA module. So if a user loads a compiler and MPI, then loads CUDA, the MPI is automatically swapped for a CUDA-aware version. This keeps the environment consistent while preserving the one-parent rule. In your case, to support swapping A1 → A2 and have C and D reload accordingly, you'd need to enforce strict naming/version consistency and rely on Lmod’s automatic reloading of matching module names after a swap. But true dependency tracking across multiple roots isn’t possible with standard Lmod hierarchy. Hope this helps—happy to elaborate further if useful. Best, Matthew From: Paul T. Bauman <ptb...@gm...> Date: Thursday, April 24, 2025 at 10:50 To: lmod-users <lmo...@li...> Cc: Damon McDougall <dam...@gm...> Subject: [Lmod-users] Modules with Multiple Dependencies Greetings Lmod Users, I'd talked with Robert about something related over a decade ago now (sigh), but wanted to see if things have changed since then. Here is the kind of scenario I'm interested in at an abstract level. Consider modules A1, A2, B1, B2, C, and D. A and B have different versions, but are the same package and do not depend on each other. Module C depends on both A and B. Module D depends on C (and therefore implicitly A and B). A,B --> C --> D I would like to be able to "module swap A1 A2" or "module swap B1 B2" and have C and D be reloaded accordingly. Is this possible? The specific use-case I have in mind is that my MPI stack depends on both the compiler and the GPU compute stack (i.e. different CUDA or ROCm versions). I would like to be able to swap out the compiler version and/or the GPU software stack version and then have dependent modules reloaded accordingly. I would be curious to hear about others' solution to this specific pattern as I'm sure I'm not the first to have thought about this at this point. Thanks for your time. Best, Paul |
From: Paul T. B. <ptb...@gm...> - 2025-04-24 15:49:42
|
Greetings Lmod Users, I'd talked with Robert about something related over a decade ago now (sigh), but wanted to see if things have changed since then. Here is the kind of scenario I'm interested in at an abstract level. Consider modules A1, A2, B1, B2, C, and D. A and B have different versions, but are the same package and do not depend on each other. Module C depends on both A and B. Module D depends on C (and therefore implicitly A and B). A,B --> C --> D I would like to be able to "module swap A1 A2" or "module swap B1 B2" and have C and D be reloaded accordingly. Is this possible? The specific use-case I have in mind is that my MPI stack depends on both the compiler and the GPU compute stack (i.e. different CUDA or ROCm versions). I would like to be able to swap out the compiler version and/or the GPU software stack version and then have dependent modules reloaded accordingly. I would be curious to hear about others' solution to this specific pattern as I'm sure I'm not the first to have thought about this at this point. Thanks for your time. Best, Paul |
From: Marcus W. <wa...@it...> - 2025-04-24 05:37:59
|
Hello all, we are using a hierarchical module naming scheme. For us, it looks like the sorting of the groups depends on the order in the modulepath. Is there a possibility, to influence the sorting? how it looks now: global aliases MPI modules Compiler modules Core modules personal Core modules what we would like to achieve: global aliases Core modules personal Core modules Compiler modules MPI modules Does anyone have a hint? Best Marcus -- Dipl.-Inf. Marcus Wagner stellv. Gruppenleitung IT Center Gruppe: Server, Storage, HPC Abteilung: Systeme und Betrieb RWTH Aachen University Seffenter Weg 23 52074 Aachen Tel: +49 241 80 24383 wa...@it... www.itc.rwth-aachen.de Social-Media-Kanäle des IT Centers: https://blog.rwth-aachen.de/itc/ https://www.facebook.com/itcenterrwth https://www.instagram.com/itcenterrwthaachen/ https://www.linkedin.com/company/itcenterrwth https://www.youtube.com/c/ITCenterRWTHAachen |
From: Robert M. <mc...@ta...> - 2025-04-07 15:13:11
|
We will hold the Lmod Zoom meeting tomorrow April 8th 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 * A discussion about generating spider cache files that contain the contents of each module file * TCL contents issues: Copying file to /dev/shmem, Reporting Errors * Regular Spider cache file vs. Big Spider Cache file * Is this going to improve performance on parallel file systems? Best, Lmod Team |
From: Robert M. <mc...@ta...> - 2025-04-03 17:01:58
|
Typically, the less program is installed where LESSOPEN is defined. This starts a new shell. When this shell is run, it sources the files in /etc/profile.d. In your case it sources /etc/profile.d/lmod.sh. And that executes /opt/ohpc/admin/lmod/lmod/libexec/addto. At the top of addto has in your case: #!/usr/bin/lua5.3 -- -*- lua -*- The command addto is expecting /usr/bin/lua5.3 to exist and be executable by you the user. For some reason, the lua5.3 executable is not there in /usr/bin. This is not an Lmod issue. It might be an OHPC issue. Best, Robert ________________________________ From: Aziz Öğütlü <azi...@ed...> Sent: Tuesday, April 1, 2025 10:01 PM To: Lmod Users <lmo...@li...> Subject: [Lmod-users] after less command lua permission denied Hi there all lmod users, I've installed lmod-ohpc package on SUSE 15.6 and when I run less command with root user after close the command this error shows: software:~ # less log /opt/ohpc/admin/lmod/lmod/init/bash: /opt/ohpc/admin/lmod/lmod/libexec/addto: /usr/bin/lua5.3: bad interpreter: Permission denied What can be the problem? -- Best regards, Aziz Öğütlü Eduline Bilişim Sanayi ve Ticaret Ltd. Şti. https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.eduline.com.tr%2F&data=05%7C02%7C%7Cc04678b164274048a08808dd719da4e7%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C0%7C0%7C638791644087705775%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=sERk4ILr8d39H%2FBxWUSm1YvR3n0DGfJG%2BGHCilo44v4%3D&reserved=0<http://www.eduline.com.tr/> Merkez Mah. Ayazma Cad. No:37 Papirus Plaza Kat:6 Ofis No:118 Kağıthane - İstanbul - Türkiye 34406 Tel : +90 212 324 60 61 Cep: +90 541 350 40 72 _______________________________________________ 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%7Cc04678b164274048a08808dd719da4e7%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C0%7C0%7C638791644087725074%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=WcoRh1luj3GAQcszBkKvOFiI%2FHsMadsxhMoK70y20Ws%3D&reserved=0<https://lists.sourceforge.net/lists/listinfo/lmod-users> >> This message is from an external sender. Learn more about why this << >> matters at https://links.utexas.edu/rtyclf. << |