Difference between revisions of "ntimes"
m (→NTIMES) (change visibility) |
|||
| Line 1: | Line 1: | ||
= NTIMES = | = NTIMES = | ||
NTIMES | NTIMES is the total number of baroclinic timesteps in the current run. In a strictly barotropic configuration (i.e CPP option [[SOLVE3D]] is undefined) NTIMES is the total number of barotropic timesteps. | ||
NTIMES determines the timestep on which the run will ''' | |||
'''Note that NTIMES determines the timestep on which the run will ''end'''''. Be aware that time step counting does not necessarily always start from 1. This could be so if [[ocean_time]] in the initial conditions file is not zero such as when: | |||
(1) You restart a crashed run from a Restart or History file | |||
(2) You chose a reference time for [[ocean_time]] that preceeds the time range you wish to simulate. For example, if your forcing file data uses ocean_time = "seconds since 2006-01-01 00:00:00", but you wish only to model the period from 2006-04-01 onward, you would set ocean_time = 7776000 (90 days since 2006-01-01 multiplied by 86400 seconds per day) in the initial conditions netcdf file. For [[DT]] of 180 seconds (480 timesteps per day) NTIMES = 7776480 would cause the run to conclude on 2006-04-02, i.e. it would only run for 1 day of simulated time. If you set NTIMES = 480 thinking this would be 1 day of simulation you will find ROMS will simply end immediately saying it is already done becuase the end time you requested predates the initial conditions. | |||
However, see [[DSTART]] for more information on how to shift the internal time keeping in ROMS without upsetting your ocean_time = "seconds since yyyy-mm-dd HH:MM:SS" convention. | |||
Revision as of 14:59, 14 December 2006
NTIMES
NTIMES is the total number of baroclinic timesteps in the current run. In a strictly barotropic configuration (i.e CPP option SOLVE3D is undefined) NTIMES is the total number of barotropic timesteps.
Note that NTIMES determines the timestep on which the run will end. Be aware that time step counting does not necessarily always start from 1. This could be so if ocean_time in the initial conditions file is not zero such as when:
(1) You restart a crashed run from a Restart or History file
(2) You chose a reference time for ocean_time that preceeds the time range you wish to simulate. For example, if your forcing file data uses ocean_time = "seconds since 2006-01-01 00:00:00", but you wish only to model the period from 2006-04-01 onward, you would set ocean_time = 7776000 (90 days since 2006-01-01 multiplied by 86400 seconds per day) in the initial conditions netcdf file. For DT of 180 seconds (480 timesteps per day) NTIMES = 7776480 would cause the run to conclude on 2006-04-02, i.e. it would only run for 1 day of simulated time. If you set NTIMES = 480 thinking this would be 1 day of simulation you will find ROMS will simply end immediately saying it is already done becuase the end time you requested predates the initial conditions.
However, see DSTART for more information on how to shift the internal time keeping in ROMS without upsetting your ocean_time = "seconds since yyyy-mm-dd HH:MM:SS" convention.
