NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.

To learn about what's going on, see About the Archive Site.

Re: [idvusers] [thredds] Update - Changes to thredds.ucar.edu

I'm going to ask that you either keep this discussion on the list, or, if
that's not practical, please keep me in the loop. I use IDV occasionally,
and I'm about to institute a TDS here for some of our research. I need to
know when things stabilize and it's time for me to update. I have also
found the discussion interesting. Roy, sorry if it's too much traffic but
having it go offline means it suddenly goes into a black hole for some of
us.

gerry


On Thu, Apr 3, 2014 at 8:25 AM, Robert Mullenax <
Robert.Mullenax@xxxxxxxxxxxxx> wrote:

>  Yes agreed there are a lot of advantage to remote and THREDDS and McIDAS
> ADDE are really amazing!
>
>
>
> -----Original Message-----
> From: John Caron [mailto:caron@xxxxxxxxxxxxxxxx <caron@xxxxxxxxxxxxxxxx>]
> Sent: Thu 4/3/2014 8:04 AM
> To: Robert Mullenax
> Cc: thredds@xxxxxxxxxxxxxxxx; idvusers@xxxxxxxxxxxxxxxx
> Subject: Re: [idvusers] [thredds] Update - Changes to thredds.ucar.edu
>
> Hi Robert:
>
> Good advice, thanks.
>
> GEMPAK is an interesting contrast in table management. It uses
> hand-maintained mappings of GRIB tables to an assigned variable name. it
> is NCEP specific, so cant be used as a general solution to all GRIB
> files. NCEP is focused on keeping operational software like AWIPS
> current (probably GEMPAK is in this category), and not much else, in
> particular archived data is an afterthought. Tools like wgrib and wgrib2
> use these hand maintained tables, but its up to the user to ensure that
> the tables are current, though users typically dont have the expertise
> to know how to do that. The system hangs together likely 99.44% of the
> time, but it sometimes "silently fails" by misidentifying variables.
>
> Anyway, the problems with changing names is part of GRIB, regardless of
> whether its local or remote. The advantage of remote is that, in
> principle, the right thing can be done on the server and clients can
> take advantage of it.
>
> Regards,
> John
>
> On 4/2/2014 8:03 PM, Robert Mullenax wrote:
> > I would also add that depending on bundles from Unidata is short
> sighted. As has been noted Unidata is not 24/7. The great thing about
> GEMPAK is it forces you to be self sufficient at least to the point where
> you are responsible for your own downloads. Maybe a greater reliance on
> local datasets would be a good thing for IDV. I know that GEMPAK and McIDAS
> are passé but their are advantages..even in the teaching and research realm.
> >
> >
> >
> >> On Apr 2, 2014, at 8:08 PM, "Robert Mullenax" <
> Robert.Mullenax@xxxxxxxxxxxxx> wrote:
> >>
> >> I am not a frequent IDV user but the basic rule of being a sys admin or
> developer is to not make changes on a Friday afternoon unless you are
> staffed 24/7.  I am a just a met guy and a somewhat annoying presence to
> Unidata but that has been my experience over the years as a pretend sys
> admin and developer.
> >>
> >> In other words, test it thoroughly, and don't release on a Friday
> unless there is a lot of backup support..
> >>
> >> Hang in there,
> >> Robert Mullenax
> >> CSBF/NMSU
> >>
> >>
> >>
> >>> On Apr 2, 2014, at 7:38 PM, "John Caron" <caron@xxxxxxxxxxxxxxxx>
> wrote:
> >>>
> >>> Hi all:
> >>>
> >>> The rollout on friday hit a few snags, compounded by me being sick so
> I couldnt respond quickly. "Bundles broke" because there was a file leak
> that brought the whole server down. Also there was a problem with the way
> the new GRIB indexer handled GRIB1 timeType=10. Those problems have been
> fixed now.
> >>>
> >>> You might think "why dont we just wait?" The problem is that the TDS
> 4.3 server is not getting updated as the data changes. We made a decision 2
> weeks ago that it wasnt worth fixing, since the problem is fixed in 4.5. So
> its in all of our interests to get 4.5 onto thredds.ucar.edu, as soon as
> possible .
> >>>
> >>> You might think "Why didnt we find these problems before releasing?"
> Because we dont have a separate test team, like commercial software release
> cycle does. We constantly improve our testing, but plenty gets past us. We
> rely on the users to find the last set of bugs. And its all but impossible
> to get users to try beta software. Fact of life.
> >>>
> >>> The variable names have not changed. The bundles will still work. We
> are fixing the ones that Darryl discovered had changed.
> >>>
> >>> The ncss service changed its service endpoint. Users reading the
> catalog or using the html form will pick that up transparently. If you have
> it hardcoded in a script, then you need to change it. If its operational,
> you have to do it immediately after we switch. Just remove the /grid/ part
> of your URL. The IDV doesnt use the ncss service.  If theres an actual
> script user who is using the ncss service, who cant make changes in a
> timely manner, let us know and we will work with you. We dont need to
> imagine possible scenarios that may not exist.
> >>>
> >>> Right now, we know there's a problem with the radar server, which we
> will have fixed by tommorrow. Otherwise, try your bundles against
> thredds-test.unidata.ucar.edu. Give it a try, report the problems, we
> will get them fixed. When they are fixed, we will make the switch. But
> please dont wait a week, do them this week.
> >>>
> >>> Theres typically a long tail of problems that get fixed over time. If
> you cant get to it, ok, let us know when you find them and we will fix the
> problem then. The IDV could make a contribution here by allowing users to
> easily update the URLS in their bundles. The NCEP models are constantly
> changing, not to mention the GRIB tables themselves. The idea that URLS can
> never change is not a real possibility. Just a fact of life.
> >>>
> >>> We arent releasing 4.5 yet for others to use. We are shaking it out
> against the thredds.ucar.edu live server. We dont really have any better
> options. We are working really hard to make this work. I would personally
> appreciate any help you can give.
> >>>
> >>> Thanks,
> >>> John
> >>>
> >>> _______________________________________________
> >>> idvusers mailing list
> >>> idvusers@xxxxxxxxxxxxxxxx
> >>> For list information, to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
> >> _______________________________________________
> >> idvusers mailing list
> >> idvusers@xxxxxxxxxxxxxxxx
> >> For list information, to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
>
>
>
> _______________________________________________
> thredds mailing list
> thredds@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe,  visit:
> http://www.unidata.ucar.edu/mailing_lists/
>



-- 
Gerry Creager
NSSL/CIMMS
405.325.6371
++++++++++++++++++++++
"Big whorls have little whorls,
That feed on their velocity;
And little whorls have lesser whorls,
And so on to viscosity."
Lewis Fry Richardson (1881-1953)


  • 2014 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the idvusers archives: