Standard model Output (IOM)

Since version 3.2, iomput is the NEMO output interface of choice. It has been designed to be simple to use, flexible and efficient. The two main purposes of iomput are:

1. The complete and flexible control of the output files through external XML files adapted by the user from standard templates.
2. To achieve high performance and scalable output through the optional distribution of all diagnostic output related tasks to dedicated processes.

The first functionality allows the user to specify, without code changes or recompilation, aspects of the diagnostic output stream, such as:

• The choice of output frequencies that can be different for each file (including real months and years).
• The choice of file contents; includes complete flexibility over which data are written in which files (the same data can be written in different files).
• The possibility to split output files at a choosen frequency.
• The possibility to extract a vertical or an horizontal subdomain.
• The choice of the temporal operation to perform, e.g.: average, accumulate, instantaneous, min, max and once.
• Control over metadata via a large XML "database" of possible output fields.

In addition, iomput allows the user to add the output of any new variable (scalar, 2D or 3D) in the code in a very easy way. All details of iomput functionalities are listed in the following subsections. Examples of the XML files that control the outputs can be found in:

NEMOGCM/CONFIG/ORCA2_LIM/EXP00/iodef.xml


NEMOGCM/CONFIG/SHARED/field_def.xml


and


NEMOGCM/CONFIG/SHARED/domain_def.xml.

The second functionality targets output performance when running in parallel (key_ mpp_mpi). Iomput provides the possibility to specify N dedicated I/O processes (in addition to the NEMO processes) to collect and write the outputs. With an appropriate choice of N by the user, the bottleneck associated with the writing of the output files can be greatly reduced. In version 3.6, the iom_put interface depends on an external code called XIOS-1.0 (use of revision 618 or higher is required). This new IO server can take advantage of the parallel I/O functionality of NetCDF4 to create a single output file and therefore to bypass the rebuilding phase. Note that writing in parallel into the same NetCDF files requires that your NetCDF4 library is linked to an HDF5 library that has been correctly compiled (i.e. with the configure option $--$enable-parallel). Note that the files created by iomput through XIOS are incompatible with NetCDF3. All post-processsing and visualization tools must therefore be compatible with NetCDF4 and not only NetCDF3. Even if not using the parallel I/O functionality of NetCDF4, using N dedicated I/O servers, where N is typically much less than the number of NEMO processors, will reduce the number of output files created. This can greatly reduce the post-processing burden usually associated with using large numbers of NEMO processors. Note that for smaller configurations, the rebuilding phase can be avoided, even without a parallel-enabled NetCDF4 library, simply by employing only one dedicated I/O server.

XIOS: the IO_SERVER

Attached or detached mode?

Iomput is based on XIOS, the io_server developed by Yann Meurdesoif from IPSL. The behaviour of the io subsystem is controlled by settings in the external XML files listed above. Key settings in the iodef.xml file are using_server and the type tag associated with each defined file. The using_server setting determines whether or not the server will be used in ”attached mode” (as a library) [false] or in ”detached mode” (as an external executable on N additional, dedicated cpus) [true]. The ”attached mode” is simpler to use but much less efficient for massively parallel applications. The type of each file can be either ”multiple_file” or ”one_file”. In attached mode and if the type of file is ”multiple_file”, then each NEMO process will also act as an IO server and produce its own set of output files. Superficially, this emulates the standard behaviour in previous versions, However, the subdomain written out by each process does not correspond to the jpi x jpj x jpk domain actually computed by the process (although it may if jpni=1). Instead each process will have collected and written out a number of complete longitudinal strips. If the ”one_file” option is chosen then all processes will collect their longitudinal strips and write (in parallel) to a single output file. In detached mode and if the type of file is ”multiple_file”, then each stand-alone XIOS process will collect data for a range of complete longitudinal strips and write to its own set of output files. If the ”one_file” option is chosen then all XIOS processes will collect their longitudinal strips and write (in parallel) to a single output file. Note running in detached mode requires launching a Multiple Process Multiple Data (MPMD) parallel job. The following subsection provides a typical example but the syntax will vary in different MPP environments.

