|
Hi Ryo, By creating an axis whole span is greater than 360 degrees (you have a grid point at -180 and another at 180) you are actually thwarting Ferret's in-built capabilities to handle longitudes as "modulo". These commands illustrate yes? define axis/x=-180:180:5/units=longitude/edges x360Notice how "X365" lacks the "m" attribute and lacks the comment about its modulo span. An axis may be less than global (e.g. axis "x30") and still be understood to have modulo 360 behavior. This is inferred automatically from its units of degrees_east. To reliably regard a variable defined on an X axis of more than 360 degrees, Ferret would have to check that the overlapping points at each end all had identical values. Ferret has no internal logic to do this. - Steve P.S. The attribute "modulo" is from older Ferret versions. ============================================= On 2/9/2016 3:13 PM, Ryo Furue wrote:
Hi Ferret users, I've come across a netCDF file whose longitude axis is marked "modulo". The dataset includes both values at x = -180 and x = 180. I examined the dataset and confirmed that var[x=-180] == v[x=180] for all latitudes. But, Ferret doesn't recognize the longitude axis as modulo. I understand why not. I looked at the CF conventions but didn't find specifications about modulo longitude. I can see that such a grid configuration as above is sometimes useful. Think about computing gradients in the x-direction when your tool doesn't natively recognize the cyclicity of longitude as when you program in Fortran (because writing var(mod(i-1,N)+1, j, k) is tedious and you have to look up the Fortran manual to see what mod does when i <= 0). For this reason, I hesitate a bit to try to convince the creators of the dataset to fix their longitude axis. Is there a widely-followed convention that deals with this issue for me to cite to convince them with? Or can Ferret be extended to handle this special case? Regards, Ryo |