• Created by Unknown User (joakimkjellsson@gmail.com) on Apr 10, 2019

Hi 

I was wondering about AMIP-style runs with OpenIFS. About a year ago, Glenn sent me a set of ICMCL files (from prepIFS I think) that I use to give OpenIFS a surface condition when running. These files include skin-temperature, sea ice concentrations, and a bunch of vegetation and soil indices etc. My question is which if all these fields are actually needed.
I know the EC-Earth folks have run AMIP runs where they only give SST and sea-ice defined by some AMIP protocol, but what about all the vegetation, soil and snow variables? Are these kept fixed to some climatology in that case? Or does HTESSEL allow these variables, e.g. snow depth, to evolve over time? 
If I run OpenIFS with only skin temperature and sea ice conc in my ICMCL file, will OpenIFS still produce reasonable results? 

Also, is the skin-temperature over land from the ICMCL really used, or does HTESSEL calculate this by itself so that skin-temp over ocean is the only field I need? 

I'm asking because I'd like to take a few different SST/sea-ice data sets (obs and some future scenarios) and run OpenIFS to see how the atmosphere responds to surface warming/cooling, but I'm not sure which fields I have to present to OpenIFS. 

Best regards
Joakim


6 Comments

  1. Glenn Carver

    Hi Joakim,

    Just spoke with one of our HTESSEL modellers. If I understand correctly, HTESSEL evolves the soil and snow/ice variables according to it's soil layer models.  There is a description of this in the IFS manual for 40r1 (physics).  So the skin temperature over land is evolved by HTESSEL.  The ICMCL files contain the fields that HTESSEL is forced by such as SST & sea-ice, which normally in operations come from NEMO with LIM.

    Does that answer your question?

    Cheers,  Glenn

  2. Unknown User (joakimkjellsson@gmail.com)

    Hi Glenn

    Thanks for the reply! 
    So if I understand correctly, the only variables that OpenIFS actually uses are skin-temp over open ocean and sea-ice concentration? 
    And things like leaf-area index etc are taken from the monthly climatologies in the files "month_laih" and similarly for albedo etc? 

    I also noticed that the skin-temp over sea ice is ~ -30°C in the ICMCL file, which makes sense. But when I replace the values in ICMCL with other SSTs, I set the skin temp to -1.8°C over ice. However, the output shows ~-30°C over sea ice, so that seems HTESSEL evolves the skin-temp to something that makes sense in the end.  

    At some point it would be great if I was able to force OpenIFS with a netCDF file without the need for the ICMCL file, as it takes a bit of scripting to replace the SST/SIC data in the file by data from somewhere else. 
    Are there any plans to make it easier to run OpenIFS in AMIP mode without the need for an ICMCL file from prepIFS? And possibly even run with slab-ocean? 

    Again, thanks for the explanation.

    Best regards
    Joakim 

  3. Glenn Carver

    After Easter I can ask our sea-ice modeller exactly what's going on (it might already be described in the manuals).  This thread is moving into topics I am not so familiar with.

    As for your other points, couple of things. We have to stay close to how the model is used at ECMWF as we're only a small team and could not support the model if it was very different from IFS.  That said, I hope to make use of the AMIP setup from EC-Earth, partly for testing the model but also I hope later to make this configuration available. I've had meetings & conversations with EC-Earth about this. But that's dependent on resources.  You are also aware I think of the development in EC-Earth to add XIOS to OpenIFS 43r3, if I understand correctly that will do what you're asking.  As for a slab ocean, yes there are plans and some work is going on but I'm not going to say any more here or give a timetable.

    Regarding changing the SSTs, I had an email from another (new) user recently who was asking how to modify the SSTs in the ICMCL file. Would it be ok to put them in touch with you?

    Cheers,  Glenn

  4. Unknown User (joakimkjellsson@gmail.com)

    Hi Glenn

    Thanks for the thorough reply. I completely understand that the team is pretty small and things have to be prioritised. Had I been an EC-Earth user, I would probably just have picked up the method they are using, which seems pretty straightforward. 
    On the other hand, I've been digging into the ifs/climate/updclie file to figure out if I could alter SSTs in an easy fashion. 

    My strategy right now is to use grib_copy to crop out one time step of stl1 and ci (skin temp and sea ice) as use as a template. Then use CDO to regrid some other SST/SIC data to the reduced grid, and then use python-eccodes to make a new grib file from the template but with the new SST/SIC data. 
    I'm thinking an easier way is to just take any SST/SIC data, regrid to reduced grid and rename the file to ICMCL. I would then have a file without the headers that OpenIFS looks for, but I could perhaps disable those checks in updclie. 

    I'm still working on it, but I'm happy to share the scripts, any code changes, and ideas with anyone else who is interested. 

    Happy Easter!
    Joakim 

  5. Unknown User (joakimkjellsson@gmail.com)

    Hi again

    In case anyone is interested, here are the scripts I've used to replace SST/SIC in the ICMCL files by the NOAA OI data (https://www.esrl.noaa.gov/psd/data/gridded/data.noaa.oisst.v2.highres.html). I hope the comments explain what I've been up to. 
    NOAA OI is daily data, so I haven't done any time interpolations, but it would probably be pretty straightforward to do in python or so. 

    The script to run is set_sst_sic.sh, which calls set_icmcl_year.sh and set_sst_sic.py (requires netCDF4, eccodes). All scripts require CDO and ecCodes/gribapi. 

    As far as I can see, OpenIFS accepts the new ICMCL files without complaints. (smile) 

    Cheers
    Joakim 

    set_sst_sic.shset_sst_sic.pyset_icmcl_year.sh

  6. Yue Yu

    Hi Joakim

    Thank you very much! The scripts you shared are really useful, which help me a lot to make the climate file for long-term integration. However, at the last step you use cdo to sort the variables by dataDate, which make the order of variables are irregular in each day. It leads to some error when OpenIFS read in the climate input file at the starting point. So I noticed that the 9 variables in every timestep are required to be sorted as follows:

    centre paramId units name shortName
    ecmf 31 (0 - 1) Sea ice area fraction ci
    ecmf 139 K Soil temperature level 1 stl1
    ecmf 174 (0 - 1) Albedo al
    ecmf 15 (0 - 1) UV visible albedo for direct radiation aluvp
    ecmf 16 (0 - 1) UV visible albedo for diffuse radiation aluvd
    ecmf 17 (0 - 1) Near IR albedo for direct radiation alnip
    ecmf 18 (0 - 1) Near IR albedo for diffuse radiation alnid
    ecmf 66 m**2 m**-2 Leaf area index, low vegetation lai_lv
    ecmf 67 m**2 m**-2 Leaf area index, high vegetation lai_hv

    I am not sure if it is because of the version of model. However, the data is read smoothly after I combined the separate files day by day to make sure the order is correct.

    Regards

    Yue