White line running through 0 (zero) meridian in map plots due to data shifting.

[rswamina]

I have noticed a white line indicating no data available along the 0 (zero) degree meridian for some data sets when plotting maps. These are data sets whose native grid goes from 0 to 360 and has been shifted to run from -180 to 180 by ESMValTool routines. An example would be the CESM1-BGC model data. Regridding potentially could make this white line thicker as well. I don't necessarily think there is a problem with the shift routines but was wondering if there is a solution to this?

[valeriupredoi]

what variables are you looking at? Can you pls give me the fullpath to the file on BADC? :beer:

[rswamina]

One example is soil moisture : /badc/cmip5/data/cmip5/output1/NSF-DOE-NCAR/CESM1-BGC/esmHistorical/mon/land/Lmon/r1i1p1/latest/mrsos/mrsos_Lmon_CESM1-BGC_esmHistorical_r1i1p1_185001-200512.nc

[mattiarighi]

I guess you are using NCL. This is a known issue. You can try solving it by setting:

gsnAddCyclic = True

in your plot resources.

See the discussion here for more details.

This however does not work well if you have missing values in your input data.

[valeriupredoi]

cheers @rswamina - note that the CMOR standard for 'longitude' is 0-360 degs and that file you point me to is correctly cmorized (0-360). What routines are you referencing to when you say ESMValTool converts them to -180 to 180 degs?

[mattiarighi]

I guess the NCL plotting routines, that by default show the data on a -180:180 map. This can be changed of course.

[rswamina]

I am (a) reading monthly data as specified in previous comment, (b) computing annual average and (c) plotting the annual average using iris routines with python. Specifically I use the contourf routine. I noticed that this white line appeared in the CESM1-BGC data set and appeared when that data set was included in a multimodel mean. I thought that native grids of 0 to 360 are shifted to go from -180 to 180 when read by the ESMValTool and wondered if this was introduced during the shift. The plots are naturally plotted in a grid -180 to 180 hence the assumption that the shift was done by the tool when reading in the data. How can I fix this under such circumstances? I notice the recipe_perfmetrics_CMIP5 recipe uses this data set and am not sure if this problem is reproduced for any plots there?

[valeriupredoi]

ESMValTool will not shift the grid if it's already on a 0-360 grid. contourf does it for graphical purposes; one thing you can do is to examine the output file in iris and see if the data is masked there for any reason

[rswamina]

Ok. I will take a look and get back...

[rswamina]

I have found out the reason for the white line - it is due to regridding to a particular resolution. I am not sure why exactly but regridding to a different resolution fixed this. It also happens only in certain data sets, ones where the native grid goes from 0 to 360 I believe. I am closing this issue because I know why the white line occurs. I am yet to find a way to fix this for certain grid resolutions (or discover that is not possible with iris regridding options). Thanks you @valeriupredoi and @mattiarighi

[valeriupredoi]

good stuff @rswamina but the question is - is it the iris regridding from esmvalcore that is causing this or it is a plotting artefact from the iris plotter? if the regridding mechanism is creating it then it'll be possible to see it in the cube mask (ie there will be a column of True's along the 0 meridian) and that's bad so I wouldn't close the issue unless we are sure it's just a plotting deficiency :beer:

[rswamina]

I believe it is the iris regridding and not the plotting. I was going to debug to see why a particular resolution caused this problem, will check this as well.

[bouweandela]

I've seen a similar issue when testing the perfmetrics recipe https://github.com/ESMValGroup/ESMValTool/pull/939#issuecomment-477154001

[valeriupredoi]

the question is, with the risk of repeating myself, is this a plotting artifact or an issue in the data produced by a certain analysis. Please look in the cube and if it's found in the data, need to look at different stages of the preprocessing: run with save_intermediary_cubes: true and look in each of that dataset's preprocessed output cubes to identify which step produces the line

[valeriupredoi]

any updates on this one @rswamina ?

[rswamina]

I am having problems running setup.py -- once that is fixed will get to this issue..not forgotten!

[valeriupredoi]

cool, see my comment on that issue, you should be fine with --name :grin:

[mattiarighi]

@rswamina please close the issue if solved.

[mattiarighi]

Any update?