Isca icon indicating copy to clipboard operation
Isca copied to clipboard

Adding ability to use multiple Socrates versions and compile separate executables

Open sit23 opened this issue 1 year ago • 2 comments

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 within GFDL_SOC_DIR within a subfolder called whatever is passed in as the socrates_version when creating the SocratesCodeBase object. In the above example, it will therefore look for the source code in GFDL_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 form GFDL_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 being soc_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.

sit23 avatar Sep 13 '24 11:09 sit23

@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 soc_nocompile etc.

sit23 avatar Sep 13 '24 11:09 sit23

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.

daw538 avatar Sep 13 '24 13:09 daw538