[[PageOutline]] Last edited [[Timestamp]] [[BR]] '''Author''' : Steven Alderson '''ticket''' : #932 '''Branch''' : [https://forge.ipsl.jussieu.fr/nemo/browser/branches/2012/dev_r3322_NOCS09_SAS dev_r3322_NOCS09_SAS ] ---- == '''NOCS.09 — Stand alone surface module''' == ''' Motivation:''' A standalone surface module is proposed which will allow surface elements such as sea-ice, iceberg drift and surface fluxes to be run using prescribed model state fields. For example, it can be used to inter-compare different bulk formulae or adjust the parameters of a given bulk formula [[BR]] ''' Status: ''' Branch created [[BR]] ''' Main task''' (3 wk)[[BR]] (1) Create new NEMO sub-directory (SAS_SRC) which will contain a cut down set of routines to read in or interpolate ocean state at any time and then run all surface routines required. [[BR]] (2) Write new version of nemogcm for initialising required modules and time-stepping through them [[BR]] (3) Write new routine to read in ocean state [[BR]] (4) Look at most convenient form for input data and see if fldread can be modified accordingly [[BR]] (5) Validation and Documentation [[BR]] ''' Deadline :''' September 2012 [[BR]] ''' Priority: ''' High[[BR]] ''' Science Reviewer :''' Gurvan Madec [[BR]] ''' System Reviewer : ''' INGV [[BR]] ''' Principal Investigator :''' Steven Alderson (sga@noc.ac.uk) ---- == ''' Detail of the implementation''' == A new copy of the model has to be compiled with a configuration based on ORCA2_SAS_LIM. However no namelist parameters need be changed from the settings of the previous run (except perhaps nn_date0). In this configuration, a few routines in the standard model are overriden by new versions. This is achieved by creating a new sub-directory SAS_SRC which includes copies of new versions of routines. By specifying the order in which sub-directories are included in the build (i.e. SAS_SRC after OPA_SRC in cfg.txt), files with the same name in SAS_SRC are preferentially used over those in OPA_SRC. Routines in SAS_SRC are: nemogcm.F90 This routine initialises the rest of the model and repeatedly calls the stp time stepping routine (step.F90) Since the ocean state is not calculated all associated initialisations have been removed. step.F90 The main time stepping routine now only needs to call the sbc routine (and a few utility functions). daymod.F90 No ocean restarts are read or written (though the ice model restarts are retained), so calls to restart functions have been removed. This also means that the calendar cannot be controlled by time in a restart file, so the user must make sure that nn_date0 in the model namelist is correct for his or her purposes. stpctl.F90 Since there is no free surface solver, references to it have been removed from stp_ctl. diawri.F90 All 3D data have been removed from the output. The surface temperature, salinity and velocity components (which have been read in) are written along with relevant forcing and ice data. The surface velocity is now also written into the mean files as a 2D field. The internal workings of one routine have been completely replaced (which means that sbcmod does not have to be modified): sbcssm.F90 This routine now initialises the input files needed for reading temperature, salinity, velocity and sea surface height arrays at the surface. These filenames are supplied in namelist namsbc_ssm. Unfortunately because of limitations with the iom module, the full 3D velocity fields from the mean files have to be read in and interpolated in time, before using just the top level. However an option is included to read 2D velocity fields if they are available in the input file, but ln_3d_uv must be explicitly set to be false in the namelist for the code to be able to use them. Since fldread is used to read in the data, Interpolation on the Fly may be used to change input data resolution. Routines in OPA_SRC changed: sbcssm.F90 Initialisation on the first time step has been replaced by initialisation before the first time step in a new subroutine sbc_ssm_init called from sbc_init. sbcmod.F90 Subroutine sbc_init now includes a call to sbc_ssm_init to mirror its introduction in SAS_SRC/sbcssm. This allows the SAS code to switch off non-relevant options before they are acted upon. ---- == ''' Further Discussion''' == Some of the above changes has implications for other parts of the code (and therefore outside the remit of this branch): * daymod currently includes a call to open the ocean restart file for writing. The offline code (OFF_SRC) modifies this with the lk_offline key and replaces control of nitrst with code in trcrst.F90. I wonder if control functionality for all restarts should be in its own routine and removed from restart.F90, daymod.F90 and trcrst.F90. This would mean the above SAS_SRC daymod is unnecessary. * There are now three copies of nemogcm with repeat non-overlapping code. I think this part of these files should be moved into a separate file so there is no danger of divergence when the original OPA_SRC copy of nemogcm is modified. ---- == ''' Test Case ''' == A standard ORCA2 configuration is run for one year with five day mean output. The mean files are then combined into single files containing 73 means covering the globe. The SAS configuration is then run for one year with surface temperature, salinity and velocity read from this standard run. This run is started from 5th January in order to avoid interpolation between records 73 and 1 in the inputs and the resulting starting transients. [[Image(sas_mean_diff2.png)]] Figure 1: Mean and +/- 1 standard deviation of the differences between fields in the 5-day mean files from the control and the SAS runs. Three variables are plotted: ice fraction, total radiation and solar radiation. Ocean only values are used (including the ice difference). Differences are reasonable, except perhaps near the beginning and around 150 days. Those around 150 days are due to large differences in the ice fields in Hudson Bay. [[Image(sas_year_diff2.png)]] Figure 2: Difference between end-of-year fields in the 5-day mean files from the control and the SAS runs. Reasonably small differences. But a large discrepancy near Kamchatka Peninsula. Restartability is still an issue when running SAS, because of the ice model restarting between job segments. So a SAS run has been broken down into two segments of 20 days each. The results at 40 days can then be compared when restarting from 20 days (changing nn_date0 accordingly) and when running for the full 40 days. Differences turn out to be identically zero. ---- == ''' Comments / ideas ''' == Nice test case. It should be interesting to redo it with no time interpolation. In this case, the qsr should be identical but in icy area. Gurvan ---- === Testing === Testing could consider (where appropriate) other configurations in addition to NVTK]. ||NVTK Tested||!'''NO!'''|| ||Other model configurations||!'''YES!'''|| ||Processor configurations tested||[ ORCA2_SAS_LIM ]|| ||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||!'''NA!'''|| For this code, running without it switched on is a null test. Results with SAS are only an approximation to the original run (see Test Case above). NOC SGI Altix cluster running with ifort compiler. Also with key_agrif, code has been compiled with gfortran (gcc 4.5.3). There were problems compiling using gcc 4.3.1 (not related to this branch). === Bit Comparability === ||Does this change preserve answers in your tested standard configurations (to the last bit) ?||!'''NA!'''|| ||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?||!'''NA!'''|| ||Is this change expected to preserve all diagnostics? [[BR]]!,,!''Preserving answers in model runs does not necessarily imply preserved diagnostics. !''||!'''NA!'''|| 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 !'''|| An extra namelist is required in order to supply source data filenames for sst, sss, ssu and ssv. ---- === Resources === !''Please !''summarize!'' any changes in runtime or memory use caused by this change......!'' Memory and runtime are both significantly reduced by use of this configuration. Only four 3D arrays are allocated in this configuration in fld_read, Most of the stp routine is not used. ---- === 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..........