Open andreas-h opened 5 years ago
That sounds like the correct way to do it. Just make sure that the easyblock complains if the dependencies are missing when enable_kpp is True. While you're at it, make a easyconfig that only turns on chem to make the suite complete.
What would be the correct way to check for dependencies in the easyblock? Check if a module for xxx and yyy is loaded without caring about the version? In which step would I do that?
To see if xxx is in the (build)dependency list use get_software_root('xxx') If you need to enforce a version too, use get_software_version('xxx') after get_software_root.
It's usually done in the configure_step. See gromacs.py for instance, there are several more that do this.
Since WRF 4.0, the chemistry code (a.k.a. WRF-Chem) is included in the main WRF code base. This means that it would be easy to allow building WRF-Chem with Easybuild.
WRF-Chem is in principle just WRF, but with some extra code enabled. Building the WRF-Chem code is triggered by some environment variables.
When building WRF-Chem, one can optionally also build KPP (the kinetic pre-processor), which is also included in the WRF codebase . Again, compilation is triggered by setting some environment variables before running
./compile
.In principle, one can use Easybuild to build WRF-Chem with KPP. I have an easyblock lying around here, which does that by checking for two additional paramters from the easyconfig file, which I called
enable_chem
andenable_kpp
, and then setting the appropriate environment variables before building.The only complication comes from the fact that when building KPP, there are additional dependencies needed (flex and byacc).
I'm wondering how to best organize this before preparing a PR. My way would be to
enable_kpp
andenable_chem
(which would both default toFalse
)-chem-kpp
, which setsenable_kpp
andenable_chem
toTrue
and adds the additional dependencies.Do you agree this should be the way forward, or would you prefer a different route?