[IDD #WFA-619667]: Request for CONDUIT feed

Hi Randy,

re: pattern-action file entry broken down

> Excellent. As you wrote this message I made myself figure it out and it
> looks like I agree with you.

Great!

> My problem is I do very little technical
> anymore and it's all slowly fading....

Getting older sucks, doesn't it ;-)

> One other question for now. How do you know that the gefs files you
> created over the weekend are not also corrupt? I just want to rule that
> out.

This is a timely question indeed.  I talked with Robb Kambic (one of the
people working on THREDDS) yesterday about this situation.  I became
convinced that the way that the THREDDS indexing works, a bad GRIB/GRIB2
message might not be directly detected/reported.  It might end up looking
like that field was simply not part of the set of products received by
the LDM.

In fact, Robb _just_ sent me an email about this situation:

  Date:    Tue, 24 Feb 2009 09:43:43 MST
  To:      address@hidden
  cc:      John Caron <address@hidden>

  From:    Robb Kambic <address@hidden>
  Subject: SREF/grefs

  From address@hidden  Tue Feb 24 09: 43:47 2009

  Tom,

  - as long as the underlining os can support large files then the JVM will 
    be able to support large files. so the TDS will be able to support 
    large files too.

  - The TDS 4.0 is in alpha release now but it doesn't have the ensemble 
    support included in it. if testing goes well this week, then ensemble mods 
    will be included.

  - for the grefs corrupted grids, have gruman make available a corrupted 
    file with all the information about the corruption so i can verify the 
    problem.

  Robb...

Robb's first comment relates to my asking if THREDDS would work correctly
on large files on all 32-bit systems.

The second comment relates to when there will be a new THREDDS release that
supports the ensemble data.

The third comment directly relates to the bad GRIB2 messages you are seeing
in the GEFS and SREF data from CONDUIT.

So, we will need to grab one of the files from your system for which wgrib2
shows a bad GRIB2 message.  We will also need the wgrib2 output for that
same file.  It would be most useful if you can produce a wgrib2 output
for an entire file -- meaning that it does not stop when it encounters a
bad GRIB2 message, but, rather, continues listing the rest of the messages
in the file.

When you have created a complete wgrib2 listing for a file that shows one
ore more bad GRIB2 messages, I will logon to your machine and copy it back
to Unidata (you can not do this yourself).

> Hopefully in the next hour we'll have some more answers to this
> mystery..

Yes.  My conversation with Robb was to the effect that we need to determine
if the bad GRIB2 messages you are seeing are a result of one of the following:

- a fault with wgrib2
- an error in transmission by the LDM (not likely!)
- an error when extracting the GRIB2 message from the monolithic model output
  file at the TOC
- an error with the GRIB2 message itself

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: WFA-619667
Department: Support IDD
Priority: Normal
Status: Closed