[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> 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