Number of cpu used by XIOS in detached mode

The number of cores used by the XIOS is specified when launching the model. The number of cores dedicated to XIOS should be from 1/10 to 1/50 of the number or cores dedicated to NEMO. Some manufacturers suggest using O($\sqrt{N}$) dedicated IO processors for N processors but this is a general recommendation and not specific to NEMO. It is difficult to provide precise recommendations because the optimal choice will depend on the particular hardware properties of the target system (parallel filesystem performance, available memory, memory bandwidth etc.) and the volume and frequency of data to be created. Here is an example of 2 cpus for the io_server and 62 cpu for nemo using mpirun: mpirun -np 62 ./nemo.exe : -np 2 ./xios_server.exe

Control of XIOS: the XIOS context in iodef.xml

As well as the using_server flag, other controls on the use of XIOS are set in the XIOS context in iodef.xml. See the XML basics section below for more details on XML syntax and rules.

variable name	description	example
buffer_size	buffer size used by XIOS to send data from NEMO to XIOS. Larger is more efficient. Note that needed/used buffer sizes are summarized at the end of the job	25000000
buffer_server_factor_size	ratio between NEMO and XIOS buffer size. Should be 2.	2
info_level	verbosity level (0 to 100)	0
using_server	activate attached(false) or detached(true) mode	true
using_oasis	XIOS is used with OASIS(true) or not (false)	false
oasis_codes_id	when using oasis, define the identifier of NEMO in the namcouple. Note that the identifier of XIOS is xios.x	oceanx

Practical issues

Installation

As mentioned, XIOS is supported separately and must be downloaded and compiled before it can be used with NEMO. See the installation guide on the XIOS wiki for help and guidance. NEMO will need to link to the compiled XIOS library. The XIOS with NEMO guide provides an example illustration of how this can be achieved.

Add your own outputs

It is very easy to add your own outputs with iomput. Many standard fields and diagnostics are already prepared (i.e., steps 1 to 3 below have been done) and simply need to be activated by including the required output in a file definition in iodef.xml (step 4). To add new output variables, all 4 of the following steps must be taken.

1.

in NEMO code, add a
CALL iom_put( 'identifier', array )
where you want to output a 2D or 3D array.

2.

If necessary, add
USE iom ! I/O manager library
to the list of used modules in the upper part of your module.

3.

in the field_def.xml file, add the definition of your variable using the same identifier you used in the f90 code (see subsequent sections for a details of the XML syntax and rules). For example:

  

   <field_definition>

      <!-- T grid -->



     <field_group id="grid_T" grid_ref="grid_T_3D">

      ...

      <field id="identifier" long_name="blabla" ... />   

      ...

   </field_definition> 

Note your definition must be added to the field_group whose reference grid is consistent with the size of the array passed to iomput. The grid_ref attribute refers to definitions set in iodef.xml which, in turn, reference grids and axes either defined in the code (iom_set_domain_attr and iom_set_axis_attr in iom.F90) or defined in the domain_def.xml file. E.g.:

  

     <grid id="grid_T_3D" domain_ref="grid_T" axis_ref="deptht"/>

Note, if your array is computed within the surface module each nn_fsbc time_step, add the field definition within the field_group defined with the id ”SBC”: $<$field_group id=”SBC”...$>$ which has been defined with the correct frequency of operations (iom_set_field_attr in iom.F90)

4.

add your field in one of the output files defined in iodef.xml (again see subsequent sections for syntax and rules)

  

   <file id="file1" .../>   

      ...

      <field field_ref="identifier" />   

      ...

   </file>   

XML fundamentals

XML basic rules

