Last edited Timestamp?


Author : Daley Calvert

ticket : #1332

Branch : https://forge.ipsl.jussieu.fr/nemo/browser/branches/2014/dev_r5134_UKMO4_CF_compliance


Description

This development implements compliance with the CF-1.5 standard, through a combination of changes to XIOS (via XIOS dev team) and the NEMO IOM module.

XIOS-1.0 r618 is required at version r5415 of the trunk and above.


Testing

NVTK TestedYES
Other model configurationsYES
Processor configurations tested[ 4x4, 2x2, 2x1, 1x2, 1x1 ] [attached XIOS, 1 XIOS server, 2 XIOS servers, 4 XIOS servers]
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

Mainly 2x2 decomposition, 10 day tests with ORCA2_LIM and some basic checking of ORCA2_LIM3. Tested at trunk version r5426 with XIOS-1.0 r618.

Tested with standard ORCA2_LIM and ORCA2_LIM3 iodef.xml namelists, iodef_ar5.xml and an iodef.xml file containing all possible outputs (not all of which were output by the model of course).

Issues encountered:

On the Met Office IBM there appears to be an issue with parallel write and detached XIOS: for 2+ XIOS servers in "one_file" mode there is a crash of sorts (no core file) in XIOS after it has completed the files (perhaps during finalization) and the job will hang. This is not an issue with attached XIOS. Unknown if this occurs on the Cray machine. Since this has not been reported elsewhere it is presumed to be a problem with our build, but it is noted here.

The iodef_ar5.xml file causes the job to hang in one_file mode for 2+ XIOS servers (another parallel write issue) while the scalar "transifs" variable is inside the "_icemod.nc" file. When moved to the scalar file the job proceeds ok. Perhaps an issue with XIOS? Unknown if anyone else in the institution has used the iodef_ar5.xml file for a while.


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

The changes significantly affecting file size are controlled by the ln_cfmeta namelist parameter; the equivalent of 5 global 2D arrays are added.

At ORCA2, the T grid file size (using standard iodef.xml for ORCA2_LIM) increases from 23.12Mb to 24.06Mb.


System Changes

Does your change alter namelists?YES
Does your change require a change in compiler options?NO

Parameter ln_cfmeta added to namrun. This controls the output of cell areas and cell vertices to all output files.


Resources

Results below are for ORCA2_LIM on a 2x2 decomposition with 1 XIOS server, multiple_file mode.

No notable change in run time.

Significant increase in highwater memory for NEMO-XIOS combined when using ln_cfmeta = .TRUE. (from ~2100Mb to ~2650Mb). Presumably this is on the XIOS side as the only extra NEMO arrays in memory are allocated and deallocated within a single initialization subroutine.


IPR issues

Has the code been wholly (100%) produced by NEMO developers staff working exclusively on NEMO?YES
Last modified 5 years ago Last modified on 2015-06-18T18:50:49+02:00