[Datastream #IZJ-689237]: Additional Datafeeds

Hi Jeff,

re:
> Well, I'm pulling my hair out (OK, I don't have any hair, but if I did,
> I would be pulling it out),

:-)

> trying to figure out what is causing the
> dcgrib2 "cannot write to file" errors on the model data.

I am also perplexed (to say the least) about the problems you are experiencing.
They are quite different than anything we have seen before.

> I've tried
> numerous things, to no avail.

For "grins", I would try downloading the GEMPAK 5.11.1 binary release for
64-bit Linux and trying its decoders.  I am not expecting that this will change
anything, but it can't hurt.

The other thing that you could try is downloading the 32-bit 5.11.1 binary 
release
and trying those decoders.  They should work fine on 64-bit Linux.
 
> It seems to me that maybe it's not write
> permissions on the file but possibly a misconfigured file path
> somehow/somewhere that's sending it to a non-existent file location.

I did not see that you changed anything in the GEMPAK-script-generated 
pqact.conf
files, so it would seem that the paths for those should be OK.

> Over the last couple of days, I've:
> 
> 1> Set and reset the file permissions on all of the data files.
> 2> Tried to redo the file paths to resemble the usual file paths
>    (~ldm/data -> /var/data/ldm rather than /var/data/ldm/data), etc.

Very good.

> 3> Swapped in a precompiled copy of dcgrib2, in place of the one built
>    on the machine.

OK, so you tried one of the tests that I listed above (rats that this didn't
have any effect!).

> I find it interesting that part of the log message is that it can't find
> some GRIB records and parameter names.

This may well be due to the 5.11.1 tables not having entries for parameters
that are being received.

> Is it possible that because it's
> not finding all of the info that it needs that maybe it doesn't even get
> a filename or path to write to?

I don't think so.

> Shouldn't the GRIB records and
> parameters all be there?

New parameters are being added to NOAAPort and IDD model datastreams all of
the time.  It is possible that a _small_ part of the effect you are seeing
is due to this.

> I'll probably try moving on to substituting
> tables, etc...

This shouldn't matter.

FYI:  Last Friday afternoon/evening I worked with an LDM workshop attendee who
was having problems processing HDS (aka HRS) he was receiving by the IDD.  Hours
of trial and error revealed that disabling IPv6 on his workstation made things
work.  The good thing about our testing was that he had 'root' privilege on his
machine, so we could make wholesale changes on the spot to see if there any
effects.  The process also required rebooting the machine several times.

The reference I used for disabling IPv6 was:

  How To Disable IPv6 on Fedora / Linux & Why
  
http://blog.taragana.com/index.php/archive/how-to-disable-ipv6-on-fedora-linux-why/

The other thing I might try on your machine "just in case" is changing the
clock to run on local time instead of on UTC (recall that the OS actually uses
UTC, but the end-user view of the time is typically local time).

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: IZJ-689237
Department: Support IDD
Priority: Normal
Status: Closed