Version 5 (modified by djlea, 9 years ago) (diff) |
---|
Last edited Timestamp?
Author : Daniel Lea
ticket : #1310
Branch : dev_r4650_UKMO7_STARTHOUR
Description
NEMO is hard-wired to always start a run at the start of the day (at 0z). I propose to extend the option of setting the start date to allow for the setting of a start time via a namelist option.
There was an old ticket which dealt with starting runs at arbitrary times (#1037). It was implemented here by changing the initial time step, but it was never committed to the trunk. The main problem with the approach suggested though was that if you change the length of the time step that would result in a potentially unpredictable change in the start time. The way it is done here by explicitly specifying the start time it is more flexible and controllable.
The changes to the code are quite minimal and are mainly in the daymod routine. There are a few changes to OBS and ASM to make them aware of the start time. I did take the opportunity to tidy up the date calculation code in ASM to remove some duplication of code.
Testing
Testing could consider (where appropriate) other configurations in addition to SETTE].
SETTE Tested | YES |
Other model configurations | ORCA2, AMM12 |
Processor configurations tested | All the standard SETTE tests |
If adding new functionality please confirm that the New code doesn't change results when it is switched off and ''works'' when switched on | YES |
(Answering UNSURE is likely to generate further questions from reviewers.)
'Please add further summary details here'
- The code passes all SETTE tests (at r5072 of the trunk)
- If start time = 0000 then results of SETTE test results don’t change (this is the default if the start time is not specified)
- AMM12 is restartable with start time 0600 and all write statements indicate that correct forcing files are being read in to the model. AMM12 includes tides and these was the hardest bit to get right (but it now works!)
- I've tested the code with runs of less than a day and it is now restartable (this previously wasn't the case and also isn't for the trunk). I also tested this with starthour 1200.
Bit Comparability
Does this change preserve answers in your tested standard configurations (to the last bit) ? | YES |
Does this change bit compare across various processor configurations. (1xM, Nx1 and MxN are recommended) | YES |
Is this change expected to preserve answers in all possible model configurations? | YES |
Is this change expected to preserve all diagnostics? ,,''Preserving answers in model runs does not necessarily imply preserved diagnostics. '' | YES |
If you answered '''NO''' to any of the above, please provide further details:
- Which routine(s) are causing the difference?
- Why the changes are not protected by a logical switch or new section-version
- What is needed to achieve regression with the previous model release (e.g. a regression branch, hand-edits etc). If this is not possible, explain why not.
- What do you expect to see occur in the test harness jobs?
- Which diagnostics have you altered and why have they changed?Please add details here........
System Changes
Does your change alter namelists? | YES |
Does your change require a change in compiler options? | NO |
If any of these apply, please document the changes required here.......
There is an additional namelist variable nn_time0 in namrun namelist which is used to specify the start time in hours and minutes (HHMM) for the run.
Resources
''Please ''summarize'' any changes in runtime or memory use caused by this change......''
None
IPR issues
Has the code been wholly (100%) produced by NEMO developers staff working exclusively on NEMO? | YES |
If No:
- Identify the collaboration agreement details
- Ensure the code routine header is in accordance with the agreement, (Copyright/Redistribution? etc).Add further details here if required..........