CISM config file - time varying input?

[l_n_vanderlaan@uu_nl]

Dear CISM community, Currently, I’m running CISM stand-alone, simulating the GrIS. We’ve been running CISM with a constant smb field generated by RACMO. In order to gauge CISM’s sensitivity to changes in smb, we’d like to be able to run it with a time varying field, meaning it would read in a new time slice from the input netcdf file for every N model years (ideally every model year).  Is there a flag available in the CF Input section of the config file to do this (such as the frequency flag in the CF output section), or does CISM then require separate input files? Input would be greatly appreciated! Cheers, Larissa van der Laan

 

[sacks]

From Bill Lipscomb: I think I see how this works.  I’ve attached a config file, called dome-forcing.nc, that I used to implement time-dependent forcing for the dome test case.  It’s slightly modified from a file of the same name that’s already in the repo. The standard way of running the dome test is by launching the runDome python script: > python runDome.py By default, this script uses the config file dome.config.  But you can specify a different config file as follows: > python runDome.py -c dome-forcing.config Give this a try.  The python script will look for a section called ‘[CF forcing]’.  When that section is present, the script will create a netCDF file with 10 years of time-dependent acab and artm.  It’s called dome-forcing.0031.p001.nc, and it’s placed in the output subdirectory (though it’s actually an input file).  If you look at this file (e.g., with ncdump and a netCDF viewer), you should find time indices 0 to 9.  The forcing is schematic, with stripes of data that are incremented over time. When you look at the output (either the *.config.log file or the *.out.nc file), you should see that the time 0 forcing is applied for dt in the range [0,1), then the time 1 forcing will be applied in the range [1,2), and so on until the end of the experiment. This is just an example, but I think it illustrates what you need to do.  You’ll need a netCDF forcing file, let’s call it racmo-forcing.nc.  This is distinct from the input file containing the initial ice thickness and bed topography.  The forcing file should have a time index varying from 0 to N-1, where N is the number of time slices (presumably one per year).  Your config file needs a section like this: [CF forcing]name = racmo-forcing.nc Then CISM should be smart enough to read the forcing file and choose the appropriate time slice at each step.  Let me know if this works.  It would take more code changes if you wanted to linearly interpolate between adjacent time slices within a year.  But hopefully an annual step change in forcing will serve your purposes for now.

 

[l_n_vanderlaan@uu_nl]

Hi all, After great help from Bill L. and Bill S. we have come to the following conclusions as to what is essential for CISM to read in the correct time slices from the forcing file: - as stated above: separate input file with initial ice thickness etc.- forcing file under [CF forcing] section in config file- forcing file may contain an unlimited or a fixed time dimension- time values must incrementally increase, as CISM interprets these values rather than the order of the time slices Partial ncdump output giving example of working forcing file: ncdump -v time 2testforcing.nc netcdf 2testforcing {dimensions:time = UNLIMITED ; // (1001 currently)y1 = 701 ;x1 = 376 ; variables:(..)float time(time) ;time:long_name = "Model time" ;time:standard_name = "time" ;time:units = "year since 1-1-1 0:0:0" ; time:calendar = "none" ;data:  time = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19,     20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37,     38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55,      56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, (..)
For whoever is interested, I have written a matlab script with which to alter netcdf files with a single time slice into time varying forcing files for test runs. I'm happy to share it, and can be contacted under l.n.vanderlaan@uu.nl