[IDV #TOO-707846]: Possible small bug between RTOFS and IDV

Greetings Avichal,

Just out of curiosity, what security issues with THREDDS are you referring to in
track 2 below?

Thanks!

Sean

> 
> 
> Hello Murray,
> 
> Yes, you are correct. We need to somehow fix these problems.
> And we are pursuing two tracks:
> 
> Track 1:  As per my understanding, removal of empty date and time will 
> require customized changes
> to GDS which might not be feasible, given that GDS serves out multiple 
> operational
> systems. Instead, providing the missing fields i.e. at times f000 and n000 is
> preferable. This
> will require changes to the operational RTOFS Global system. I was hoping for
> this early
> next year but with this shutdown -- all such time lines will have to be 
> reassessed.
> 
> Track 2:   Make THREDDS operational. Now, this is somewhat harder to 
> implement because of some
> prior well-known security issues with THREDDS. But lately, these issues have 
> been
> overcome and we plan to have a non-operational/developmental THREDDS server up
> and running for testing purposes in the near future.
> 
> Cheers, Avichal.
> 
> 
> 
> On 10/17/2013 06:43 AM, Murray Brown wrote:
> > Good Morning Avichal,
> >
> > Glad you're back to full duty.  This is to take up our interrupted 
> > discussion from Oct 1:
> >
> > I've gone over everything you've said and I appreciate your candor.  I 
> > think I understand your points about the underlying technical issues.  But 
> > I can't help but say that explanations about why something is wrong are not 
> > the same thing as making something right.  There are examples of 
> > OPENDAP-based servers that muddle through the date and time problems 
> > accurately, e.g. http://marinedataliteracy.org/ops/modwaves.htm.  Can the 
> > missing products be provided, or -- less desirable -- can the empty date 
> > and time be deleted?
> >
> > Murray
> >
> > -----Original Message-----
> > From: Avichal Mehra [mailto:address@hidden]
> > Sent: Tuesday, October 01, 2013 10:12 AM
> > To: Murray Brown
> > Cc: address@hidden; address@hidden; address@hidden
> > Subject: Re: [IDV #TOO-707846]: Possible small bug between RTOFS and IDV
> >
> > On 09/30/2013 06:58 PM, Murray Brown wrote:
> >> Hi Avichal,
> >>
> >> Thanks for the informative reply.  Before I can understand it completely, 
> >> I need to ask 2 secondary questions:
> >>
> >> In Panel 20, the date 20130923 appears, but it has no data.  Does the data 
> >> link 20130924, just below, refer accurately to data for September 24, or 
> >> to a different day? Which day?
> >         NOMADS only keeps RTOFS data for one day. As the next day is 
> > populated, data from the previous data is removed.
> >         This process continues till the next day is fully populated and the 
> > previous day directory is empty.
> >
> >         The directory name is the actual time stamp of the data.
> >> Similarly in Panel 21, does the link for "10 millibars" refer accurately 
> >> to data for 10 m, or to a different depth?  Which depth?
> >          10 meters.
> >
> >           Cheers, Avichal.
> >> Murray
> >>
> >> -----Original Message-----
> >> From: Avichal Mehra [mailto:address@hidden]
> >> Sent: Monday, September 30, 2013 3:52 PM
> >> To: Murray Brown
> >> Cc: address@hidden; address@hidden;
> >> address@hidden
> >> Subject: Re: [IDV #TOO-707846]: Possible small bug between RTOFS and
> >> IDV
> >>
> >>
> >>     Hello Murray,
> >>
> >>       Let me address both the time stamp and variable "lev" issues:
> >>
> >>       1. The time stamp issue is a peculiarity of GDS (GRADS Data Server) 
> >> where
> >>            it defaults to having a counter "0" in the first file name (as 
> >> in f000). Since
> >>            RTOFS files start from f001 (not f000), it gives an error (or 
> >> undefined values)
> >>             for the first time stamp.
> >>
> >>            In future, we will address this by providing a f000 file or 
> >> switching to THREDDS
> >>             which has no such requirement.
> >>
> >>      2. GDS was designed for NWP -- not ocean models. As such, they have 
> >> no option
> >>         of assigning  positive = "down" to the variable lev or any other 
> >> variable to
> >>         signify depths (below the surface). The unit for this variable is 
> >> meters not
> >>         millibars. We are hoping to fix this in a future upgrade of NOMADS.
> >>
> >>     Cheers, Avichal.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On 09/27/2013 03:56 PM, Murray Brown wrote:
> >>> Hi Yuan,
> >>>
> >>> Nice to hear from you.  Hope you're OK out there after all the troubles 
> >>> this summer.
> >>>
> >>> Your analysis is very thorough, and I appreciate your time in checking.  
> >>> We’ll wait to see what my RTOFS contact has to say.
> >>>
> >>> Murray
> >>>
> >>> -----Original Message-----
> >>> From: Unidata IDV Support [mailto:address@hidden]
> >>> Sent: Friday, September 27, 2013 3:03 PM
> >>> To: address@hidden
> >>> Cc: address@hidden; address@hidden;
> >>> address@hidden
> >>> Subject: [IDV #TOO-707846]: Possible small bug between RTOFS and IDV
> >>>
> >>>> Dear Folks,
> >>>>
> >>>> I've been working on cleaning up my exercises for operational work,
> >>>> and just completed the draft of 9.31 Visualizing Ocean Model Scalars
> >>>> <http://www.marinedataliteracy.org/ops/rtofs_mod.htm> & Vectors in
> >>>> IDV: RTOFS/HYCOM.  I ran into something that you should know about,
> >>>> as it possibly involves a bug.  Check out Panel 20-21 in the draft
> >>>> and you see what I mean.it was easier to include it in the draft
> >>>> with illustrations than to describe it in an email.  Something is
> >>>> screwing up the indexing or the reading of the first objects in the
> >>>> lists, by time and/or by depth.  In the old days we immediately
> >>>> suspected that one system's counter was 0-based and the other was
> >>>> 1-based, but it's probably more complicated nowadays.
> >>>>
> >>>> Second, smaller issue:  The appearance of millibars instead of
> >>>> decibars is probably just a fiendish glitch somewhere, but I don't
> >>>> know whether this comes in with the RTOFS data or is read from a 
> >>>> dictionary somewhere.
> >>>>
> >>>> Anyway, please take a look, and while you're at it, don't hesitate
> >>>> to let me know about any errors or wrong turns.  Thanks.
> >>> Murray,
> >>>          I checked the rtofs dataset, and it seems to me this is the 
> >>> problem of the remote data server. This data is in GrADS format, and the 
> >>> index of time and depth in its control file probably misses by 1. You 
> >>> need to contact the data providers for more information. Also, you can 
> >>> tell them to add attribute positive = "down"  to the variable lev, (and 
> >>> correct unit for this variable if you think the correct unit should be 
> >>> decibars). So, the display will be showing under the earth surface.
> >>>
> >>>
> >>> Yuan
> >>>> Murray
> >>>>
> >>>> Murray Brown, PhD
> >>>> 1710 Washington St., Apt. B
> >>>> New Smyrna Beach, Florida 32168
> >>>> PLEASE USE ONLY THIS EMAIL --> address@hidden
> >>>> (Home) 386.428.6367, (Cell) 386.341.0868 www.marinedataliteracy.org
> >>>> <http://www.marinedataliteracy.org/>
> >>>>
> >>>>
> >>>>
> >>> =========================================== Dr. Avichal Mehra 
> >>> address@hidden In charge
> >>> -Ocean Modeling Operations, NWS/NCEP/EMC NOAA Center for Weather & 
> >>> Climate Prediction 5830
> >>> University Research Court Room 2107 College Park Ph. 301-683-3746 MD 
> >>> 20740 Fax: 301-683-3703
> >>> ===========================================
> 
> 

Ticket Details
===================
Ticket ID: TOO-707846
Department: Support IDV
Priority: High
Status: Open