Met_Office-1 Use XIOS to read single file restart file

[andmirek]

Context

This development is to add functionality to read single file restart with XIOS

Analysis

Currently for a single file restart all processors open the file and read corresponding data. This method becomes inefficient when large number of processors is used to run NEMO. Recent XIOS version (ver. 2) has the capability to read data. This capability may be used to read restart if needed. This would be an addition to the existing reading functionality, activated through the variable in the namelist. https://forge.ipsl.jussieu.fr/nemo/wiki/2017WP/Met_Office-1_Mirek_XIOSread

Fix

...

[andmirek]

Branch created: branches/UKMO/dev_r5518_GO6_package_XIOS_read: https://forge.ipsl.jussieu.fr/nemo/log/branches/UKMO/dev_r5518_GO6_package_XIOS_read. Restart read functionality works and there is no need to define file in the new context in iodef.xml. iodef.xml (and other xml files) modified in CONFIG/GYRE_XIOS/EXP00/domain_def.xml to provide a template for use of xios read functionality.

[andmirek]

revision 8153 disables reading restart with xios when AGRIF is used. SETTE test resulted in error: "Incoherent data received from servers, expected 2 chunks but 1 were given." Similar error was reported by Samantha Adams in a different context (see XIOS mailing list in June 2017: Can anyone help with the meaning of this error message?). The possible reasons for this error were given, but I can not relate any of them to this case.

[andmirek]

With the latest commit @8293 this branch works with Agrif. Performance of the read interface is far from perfect for high resolution (GO6, ORCA12 - MetOffice?) configurations. There are also failures when reading restart for large number of processors. Reading functionality works when domain is decomposed using up to 60x60 processors (with land suppression on), but fails when 70x70 (or more) is used. For ORCA25 XIOS read interface works fine up to 1440 processors, but is slower than reading single file restart with default NEMO interface.

For a single restart file XIOS can almost match default NEMO read functionality, but the interface is slower than reading multiple restart files (each processor is reading its own domain).

MetOffice? twiki page: ​http://www-twiki/Main/GO6eORCA12TechnicalImprovements

[andmirek]

#1953 documents development for WP2017

[andmirek]

In 9424:

Error: Failed to load processor CommitTicketReference

No macro or processor named 'CommitTicketReference' found

[andmirek]

A problem was encountered when testing performance of XIOS read interface for ORCA12 with land suppression. For some decomposition solver didn't converge (with NaNs?) on the first timestep. The problem is most likely related to the way XIOS reads data (must be doing it differently than default NEMO interface). Setting output arrays to 0 in iom_get_123d resolved the issue. But in the future use of appropriate masks may need to be considered. Fix is in revision 9424. The same fix fill have to be applied to the trunk.