NorESM2.0.6 release

[DirkOlivie]

Hi @kjetilaas @monsieuralok @oyvindseland @tto061 @matsbn @MichaelSchulzMETNO @TomasTorsvik @adagj @JorgSchwinger @tjiputra @JensBDebernard,

we plan to have a new release of NorESM2 (noresm2.0.6) by 30 November 2022 (this is still aimed to be a release that can reproduce the CMIP6 results of NorESM2).

There is a milestone shortly describing it : https://github.com/NorESMhub/NorESM/milestone/2 where one can find a short overview of the planned updates. Feel free to edit it, if relevant information is missing.

To allow for testing, it would be good that individual components are updated by 23 November 2022.

To facilitate the process, it is maybe a good practice that these individual components get their own milestone (with due date 23 November 2022). I hope that the individual component maintainers could make those milestones.

Best regards, Dirk

[TomasTorsvik]

I have created a milestone for BLOM/iHAMOCC-1.3.0 for 23 November.

[TomasTorsvik]

I think this is only needed for components that will have an updated CMIP6-compatible version. If there are no changes (or only answer-changing code changes) we can use the component tag from noresm2.0.5.

[DirkOlivie]

Hi @matsbn @TomasTorsvik @JorgSchwinger

I have tested the noresm2 branch (in preparation of the noresm2.0.6 release). For BLOM I used the branch release-1.3, but I obtain a problem during compilation with BLOM : (test was done on FRAM)

blom/hamocc/read_netcdf_var.F90(103): error #6404: This name does not have a type, and must have an explicit type. [II] blom/hamocc/read_netcdf_var.F90(103): error #6385: The highest data type rank permitted is INTEGER(KIND=8). [II] blom/hamocc/read_netcdf_var.F90(103): error #6404: This name does not have a type, and must have an explicit type. [JJ] blom/hamocc/read_netcdf_var.F90(103): error #6385: The highest data type rank permitted is INTEGER(KIND=8). [JJ] blom/hamocc/read_netcdf_var.F90(107): error #6404: This name does not have a type, and must have an explicit type. [I0] blom/hamocc/read_netcdf_var.F90(109): error #6404: This name does not have a type, and must have an explicit type. [J0]

When I tried for BLOM the v1.1.0 tag, I found back identical results to CMIP6 results for a N1850_f19_tn14 simulation.

Any idea what might cause this?

Regards, Dirk

[jmaerz]

Dear Dirk, it looks as if it could be related to the usage of PNETCDF. I am not sure, if it is related to loaded modules (or similar) or to the introduction of the explicit use statements, though (betzy is down and I cannot check my usual settings). Since you're able to compile with v1.1.0 tag (I assume with the same settings), the latter is likely which would require to go one step back to resolve this. I got in contact with Tomas and Jörg about it.

[TomasTorsvik]

