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

[McIDAS #TYJ-792885]: Not Filing NEXRAD Data



Hi Martha,

re:
> Yesterday I upgraded our system that is used to decode NOAAPORT data
> to Centos 5.5.  This upgrade was performed because we were seeing frame
> packets dropped and LDM was failing which was presumably caused by the
> older LINUX kernel we were running (we ran successfully with that kernel
> for several weeks with the new NOAAPORT receiver, but all of a sudden
> the LDM system started having the packet dropping problem).

Since you ran with the old kernel successfully for several weeks, I would think
that the problem you were seeing was due to something other than a need for an
OS upgrade.  For instance, perhaps the kernel tuning parameter was edited out
of the configuration file?

re:
> After the install was complete and the kernel tuning parameter for
> ip_frag_max was altered, I rebuilt LDM (version 6.9.8) and McIDAS 2009.

You don't mention rebuilding the NOAAPort ingest package.  It is our 
recommendation
that the NOAAPort package be rebuilt/reinstalled after the installation or 
rebuild
of the LDM.  This is the first thing I would do before spending a lot of time on
other troubleshooting:

- stop the LDM

- rebuild and then reinstall the NOAAPort package

  NB: there should be no need to download the package again.  Simply do a
  'make distclean' in the noaaport-1.x.x.x directory followed by running
  'configure', 'make' and then 'make install'.

- after the NOAAPort package has been successfully rebuilt, restart the
  LDM

Also, you should check to make sure that the OS upgrade did not wipe out
an IPTABLES configuration that explicitly allowed all traffic from the
Ethernet interface that the Novra S300 is plugged into.  I assume that
it did not given that you say that you are once again decoding IDS|DDPLUS
data into McIDAS MDXXnnnn files.

Also, you should make sure that SELINUX is disabled so that your LDM logging
will work correctly.

re:
> After restarting LDM, and after a few bumps along the way, we are now
> successfully getting MDXX data, and our data from the CONDUIT are coming
> in and being filed.
> 
> However, the NEXRAD data are not being filed.  The indicators on the XCD
> statdisp show no problems for NEXRAD, but we are collecting nothing of
> type NEXRAD.

Are you using McIDAS-XCD to process NEXRAD3 data?  Most sites FILE the
NEXRAD3 products directly from actions in an LDM pattern-action file
(e.g., pqact.conf).  If you are doing this, then statdisp will not
show anything related to NEXRAD Level III processing.

re:
> I am attaching a screen capture of the statdisp screen,
> and a tar file containing the *.conf files from /usr/local/ldm/etc.

'statdisp' output would be a red herring _if_ you are filing the NEXRAD3
products from an LDM pattern-action file.

re:
> None of the ldm conf files were changed; these are the versions we were
> running with successfully before the OS upgrade.
> 
> I kept the file system where we are writing the NOAAPORT data intact,
> and all permissions seem to be correct.

OK.

re:
> Any advise you can offer will be much appreciated.

<after looking at the pqact.conf files you sent>

OK, I see that you _are_ relying on McIDAS-XCD to handle your NEXRAD3
products...

Here are some additional things to check:

- check to make sure that the XCD data monitor for NEXRAD products
  is active:

  <as 'mcidas'>
  cd $MCDATA
  decinfo.k LIST

  If DMNEXR is not active, activate it.


- check to see that your LDM is receiving/seeing the NEXRAD3 products:

  <as 'ldm'>
  ldmadmin watch -f NEXRAD3

  If you are seeing NEXRAD3 products being inserted into your LDM queue,
  there is some configuration problem on the McIDAS-XCD side.  If you
  are not seeing NEXRAD3 products being inserted into your LDM queue,
  you have a problem on the NOAAPort ingest side.



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: TYJ-792885
Department: Support McIDAS
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.