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

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



> 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> wrote:
> 
> >>> Full Name: brian mapes
> >>> Email Address: 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


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.