Changes between Version 2 and Version 3 of ticket/1332


Ignore:
Timestamp:
2015-06-18T18:50:49+02:00 (5 years ago)
Author:
hadcv
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • ticket/1332

    v2 v3  
    99 
    1010'''Branch''' : https://forge.ipsl.jussieu.fr/nemo/browser/branches/2014/dev_r5134_UKMO4_CF_compliance 
     11 
    1112---- 
    1213 
    1314=== Description === 
    1415 
    15 The development aims to make NEMO-XIOS output CF-1.5 compatible. This will be done through a combination of proposed changes to both XIOS (via XIOS dev team) and the NEMO IO modules. 
     16This 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. 
     17 
     18'''XIOS-1.0 r618''' is required at version r5415 of the trunk and above. 
    1619 
    1720---- 
     21 
    1822=== Testing === 
    19 Testing could consider (where appropriate) other configurations in addition to NVTK]. 
    2023 
    21 ||NVTK Tested||!'''YES/NO!'''|| 
    22 ||Other model configurations||!'''YES/NO!'''|| 
    23 ||Processor configurations tested||[ Enter processor configs tested here ]|| 
    24 ||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/NO/NA!'''|| 
     24||NVTK Tested||'''YES'''|| 
     25||Other model configurations||'''YES'''|| 
     26||Processor configurations tested||'''[ 4x4, 2x2, 2x1, 1x2, 1x1 ] [attached XIOS, 1 XIOS server, 2 XIOS servers, 4 XIOS servers]''' || 
     27||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'''|| 
    2528 
    26 (Answering UNSURE is likely to generate further questions from reviewers.) 
     29Mainly 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. 
    2730 
    28 'Please add further summary details here' 
     31Tested 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). 
    2932 
    30  * Processor configurations tested 
    31  * etc---- 
     33'''Issues encountered:''' 
     34 
     35On 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. 
     36 
     37The 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. 
     38 
     39---- 
    3240 
    3341=== Bit Comparability === 
    34 ||Does this change preserve answers in your tested standard configurations (to the last bit) ?||!'''YES/NO !'''|| 
    35 ||Does this change bit compare across various processor configurations. (1xM, Nx1 and MxN are recommended)||!'''YES/NO!'''|| 
    36 ||Is this change expected to preserve answers in all possible model configurations?||!'''YES/NO!'''|| 
    37 ||Is this change expected to preserve all diagnostics? [[BR]]!,,!''Preserving answers in model runs does not necessarily imply preserved diagnostics. !''||!'''YES/NO!'''|| 
     42||Does this change preserve answers in your tested standard configurations (to the last bit) ?||'''YES'''|| 
     43||Does this change bit compare across various processor configurations. (1xM, Nx1 and MxN are recommended)||'''YES'''|| 
     44||Is this change expected to preserve answers in all possible model configurations?||'''YES'''|| 
     45||Is this change expected to preserve all diagnostics? [[BR]]!,,!''Preserving answers in model runs does not necessarily imply preserved diagnostics. !''||'''YES'''|| 
    3846 
    39 If you answered !'''NO!''' to any of the above, please provide further details: 
     47The changes significantly affecting file size are controlled by the '''ln_cfmeta''' namelist parameter; the equivalent of 5 global 2D arrays are added. 
    4048 
    41  * Which routine(s) are causing the difference? 
    42  * Why the changes are not protected by a logical switch or new section-version 
    43  * 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. 
    44  * What do you expect to see occur in the test harness jobs? 
    45  * Which diagnostics have you altered and why have they changed?Please add details here........ 
     49At ORCA2, the T grid file size (using standard iodef.xml for ORCA2_LIM) increases from 23.12Mb to 24.06Mb. 
    4650 
    4751---- 
     52 
    4853=== System Changes === 
    49 ||Does your change alter namelists?||!'''YES/NO !'''|| 
    50 ||Does your change require a change in compiler options?||!'''YES/NO !'''|| 
     54||Does your change alter namelists?||'''YES'''|| 
     55||Does your change require a change in compiler options?||'''NO'''|| 
    5156 
    52 If any of these apply, please document the changes required here....... 
     57Parameter '''ln_cfmeta''' added to namrun. This controls the output of cell areas and cell vertices to all output files. 
    5358 
    5459---- 
     60 
    5561=== Resources === 
    56 !''Please !''summarize!'' any changes in runtime or memory use caused by this change......!'' 
     62 
     63Results below are for ORCA2_LIM on a 2x2 decomposition with 1 XIOS server, multiple_file mode. 
     64 
     65No notable change in run time. 
     66 
     67Significant 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. 
    5768 
    5869---- 
     70 
    5971=== IPR issues === 
    60 ||Has the code been wholly (100%) produced by NEMO developers staff working exclusively on NEMO?||!'''YES/ NO !'''|| 
    61  
    62 If No: 
    63  
    64  * Identify the collaboration agreement details 
    65  * Ensure the code routine header is in accordance with the agreement, (Copyright/Redistribution etc).Add further details here if required.......... 
     72||Has the code been wholly (100%) produced by NEMO developers staff working exclusively on NEMO?||'''YES'''||