How to set initial date and the length of an experiment of Icepack

[CST1996]

Dear support of Icepack model,
The time length of standard run of Icepack is 8760, that is, starting from 01/01 0:00 to 12/31 23:00. However, I
don't know how to change time settings if the run is from a random date, for example from 03/01 0:00 to 06/01
23:00. I know 'istep0' and 'npt' in namelist need to be changed, but it seems not enough. Is there anything else that
has to be changed?
Look forward to your reply.
Best wishes!

Sincerely,
Cao Shutao

 

[dbailey]

npt = the number of timesteps to run
dt = timestep
istep0 = the starting timestep

With dt =3600s, or one-hourly, a 31 day run would be npt = 24*31 = 744. For a one-year run, npt = 24*365 = 8760.

 

[tcraig]

I believe year_init and istep0 allow you to set the initial date. If dt is 1 hour and you'd like a start date of March 1, 2015, then try

year_init=2015
istep0=1464

istep0 is the initial number of timesteps. 1464 = 24 (timesteps/day) * 61 (days). If your timestep is not 1 hour, istep0 has to be adjusted accordingly.

 

[Alfred]

npt = the number of timesteps to run
dt = timestep
istep0 = the starting timestep

With dt =3600s, or one-hourly, a 31 day run would be npt = 24*31 = 744. For a one-year run, npt = 24*365 = 8760.

I want to use some ovservation data to forcing the Icepak, but the ovservartion is not whole year, which is from 10 April to 20 November, and Ta, U, V, radiation is hourly and the precipitation is daily. How can I modiy the setting?

Alfred

 

[eclare@lanl_gov]

As tcraig outlines above, you can calculate the istep0 value needed to start on 10 April, and then set npt for the number of timesteps to run through 10 Nov. The forcing routines in the code include the capability to interpolate data, which you can use as a guide - you'll need to set up your own subroutine to read your data at the frequency available, and then interpolate it to the timestep as needed.

 

[Alfred]

As tcraig outlines above, you can calculate the istep0 value needed to start on 10 April, and then set npt for the number of timesteps to run through 10 Nov. The forcing routines in the code include the capability to interpolate data, which you can use as a guide - you'll need to set up your own subroutine to read your data at the frequency available, and then interpolate it to the timestep as needed.

Thanks for youre reply. I confused with the parameter 'timestep' in the icedrv_forcing.F90. I am not sure if it is 'npt' (total number of time steps to take) or 'dt' (recommend 3600s, thermodynamics time step length) in the icepack_in?

 

[eclare@lanl_gov]

By 'timestep' I'm referring generically to the increment of time that the numerical model is solving the equations for during each step of the numerical simulation. The timestep length dt is often 3600s. npt controls the number of timesteps that the numerical model takes during a run. Depending on how the model namelist is configured, each timestep is associated with a particular time (date and hour), and you'd usually want your forcing data fields to be set appropriately for that time. To do that, you'll need to write a forcing routine for your particular data set, reading it in and perhaps interpolating it to the particular timestep as the model runs.

 

[Alfred]

By 'timestep' I'm referring generically to the increment of time that the numerical model is solving the equations for during each step of the numerical simulation. The timestep length dt is often 3600s. npt controls the number of timesteps that the numerical model takes during a run. Depending on how the model namelist is configured, each timestep is associated with a particular time (date and hour), and you'd usually want your forcing data fields to be set appropriately for that time. To do that, you'll need to write a forcing routine for your particular data set, reading it in and perhaps interpolating it to the particular timestep as the model runs.

Thanks for you reply. If 'timestep' referring generically to the increment of time (such as 3600s), the code of subroutine get_forcing(timestep) in the icedrv_forcing.F90 as follows, i = mod(timestep-1,ntime)+1, ntime is 8760, so i=3600, I don't understang the use of i.
if (trim(atm_data_type) == 'CFS') then
! calculate data index corresponding to current timestep
i = mod(timestep-1,ntime)+1 ! repeat forcing cycle
mlast = i
mnext = mlast
c1intp = c1
c2intp = c0

