The CO2 concentration (and other GHG concentrations) in openIFS is controlled via a couple of switches.

In the climate data directory, you find the files CO2CLIM and GCO2CLIM. The CO2CLIM and GCO2CLIM files however only define the distributions across latitude and height, not the absolute co2 concentrations. The real concentrations are controlled by various settings in the model.
The SRES-emmission scenarios (or better, their gas concentrations) are hard-coded in the model source code, and can be chosen with NSCEN in the "naerad" namelists. There is also code for the RCP (CMIP5) scenarios. It can be activated with

  LGHGCMIP5=.true.,
  GHGDATADIR="/path/to/ghgfiles/"

Then you need the input files

"PRE2005_MIDYR_CONC.txt"
"RCP3PD_MIDYR_CONC.txt"
"RCP45_MIDYR_CONC.txt"
"RCP6_MIDYR_CONC.txt"
"RCP85_MIDYR_CONC.txt"


located at GHGDATADIR. I successfully used the corresponding files from EC-EARTH with openIFS.



11 Comments

  1. Glenn Carver

    Thanks for the information Sebastian.

  2. Unknown User (joakimkjellsson@gmail.com)

    Hi Sebastian 

    I'm revisiting this somewhat old thread here just to update. I did exactly this my OpenIFS runs, but it only worked at lower resolutions. I think the problem is that each MPI task reads the data from the files. So when I run T511 on ~2000 CPUs, the text files get 2000 read calls, and the file system gets overwhelmed. 

    In order to get around it we can either update the arrays hard-coded into OpenIFS to follow the CMIP5 recommendations (or even CMIP6), or set the values in the namelist, or have just the master task read the file and then distribute the information to the remaining tasks. 

    For now, I'm using the arrays hard-coded into OpenIFS. 

    Cheers
    Joakim 

  3. smkm

    Thanks for this update Joakim. I had made only low-resolution runs on one node with 16 cores, therefore I didnt run into this problem. Great to hear that you also found a workaround for larger tasks.

    Sebastian

  4. Glenn Carver

    We have seen a similar problem with file system overload when running at the highest resolutions reading the GRIB templates at startup. Reading the data on the master task and distributing was used.

    A while ago, some of the IFS code was changed to remove large data statements hard-coded into IFS. The problem was the compile time became very slow. I forget the part of the model that this was causing a problem.

    I'll look at this for the next version and check what happens.

    Cheers,  Glenn

  5. Unknown User (joakimkjellsson@gmail.com)

    Hi Glenn

    Did you have this issue with the HRES model, T1279 L137? I did not have that issue at all when I ran that configuration with cy40r1v2 on CCA. It should be almost exactly the same code as is on the ftp.ecmwf.int site. 

    Let me know if you manage to solve it. 
    For me, it's not a priority to fix, but if I do something, I'll post the changed code. 

    Cheers
    Joakim 

  6. Glenn Carver

    The grib template issue was resolutions above T1279 (in testing) but the impact on the filesystem was the same.  For this case, the code was altered to reduce the reads but this was dealing with a lot more files.  Better in scenarios like this to read on the master MPI tasks and distribute. There should be examples of this being done in the model already you could follow as examples.

    Cheers,  Glenn

  7. Jan Streffing

    I recently ported the code that reads CMIP5 and CMIP6 trace gas files from EC-Earth IFS-36r4 into the OIFS-40r3 version that Joakim and me are using. This updated routine has only the first processor reading the files (txt for CMIP5, netcdf for CMIP6) and subsequently uses MPI_Broadcast to distribute the data to all processes.


    If there is interest I can provide this code. The changes affect the following files: updrgas.F90, yoerad.F90, suecrad.F90, naerad.nam.h, fort.4, oifs-depend.cfg and your own .cfg file

    Cheers, Jan


  8. Glenn Carver

    Hi Jan,

    I would be interested in having a copy of this code, if that's still possible.  As you know there are no plans to offer updates of 40r1, but I'd like to have these code changes in a branch on my 40r1 repository. It will be useful reference for changes to put into 43r3, though this would be in discussion with you, Joakim & EC-Earth folk.

    Thanks,  Glenn


    1. Jan Streffing

      Hello Glenn,

      I recently put those changes into EC-Earth OpenIFS so you could reference the following change-set:

      https://dev.ec-earth.org/projects/ecearth3/repository/diff/ecearth4/branches/development/2019/r6750-orbital-forcing?utf8=%E2%9C%93&rev=6759&rev_to=6194

      I includes some changes to the EC-Earth style runscript and namelist templates that you would have to rework a bit to functions with the default OpenIFS.

  9. Etienne Tourigny

    It would be great to have this available in the next openifs version!

    1. Glenn Carver

      Yes, it's on my list. Unfortunately because of resources issues we've had in the OpenIFS team over the last year, and the pandemic, we've got behind integrating some of these user contributions. I hope to catch up soon.

      Glenn