XML tags begin with the less-than character ("$<$") and end with the greater-than character (”$>$”). You use tags to mark the start and end of elements, which are the logical units of information in an XML document. In addition to marking the beginning of an element, XML start tags also provide a place to specify attributes. An attribute specifies a single property for an element, using a name/value pair, for example: $<$a b="x" c="y" b="z"$>$ ... $<$/a$>$. See here for more details.

Structure of the xml file used in NEMO

The XML file used in XIOS is structured by 7 families of tags: context, axis, domain, grid, field, file and variable. Each tag family has hierarchy of three flavors (except for context):

flavor	description	example
root	declaration of the root element that can contain element groups or elements	< file_definition ... >
group	declaration of a group element that can contain element groups or elements	< file_group ... >
element	declaration of an element that can contain elements	< file ... >

Each element may have several attributes. Some attributes are mandatory, other are optional but have a default value and other are are completely optional. Id is a special attribute used to identify an element or a group of elements. It must be unique for a kind of element. It is optional, but no reference to the corresponding element can be done if it is not defined.

The XML file is split into context tags that are used to isolate IO definition from different codes or different parts of a code. No interference is possible between 2 different contexts. Each context has its own calendar and an associated timestep. In NEMO, we used the following contexts (that can be defined in any order):

context	description	example
context xios	context containing information for XIOS	<context id="xios" ...
context nemo	context containing IO information for NEMO (mother grid when using AGRIF)	<context id="nemo" ...
context 1_nemo	context containing IO information for NEMO child grid 1 (when using AGRIF)	<context id="1_nemo" ...
context n_nemo	context containing IO information for NEMO child grid n (when using AGRIF)	<context id="n_nemo" ...

The xios context contains only 1 tag:

context tag	description	example
variable_definition	define variables needed by XIOS. This can be seen as a kind of namelist for XIOS.	<variable_definition ...

Each context tag related to NEMO (mother or child grids) is divided into 5 parts (that can be defined in any order):

context tag	description	example
field_definition	define all variables that can potentially be outputted	<field_definition ...
file_definition	define the netcdf files to be created and the variables they will contain	<file_definition ...
axis_definition	define vertical axis	<axis_definition ...
domain_definition	define the horizontal grids	<domain_definition ...
grid_definition	define the 2D and 3D grids (association of an axis and a domain)	<grid_definition ...

Nesting XML files

The XML file can be split in different parts to improve its readability and facilitate its use. The inclusion of XML files into the main XML file can be done through the attribute src:
<context src="./nemo_def.xml" />

In NEMO, by default, the field and domain definition is done in 2 separate files:

NEMOGCM/CONFIG/SHARED/field_def.xml
and
NEMOGCM/CONFIG/SHARED/domain_def.xml

that are included in the main iodef.xml file through the following commands:
<field_definition src="./field_def.xml" />
<domain_definition src="./domain_def.xml" />

Use of inheritance

XML extensively uses the concept of inheritance. XML has a tree based structure with a parent-child oriented relation: all children inherit attributes from parent, but an attribute defined in a child replace the inherited attribute value. Note that the special attribute ”id” is never inherited.

example 1: Direct inheritance.

      

   <field_definition operation="average" >

     <field id="sst"                    />   <!-- averaged      sst --> 

     <field id="sss" operation="instant"/>   <!-- instantaneous sss --> 

   </field_definition> 

The field ”sst” which is part (or a child) of the field_definition will inherit the value ”average” of the attribute ”operation” from its parent. Note that a child can overwrite the attribute definition inherited from its parents. In the example above, the field ”sss” will for example output instantaneous values instead of average values.

example 2: Inheritance by reference.

  

   <field_definition>

     <field id="sst" long_name="sea surface temperature" />   

     <field id="sss" long_name="sea surface salinity"    />  

   </field_definition>      



   <file_definition>

     <file id="myfile" output_freq="1d" />   

       <field field_ref="sst"                            />  <!-- default def -->

       <field field_ref="sss" long_name="my description" />  <!-- overwrite   -->

     </file>   

   </file_definition> 

