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

[CONDUIT #OZC-764376]: pqact.gempak_decoders_conduit

Hi Mina,

Please note that I moved this inquiry from our CONDUIT support (support-conduit)
to GEMPAK support (support-gempak) as it is not a CONDUIT-specific problem.

> I have two machines both with GEMPAK5.11.4. both machines run ldm with
> the same pqact "pqact.gempak_decoders_conduit". nam212, nam104, and
> nam216 produced on the two machines with different size
> machine 1: 41M -rw-rw-r-- 1 ldm ldm 41M Oct 30 10:33 2009103012_nam212.gem
> machine 2: 169M -rw-r--r--  1 ldm gempak 168M Oct 30 11:00 09103012_nam212.gem
> same size issue applies to nam104 and nam216. looking at the machine 1
> dcgrib2_NAM.log log file I see the following error:
> [9169] 091030/1049[DECODE_GRIB2 -6] TSTM03 [091030/1200F069] 0:-1 NONE 185 129
> [9169] 091030/1050[FL -5]  Cannot write to file ....
> [9169] 091030/1050[DM 0]
> [9169] 091030/1050[DECODE_GRIB2 -6] DRCT [091030/1200F069] 10:-1 HGHT 185 129
> [9169] 091030/1050[FL -5]  Cannot write to file ....
> [9169] 091030/1050[FL -5]  Cannot write to file ....
> [9169] 091030/1050[DM 0]
> the files nam212, nam104, nam216 are being created, with the above size
> issue,  however it seems that the process can not go back and open the
> files to write more data.
> Has anyone seen this before or can you point to where I should start to
> troubleshoot the this problem.

I have seen data filing/decoding problems like the one you are reporting
on CentOS Linux systems in which IPv6 support is enabled.  In fact, in
one particularly bad case, no products would be processed.


- what OSes are your systems running (e.g., RedHat Enterprise; CentOS;
  Solaris 10 x86_64, etc.)  (the output from 'uname -a' on each system
  would be helpful

Our "solution" (hack/workaround/etc.) for the "bad case" was to configure
the system to not run/use/support IPv6.  The following article will likely
be of interest:

How To Disable IPv6 on Fedora / Linux & Why

Basically, the changes were:


alias net-pf-10 off
alias ipv6 off





Also, turn off IPv6 iptables if it is on.

A reboot is the quickest/most foolproof way to insure that the changes
have taken effect even though the article listed above suggests simply
restarting your networking.

Please let us know if you decide to implement this "fix", and your


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: OZC-764376
Department: Support GEMPAK
Priority: Normal
Status: Closed

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.