[IDV #ANH-722599]: 1-day offset error bug when saving .zidv bundles

> Why does IDV grab the right data when loading the .xidv,
> but not when downloading it to save the .zidv?
> 
> Can't the correct behaviour of loading the displays be replicated
> in the reading of data for the .zidv file?
> 

Well, the data saved in the zidv file is corrected. But the local nc java 
library uses the new standard to interpolate this and the result is 2 day off, 
this is why you only see one time frame.


Yuan
> 
> On May 2, 2013, at 11:20 PM, Unidata IDV Support wrote:
> 
> >> Wow, what a puzzle, and such a surprising one.
> >> You're my hero for tracking it down.
> >> I'm glad there is a fix.
> >>
> >> But how can I tell which of my several datasets needs the fix?
> >> I should look for base time in the header?
> >
> > You can reference:
> >
> > http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#calendar
> >>
> >> Will this always be a problem, or will the netcdf-java libraries get 
> >> updated to fix this someday?
> >
> > Actually, this is the updated netcdf java library that follows more strick 
> > CF conventions. If you run the IDV 3.1 version, you can probably get what 
> > you want.
> >>
> >> Actually I will tell the dataset curators about it, they may fix it 
> >> (gradually) in the future.
> >> I don't want to become too reliant on .ncml fixes in my RAMADDA server for 
> >> the long term.
> >
> > Good luck with that.
> >
> >
> > Yuan
> >>
> >>
> >>
> >> I will be around Boulder next week at Foothils Lab. I may drop by.
> >> Thanks for finding this one!
> >> Brian
> >>
> >>
> >>
> >> On May 2, 2013, at 9:09 PM, Unidata IDV Support wrote:
> >>
> >> Not ramadda, they are from gds servers I think. I have a .ncml for merra 
> >> on my ramadda server that fixes some units but the data is in Maryland.
> >>
> >> Brian Mapes
> >>
> >> Well, good to know this information.
> >>
> >> I think I know what is wrong here.  It is not the IDV, it is the dataset 
> >> and you may need to modify the ncml file to make it work correctly in the 
> >> IDV .
> >>
> >> If you unzip the zidv file, you will see the data saved in the zidv file 
> >> has the correct time steps but off by 2 days. This is why you only see one 
> >> time display in the IDV.
> >>
> >> In the new netcdf-java library, you need to be careful in that you specify 
> >> which calendar you are using. If it's not specified, a mixed Gregorian / 
> >> Julian calendar is used unless your base time unit occurs before 
> >> 1582-10-15. In your case, a proleptic_gregorian calendar is used, which 
> >> treats leap years a bit differently. Because the calendar attribute isn't 
> >> used in the netCDF file, the leap years and handled differently, resulting 
> >> in the two day difference. The fix? Add the calandar attribute using NcML:
> >>
> >> <?xml version="1.0" encoding="UTF-8"?>
> >> <netcdf xmlns="http://www.unidata.ucar.edu/namespaces/netcdf/ncml-2.2";
> >> location="./****.nc">
> >> <variable name="time">
> >> <attribute name="calendar" value="gregorian" />
> >> </variable>
> >> </netcdf>
> >>
> >>
> >> Yuan
> >>
> >>
> >> This message was typed on a cell phone, please forgive its terseness and 
> >> any errors.
> >>
> >> On May 2, 2013, at 7:16 PM, "Unidata IDV Support" 
> >> <address@hidden<mailto:address@hidden>> wrote:
> >>
> >> Full Name: brian mapes
> >> Email Address: address@hidden<mailto:address@hidden>
> >> Organization: U of Miami
> >> Package Version: 4.0u2 build date:2013-04-30 07:05 UTC
> >> Operating System: Linux
> >> Hardware: Java: home: /home/aescobedo/Desktop/IDV_4.0u2/jre version: 
> >> 1.6.0_41 j3d:1.5.2 fcs (build4)
> >> Description of problem: I have a problem starting from a template .xidv 
> >> bundle (attached) that I like.
> >> Multiple data sources, 11 displays.
> >>
> >> 1. I changed the time driver end date to 1999-09-16.
> >> 2. I saved the resulting session (hurricane Floyd) to a .zidv bundle.
> >> 3. I opened the .zidv bundle in a fresh IDV session.
> >> The IR satellite is shown for the right times, but the others (TRMM,MERRA) 
> >> don't animate. They appear right at the initial frame but they don't move. 
> >>  .
> >>
> >>
> >> Brian,
> >> This looks like a bug to me, I will let you know when there is fixed.
> >>
> >>
> >> Yuan
> >> Brian,
> >>
> >> Just to verify, are those dataset (TRMM, MERRA), that not working 
> >> correctly in the zidv, from ramadda server?
> >>
> >>
> >> Yuan
> >>
> >> A volunteer made me a bunch of .zidv case study bundles that all have this 
> >> problem.
> >> All are probably valueless, we will have to start over from the template I 
> >> suppose. I wish there were salvage tools but I doubt it.
> >>
> >> In that light, is there a way to save a .zidv bundle, with all its data 
> >> sources and all the fields that are displayed, WITHOUT having to click OK 
> >> on the (default) fields to save in each data source, one by one, as they 
> >> come up during the slow save process?
> >>
> >> It's really no fun as you will find out if you do the above, a wasted 
> >> several minutes when you can't do anything else. I dare not even go to 
> >> another virtual desktop, as IDV's "OK" popups get stuck in the wrong 
> >> workspace for me sometimes and hang the session.  I just have to sit there 
> >> and hit return occasionally like a zombie.
> >>
> >> Thanks,
> >> Brian
> >>
> >>
> >>
> >>
> >>
> >>
> >> Ticket Details
> >> ===================
> >> Ticket ID: ANH-722599
> >> Department: Support IDV
> >> Priority: Normal
> >> Status: Open
> >>
> >>
> >>
> >>
> >> Ticket Details
> >> ===================
> >> Ticket ID: ANH-722599
> >> Department: Support IDV
> >> Priority: Normal
> >> Status: Open
> >>
> >>
> >> Brian Mapes
> >> address@hidden<mailto:address@hidden>
> >>
> >>
> >>
> >>
> >>
> >
> > Ticket Details
> > ===================
> > Ticket ID: ANH-722599
> > Department: Support IDV
> > Priority: Normal
> > Status: Open
> >
> 
> Brian Mapes
> address@hidden or address@hidden
> 
> 
> 
> 


Ticket Details
===================
Ticket ID: ANH-722599
Department: Support IDV
Priority: Normal
Status: Open