#265 closed Bug (fixed)
possible bug in daymod module relating to multi-year runs
Reported by: | nemo_user | Owned by: | nemo |
---|---|---|---|
Priority: | low | Milestone: | |
Component: | OCE | Version: | v3.0 |
Severity: | Keywords: | OPA v3.0 | |
Cc: |
Description
In the daymod module subroutine day_init() the real variable sec1jan000
(seconds since Jan. 1st 00h of nit000 year) is calculated from the current day ndastp
this is done in line 113:
sec1jan000 = sec1jan000 - rday * REAL( nyear_len(0), wp )
wouldn't calculating it this way would mean that sec1jan000 would be negative (as it is initialised to 0.e0)?
Ed
Commit History (0)
(No commits)
Change History (7)
comment:1 Changed 16 years ago by smasson
- Resolution set to fixed
- Status changed from new to closed
comment:2 Changed 8 years ago by nicolasmartin
- Keywords bug removed
comment:3 Changed 8 years ago by nicolasmartin
- Keywords nemo_v3* added
comment:4 Changed 8 years ago by nicolasmartin
- Keywords day_init daymod removed
comment:5 Changed 6 years ago by nemo
- Keywords release-3.0 added; nemo_v3* removed
comment:6 Changed 2 years ago by nemo
- Keywords OPA r3.0 added; release-3.0 removed
comment:7 Changed 2 years ago by nemo
- Keywords v3.0 added; r3.0 removed
Note: See
TracTickets for help on using
tickets.
Daymod is called at the beginning of step. So, in the initialization phase, calendar parameters are set one time step before the beginning of the run (nit000). If your run starts on Jan 1st, you will endup the year before. In this case, YES sec1jan000 will be negative and this is not a bug. Note that at the first call of step, you will go back to the current year and sec1jan000 will ne redefined to 0.