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

[McIDAS #FKB-492129]: noaapxcd point data

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: [McIDAS #FKB-492129]: noaapxcd point data
  • Date: Wed, 19 Dec 2007 14:59:25 -0700
Hi Randy,

re:
> I am not sure if me changing mcscour.sh to keep 10 days of data is related to 
> the
> problems Martha is referring to in her other ticket (related to upgrading to
> ldm 6.6.5 and dvb reader 1.3.0
> 
> i incorretly set
> 
> doqtl.k   1  90 9
> 
> to 10 instead of 9. Therefore it deleted all the files last night.

Hmm...  changing the 9 to a 10 tells DOQTL (doqtl.k) to _keep_ 10 files, not
delete them.

By the way trying to keep 10 realtime MD files online is a bad idea for the
following reason:

- the McIDAS-XCD POINT decoders (SAODEC, RABDEC, etc) write current data
  to the output file whose last digit (e.g., '8' in MDXX0008 for surface
  files; '8' in MDXX0018 for mandatory level upper air files; etc.) matches
  the last digit of the current Julian day (using 'Nx10' for days where the last
  digit is a '0' -- MDXX0010 for surface files, MDXX0020 for mandatory level
  upper air MD files, etc.).

  If the file that is to be written to exists from 10 days previous, the new
  data will be written to the _end_ of the MD file.  Since MD files have a 
finite
  size (defined by their schema), at some point the decoder will stop writing
  new data to the file because the file will be full.

  Also, when the McIDAS POINT server tries to read data from the MD file, the 
first
  data it will find will be 10 days old and, so, will not match the DAY of the 
data
  requested unless the user explicitly specified the DAY value on the command 
being
  run (e.g., 'SFCPLOT param map time DAY', etc.)

  Because of this, one should always scour (or rename) MD files before they
  get to be 10 days old.  The other consequence is that one always has to
  specify the DAY value for data in non-realtime MD files.

> I will delete all the current MD files and let it repopulate.

OK.  Please keep me apprised of your situation.

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: FKB-492129
Department: Support McIDAS
Priority: Normal
Status: Closed