Inherit (and overwrite, if needed) the attributes of a tag you are refering to.

Use of Groups

Groups can be used for 2 purposes. Firstly, the group can be used to define common attributes to be shared by the elements of the group through inheritance. In the following example, we define a group of field that will share a common grid ”grid_T_2D”. Note that for the field ”toce”, we overwrite the grid definition inherited from the group by ”grid_T_3D”.

  

   <field_group id="grid_T" grid_ref="grid_T_2D">

    <field id="toce" long_name="temperature"             unit="degC" grid_ref="grid_T_3D"/>

    <field id="sst"  long_name="sea surface temperature" unit="degC"                     />

    <field id="sss"  long_name="sea surface salinity"    unit="psu"                      />

    <field id="ssh"  long_name="sea surface height"      unit="m"                        />

         ...

Secondly, the group can be used to replace a list of elements. Several examples of groups of fields are proposed at the end of the file CONFIG/SHARED/field_def.xml. For example, a short list of the usual variables related to the U grid:

  

   <field_group id="groupU" >

    <field field_ref="uoce"  />

    <field field_ref="suoce" />

    <field field_ref="utau"  />

   </field_group>

that can be directly included in a file through the following syntax:

  

   <file id="myfile_U" output_freq="1d" />   

    <field_group group_ref="groupU"/>  

    <field field_ref="uocetr_eff"  />  <!-- add another field -->

   </file>   

Detailed functionalities

The file NEMOGCM/CONFIG/ORCA2_LIM/iodef_demo.xml provides several examples of the use of the new functionalities offered by the XML interface of XIOS.

Define horizontal subdomains

Horizontal subdomains are defined through the attributs zoom_ibegin, zoom_jbegin, zoom_ni, zoom_nj of the tag family domain. It must therefore be done in the domain part of the XML file. For example, in CONFIG/SHARED/domain_def.xml, we provide the following example of a definition of a 5 by 5 box with the bottom left corner at point (10,10).

  

   <domain_group id="grid_T">

    <domain id="myzoom" zoom_ibegin="10" zoom_jbegin="10" zoom_ni="5" zoom_nj="5" />

The use of this subdomain is done through the redefinition of the attribute domain_ref of the tag family field. For example:

  

   <file id="myfile_vzoom" output_freq="1d" >

      <field field_ref="toce" domain_ref="myzoom"/>

   </file>

Moorings are seen as an extrem case corresponding to a 1 by 1 subdomain. The Equatorial section, the TAO, RAMA and PIRATA moorings are alredy registered in the code and can therefore be outputted without taking care of their (i,j) position in the grid. These predefined domains can be activated by the use of specific domain_ref: ”EqT”, ”EqU” or ”EqW” for the equatorial sections and the mooring position for TAO, RAMA and PIRATA followed by ”T” (for example: ”8s137eT”, ”1.5s80.5eT” ...)

  

   <file id="myfile_vzoom" output_freq="1d" >

      <field field_ref="toce" domain_ref="0n180wT"/>

   </file>

Note that if the domain decomposition used in XIOS cuts the subdomain in several parts and if you use the ”multiple_file” type for your output files, you will endup with several files you will need to rebuild using unprovided tools (like ncpdq and ncrcat, see nco manual). We are therefore advising to use the ”one_file” type in this case.

Define vertical zooms

Vertical zooms are defined through the attributs zoom_begin and zoom_end of the tag family axis. It must therefore be done in the axis part of the XML file. For example, in NEMOGCM/CONFIG/ORCA2_LIM/iodef_demo.xml, we provide the following example:

  

   <axis_group id="deptht" long_name="Vertical T levels" unit="m" positive="down" >

      <axis id="deptht" />

      <axis id="deptht_myzoom" zoom_begin="1" zoom_end="10" />

The use of this vertical zoom is done through the redefinition of the attribute axis_ref of the tag family field. For example:

  

   <file id="myfile_hzoom" output_freq="1d" >

      <field field_ref="toce" axis_ref="deptht_myzoom"/>

   </file>

