[[PageOutline]] Last edited [[Timestamp]] [[BR]] '''Author''' : Andy Ryan (c/o Dan Lea) '''ticket''' : #1148 '''Branch''' : [http://forge.ipsl.jussieu.fr/nemo/browser/branches/2013/dev_r3987_UKMO4_OBS 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 [[BR]]New code doesn't change results when it is switched off [[BR]]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 1. Two profiles against two model fields 1. Single profile against zonally varying model fields 1. Single profile against meridionally varying model fields 1. Single profile against depth varying model fields 1. Single profile against multiple forecasts 1. 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. [[Image(fdbk_case_1.gif, 400px)]] '''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. [[Image(fdbk_case_2.1.gif, 400px)]] [[Image(fdbk_case_2.2.gif, 400px)]] '''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. [[Image(class4_zonal.gif, 400px)]] 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. [[Image(class4_meridional.gif, 400px)]] 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. [[Image(class4_depth.gif, 400px)]] 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, ... [[Image(class4_case_1.2.gif, 400px)]] '''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? [[BR]]!,,!''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..........