Icepack - Input Data

[simondriscoll]

Hi, I'm looking to run Icepack but with different forcing data to the default/preset options (CFS, ISPOL, etc.) in the model. In order to run Icepack I would need to know all the atmosphere/ocean/biogeochemistry fields to obtain so I can force it with these. Could someone provide me a list of all atm/ocean/biogeo variables/fields required to force Icepack?

I can't see it in model documentation. And for example, the forcing data in cfsv2_2015_220_70_01hr.txt lists 7 fields for atmospheric forcing at the top of the text file: #DSWSFC DLWSFC WNDU10 WNDV10 TEMP2M SPECHUM PRECIP

but other files for oceanic fields, including all other campaigns, e.g. ISPOL just contain the data/numbers:
-1.6826765537262 -1.69553518295288 -1.79329824447632 -1.80631458759308 -1.8071436882019 -1.80516445636749

Thanks!

 

[dbailey]

I think the best place to look is at the icedrv_forcing.F90 module. You can see where everything is read in here. You would have to add your own subroutine to read in the new forcing. You can use one of the existing subroutines as a template.

 

[simondriscoll]

Ok, thanks David!

 

[simondriscoll]

Hi David/anybody,

I have done a quick test. And I have come across a result I wouldn't expect. If I change Icepack to use e.g. ISPOL data, it runs effectively indefinitely. The ISPOL campaign, and associated forcing data, is however about 6 months long. Thus I would have expected when forcing Icepack with this data that after this period the model effectively complains there is no input/forcing data to use to continue the run. But it carries on running, and there are values of temperature etc. etc. and data for what I think are 'forcing variables' in the output, e.g. the ice_diag.full_ITD output, for years after the forcing data should have run out. (There is no forcing data that is e.g. 5 years long). Perhaps more importantly, is that Icepack continues to run and give reasonable values in this period too (seemingly for whatever input data I choose no matter if it runs past it).

I assume Icepack somehow defaults to some type of forcing if it has run to the end of a file (whether CFS, ISPOL, N-ICE, SHEBA or any other forcing data) therefore. What forcing is this it relies on to give answers of these fields if it has run for a few years well after the length the forcing data set in icepack_in? I cannot see in the model easily something that gives this answer.

In Icepack in I have changed the following forcing data-related lines only to be as follows:

atm_data_type = 'ISPOL'
ocn_data_type = 'ISPOL'
bgc_data_type = 'ISPOL'
...
data_dir = '/Users/simondriscoll/icepack-dirs/input/Icepack_data/forcing'
atm_data_file = 'ISPOL_atm_forcing.txt'
ocn_data_file = 'pop_frc.gx1v3.051202_but_hblt_from_010815_ispol.txt'
bgc_data_file = 'nutrients_daily_ISPOL_WOA_field3.txt'
ice_data_file = 'open_clos_lindsay.dat'

atm_data_format = 'bin'
ocn_data_format = 'bin'
bgc_data_format = 'bin'

And changing also the line for the length of run:
npt = 8760
(1 year) to be e.g.
npt = 87600
(10 years)

Secondly, CFS data is suitable for running annual cycles. I had assumed that changing the input fields to direct to CFS files (in icepack_in file) would be sufficient, and that it would repeat this forcing year on year. (again from the same unrealised assumption that it would collapse if it had none)

Here I had icepack_in forcing data as: (a diff between this icepack_in and above's):

> atm_data_type = 'CFS'
> ocn_data_type = 'default'
> bgc_data_type = 'default'

> atm_data_file = 'cfsv2_2015_220_70_01hr.txt'
> ocn_data_file = 'unknown_ocn_data_file'
> bgc_data_file = 'unknown_bgc_data_file'

I would think that npt = 876000 (say!) would run 100 years repeating the CFS annual cycle forcing data. Given the ISPOL result I am thinking this is not the case, thus I may have to redo a luckily small/modest amount of runs.

In order to have a repeating annual cycle year-on-year in Icepack of e.g. X years, should I e.g. copy the CFS forcing files, and effectively paste the data X times back-to-back and save these files as the forcing data to read in, or is there something more sophisticated for annual cycles?

Thank you so much for your (and everyone's) help!! It is extremely useful/gratefully received.

 

[simondriscoll]

*and an additional/related question. When running e.g. ISPOL forcing, does the start year in Icepack necessarily mean anything beyond a notional timestamp of start date. i.e. if I gave it forcing data from a different period, would it somehow select based on the time/start date/year in the icepack_in? (the forcing data don't seem to have year info, so as far as I can tell it is semi-figurative/stamping a marker of "begin of run").

 

[simondriscoll]

I was wondering if there was any responses knowledge about this, so I hope it is not rude to 'bump' it up again. :) In essence my question can be summarised as: I thought pointing Icepack to the forcing data types and forcing data files in the icepack_in file would be enough to change the forcing used for the run, but this does not seem the case?

Thanks!

 

[eclare@lanl_gov]

Hi Simon,
The forcing data is mainly for testing purposes, and the namelist options are designed to be very flexible, so that you can mix-and-match, label output with different dates from the original forcing, etc. That said, mixing and matching is not necessarily a good idea. Re ISPOL, there should be a set_nml file to configure it for the correct time period. Please treat the forcing options and configurations provided with the model as merely suggestions. It is up to you to collect and configure and validate the forcing combination needed for your particular study, which generally means writing your own forcing subroutine (which can be "modeled" on other similar routines).

As I mentioned in a separate message, running Icepack by itself for 100 or even 10 years may not produce reasonable results, because Icepack does not include sea ice dynamics.

 

[simondriscoll]

Hi Elizabeth,

many thanks. As you mention, some of what I'm doing right now is for testing purposes, and getting a handle, but at a later stage to include it in wider runs hopefully. Perhaps it is more helpful if I am a little specific.

In icepack_in:

&setup_nml
days_per_year = 365
use_leap_years = .false.
year_init = 2015

and

atm_data_type = 'ISPOL'
ocn_data_type = 'ISPOL'
bgc_data_type = 'ISPOL'
...
data_dir = '/Users/simondriscoll/icepack-dirs/input/Icepack_data/forcing'
atm_data_file = 'ISPOL_atm_forcing.txt'
ocn_data_file = 'pop_frc.gx1v3.051202_but_hblt_from_010815_ispol.txt'
bgc_data_file = 'nutrients_daily_ISPOL_WOA_field3.txt'
ice_data_file = 'open_clos_lindsay.dat'

In icepack_in we can see we clearly list the forcing files. Given e.g. ISPOL forcing files are short, I would expect icepack to have 'no forcing' if run for longer than these files.

This does not happen. In fact it runs with input/forcing from somewhere, more or less indefinitely (not that I necessarily want this, but it suggests it is forced somehow/some other way i.e. it still seems to use forcing/take input and run indefinitely stand-alone as if it is). My questions are:

1) (therefore) what forcing does Icepack default to when the forcing it is provided has run out to continue running indefinitely?

2) I also cannot understand the relation between the year_init (and specific time) and the required forcing. This may be related to 1) given it doesn't seem to matter what is included, it just runs anyway as if forcing is used indefinitely, and I believe the above few lines are correct for what is desired.