Control of the output file names

The output file names are defined by the attributs ”name” and ”name_suffix” of the tag family file. for example:

  

   <file_group id="1d" output_freq="1d" name="myfile_1d" > 

      <file id="myfileA" name_suffix="_AAA" > <!-- will create file "myfile_1d_AAA"  -->

         ...

      </file>

      <file id="myfileB" name_suffix="_BBB" > <!-- will create file "myfile_1d_BBB" -->

         ...

      </file>

   </file_group>

However it is often very convienent to define the file name with the name of the experiment, the output file frequency and the date of the beginning and the end of the simulation (which are informations stored either in the namelist or in the XML file). To do so, we added the following rule: if the id of the tag file is ”fileN”(where N = 1 to 999 on 1 to 3 digits) or one of the predefined sections or moorings (see next subsection), the following part of the name and the name_suffix (that can be inherited) will be automatically replaced by:

placeholder string	automatically replaced by
@expname@	the experiment name (from cn_exp in the namelist)
@freq@	output frequency (from attribute output_freq)
@startdate@	starting date of the simulation (from nn_date0 in the restart or the namelist). yyyymmdd format
@startdatefull@	starting date of the simulation (from nn_date0 in the restart or the namelist). yyyymmdd_hh:mm:ss format
@enddate@	ending date of the simulation (from nn_date0 and nn_itend in the namelist). yyyymmdd format
@enddatefull@	ending date of the simulation (from nn_date0 and nn_itend in the namelist). yyyymmdd_hh:mm:ss format

For example,

   <file id="myfile_hzoom" name="myfile_@expname@_@startdate@_freq@freq@" output_freq="1d" >

with the namelist:

   cn_exp      =  "ORCA2"
   nn_date0    =  19891231
   ln_rstart   = .false.

will give the following file name radical:

   myfile_ORCA2_19891231_freq1d

Other controls of the xml attributes from NEMO

The values of some attributes are defined by subroutine calls within NEMO (calls to iom_set_domain_attr, iom_set_axis_attr and iom_set_field_attr in iom.F90). Any definition given in the xml file will be overwritten. By convention, these attributes are defined to ”auto” (for string) or ”0000” (for integer) in the xml file (but this is not necessary).

Here is the list of these attributes:

tag ids affected by automatic		name	attribute value
definition of some of their attributes		attribute
field_definition		freq_op	rn_rdt
SBC		freq_op	rn_rdt $\times$ nn_fsbc
ptrc_T		freq_op	rn_rdt $\times$ nn_dttrc
diad_T		freq_op	rn_rdt $\times$ nn_dttrc
EqT, EqU, EqW		jbegin, ni,	according to the grid
		name_suffix
TAO, RAMA and PIRATA moorings		zoom_ibegin, zoom_jbegin,	according to the grid
		name_suffix

Advanced use of XIOS functionalities

XML reference tables

(1) Simple computation: directly define the computation when refering to the variable in the file definition.

      

 <field field\_ref="sst"  name="tosK"  unit="degK" > sst + 273.15 </field>

 <field field\_ref="taum" name="taum2" unit="N2/m4" long\_name="square of wind stress module" > taum * taum </field>

 <field field\_ref="qt"   name="stupid\_check" > qt - qsr - qns </field>

(2) Simple computation: define a new variable and use it in the file definition.

in field_definition:

      

 <field id="sst2" long\_name="square of sea surface temperature" unit="degC2" >  sst * sst </field >

in file_definition:

      

 <field field\_ref="sst2" > sst2 </field>

Note that in this case, the following syntaxe $<$field field_ref="sst2" /$>$ is not working as sst2 won't be evaluated.

(3) Change of variable precision:

      

     <!-- force to keep real 8 -->

 <field field\_ref="sst" name="tos\_r8" prec="8" />

      <!-- integer 2  with add\_offset<<17881>><<17881>> and scale\_factor<<17882>><<17882>> attributes -->

 <field field\_ref="sss" name="sos\_i2" prec="2" add\_offset="20." scale\_factor="1.e-3" />

