Configure a Lagrangian diagnostic: The Namelist file part 3/4
Hello, we are now going to add to the Namelist file
how to read the zonal and meridional current components
that Ariane needs (including any tracers)
issued from the outputs of an ocean circulation model.
Ariane can directly read currents
contained in NetCDF files output from models
such as NEMO, ROMS or others,
without having to copy the data to another format.
However, as data output strategies
differ among models
or among configurations,
a method had to be established for all cases.
Earlier we looked at 'Time integration'.
We will now move on to descriptions of files
on the zonal and meridional components of the current.
First, we'll just look at the convention
we adopted in Ariane to read back NetCDF files.
Here is an example of output from the NEMO model
where the choice was made to record each
of the current components in different file.
This file contains all the parameters
on point 'U' of grid 'C'.
Here we find the zonal component of the current.
We have other files (extension 'gridV')
for the meridional component of the current
and so on with other files.
In this example, I take
data from the years 2000 to 2019
and in each file I group
my daily recordings by month.
In the first file there are 31 recordings,
in the second one 29 recordings, and so on.
When you fill in the Namelist file
the number of recordings ('lmt')
is the sum of all the recordings in the NetCDF files.
You can have a third set of files
with information about point 'T' in your 'C' grid.
These files usually have a 'gridT' extension.
For the CROCO / ROMS model,
we will have another convention.
The zonal and meridional components of the current
and any tracers
are all stored in the same files.
As an example, I'll use a simulation
that ran for 10 years, from year 1 to year 10,
and recorded daily fields on a monthly basis
with the convention of 30 days per month.
Here in the first file I have 30 recordings,
in the second file I have 30 recordings, etc.
A short digression:
The 'time' parameter you had to fill in
in the Namelist file
for the CROCO / ROMS model
is the sum of the number of recordings
of all your NetCDF files.
So there are different strategies
depending on the model or configuration.
In Ariane we have adopted a different convention.
The NetCDF file name is split into three parts:
1. a prefix, corresponding to a string of characters;
2. a number, corresponding to an integer
defined with a constant number of characters (digits)
with a step of 1;
3. a suffix.
Two examples of this:
1. prefix = 'model_'
2. number (defined here with four characters) = '0109'
3. suffix = '_daily.nc'
File numbers increase by an increment of one.
Here we go from 109 to 110.
We can reduce the size of the file
by keeping only the prefix and the number.
For example, prefix = 'Simulation_'
and number = '023', '024', etc.
Or a number and a suffix,
for example '3467.nc', '3468.nc', etc.
In an extreme case, we could have
all data in one file,
whose name would be considered by Ariane
as a prefix or a suffix.
Example: ORCA2, which is a low-resolution
climate model with all data
contained in the same file.
Here are some examples of NetCDF file names
that Ariane cannot interpret.
Here in a first example:
the prefix part is 'tracers_',
then an integer
and a suffix: '_model.nc'.
We see that the number
is sometimes defined with 1 character, sometimes 2.
So Ariane will not be able to read
all these files.
In this second example,
month and year are integers
but without an increment of one,
so Ariane cannot read these files.
In this third example,
we have a prefix,
a number and a suffix.
The number is well defined with three digits,
but the increment is by five,
so Ariane will not be able to read it.
In the fourth example there are no numbers,
so Ariane will not be able to read these files.
Now let's see some examples
that Ariane can read.
In this first case: a prefix,
a number and a suffix.
The prefix is 'tracers_',
the number has three characters
with an increment of one,
and a suffix: '_model.nc'.
In this second case we have a prefix and a number.
The prefix 'Temp',
and a number defined with five characters
with an increment of one.
In the third case here, we have
a number and a suffix.
The number is defined with two characters
with an increment of one,
and a suffix: '_data.nc'.
The last case is 'data.nc'.
Like we saw for the NEMO and ROMS model examples,
the output of the model doesn't necessarily match
what Ariane can handle as input.
I advise you to use the command 'ln -s',
which allows you to create symbolic links,
a kind of alias. So you put 'ln -s',
the name of the output file of your model
with the name of the alias you want to create.
Here, we have again taken the example
of the output of the NEMO model
for files at grid point 'U'
and created an alias compatible with Ariane,
with the prefix 'conf_',
a four-digit number
with an increment of one,
and a suffix for the grid 'U',
and which points to the model output files.
Let's go back to our 'ANA' tool
which allows us to fill in a Namelist file.
We were at 'Time integration',
and now move on to 'Velocity file description'
to tell Ariane
where the NetCDF files are
from your model's outputs.
I'm going back to the beginning of our 'ANA' tool.
I delete the fields already filled in.
Now, if I scroll down the page,
the 'Velocity file description' part is empty.
When I choose NEMO-OPA as my model,
this opens out
and shows two parts:
the zonal component of the current
and the meridional component.
Using the convention presented earlier,
we can fill in these parameters.
The first is the directory
where your files are located:
this is the path on your hard drive.
Then we have the 'prefix' part
of the NetCDF file name.
For the next three parameters,
we have the first and last integers
of your file list.
For example, if we have 24 files,
I put '24'.
The next parameter is the number of characters
with which your integers are encoded.
Usually, two integers should be enough
but if you exceed 100 or 1000,
you will have to put four or more.
The next parameter is the suffix part of the file name.
The next parameter is the name of the variable
in the NetCDF file which corresponds
to the zonal component of the current.
In some cases there may be an additional part
to this zonal component: 'Eddy Induce Velocity'
corresponding to the zonal component of the current.
For the last parameter, 'nc_att_mask_zo',
the data is probably masked
using 'missing_value' or 'fig_value'.
Warning: a string is expected here
and not the value,
so as to hide data in the NetCDF file.
In the same way as for
the zonal component of the current,
we must provide details for
the meridional component of the current.
The same parameters are found here.
We have seen that it is possible to
read back the vertical components of the current.
'FALSE' must be selected here.
If I do this and go back down
I see that I have to fill in
the vertical component of the current.
Now let's look at the CROCO / ROMS model,
for which the same heading opens.
We need to fill in the zonal component
and the meridional component of the current,
but also the 'Zeta' component of the free surface,
Which we fill in as for the other two components.
The next section is about tracers.
You may have recorded
temperature and salinity
and want to have this information
along your trajectory.
If you select 'TRUE'
the field expands:
the directory needs to be filled in,
as must the NetCDF file names
corresponding to the temperature and salinity.
Before moving on to the last section,
concerning the model grid
we'll take a break. Thank you!