Opened 11 years ago

Closed 10 years ago

Last modified 3 years ago

#631 closed Enhancement (fixed)

proposal to modify behaviour of interpolation on the fly code in fld_read

Reported by: sga Owned by: sga@…
Priority: low Milestone:
Component: OCE Version: release-3.3
Severity: Keywords: 2010
Cc: Review:
MP ready?:
Progress:

Description

We wish to make some changes to the "interpolation on the fly" code in the fld_read routine.

Originally it was intended that this code should be able to cope with any input grid presented to it.
This was so that no changes would be required to the input forcing datasets. Unfortunately this also means
that the code is difficult to understand and maintain.

The bilinear case is straightforward: at each model grid point the code needs the indices of the four
surrounding points on the input grid. The resulting output value is the sum of the weights times the
input values on these four points. For bicubic interpolation the situation is more complex since the
16 weights correspond not only to linear terms, but also gradients of the values on the input grid which
need to be defined at the same four surrounding points. It is assumed that these gradients are the ones
that the input weights have been calculated with.

When the input grid only just covers the model domain, the code in fld_read attempts to guess whether
the input grid is cyclic or not in the east-west direction. For example, if the input data grid
spans 0 → 359 (360 columns) in steps of 1, the code adds a copy of column 360 to the beginning and a
copy of column 1 to the end of its temporary workspace array in order to calculate gradients.
If the input data grid spans 0 → 360 (361 columns), then column 360 is added at the beginning and
column 2 at the end.

The code needs to be simplified so that it's behaviour is predictable and comprehensible.

Some options:

1) remove all efforts to allow for variations in the input grid:

assume that the input grid is always wider in space than the model grid by at least one grid cell;
this may require the input data to be modified before the weights are calculated, if necessary by
duplicating columns and rows of data

2) retain the code in fld_read, but modify it so that there is no default behaviour and the correct

behaviour is selected by examining an attribute inside the input forcing data grid:
this requires the addition of this attribute to the input datasets

Comments on this are welcome.
Also since we want to change it, other suggestions are welcome.

Steven Alderson

Commit History (0)

(No commits)

Change History (16)

comment:1 Changed 11 years ago by smasson

I vote for solution 2
With Gurvan, we were thinking of adding an attribute in the "weights" file, something that would come from nocs_weights tools…

comment:2 Changed 11 years ago by sga

Personally, I prefer the first option.
This reduces the complexity of the code, which would mean that it's easier to maintain and to understand.
It also means that the atmospheric fields interpolated onto the ORCA grid should be reproducible offline using SCRIP.
This is offset by the problem of having to modify the input data of course!

comment:3 Changed 10 years ago by sga

  • Version changed from trunk to nemo_v3_3_beta

Just to let people know that we are intending to implement option two (i.e introduce a netcdf attribute into the weights file which is read by fld_read to determine the periodicity of the input non-model grid). This should solve the problem of having to second guess the name of the longitude variable in the input file and also having to assume its dimensionality.
The NOCS tool to calculate weights will be modified accordingly. Existing weights files can be simply modified (i.e. without having to create new files) by use of the nco tools (more on that when I know how!).

comment:4 Changed 10 years ago by sga

nemo_v3_3_beta has now been modified: instead of attempting to decide on cyclicity of input non-model grid by inspecting a longitude variable, fld_read now expects to find an attribute in the input weights file to tell it how many columns overlap
at the east-west edges of the grid.

This global attribute must be called ew_wrap and is an integer taking values -1,0,1,2:
-1: input non-model grid is not cyclic

0: input grid is cyclic with no overlapping east-west columns

0: the number of overlapping columns in the input grid

iom and iom_nf90.F90 have new routines to expose netcdf attributes to the model.
iom has a new interface called iom_getatt (only the form for integer attributes has so far been written, but it should be easy to generalise to character attributes for example).
iom_nf90 does the real work, so this too has a new interface (again integer only).
(The naming conventions for these are my own inventions, so if anyone objects to them, they can be changed!)

These changes correspond to revision 2351

Testing:
This has been tested so far with an ORCA2 forced by DFS4.1 data and corresponding weights files.
Two parallel experiments were run (using base code at revision 2330): one with the old fld_read (determining cyclicity from the input lon variable) and the second with the new scheme. Using key_mpp_rep and no optimisation in compilation the two runs produced identical answers over 150 timesteps.

comment:5 Changed 10 years ago by sga

Correction:

the section on ew_wrap should have come out as

minus 1: input non-model grid is not cyclic

equal to zero: input grid is cyclic with no overlapping east-west columns

greater than 0: the number of overlapping columns in the input grid

(wiki formatting stole the original greater than symbol!)

comment:6 Changed 10 years ago by sga

Added code for calculating weights files for interpolation on the fly to nemo_v3_3_beta (revision 2352).
This should build with the maketools script and use the same architecture configuration file as the main model.
See README file for a description of how to use it.
Code uses the scrip package from Los Alamos.

comment:7 Changed 10 years ago by sga

  • Resolution set to fixed
  • Status changed from new to closed

To tidy up the loose ends (that I currently know about):

To create a global attribute "ew_wrap" in an existing file try: "ncatted -a ew_wrap,global,c,l,-1 nc_file_name"
Here "c" is for "create" ("m" can be used to modify an existing value); "l" (small letter L) is for a long integer.
Note that there are no spaces in the text that follows "-a".

Some test data will be created and may possibly appear with the other configuration data (yet to be agreed)

This ticket is therefore closed (at least until it is next reopened!)

comment:8 Changed 4 years ago by nicolasmartin

  • Keywords 2010 Interfaces Stream User added

comment:9 Changed 4 years ago by nicolasmartin

  • Keywords interfaces added; Interfaces removed

comment:10 Changed 4 years ago by nicolasmartin

  • Keywords user added; User removed

comment:11 Changed 4 years ago by nicolasmartin

  • Keywords nemo_v3_3* added

comment:12 Changed 4 years ago by nicolasmartin

  • Milestone 2010 Stream 1: User Interfaces deleted

Milestone 2010 Stream 1: User Interfaces deleted

comment:13 Changed 4 years ago by nicolasmartin

  • Keywords interfaces user added; UI removed

comment:14 Changed 4 years ago by nicolasmartin

  • Keywords interfaces removed

comment:15 Changed 4 years ago by nicolasmartin

  • Keywords user removed

comment:16 Changed 3 years ago by nemo

  • Keywords nemo_v3_3* removed
Note: See TracTickets for help on using tickets.