Note that, then the code is crashing, writting real4 variables forces a numerical convection from real8 to real4 which will create an internal error in NetCDF and will avoid the creation of the output files. Forcing double precision outputs with prec="8" (for example in the field_definition) will avoid this problem.

(4) add user defined attributes:

      

      <file\_group<<17885>><<17885>> id="1d" output\_freq="1d" output\_level="10" enabled=".TRUE."> <!-- 1d files --> 

 <file id="file1" name\_suffix="\_grid\_T" description="ocean T grid variables" >

   <field field\_ref="sst" name="tos" >

     <variable id="my\_attribute1" type="string"  > blabla </variable>

     <variable id="my\_attribute2" type="integer" > 3      </variable>

     <variable id="my\_attribute3" type="float"   > 5.0    </variable>

   </field>

   <variable id="my\_global\_attribute" type="string" > blabla\_global<<17886>><<17886>> </variable>

       </file>

     </file\_group> 

(5) use of the “@” function: example 1, weighted temporal average

- define a new variable in field_definition

      

 <field id="toce\_e3t" long\_name="temperature * e3t" unit="degC*m" grid\_ref="grid\_T\_3D" > toce * e3t </field >

- use it when defining your file.

      

<file\_group<<17891>><<17891>> id="5d" output\_freq="5d"  output\_level="10" enabled=".TRUE." >  <!-- 5d files -->  

 <file id="file1" name\_suffix="\_grid\_T" description="ocean T grid variables" >

  <field field\_ref="toce" operation="instant" freq\_op="5d" > @toce\_e3t<<17892>><<17892>> / @e3t </field>

 </file>

</file\_group> 

The freq_op="5d" attribute is used to define the operation frequency of the “@” function: here 5 day. The temporal operation done by the “@” is the one defined in the field definition: here we use the default, average. So, in the above case, @toce_e3t will do the 5-day mean of toce*e3t. Operation="instant" refers to the temporal operation to be performed on the field”@toce_e3t / @e3t”: here the temporal average is alreday done by the “@” function so we just use instant to do the ratio of the 2 mean values. field_ref="toce" means that attributes not explicitely defined, are inherited from toce field. Note that in this case, freq_op must be equal to the file output_freq.

(6) use of the “@” function: example 2, monthly SSH standard deviation

- define a new variable in field_definition

      

 <field id="ssh2" long\_name="square of sea surface temperature" unit="degC2" >  ssh * ssh </field >

- use it when defining your file.

      

<file\_group<<17897>><<17897>> id="1m" output\_freq="1m"  output\_level="10" enabled=".TRUE." >  <!-- 1m files -->  

 <file id="file1" name\_suffix="\_grid\_T" description="ocean T grid variables" >

  <field field\_ref="ssh" name="sshstd" long\_name="sea\_surface\_temperature\_standard\_deviation" operation="instant" freq\_op="1m" > sqrt( @ssh2 - @ssh * @ssh ) </field>

 </file>

</file\_group> 

The freq_op="1m" attribute is used to define the operation frequency of the “@” function: here 1 month. The temporal operation done by the “@” is the one defined in the field definition: here we use the default, average. So, in the above case, @ssh2 will do the monthly mean of ssh*ssh. Operation="instant" refers to the temporal operation to be performed on the field ”sqrt( @ssh2 - @ssh * @ssh )”: here the temporal average is alreday done by the “@” function so we just use instant. field_ref="ssh" means that attributes not explicitely defined, are inherited from ssh field. Note that in this case, freq_op must be equal to the file output_freq.

(7) use of the “@” function: example 3, monthly average of SST diurnal cycle

