Last edited Timestamp?

Author : Andy Ryan (c/o Dan Lea)

ticket : #1148

Branch : ​dev_r3987_UKMO4_OBS

---

Description

The offline obs_oper consists of an alternative main program which calls routines in OBS to generate model observation match ups.

---

Testing

Testing could consider (where appropriate) other configurations in addition to NVTK].

SETTE Tested	YES
Other model configurations	YES: Gyre, ORCA2 ...
Processor configurations tested	[ 2x2, 1x4, 2x8, 4x4 ]
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 to both, solver.stat and ocean.output identical to trunk

(Answering UNSURE is likely to generate further questions from reviewers.)

'Please add further summary details here'

• Processor configurations tested
• etc----

The following tests have been run to test each of the common use cases.

1. Single profile against single uniform model field
2. Two profiles against two model fields
3. Single profile against zonally varying model fields
4. Single profile against meridionally varying model fields
5. Single profile against depth varying model fields
6. Single profile against multiple forecasts
7. Single SST observation against uniform model field

Case 1. Single profile uniform model field

For this unit test, a solitary AMM12 field was created with uniform temperature of 20C and salinity of 35PSU. This was compared against a single EN3 observation valid within the chosen time window and model domain.

Result: PASS

Case 2. Two profiles against two model fields

For this test the single observation from case 1 was duplicated with +1 latitude and +24 hours to create a second profile observation. A second AMM12 field was created to test the time step interpolation. The first AMM12 field consists of uniform temperature of 20C while the second contained uniform 25C. The run start and end dates were chosen to be 2 days long and the read in frequency was selected to be 1 day.

Result: PASS

Case 3. Single profile latitude interpolation

This unit test asserts that the lattitudinal interpolation is being performed correctly. An input AMM12 file was created with the model counterpart equal to the model domain nav_lat.

The observation latitude is 55.07 and the interpolated model counterpart is found to also be 55.07.

Result: PASS

Case 4. Single profile longitude interpolation

This unit test asserts that the longitudinal interpolation is being performed correctly. An input AMM12 file was created with the model counterpart equal to the model domain nav_lon.

The observation longitude is -13.49 and the interpolated model counterpart is found to be 346.51, or 360 - 13.49.

Result: PASS

Case 5. Single profile vertical interpolation

This unit test asserts that the vertical interpolation is being performed correctly. An input AMM12 file was created with the model counterpart equal to the model domain deptht.

The model counterpart is equal to the observation depth at all points.

Result: PASS

Case 6. Profile against multiple forecasts

This unit test asserts that multiple forecast lead times valid for the same observation are interpolated correctly and saved in the correct component of the output file. Since the horizontal, vertical and temporal interpolation properties were tested in previous cases it suffices to check a uniform field for each forecast. In this case, the forecast fields begin at T = 20C, 25C, 30C, ...

Result: PASS

Case 7. Single SST observation

This unit test case merely checks the behaviour of a different observation type than previous tests. The following ncdump snippet from the resulting class 4 file demonstrates the action for a single SST observation in the domain at the correct time.

data:

 leadtime = 12 ;

 longitude = -12.62207 ;

 latitude = 50.54785 ;

 depth =
  0 ;

 varname =
  "SST     " ;

 unitname =
  "Degree c" ;

 observation =
  15.99561 ;

 forecast =
  20 ;

...

 qc =
  1 ;

 juld = 23271.45 ;

 modeljuld = _ ;

 type =
  "28                                                                                                                              " ;

 id =
  "        " ;

Result: PASS

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

We added a ln_nightav namelist option to fix a bug in a previous commit whereby SST data was assuming night time average data in all cases. There is now a namelist variable in the OBS namelist to allow this to be turned on where night time average data is provided. Note without this change the offline observation operator code does not work since it currently has no concept of day time or night time as it does not run the ocean model.

---

Resources

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