Discussion
summary on OASIS4 developments
R. Redler, S.Valcke (04/04/2006)
(draft S. Valcke,
10/04/2006)
1) Restart mechanism
The restart mechanism in OASIS4 works as in OASIS3, except that when a
reading from a restart file is needed at the beginning of the run, the
reading is done, in OASIS3, by the interpolation process (and then
interpolated and sent to the target component), whereas it is done, in
OASIS4, by the source component PSMILe below the prism_enddef (and
then, if needed, sent to the Transformer and interpolated, and then to
the target component).
In OASIS4 however, the last prism_put of a run leads, if there is a lag
= 0 defined in the SMIOC file, to both a coupling exchange and also to
a writing in a restart file. If the lag=0, the writing in a restart
file should not happen.
Actions:
- Rene, to remove the writing to the restart file below the last
prism_put of a run when lag=0.
- Josefine + Rene: to add an example (in
PRISM_Cpl/examples/create_restart) of a stand-alone component using a
prism_put_restart to write a coupling restart file (Rene to send
existing program to Josefine, Josefine to finalize and release the
example).
- Rene: ensure that prism_put_restart creates a restart file even
if there is no lag defined in the SMIOC file (currently a lag=0
must be defined).
2) PSMILe API for gridless
field
As for the other grid types, the prism_def_grid should be used, for
gridless grids to describe only the local partition.
A prism_set_point must also be called to return a point_id (that must
be used later as input argument to the prism_def_var) but without the
point_xxx_array arguments. It would be better to tell the developer to
use directly a prism_set_point_gridless, already available.
Action:
Sophie to modify the documentation to tell the developer to use
directly a prism_set_point_gridless
For coding reasons, ndim must be = 3 for gridless grids (most general
case). For one particular gridless grid, if the 2nd and/or 3rd
dimensions in fact do not exist, the developer should have to
initialize the grid_valid_shape(1:2, 2) and/or grid_valid_shape(1:2, 3)
to PRISM_undefined.
Actions:
- Sophie to clarify this in the documentation
- Rene to make sure that this convention is used in the PSMILe
sources.
3) PSMILe API for Gaussian
Reduced grids
For Gaussian Reduced grids, there is no need to call a
prism_def_partition if there is no partitioning, or if the partitioning
is only vertically (i.e. level per level).
There is a need to call prism_def_partition when there is a
partitioning done horizontally. Each segment of each latitude row must
then be defined as a subdomain on its own. Currently, the horizontal
partitioning, if any, must be the same for all vertical levels (this is
why there is in fact no need to define the partitioning for ndim=2).
For coherency, the documentation will be modified to tell the developer
to define a unique partitioning for ndim=2, i.e. an
offset_array(:,2)=0 and extent_array(:,2)=number_of_vertical_levels.
Actions:
- Sophie to modify the documentation to add remarks above
- Rene to check that defining offset_array(:,2)=0 and
extent_array(:,2)=number_of_vertical_levels will effectively create no
misbehaviour
The current way of expressing the partitions with offset_array(:,2) and
extent_array(:,2) will also be fine when different horizontal
partitionings in the vertical will be supported.
One example with two levels (1 and 2) and two different partitions per
level (A and B for level 1, and C and D for level 2):
level 1: A A A A A A level 2: C C C C C C
A A B B B
B
D D D D D D
B B B B B
B
D D D D D D
In this case, 7 subdomains will have to be defined:
subdomain 1: A A A A A
A (level 1)
offset_array(1,1)=0 extent_array(1,1)=6
offset_array(1,2)=0 extent_array(1,2)=1
subdomain 2:
A A
(level 1)
offset_array(2,1)=6 extent_array(1,1)=2
offset_array(2,2)=0 extent_array(2,2)=1
subdomain
3:
(level 1)
B B B B
offset_array(3,1)=8 extent_array(1,1)=4
offset_array(3,2)=0 extent_array(3,2)=1
subdomain
4:
(level 1)
B B B B B B
offset_array(4,1)=12 extent_array(4,1)=6
offset_array(4,2)=0 extent_array(4,2)=1
subdomain 5: C C C C C C
(level 2)
offset_array(5,1)=0 extent_array(5,1)=6
offset_array(5,2)=1 extent_array(5,2)=1
subdomain 6:
(level 2)
D D D D D D
offset_array(6,1)=6 extent_array(6,1)=6
offset_array(6,2)=1 extent_array(6,2)=1
subdomain 7:
(level 2)
D D D D D D
offset_array(7,1)=12 extent_array(7,1)=6
offset_array(7,2)=1 extent_array(7,2)=1
4) CICLE project
The first meeting of the French project CICLE (funded by ANR) was hold
in Paris on March 14th. The requirement for the OASIS4 coupler that one
can foresee are:
- Reproducability of OASIS3 interpolations
- Implementation of Conservative Remapping
- Interpolation with a set of weights-and-addresses pre-defined by
the user (not discussed with Rene)
- Combination of source fields (however it would be still possible
to the combination in the target model after reception by the
prism_get).
- Generic toy model reading a field and its grid in a file,
performing automatically the appropriate intialization calls and
sending the field to the Transformer (not discussed with Rene).
5) Support of ORCA grid
The ORCA grid and corners should be cleanly defined by the OPA team.
Sebastien Masson seems to be the good contact on this subject. The
restrictions are:
-jump in the corner definition at a cyclic boundary are not allowed
-the use of the F points to define the corners lead to few stange cell,
that perturb the neighborhood search in OASIS4. There corners should be
redefined appropriately.
Action: ?
6) I/O
As it works with a standalone model (no need of Driver) OASIS4 psmile
can be distributed as an I/O library, even if the user does not intend
to couple its model.
Action: Sophie
to modify the PAE coupling "bullet points" on the wiki.