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.

---

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..........