This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
> 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