- define 2 new variables in field_definition

      

 <field id="sstmax" field\_ref="sst" long\_name="max of sea surface temperature" operation="maximum" />

 <field id="sstmin" field\_ref="sst" long\_name="min of sea surface temperature" operation="minimum" />

- use these 2 new variables when defining your file.

      

<file\_group<<17902>><<17902>> id="1m" output\_freq="1m"  output\_level="10" enabled=".TRUE." >  <!-- 1m files -->  

 <file id="file1" name\_suffix="\_grid\_T" description="ocean T grid variables" >

  <field field\_ref="sst" name="sstdcy" long\_name="amplitude of sst diurnal cycle" operation="average" freq\_op="1d" > @sstmax - @sstmin </field>

 </file>

</file\_group> 

The freq_op="1d" attribute is used to define the operation frequency of the “@” function: here 1 day. The temporal operation done by the “@” is the one defined in the field definition: here maximum for sstmax and minimum for sstmin. So, in the above case, @sstmax will do the daily max and @sstmin the daily min. Operation="average" refers to the temporal operation to be performed on the field “@sstmax - @sstmin”: here monthly mean (of daily max - daily min of the sst). field_ref="sst" means that attributes not explicitely defined, are inherited from sst field.

Tag list

tag name	description	accepted attribute	child of	parent of
simulation	this tag is the root tag which encapsulates all the content of the xml file	none	none	context
context	encapsulates parts of the xml file dedicated to different codes or different parts of a code	id (”xios”, ”nemo” or ”n_nemo” for the nth AGRIF zoom), src, time_origin	simulation	all root tags: ... _definition
field_definition	encapsulates the definition of all the fields that can potentially be outputted	axis_ref, default_value, domain_ref, enabled, grid_ref, level, operation, prec, src	context	field or field_group
field_group	encapsulates a group of fields	axis_ref, default_value, domain_ref, enabled, group_ref, grid_ref, id, level, operation, prec, src	field_definition, field_group, file	field or field_group
field	define a specific field	axis_ref, default_value, domain_ref, enabled, field_ref, grid_ref, id, level, long_name, name, operation, prec, standard_name, unit	field_definition, field_group, file	none
file_definition	encapsulates the definition of all the files that will be outputted	enabled, min_digits, name, name_suffix, output_level, split_freq_format, split_freq, sync_freq, type, src	context	file or file_group
file_group	encapsulates a group of files that will be outputted	enabled, description, id, min_digits, name, name_suffix, output_freq, output_level, split_freq_format, split_freq, sync_freq, type, src	file_definition, file_group	file or file_group
file	define the contents of a file to be outputted	enabled, description, id, min_digits, name, name_suffix, output_freq, output_level, split_freq_format, split_freq, sync_freq, type, src	file_definition, file_group	field
axis_definition	define all the vertical axis potentially used by the variables	src	context	axis_group, axis
axis_group	encapsulates a group of vertical axis	id, lon_name, positive, src, standard_name, unit, zoom_begin, zoom_end, zoom_size	axis_definition, axis_group	axis_group, axis
axis	define a vertical axis	id, lon_name, positive, src, standard_name, unit, zoom_begin, zoom_end, zoom_size	axis_definition, axis_group	none
domain_definition	define all the horizontal domains potentially used by the variables	src	context	domain_group, domain
domain_group	encapsulates a group of horizontal domains	id, lon_name, src, zoom_ibegin, zoom_jbegin, zoom_ni, zoom_nj	domain_definition, domain_group	domain_group, domain
domain	define an horizontal domain	id, lon_name, src, zoom_ibegin, zoom_jbegin, zoom_ni, zoom_nj	domain_definition, domain_group	none
grid_definition	define all the grid (association of a domain and/or an axis) potentially used by the variables	src	context	grid_group, grid
grid_group	encapsulates a group of grids	id, domain_ref, axis_ref	grid_definition, grid_group	grid_group, grid
grid	define a grid	id, domain_ref, axis_ref	grid_definition, grid_group	none

Attributes list

