consider transitioning code installation to conda #161
Labels
Comments
|
See marvel-nccr/ansible-role-conda-codes#1; currently some issues to address on how to activate the Conda environments programmatically |
|
For reference these are the longest running tasks in the current (v16.04.21a) vagrant build |
|
I guess another thing to bare in mind is "access" to the executables for users. |
I agree this is an important point. Since the activation of the environment is not necessary for the executables, we could play around with symlinks etc. In the long term, ideally we should aim for maximum compatibility in the conda packages as well - I guess at some point there will always be packages that need their own environment, but there is a significant benefit in being able to install different simulation codes into the same environment (also just to simplify user workflows outside AiiDA etc.) |
Do the executables need to use the |
you're right... I hadn't thought of this (for different mpi libraries this is a problem). |
|
by the way, how did this use to work? |
I agree it would be great to minimise the need for installing different versions of each package, but practically it will be difficult to keep all these conda recipes in sync |
It doesn't, everything is compiled against the same openmpi (from apt) |
Great, so we should just be able to copy this recipe in the conda package - I remember that jan tried but failed to compile with openmpi and that's why he used mpich |
|
Well abinit does not work quite correctly at present, that's the problem. See marvel-nccr/ansible-role-abinit#14 |
|
Just to keep track, I've started looking into adding recipes for fleur, yambo and nwchem conda-forge/staged-recipes#14725 I'm not doing bigdft at the moment since it bundles a couple of different codes with different licenses; we can leave that to last |
|
Update: Currently, running inside the Adding siesta or abinit makes the environment fail to resolve. some stdout notes from the end of the install: Stats (after ( |
|
Next update, using https://github.com/mamba-org/mamba allows abinit still cannot be installed, in part for a clash between libxc requirements in abinit (<5) and cp2k (>=5.1)
but then also after cp2k is removed, there are still issues with libgfortran then there is also the issue that abinit uses a different mpi: conda-forge/abinit-feedstock#32 |
This was referenced Jul 19, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Installing simulation codes via conda (from the conda-forge channel) looks like a very promising way forward (keywords: dependency management, multi-platform support, multi-language support, automated build system, community size).
If conda-forge is widely adopted as a way of installing simulation codes in the computational materials science community (which seems likely to me; has already happened in other disciplines), switching to conda-forge for installing roles would reduce time spent on the details of ansible roles (or spend it on the conda build setup, where it benefits many more people).
There are currently ~12k packages on conda-forge (many, but not all, of scientific origin). In terms of MaX codes, I find:
One point worth mentioning may be that there isn't just a "present / not present", but codes that are present can be present at different levels of sophistication, depending on whether they are built with all bells and whistles (e.g. in the case of cp2k: openmp, mpi, libxc, libxsmm, libint, sirius, ...) or just the minimalist version. That's where having a member of the code development team on board can have a big impact.
Furthermore, I noticed that all MaX libraries seem to be missing (less relevant for Quantum Mobile)
chess
laxlib / fftxlib
sirius
dbcsr
cosma
spfft
The text was updated successfully, but these errors were encountered: