-
Notifications
You must be signed in to change notification settings - Fork 127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding ability to use multiple Socrates versions and compile separate executables #271
base: master
Are you sure you want to change the base?
Conversation
…ically defined, so it is not automatically updated when a new version of socrates is used. It would be useful to be able to support more than 1 version of socrates. Here I have split the socrates-specific path names into seperate files depending on the version, and have allowed the socrates-version to be specified as an argument when the SocratesCodeBase object is defined.
… parameter. Here it is specified to the default value, which should mean existing installations are unaffected.
…w have to tackle the problem of the symbolic links.
…C_DIR, which then contains folders of different Socrates versions. Have updated docs to explain changes, but default behaviour of setting a single Socrates version should still work.
…es of the socrates code base, rather than having to redefine everything. Done the same with Column code base. Have also changed column model path names so that it inherits socrates paths in the same way as socrates code base.
@daw538 - I've added you to this p/r as you and I have talked about this and worked on it together. @ntlewis - I've added you as I've made a few changes to the column model classes in the codebase, just so that they inherit the properties of the full-model parent class, rather than having to re-define things like |
Overall happy with this. Many of the changes I'm already familiar with on my own fork since we've worked on some of this together before as you mention. The bits that are new to me are mainly to make the process more robust for the end user and look okay from a quick read through of the code (I'm assuming you're satisfied it works with multiple versions @sit23 ?). One request I would make (if it's not too onerous) would be to modify the debug statement produced by the socrates_interface.f90 routine (see here on L529). Currently it is hardcoded to print it's using v17.03 but would be good if it dynamically changed as a sanity check to the user which version is being used when running a model. |
Given that Socrates has a regular release cycle, some users of Isca may wish to have Isca working with several Socrates versions. With the existing front-end this is difficult, so I have implemented new functionality to allow for this.
The way it works is a user is now able to specify the Socrates version they would like to use when initialising the SocratesCodeBase object in their experiment script, e.g.:
cb = SocratesCodeBase.from_directory(GFDL_BASE, socrates_version='2207')
The code will then expect the environment variable
GFDL_SOC_DIR
to be set, which it expects to be a folder where the Socrates versions are all kept. The backend will then look for all the Socrates source code withinGFDL_SOC_DIR
within a subfolder called whatever is passed in as thesocrates_version
when creating the SocratesCodeBase object. In the above example, it will therefore look for the source code inGFDL_SOC_DIR/2207
.In addition to this change, the build directories are now kept seperate for each compilation of Isca with a different Socrates version. So instead of there being a folder
GFDL_WORK/codebase/*/build/soc_isca
, there will now be folders of the formGFDL_WORK/codebase/*/build/soc_isca_2207
, where 2207 would be replaced by whatever socrates_version is requested. The executable name will also show this version number, now beingsoc_isca_2207.x
in this example.The default behaviour for other users who only wish to use one Socrates version will remain the same. They can still specify GFDL_SOC and let the code find that single Socrates version.