Thanks for not saying this turn that Environment Modules
is "outdated and not maintained".
That might mislead the OMPI list audience,
which has a big intersection with Environment Modules users.
On May 16, 2014, at 4:07 PM, Maxime Boissonneault
<maxime.boissonneault_at_[hidden]> wrote:
> Instead of using the outdated and not maintained Module environment,
> why not use Lmod : https://www.tacc.utexas.edu/tacc-projects/lmod
>
> It is a drop-in replacement for Module environment that supports all
> of their features and much, much more, such as :
> - module hierarchies
> - module properties and color highlighting (we use it to higlight
> bioinformatic modules or tools for example)
> - module caching (very useful for a parallel filesystem with
> tons of modules)
> - path priorities (useful to make sure personal modules
> take precendence over system modules)
> - export module tree to json
>
> It works like a charm, understand both TCL and Lua modules
> and is actively developped and debugged. There are litteraly new
> features every month or so. If it does not do what you want, odds are
> that the developper will add it shortly (I've had it happen).
>
> Maxime
>
Some of the features introduced by LMod seem to be in the
works in the Environment modules as well (cache, hierarchies),
judging from recent mailing list postings.
I am not sure all of them are essential, though.
For instance, I am skeptical that most users,
which are scientifically trained in one way or another,
would not understand the stack nature of the the enviroment modules
and make mistakes like the one you mentioned:
> module load gcc openmpi_gcc
> module unload gcc
> module load intel
Unless they were never told about it.
Hierarchies may simplify the naming convention, but may also work
as a straitjacket, reflecting the sys admin hierarchical choices,
but potentially limiting the user choices.
In one national lab that I have access to,
navigating their module hierarchy, and specially getting around the
official one to do what you need/want, is a pain.
Anyway, this is the OMPI list, not a place for advocacy of either
package, so I am going to stop here.
I just wanted to set the record straight that:
- the Enviroment Modules package is not dead,
- it has a large user base, and
- it is sooo good that among other things it opened the road for
the imitators! :)
Thank you,
Gus Correa
On 08/05/2014 03:51 PM, Maxime Boissonneault wrote:
The Environment Modules package user base is not negligible,
including many universities, research centers, national labs,
ans private companies, in the US and around the world.
How does the user base of LMod compare?
The user base certainly is much larger for Environment Modules than LMod.
But, as a user of both Lmod and Environment Modules, I can tell you the
following :
Regardless of any virtues that LMod may have,
currently I don't see any reason to switch to LMod,
install everything over again
Nothing needs reinstalling. Lmod understands Tcl modules and can work
fine with your old module tree.
, troubleshoot it,
learn Lua, migrate my modules from Tcl,
Again, migration to Lua is not required. Tcl modules gets converted on
the fly.
educate my users and convince them to use a new
package to achieve the same exact thing that they currently have,
Very little education has to be done. The commands are the same :
module avail
module load/add
module unload/remove
module use
...
and in the end gain little if any
relevant/useful/new functionality.
If you do not want to make any changes, in the way you organize modules,
then don't. You will also get no benefit from changing to Lmod in that
situation.
If you do want to use new features, then there are plenty. Most notably is
- the possibility to organize modules in hierarchy (which you do not
HAVE to do, but in my opinion, is much more intuitive).
- the possibility to cache the module structure (and avoid reading it
from a parallel filesystem every time a user type a module command).
- the possibility to color-code modules so that users can find what they
want easier out of hundreds of modules
IF you do use hierarchy, you get the added benefit of avoiding user
mistakes such as
"
module load gcc openmpi_gcc
module unload gcc
module load intel
... why is my MPI not working!
"
IF you do use hierarchy, you get the added benefit of not having silly
module names such as
fftw/3.3_gcc4.8_openmpi1.6.3
fftw/3.3_gcc4.6_openmpi1.8.1
...
Again, you do NOT have to, but the benefits much outweight the changes
that need to be made to get them.
My 2 cents,
Maxime Boissonneault
My two cents of opinion
Gus Correa
On 08/05/2014 12:54 PM, Ralph Castain wrote:
Check the repo - hasn't been touched in a very long time
On Aug 5, 2014, at 9:42 AM, Fabricio Cannini <fcann...@gmail.com> wrote:
On 05-08-2014 13:10, Ralph Castain wrote:
Since modules isn't a supported s/w package any more, you might
consider using LMOD instead:
https://www.tacc.utexas.edu/tacc-projects/lmod
Modules isn't supported anymore? :O
Could you please send a link about it ?
_______________________________________________
users mailing list
us...@open-mpi.org
Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
Link to this post:
http://www.open-mpi.org/community/lists/users/2014/08/24918.php
_______________________________________________
users mailing list
us...@open-mpi.org
Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
Link to this post:
http://www.open-mpi.org/community/lists/users/2014/08/24919.php
_______________________________________________
users mailing list
us...@open-mpi.org
Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
Link to this post:
http://www.open-mpi.org/community/lists/users/2014/08/24924.php