3) if I want to use e.g. CFS for an annual cycle, how do I do this? I would then like to e.g. use model data with icepack, not just an annual cycle. Is there a template/guide you mention that I could be pointed to for how to set up my own forcing for Icepack?

Thank you.

 

[david_hebert@nrlssc_navy_mil]

Hi Elizabeth,

many thanks. As you mention, some of what I'm doing right now is for testing purposes, and getting a handle, but at a later stage to include it in wider runs hopefully. Perhaps it is more helpful if I am a little specific.

In icepack_in:

&setup_nml
days_per_year = 365
use_leap_years = .false.
year_init = 2015

and

atm_data_type = 'ISPOL'
ocn_data_type = 'ISPOL'
bgc_data_type = 'ISPOL'
...
data_dir = '/Users/simondriscoll/icepack-dirs/input/Icepack_data/forcing'
atm_data_file = 'ISPOL_atm_forcing.txt'
ocn_data_file = 'pop_frc.gx1v3.051202_but_hblt_from_010815_ispol.txt'
bgc_data_file = 'nutrients_daily_ISPOL_WOA_field3.txt'
ice_data_file = 'open_clos_lindsay.dat'

In icepack_in we can see we clearly list the forcing files. Given e.g. ISPOL forcing files are short, I would expect icepack to have 'no forcing' if run for longer than these files.

This does not happen. In fact it runs with input/forcing from somewhere, more or less indefinitely (not that I necessarily want this, but it suggests it is forced somehow/some other way i.e. it still seems to use forcing/take input and run indefinitely stand-alone as if it is). My questions are:

1) (therefore) what forcing does Icepack default to when the forcing it is provided has run out to continue running indefinitely?

2) I also cannot understand the relation between the year_init (and specific time) and the required forcing. This may be related to 1) given it doesn't seem to matter what is included, it just runs anyway as if forcing is used indefinitely, and I believe the above few lines are correct for what is desired.

3) if I want to use e.g. CFS for an annual cycle, how do I do this? I would then like to e.g. use model data with icepack, not just an annual cycle. Is there a template/guide you mention that I could be pointed to for how to set up my own forcing for Icepack?

Thank you.

Hi Simon,

1) I suggest grepping the code for ISPOL. In icedrv_forcing.F90, focusing quickly on the atmosphere, what the code does is read the yearly data in subroutine atm_ISPOL. Then in the subrouinte get_forcing you'll see the section "elseif (trim(atm_data_type) == 'ISPOL') then". In here it determines the record number by the year day (yday). So when a new year starts, the forcing cycle back to the first day in the data arrays.

2) Since the ISPOL data repeats over each year, it does not apply. But if you grep the code for year_init, it will be used in icedrv_caledar.F90 to set the date when the run was started.

3) You can use CFS by running a test with the 'alt04' case. An example would be

./icepack.setup --test smoke -m gaffney --env intel -s debug,run1year,alt04 --testid t1.tst --acct XXXXXXX

If you wanted to use model data, a suggestion is to obtain the JRA55 forcing from the CICE ZENODO page, then extract the data from a particular lat/lon of interest using NetCDF operator ncks. then as dbailey suggested above, you could then make a section in icedrv_forcing.F90 that applied to your specific setup.

Thank you

 

[simondriscoll]

Hi David,

thank you very much for your reply. This has helped clear things for me, e.g. by pointing me to the files and sections helped me understand well.

Thank you for the suggestion of using JRA55 data, (and to dbailey!). I guess this fits in "input data topics":

Many reanalyses have less ocean data/variables than atmospheric, and it seems that even for a default 'CFS' forcing in Icepack, the idea is to just force with atm_CFS but use a 'default' ocean forcing. I assume to fully capture the physics going on in Icepack one must use consistent atmospheric and oceanic forcing?

The answer to this seems an obvious 'yes' but perhaps there are nuances. Thanks for help so far!!

Simon

 

[simondriscoll]

/is there much physical meaning in using e.g. a default ocean forcing file, with 'reanalyses' atmospheric forcing files, for instance?

My assumption is that physically this could produce odd results, and that oceanic and atmospheric forcing must be consistent.

Thank you!