! fill all grid boxes with the same forcing data
Tair (:) = c1intp * Tair_data(mlast) + c2intp * Tair_data(mnext)
Qa (:) = c1intp * Qa_data(mlast) + c2intp * Qa_data(mnext)
uatm (:) = c1intp * uatm_data(mlast) + c2intp * uatm_data(mnext)
vatm (:) = c1intp * vatm_data(mlast) + c2intp * vatm_data(mnext)
fsnow(:) = c1intp * fsnow_data(mlast) + c2intp * fsnow_data(mnext)
flw (:) = c1intp * flw_data(mlast) + c2intp * flw_data(mnext)
fsw (:) = c1intp * fsw_data(mlast) + c2intp * fsw_data(mnext)

 

[eclare@lanl_gov]

I understand and apologize for the confusion. Now I realize you're asking about Icepack. In CICE we can set the start and end times for the forcing to match the run, but this hasn't been done yet for Icepack, as indicated in the comment at the top of subroutine get_forcing:

!ECH notes ! We will probably need to send in the time and work out what the data ! time slice is, instead of sending in the timestep. This currently assumes ! the time step and the data both start Jan 1.

Since the Icepack driver is only intended for testing, we haven't tried to make it as fully functional as CICE is. However you could do this using CICE's forcing routines as a guide, and we could then incorporate it into the repository following review and testing.

 

[Alfred]

I understand and apologize for the confusion. Now I realize you're asking about Icepack. In CICE we can set the start and end times for the forcing to match the run, but this hasn't been done yet for Icepack, as indicated in the comment at the top of subroutine get_forcing:

!ECH notes ! We will probably need to send in the time and work out what the data ! time slice is, instead of sending in the timestep. This currently assumes ! the time step and the data both start Jan 1.

Since the Icepack driver is only intended for testing, we haven't tried to make it as fully functional as CICE is. However you could do this using CICE's forcing routines as a guide, and we could then incorporate it into the repository following review and testing.

Thanks for your reply. I confused with the paremeter 'timestep' in this F90 (icedrv_forcing.F90), does it the 'dt' or 'ndt' input for icapack_in?

 

[eclare@lanl_gov]

The get_forcing subroutine is called from icedrv_InitMod.F90 and icedrv_RunMod.F90 (find it by typing 'get_forcing' into the search box in the top left corner of CICE-Consortium/Icepack and choose 'this repository'):

call get_forcing(istep1) ! get forcing from data arrays

istep1 is the timestep counter. In CICE, its values are istep0, istep0+1, istep0+2, ... istep0+npt.
istep0 is the initial timestep number, set in the namelist to make the run start on the particular date that you want. However, istep0 might not be implemented in the Icepack driver yet (and so would effectively be 0).

 

[eclare@lanl_gov]

Also, my comment at the top of get_forcing indicates that that subroutine needs to be modified in order to find the correct time slice when not starting both the run and the data on Jan 1. If you work out a nice way to do this, let us know. Otherwise we have plans to upgrade the time manager in both codes, but it might be a while in the future before it happens.

 

[Alfred]

Also, my comment at the top of get_forcing indicates that that subroutine needs to be modified in order to find the correct time slice when not starting both the run and the data on Jan 1. If you work out a nice way to do this, let us know. Otherwise we have plans to upgrade the time manager in both codes, but it might be a while in the future before it happens.

Tanks for your reply. I still try to modify the subroutine. I hope you could upgrade the time manager in the codes in future. Best regards, Alfred

 

[Alfred]

Also, my comment at the top of get_forcing indicates that that subroutine needs to be modified in order to find the correct time slice when not starting both the run and the data on Jan 1. If you work out a nice way to do this, let us know. Otherwise we have plans to upgrade the time manager in both codes, but it might be a while in the future before it happens.

Hi, I have another question. I run the Icepack with forcing data and compare the output with the input forcing, such as the down shortwave radiation, the out result and input data show the same. But I chose the dEdd sheme. The result show that the shortwave radiation parameterization scheme do not work. I don not find where so set to open the use of parameterization scheme.