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

[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


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.