WEIGHTS produces bad values

[m-n-o]

Hello again.)

To initialize the model (global ORCA2), I use the global ocean analysis and forecast 1/12 degree data from CMEMS. There are no runtime errors when creating weights using the WEIGHTS tool from the dataset coordinate grid to the ORCA_R2_zps_domcfg coordinate grid (default from ORCA2_ICE_PISCES). However, when viewing the resulting interpolation weights, it’s found that in the variables wgt03 and wgt04 there is one value approximately 2160 and -2160, respectively. Although the interpolation weights should be within [0,1].
This effect is observed with map_method = [‘bilinear’,‘bicubic’] and with ew_wrap = [-1,0,1,2]. Coordinates of the point → 179.99992124 E, 0.0 N.
When calculating interpolation weights for forcing (global gfs data), no such effect is observed.
Illustrating weights maps and namelist_bilin are attached below.

All weights variables (lat=y, lon=x in ORCA grid)

namelist_bilin

&comments
 -----------------------------------------------------------------------------------
 - grid_inputs holds parameters for the scripgrid routine which reformats information 
   about the input grids
 - scripgrid always needs a coordinates.nc file in the
   current directory and creates the remapped grid file correspondingly
 - it uses the following namelist block to determine its actions
     method:  only 'regular' is yet implemented, this assumes a cartesian grid
     input_lon: name of longitude variable in the input_file
     input_lat: name of latitude variable in the input_file
     nemo_lon: name of longitude variable in the coordinates.nc
     nemo_lat: name of latitude variable in the coordinates.nc
/
&grid_inputs
    input_file = 'gl12_mean_20230130_R20230201.nc'
    nemo_file = 'ORCA_R2_zps_domcfg.nc'
    datagrid_file = 'remap_glorys_grid.nc'
    nemogrid_file = 'remap_ORCA2_grid.nc'
    method = 'regular'
    input_lon = 'longitude'
    input_lat = 'latitude'
    nemo_lon = 'glamt'
    nemo_lat = 'gphit'
    nemo_mask = 'none'
    nemo_mask_value = 10
    input_mask = 'none'
    input_mask_value = 10
/
&comments
 -----------------------------------------------------------------------------------
 - remap_inputs holds parameters for the scrip routine which calculates the weights
   needed to convert between two grids
 - two remap grid files are required as output by scripgrid
 - num_maps is either 1 or 2 depending on whether the reverse transformation is required
 - one or two interp_file names are then supplied; these hold the weights to convert 
   one grid to another
 - the map_name variable is just descriptive
 - map_method can be 'bilinear' 'bicubic' or 'conservative' (the latter untested)
 - normalize_opt should usually be 'frac' or else the user needs to do this scaling
   manually (this seems to the case for fractional ice cover)
 - restrict_type should be 'latitude' or 'latlon' in which case num_srch_bins only are 
   used in one or two directions
 - use_grid_area fields override the scrip calculation of area in case the model gets
   slightly different answers, but the area needs to be supplied in the input files
 - output_opt may be supplied and set to either 'scrip' or 'ncar-csm'
/
&remap_inputs
    num_maps = 1
    grid1_file = 'remap_glorys_grid.nc'
    grid2_file = 'remap_ORCA2_grid.nc'
    interp_file1 = 'glorys_ORCA2_bilin.nc'
    interp_file2 = 'ORCA2_glorys_bilin.nc'
    map1_name = 'glorys to ORCA2 bilin Mapping'
    map2_name = 'ORCA2 to glorys bilin Mapping'
    map_method = 'bilinear'
    normalize_opt = 'frac'
    output_opt = 'scrip'
    restrict_type = 'latitude'
    num_srch_bins = 90 
    luse_grid1_area = .false.
    luse_grid2_area = .false.
/

&interp_inputs
    input_file = "t_10.15JUNE2009_fill.nc"
    interp_file = "core2_nordic1_bilin.nc"
    input_name = "T_10_MOD"
    input_start = 1,1,1,1
    input_stride = 1,1,1,1
    input_stop = 0,0,0,1
    input_vars = 'initial_time0_hours'
/

