# WEIGHTS produces bad values **URL:** \ **Category:** v4.2.x\ **Tags:** tools\ **Created:** [8 February 2023 13:11 UTC](https://nemo-ocean.discourse.group/t/weights-produces-bad-values/438 "2023-02-08T13:11:14Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![m-n-o](https://yyz2.discourse-cdn.com/free1/user_avatar/nemo-ocean.discourse.group/m-n-o/32/101_2.png) [@m-n-o](https://nemo-ocean.discourse.group/u/m-n-o)\ **Post date:** [8 February 2023 13:11 UTC](https://nemo-ocean.discourse.group/t/weights-produces-bad-values/438/1 "2023-02-08T13:11:14Z")
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)** > > ![all_wgt](https://global.discourse-cdn.com/free1/uploads/nemo_ocean/original/1X/ca4998174d89419af361d3866204cbbdc313ec9d.png) > **namelist\_bilin** > > ```auto > &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? ---
**Author:** ![elsy](https://yyz2.discourse-cdn.com/free1/user_avatar/nemo-ocean.discourse.group/elsy/32/163_2.png) [@elsy](https://nemo-ocean.discourse.group/u/elsy)\ **Post date:** [31 August 2023 13:12 UTC](https://nemo-ocean.discourse.group/t/weights-produces-bad-values/438/2 "2023-08-31T13:12:48Z")
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 ---
**Author:** ![Saeed](https://avatars.discourse-cdn.com/v4/letter/s/e8c25b/32.png) [@Saeed](https://nemo-ocean.discourse.group/u/Saeed)\ **Post date:** [31 August 2023 13:46 UTC](https://nemo-ocean.discourse.group/t/weights-produces-bad-values/438/3 "2023-08-31T13:46:20Z")
How are the longitudes for your forcing arranged? Are they from 0-360 or -180.0-179? Can you check that? ---
**Author:** ![elsy](https://yyz2.discourse-cdn.com/free1/user_avatar/nemo-ocean.discourse.group/elsy/32/163_2.png) [@elsy](https://nemo-ocean.discourse.group/u/elsy)\ **Post date:** [1 September 2023 07:02 UTC](https://nemo-ocean.discourse.group/t/weights-produces-bad-values/438/4 "2023-09-01T07:02:49Z")
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. ---
**Author:** ![m-n-o](https://yyz2.discourse-cdn.com/free1/user_avatar/nemo-ocean.discourse.group/m-n-o/32/101_2.png) [@m-n-o](https://nemo-ocean.discourse.group/u/m-n-o)\ **Post date:** [5 September 2023 12:56 UTC](https://nemo-ocean.discourse.group/t/weights-produces-bad-values/438/5 "2023-09-05T12:56:39Z")
Hello, Elsy. I had changed my focus on preprocessing interpolation via [SOSIE](https://github.com/brodeau/sosie) and it works fine.) ---
**Author:** ![elsy](https://yyz2.discourse-cdn.com/free1/user_avatar/nemo-ocean.discourse.group/elsy/32/163_2.png) [@elsy](https://nemo-ocean.discourse.group/u/elsy)\ **Post date:** [28 September 2023 13:54 UTC](https://nemo-ocean.discourse.group/t/weights-produces-bad-values/438/6 "2023-09-28T13:54:46Z")
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 🙂 ---
**Author:** ![Franziska](https://avatars.discourse-cdn.com/v4/letter/f/8797f3/32.png) [@Franziska](https://nemo-ocean.discourse.group/u/Franziska)\ **Post date:** [24 February 2026 10:21 UTC](https://nemo-ocean.discourse.group/t/weights-produces-bad-values/438/7 "2026-02-24T10:21:08Z")
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.] ---
**Author:** ![elsy](https://yyz2.discourse-cdn.com/free1/user_avatar/nemo-ocean.discourse.group/elsy/32/163_2.png) [@elsy](https://nemo-ocean.discourse.group/u/elsy)\ **Post date:** [24 February 2026 11:58 UTC](https://nemo-ocean.discourse.group/t/weights-produces-bad-values/438/8 "2026-02-24T11:58:50Z")
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. ---
**Author:** ![Franziska](https://avatars.discourse-cdn.com/v4/letter/f/8797f3/32.png) [@Franziska](https://nemo-ocean.discourse.group/u/Franziska)\ **Post date:** [24 February 2026 12:27 UTC](https://nemo-ocean.discourse.group/t/weights-produces-bad-values/438/9 "2026-02-24T12:27:33Z")
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. ![remapping_issue](https://global.discourse-cdn.com/free1/uploads/nemo_ocean/original/1X/7e042075b91e2ae3d8600d52b4f376647a3e67a0.jpeg) Any ideas what to look for? Thanks! ---
**Author:** ![elsy](https://yyz2.discourse-cdn.com/free1/user_avatar/nemo-ocean.discourse.group/elsy/32/163_2.png) [@elsy](https://nemo-ocean.discourse.group/u/elsy)\ **Post date:** [24 February 2026 12:47 UTC](https://nemo-ocean.discourse.group/t/weights-produces-bad-values/438/10 "2026-02-24T12:47:45Z")
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.🙂