Hi Fotis,
(answers inline)
On 05/15/2012 11:09 AM, Fotis Georgatos wrote:
Hi again so,
On 14/05/2012 22:25, Kenneth Hoste wrote:
If you have suggestions or remarks, please let us know.
[...]
and can give priority to stuff that would be useful to others
Surely you ask the right person! I've been spending some good time in the past
to find out popular HPC codes among -European mostly- HPC sites; here we go:
* http://eniac.cyi.ac.cy/display/UserDoc/Packages
- The first line there are the PRACE benchmark applications; this list has
been decided over many years of work and should be a very good first pick.
Just to be clear: we will be porting everything we already have support
for in our old code base in the next couple of months, but will not
actively start implementing support for other software packages in this
list (we just don't have the time for it).
We add support for new software packages on user demand, which is the
only feasible way for us now.
Here's a quick list of the ones in the PRACE benchmark apps list we
already have support for in our old codebase, and which we hope to port
soon: WRF, NAMD, CPMD, CP2K, GROMACS, FLUENT, GAMESS, NWCHEM, Charm++,
WIEN2k, BLAST, ABINIT (not ABINIS, typo?)
Support for CP2K should be coming very soon (release v0.7).
- The next couple lines are runner-ups and other popular software codes.
* http://eniac.cyi.ac.cy/display/UserDoc/Libraries
Here we already have support in our old codebase for LAPACK, BLAS,
ATLAS, MKL, ScaLAPACK, BLACS, FFTW, Python, SciPy, NumPy, PETSc,
GOTOBLAS, ARPACK, ACML, NETCDF, HDF5, SPRNG, SAGE.
Quite a few of these are already available in EasyBuild v0.6 (see the
easyconfigs directory).
- The most commonly used HPC libraries
An alternative way to organize the work would be per software domain:
* http://eniac.cyi.ac.cy/display/UserDoc/LS2_06-01 # OSS Math Libraries
* http://eniac.cyi.ac.cy/display/UserDoc/LS2_10-02 # OSS Language environments
* http://eniac.cyi.ac.cy/display/UserDoc/LS2_11-95 # Molecular Dynamics et al
* http://eniac.cyi.ac.cy/display/UserDoc/LS2_11-97 # Climate Science et al
We also support (to-be-ported to public version) for GSL, Octave,
matplotlib, R, Ferret, NCL, NCO, Paraview, gnuplot, OpenFOAM and MATLAB
mentioned on these pages.
So, it seems like we already support quite a bit of stuff you're
interested in coming up soon. :)
We'll see if we can push the porting of these packages forward a bit, so
they become public soon.
My suggestion for you now would be the MD codes, because you will arrive
at the success/fail states much faster (==quick progress) and by the end
of it, that community can be served really well (& invited for testing).
Of course, you'll find your self needing to build its dependencies!
In the meantime, I am looking at Bioinformatics software codes
and will come up with a shortlist for that, too.
Again, we probably won't be actively adding support for software
packages we (currently) don't need ourselves for now.
But, if you end up writing easyblocks for these packages, we'll be happy
to have a look at them and include them in the EasyBuild codebase.
Also, I'd like to bring to your attention the following notation as regards
the modules namespace: (Note "-<MPILibrary>-<Compiler>-<Precision>" suffix)
http://apps.fz-juelich.de/unite/files/unite-installguide.pdf
Here are some good practices for module names (copied as-is from elsewhere):
* Conforming sites MUST put the Version string after the "/" separator
* Conforming sites SHOULD prefer Version strings with dots notation
* Conforming sites SHOULD define a default Version when multiple ones exist
* Conforming sites MAY further expand the Version string as per local needs
* Conforming sites MAY create subcategories of modules as per local needs
* Conforming sites MUST document their module configuration& namespace policy
There are pros& cons with the different choices on the above,
but I skip it for now since this would make a separate thread ;-)
It seems like our site follows most of the good practices for module
naming. We don't include precision in the suffix of modules names now
though.
I don't think we'll change that very soon, but we can probably make the
module naming scheme that EasyBuild uses tuneable through the EasyBuild
config file.
ps/fyi.
My experience is mostly with RHEL* derivatives but, it happens so, that I now
manage Debian machines; I'm interested to see one solution working all around,
bringing more homogeneity across HPC sites and less clutter.
Since we solely run RHEL derivative based cluster, we won't be actively
adding support for Debian based systems for now.
But again, if you would like to contribute fixes for stuff that breaks
on Debian, please do, we'll be happy to add it to the EasyBuild release.
Kenneth
