Re: White band at edge of domain

[Steve Cousins <cousins@xxxxxxxxxxxxxxxxxxxxxxx>]

On Wed, 28 Jan 2004, Joe McLean wrote:

> Hi Steve,
> 
> Did you remove the old gif and html files from your las/server/output directory?
> If the image still has the white band through LAS, and you have set up Ferret
> correctly, thi smay be the problem.  You can tell which gif it is by using "view
> source" in your popular browser and finding the href attribute pointing to the
> image.  The html page in the output directory should have the same prefix.
> 
> Joe

Hi Joe,

Yes, I cleaned out the output directory when trying it with LAS.  I also
selected new areas and used different variables to make sure it wasn't a
caching problem (either with the server or the browser).  

Steve


> -------------------------------------------------
> 
> Steve Cousins wrote:
> 
> >> On Tue, 27 Jan 2004, Jonathan Callahan wrote:
> >>
> >> > Steve,
> >> >
> >> > The first thing that occurs to me is that the modulo flag might not be
> >> > set for the longitude axis in the netCDF file.  This would cause the
> >> > behavior you describe.
> >>
> >> Hi Jon,
> >>
> >> I've changed the data set to have:
> >>
> >> dimensions:
> >>         time = UNLIMITED ; // (12 currently)
> >>         latitude = 116 ;
> >>         longitude = 100 ;
> >>         depth = 25 ;
> >>         latitude_u = 116 ;
> >>         longitude_u = 100 ;
> >> variables:
> >>         float time(time) ;
> >>                 time:long_name = "time" ;
> >>                 time:units = "months since 15-DEC-2003 00:00:00" ;
> >>                 time:time_origin = "15-DEC-2003 00:00:00" ;
> >>                 time:modulo = " " ;
> >>         float latitude(latitude) ;
> >>                 latitude:units = "degrees" ;
> >>                 latitude:long_name = "Latitude" ;
> >>         float longitude(longitude) ;
> >>                 longitude:units = "degrees" ;
> >>                 longitude:long_name = "Longitude" ;
> >>                 longitude:modulo = " " ;
> >>         float latitude_u(latitude_u) ;
> >>                 latitude_u:units = "degrees" ;
> >>         float longitude_u(longitude_u) ;
> >>                 longitude_u:units = "degrees" ;
> >>                 longitude_u:modulo = " " ;
> >>
> >> etc.
> >>
> >> Unfortunately it doesn't help as far as Ferret goes.  Ansley suggested a
> >> quick test doing:
> >>
> >>         define axis/modulo axisname
> >>
> >> I tried a number of variations of this with no luck, however, I was
> >> successful with:
> >>
> >>         set axis/modulo longitude
> >>
> >> So, that works with Ferret.  The data I'm working with is actually on a
> >> restricted LAS server and LAS doesn't seem to be picking up the
> >> information about the modulo longitude variable (I did addXml.pl and then
> >> make) or something else is going on because LAS still shows the White
> >> line.
> >>
> >> With the modulo attribute set in the netCDF file should I have to do
> >> anything else in Ferret (define axis, or set axis) in order to have ferret
> >> overlap the longitudes correctly?  With modulo set should I be able to do:
> >>
> >> use l.nc
> >> fill/X=-180:180/k=5/t=1 DIAT
> >>
> >> and not have the line under Africa?  Currently this works only if I also
> >> do: set axis/modulo longitude.  This would be fine if I was just using
> >> Ferret, but with LAS it might complicate things a little.  Do I need to
> >> put something in the las.xml file for this?  Depending on the answers I
> >> get above I'll move my questions to the LAS email list.
> >>
> >> Thanks very much,
> >>
> >> Steve
> >>
> >> >
> >> >
> >> > -- Jon
> >> >
> >> >
> >> > Steve Cousins wrote:
> >> >
> >> > >>Hi,
> >> > >>
> >> > >>I have a netCDF file that has longitudes from 23.4 degrees to 379.8
> >> > >>degrees stepping by 3.6 degrees.
> >> > >>
> >> > >> longitude = 23.4, 27, 30.6, 34.2, 37.8, 41.4, 45, 48.6, 52.2, 55.8, 59.4,
> >> > >>63, 66.6, 70.2, 73.8, 77.4, 81, 84.6, 88.2, 91.8, 95.4, 99, 102.6, 106.2,
> >> > >>109.8, 113.4, 117, 120.6, 124.2, 127.8, 131.4, 135, 138.6, 142.2, 145.8,
> >> > >>149.4, 153, 156.6, 160.2, 163.8, 167.4, 171, 174.6,178.2, 181.8, 185.4,
> >> > >>189, 192.6, 196.2, 199.8, 203.4, 207, 210.6, 214.2, 217.8, 221.4, 225,
> >> > >>228.6, 232.2, 235.8, 239.4, 243, 246.6, 250.2, 253.8, 257.4, 261, 264.6,
> >> > >>268.2, 271.8, 275.4, 279, 282.6, 286.2, 289.8, 293.4, 297, 300.6, 304.2,
> >> > >>307.8, 311.4, 315, 318.6, 322.2, 325.8, 329.4, 333, 336.6, 340.2, 343.8,
> >> > >>347.4, 351, 354.6, 358.2, 361.8, 365.4, 369, 372.6, 376.2, 379.8 ;
> >> > >>
> >> > >>If I do:
> >> > >>
> >> > >>    fill/k=1/l=1 SSH
> >> > >>
> >> > >>It looks fine.  If I do:
> >> > >>
> >> > >>    fill/i=21:120/k=1/l=1 SSH
> >> > >>
> >> > >>to shift the the plot then there is a vertical white line that goes
> >> > >>through Africa.  You can see this at:
> >> > >>
> >> > >>    http://rocky.umeoce.maine.edu/images/problem.gif
> >> > >>
> >> > >>I assume this has to do with some overlap problem but I
> >> > >>haven't seen it before with other similar data sets.  I've checked the
> >> > >>data and there is data in the last column so it shouldn't be interpreted
> >> > >>as land.  For instance:
> >> > >>
> >> > >>  379.4641, 382.4534, 358.5003, 356.5043, 353.662, 359.2267, 365.5977,
> >> > >>    369.4947, 392.3723, 374.757, 372.0594, 389.124, 390.5706, 391.9053,
> >> > >>    393.023, 397.463, 375.3581, 371.0126, 372.924, 392.4577, 373.5735,
> >> > >>    364.2137, 364.4178, 372.6771, 392.912, 378.2903, 369.8222, 391.9157,
> >> > >>    370.6215, 371.5577, 371.0256, 377.0153, 374.279, 386.7569, 390.8015,
> >> > >>    371.6572, 365.4334, 366.7746, 364.0185, 362.7578, 379.4369, 377.3554,
> >> > >>    375.8331, 376.2615, 376.9933, 378.4856, 379.1119, 369.9149, 373.0526,
> >> > >>    376.518, 378.6648, 381.4642, 382.6173, 383.2715, 384.5013, 384.4879,
> >> > >>    384.6168, 386.2058, 386.3334, 384.5129, 383.7413, 384.0238, 384.1737,
> >> > >>    384.5389, 384.4421, 382.0946, 380.4161, 384.2753, 386.06, 384.2455,
> >> > >>    383.0246, 381.7079, 383.1534, 385.2602, 386.4101, 370.0849, -1e+34,
> >> > >>    368.7702, 362.1729, 358.6587, 360.2878, 362.5882, 363.6682, 367.4212,
> >> > >>    374.6625, 380.5357, 384.4504, 386.2372, 387.3375, 386.3895, 383.0319,
> >> > >>    381.321, 381.4418, 383.392, 382.2667, 382.2667, 380.2295, 376.7909,
> >> > >>    379.5762, 378.9742,
> >> > >>
> >> > >>This is at 66 degrees South which has valid entries for almost all of the
> >> > >>horizontal grid points.  -1e+34 is the land value.
> >> > >>
> >> > >>Has anyone seen this before?  Any ideas about how to bridge the gap?  This
> >> > >>is version 5.51 on a Redhat Linux 7.3 server.
> >> > >>
> >> > >>Thanks,
> >> > >>
> >> > >>Steve
> >> > >>_____________________________________________________________
> >> > >> Steve Cousins                 Email: cousins@umit.maine.edu
> >> > >> Research Associate            Phone: (207) 581-4302
> >> > >> Ocean Modeling Group
> >> > >> School of Marine Sciences     208 Libby Hall
> >> > >> University of Maine           Orono, Maine 04469
> >> > >>
> >> > >>
> >> > >>
> >> > >>
> >> > >
> >> > >
> >> >
> >
> >
>