Last edited Timestamp?

Author : Andy Ryan

ticket : #1358

Branch : 2014/dev_r4650_UKMO14.12_STAND_ALONE_OBSOPER

---

Description

The NEMO offline observationo operator needs to be updated, refactored and simplified. To allow the code to compile, the custom nemogcm.F90 must be updated to make it compatible with the latest version of OPA nemogcm.F90. The primary refactoring involves renaming the sub-directory containing the code from OOO_SRC to SAO_SRC, representing the name "Stand Alone Observation operator" which should make the purpose of the package clearer. A side effect of this change is that NEMO uses a hungarian notation style naming convention to reduce potential conflicts in the global namespace and also to ease location of a piece of code, in the context of OOO_SRC these will have to be updated from ooo to sao or be dropped. Other less obvious refactorings will present themselves during the development cycle. A suite of use-cases has been written to test the functionality of the compiled executable, these will be used ahead of every commit to ensure that functionality has not been affected by the refactoring process. There is also a suggestion by the external reviewer during the previous development cycle to change the way the I/O is controlled from the custom read/write code which is already in place to a more common framework seen in other stand alone executables such as OFF_SRC.

---

Use cases

The NEMO observation operator is a well used piece of code which has been extensively tested, as such, these use cases do not intend to be a complete suite of possible uses of the observation operator code. They are intended to cover the functionality expected by running it in stand alone mode.

• Sea surface temperature cases
  • single observation w/feedback file outputs
    • test correct values: SST_obs/SST_Hx
    • test correct temporal/spatial coordinates: latitude/longitude/julian day
    • test correct meta-data: station identifier, station type
    • test correct quality control
  • single observation out side of domain
    • test correct rejection
  • multiple model fields
• Altimetry cases
  • single observation inside/outside domain
  • multiple model fields
• Profile cases
  • single profile inside/outside domain
  • multiple model fields

When the base line tests are in place, altering the internal workings of the code (such as swapping out the read routines) shouldn't affect the results of the above tests. Some changes may be 'breaking' changes which alter the API these changes will be reflected in the accompanying documentation.

---

Testing

NVTK Tested	N/A
Other model configurations	orca025, ind12, natl12, med12
Processor configurations tested	32 processors
If adding new functionality please confirm that the New code doesn't change results when it is switched off and ''works'' when switched on	N/A

Note: NVTK testing is not appropriate for SAO_SRC code as it doesn't alter any OPA_SRC code.

The Stand Alone Observation (SAO) operator has been refactored to have a one way dependence on OPA_SRC. There is no longer SAO specific code in OPA_SRC/OBS. The SAO operator (in accordance with OBS design plans) reads and writes feedback files only.

• Stand Alone Observation (SAO) operator passes all "unit" test cases outlined above
• It has been tested using ORCA2, AMM12 and FOAM configurations ORCA025, NATL12, IND12 and MED12

Bit Comparability

Does this change preserve answers in your tested standard configurations (to the last bit) ?	'''YES/NO '''
Does this change bit compare across various processor configurations. (1xM, Nx1 and MxN are recommended)	'''YES/NO'''
Is this change expected to preserve answers in all possible model configurations?	'''YES/NO'''
Is this change expected to preserve all diagnostics? ,,''Preserving answers in model runs does not necessarily imply preserved diagnostics. ''	'''YES/NO'''

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?	'''NO '''
Does your change require a change in compiler options?	'''NO '''

If any of these apply, please document the changes required here.......

---

Resources

''Please ''summarize'' any changes in runtime or memory use caused by this change......''

---

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