Hi, I wanted to test PNETCDF on Betzy a while back, but apparently this had been tested by Alok and he found some issues with it (see retracted cime PR: https://github.com/NorESMhub/cime/pull/34 ). Since we didn't have the option to run with PNETCDF, it seems this part of the code has been somewhat neglected in our recent code development.

We might need PNETCDF enabled on other systems, so we should fix this issue for the NorESM2.0.6 release.

[jmaerz]

Dear Dirk, just to give you a brief update: we've identified the potential issues and are about to fix it. If it goes as expected, a fixed version should be available soon.

[DirkOlivie]

Hi @JensBDebernard (and @matsbn)

after discussion with Mats, we wonder whether it would be a good idea to try to reduce the number of output files from the CICE model for the noresm2.0.6 release. In the current version, the daily output of CICE ends up in individual daily files, which creates a considerable number of files. So could all the daily output be put in one file per year already during model execution?

So the concrete questions are: Is this a good idea or are there too many drawbacks (e.g., restarting in the middle of the year might create problems)? Could we manage this for the noresm2.0.6 (we can extend the deadline if needed)? Who could do this (is it difficult to do)?

Best regards, Dirk

[TomasTorsvik]

Hi @DirkOlivie we have merge a bugfix for pnetcdf to the release-1.3 branch. Did a test run on Fram that went through OK.

[TomasTorsvik]

Hi @DirkOlivie , @JensBDebernard , @YanchunHe ,

I just wonder if a change like this could have implications for the CMORization routine, i.e. if our current setup expect CICE output in individual daily files? If so, it may be better to change the CICE output in the next (non-CMIP6 conformant) release instead.

Hi @JensBDebernard (and @matsbn)

after discussion with Mats, we wonder whether it would be a good idea to try to reduce the number of output files from the CICE model for the noresm2.0.6 release. In the current version, the daily output of CICE ends up in individual daily files, which creates a considerable number of files. So could all the daily output be put in one file per year already during model execution?

So the concrete questions are: Is this a good idea or are there too many drawbacks (e.g., restarting in the middle of the year might create problems)? Could we manage this for the noresm2.0.6 (we can extend the deadline if needed)? Who could do this (is it difficult to do)?

Best regards, Dirk

[DirkOlivie]

Hi @TomasTorsvik @matsbn ,

I have now tested again the noresm2-branch after the bugfix for pnetcdf in BLOM. I now however have problems (both on fram and betzy) in the compilation of BLOM, related to the CVMix code, I think. Is that code supposed to be downloaded automatically? Or does it live somewhere?

I have the impression that I need files like, cvmix_convection.F90, cvmix_ddiff.F90, cvmix_kinds_and_types.F90, ... but they do not seem to be present when the model wants to build.

During the build I get error messages like : components/blom/phy/mod_difest.F(49): error #7002: Error in opening the compiled module file. Check INCLUDE paths. [CVMIX_KPP] components/blom/phy/mod_difest.F(55): error #7002: Error in opening the compiled module file. Check INCLUDE paths. [CVMIX_SHEAR] components/blom/phy/mod_difest.F(99): error #6457: This derived type name has not been declared. [CVMIX_TIDAL_PARAMS_TYPE] ...

The code I use can be found on : /cluster/work/users/olivie/git-repositories/2022-12-07-NorESM-DirkOlivie-Test3

Hilsen, Dirk

[jmaerz]

Hi @DirkOlivie , I just jump in since I just saw it. Under the BLOM entry in the NorESM Externals.cfg you may want to add:

externals = Externals_BLOM.cfg

which should then allow to checkout the right CVMIX automatically via ./manage_externals/checkou_externals. Hope that helps. Best, Jöran

[TomasTorsvik]

Hi @DirkOlivie CVMix was included as a submodule to BLOM/iHAMOCC as part of the transition to hybrid vertical coordinates. This is included through the file externals_BLOM.cfg in the BLOM repository: https://github.com/NorESMhub/BLOM/blob/master/Externals_BLOM.cfg

This means that NorESM Externals need to be changed, with an additional externals specification:

[blom]
tag = <...>
protocol = git
repo_url = https://github.com/NorESMhub/BLOM
local_path = components/blom
externals = Externals_BLOM.cfg
required = True

[TomasTorsvik]

Hi @DirkOlivie , I just jump in since I just saw it. Under the BLOM entry in the NorESM Externals.cfg you may want to add:

externals = Externals_BLOM.cfg

which should then allow to checkout the right CVMIX automatically via ./manage_externals/checkou_externals. Hope that helps. Best, Jöran

Thanks Jöran, didn't see you already replied, I should practice to type faster ;)

[TomasTorsvik]

Probably we should also include this as a point in the changelog file.

[DirkOlivie]

Hi @TomasTorsvik

I have two remaining issues with the documentation page on the releases (doc/access/releases_noresm20.rst), which has now an updated version in the noresm2 branch on NorESMhub.

(1) the page on read-the-docs (even when I choose the noresm2 version) is still the old one (it still starts with noresm2.0.5, although I added noresm2.0.6). So maybe I did something wrong, or is the update not taken into account automatically.

(2) I would like to add the tag number of the new release version on that documentation, but I think that it is impossible : I cannot have my commit number before I do my latest commit ... (In earlier versions I added the commit number after the actual release).

Best regards, Dirk

[TomasTorsvik]

Hi @DirkOlivie , @adagj

1) I checked the ReadTheDocs page today, it seems that it as updated with noresm2.0.6 content. The documentation should build automatically when there is an update on the noresm2 branch, but sometimes there may be some delay. You can check the build logs on https://readthedocs.org/projects/noresm-docs/builds/ to see when the latest version was built.

However, it seems that the formatting problems that we had earlier (issue #388) has returned for the noresm2 documentation. I will go through the build log and check for errors.

2) Yes, I don't think there is any way to find out what the commit number will be before the commit has been made. But I think this is redundant, because the tag name is supposed to link to the commit of the release (the tag is immutable). If someone really needs the commit hash they can alway find this in the log.

Best wishes, Tomas

[TomasTorsvik]

I updated the requirements.txt file so that it is the same as in master, but the rendering issue still remains on the noresm2 branch. I don't see any more errors/warnings that should cause problems, so right now I'm out of ideas as to what is going wrong.

[TomasTorsvik]

The noresm2 documentation renders in the same way as master, so probably it was just a matter of delay in uploading the latest build to ReadTheDocs.

I'm closing this issue since the release is now out.