&interp_outputs
    output_file = "t_10.15JUNE2009_nordic1.nc"
    output_mode = "create"
    output_dims = 'x', 'y', 'time_counter'
    output_scaling = "T_10_MOD|1.0", "time_counter|86400.0"
    output_name = 'T_10_MOD'
    output_lon = 'x'
    output_lat = 'y'
    output_vars = 'time_counter'
    output_attributes = 'time_counter|units|seconds since 1995-00-00 00:00:00',
                        'time_counter|calendar|noleap',
                        'T_10_MOD|units|mm/s'
/

&comments
 -----------------------------------------------------------------------------------
 -  shape_inputs are the input fields required by scripshape.f90
 -  first is the interpolation file created by scrip.f90 mapping data to model grid
 -  second is the name of the output weights file to create
 -  third is the east-west wrap to assume in the model (needed when calculating gradient 
          terms in the bicubic scheme); the number is just the number of columns on one side
          that are repeats of those on the opposite side (-1 for not cyclic)
/
&shape_inputs
    interp_file = 'glorys_ORCA2_bilin.nc'
    output_file = 'weights_glorys_ORCA2_bilin.nc'
    ew_wrap     = 0
/

What could be the cause of the error?

[elsy]

Dear m-n-o

I tried the same thing and I have the same error, were you able to fix it? Thanks for your answer

[Saeed]

How are the longitudes for your forcing arranged? Are they from 0-360 or -180.0-179? Can you check that?

[elsy]

I checked the lengths and yes it is 0-360, I used the same forcing file to create a “weight” file in a regional zone and yes it works fine. The problem is with the global configuration, if anyone can fix it please tell me.

[m-n-o]

Hello, Elsy.
I had changed my focus on preprocessing interpolation via SOSIE and it works fine.)

[elsy]

I think I found the problem if anyone is interested in this, you first need to make sure the lengths are ordered from smallest to largest and with values from 0 to 360, then check if the grid points in your database are greater, less or equal to the grid to be modeled. In case you get zero in your “wgt01” or any “wgt0*” values this indicates that the database point is closer to the grid point, so when applying the weight equation (which it is a sum, manual v4.0.6 - Pg. 71) some may be zero or very small values. To verify that the “weigths*.nc” file is correct execute “scripinterp.exe” (before edit “namelist*”) to obtain a netCDF file from your database gridded with the grid to be modeled. There is no detailed description for editing the “namelist” section for “scripinterp” if you need help you can write to me

[Franziska]

Hi,

I recently came across issues with a field remapped on the fly using weights built with the WEIGHTS tool. The resulting fields on the model grid appear to be shifted in longitude.
[When using scripinterp for testing, the resulting field on the model grid is OK - but this does not make use of the weights-file.]

After reading this topic here, I checked the longitude on the original grid and it is -179.875 to 179.875.

@Saeed you were asking explicitly for this - any reason? or even better: any fix in the WEIGHTS tool?

I would like to avoid manipulating the source file i.e. re-ordering longitudes as suggested by @elsy

I was afraid, other fields might be mis-placed/shifted as well without recognizing it. However, all other source fields have longitudes 0-360 instead of -180-180 - can I be sure that weights are fine in these cases?

Thanks!

[In my case this is all based on NEMO 5.0.]

[elsy]

The weights tool sorts the file of longitudes and latitudes, regardless of whether it is from -180 to 180 or from 0 to 360. Initially, due to confusion, an attempt was made to reorder them, but this tool identifies the correct order and processes the file.

[Franziska]

Thank you @elsy!
That’s what I’d expect.

However something goes wrong. If I use the weights and the input file on its original grid the data does not end up at the right location on the model grid. How could this happen? The only structural difference I see between this and other input fields is longitude being -180 to 180 instead of 0-360.

It is a bit hard see the effect but a difference plot (here SST) between two experiments, one using this field (surface chlorophyll in traqsr) and another one which doesn’t use this field, exhibits the shift as imprint of the continents in the middle of the ocean basins.

Any ideas what to look for?

Thanks!

[elsy]

Perhaps the grid configuration or file isn’t described correctly. You can try a different grid with a lower resolution to see if you get the same result. If you do, check the settings of the weight tool you’re using by adjusting the parameters. If you don’t get the same error, the grid is incorrectly described. You can try using one of the grids included in the TEST cases.