attribute name	description	example	accepted by
axis_ref	refers to the id of a vertical axis	axis_ref="deptht"	field, grid families
enabled	switch on/off the output of a field or a file	enabled=".TRUE."	field, file families
default_value	missing_value definition	default_value="1.e20"	field family
description	just for information, not used	description="ocean T grid variables"	all tags
domain_ref	refers to the id of a domain	domain_ref="grid_T"	field or grid families
field_ref	id of the field we want to add in a file	field_ref="toce"	field
grid_ref	refers to the id of a grid	grid_ref="grid_T_2D"	field family
group_ref	refer to a group of variables	group_ref="mooring"	field_group
id	allow to identify a tag	id="nemo"	accepted by all tags except simulation
level	output priority of a field: 0 (high) to 10 (low)	level="1"	field family
long_name	define the long_name attribute in the NetCDF file	long_name="Vertical T levels"	field
min_digits	specify the minimum of digits used in the core number in the name of the NetCDF file	min_digits="4"	file family
name	name of a variable or a file. If the name of a file is undefined, its id is used as a name	name="tos"	field or file families
name_suffix	suffix to be inserted after the name and before the cpu number and the ”.nc” termination of a file	name_suffix="_myzoom"	file family
attribute name	description	example	accepted by
operation	type of temporal operation: average, accumulate, instantaneous, min, max and once	operation="average"	field family
output_freq	operation frequency. units can be ts (timestep), y, mo, d, h, mi, s.	output_freq="1d12h"	field family
output_level	output priority of variables in a file: 0 (high) to 10 (low). All variables listed in the file with a level smaller or equal to output_level will be output. Other variables won't be output even if they are listed in the file.	output_level="10"	file family
positive	convention used for the orientation of vertival axis (positive downward in NEMO).	positive="down"	axis family
prec	output precision: real 4 or real 8	prec="4"	field family
split_freq	frequency at which to temporally split output files. Units can be ts (timestep), y, mo, d, h, mi, s. Useful for long runs to prevent over-sized output files.	split_freq="1mo"	file family
split_freq_format	date format used in the name of temporally split output files. Can be specified using the following syntaxes: %y, %mo, %d, %h %mi and %s	split_freq_format= "%y%mo%d"	file family
src	allow to include a file	src="./field_def.xml"	accepted by all tags except simulation
standard_name	define the standard_name attribute in the NetCDF file	standard_name= "Eastward_Sea_Ice_Transport"	field
sync_freq	NetCDF file synchronization frequency (update of the time_counter). units can be ts (timestep), y, mo, d, h, mi, s.	sync_freq="10d"	file family
attribute name	description	example	accepted by
time_origin	specify the origin of the time counter	time_origin="1900-01-01 00:00:00"	context
type (1)	specify if the output files are to be split spatially (multiple_file) or not (one_file)	type="multiple_file"	file familly
type (2)	define the type of a variable tag	type="boolean"	variable
unit	unit of a variable or the vertical axis	unit="m"	field and axis families
zoom_ibegin	starting point along x direction of the zoom. Automatically defined for TAO/RAMA/PIRATA moorings	zoom_ibegin="1"	domain family
zoom_jbegin	starting point along y direction of the zoom. Automatically defined for TAO/RAMA/PIRATA moorings	zoom_jbegin="1"	domain family
zoom_ni	zoom extent along x direction	zoom_ni="1"	domain family
zoom_nj	zoom extent along y direction	zoom_nj="1"	domain family

CF metadata standard compliance

Output from the XIOS-1.0 IO server is compliant with version 1.5 of the CF metadata standard. Therefore while a user may wish to add their own metadata to the output files (as demonstrated in example 4 of section 11.2.5) the metadata should, for the most part, comply with the CF-1.5 standard.

Some metadata that may significantly increase the file size (horizontal cell areas and vertices) are controlled by the namelist parameter ln_cfmeta in the namrun namelist. This must be set to true if these metadata are to be included in the output files.