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

[CONDUIT #OZC-764376]: pqact.gempak_decoders_conduit

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: [CONDUIT #OZC-764376]: pqact.gempak_decoders_conduit
  • Date: Fri, 30 Oct 2009 13:20:33 -0600
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.

re:
> 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.

Question:

- 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
http://blog.taragana.com/index.php/archive/how-to-disable-ipv6-on-fedora-linux-why/

Basically, the changes were:

/etc/modprobe.conf:

alias net-pf-10 off
alias ipv6 off

/etc/sysconfig/network:

NETWORKING=yes
NETWORKING_IPV6=no

/etc/sysconfig/network-scripts/ifcfg-<interface>

IPV6INIT=no

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
results.

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