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

[IDD #OMZ-874415]: GOESR ldm feed

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: [IDD #OMZ-874415]: GOESR ldm feed
  • Date: Thu, 27 Sep 2018 08:50:36 -0600
Hi Carol,

After reflecting on the ldmd write failure because of no unlocked
regions in the 500M LDM queue on typhoon, AND, more importantly,
reviewing the sizes of the various ABI products from the GOES-16
GRB, I am now of the opinion that the problem was that typhoon's queue
was simply too small, and the solution was increasing the queue
size to 8G, not deletion of a corrupt queue.

Why have I changed my mind?  A quick review of the sizes of 
GOES-16 ABI products shows that the each Channel 2 Full Disk image
is nearly large enough to fill a 500M queue all by itself.  Here,
for instance is a listing of the sizes of current Channel 2 products
from the TDS server thredds-test.unidata.ucar.edu:

  GRB16/ABI/FullDisk/Channel02/current/          --
           
OR_ABI-L1b-RadF-M3C02_G16_s20182681430348_e20182681441115_c20182681441146.nc  
424.2 Mbytes   2018-09-25T14:41:52Z
           
OR_ABI-L1b-RadF-M3C02_G16_s20182681445348_e20182681456115_c20182681456147.nc  
429.6 Mbytes   2018-09-25T14:56:51Z
           
OR_ABI-L1b-RadF-M3C02_G16_s20182681500348_e20182681511115_c20182681511149.nc  
434.2 Mbytes   2018-09-25T15:11:49Z
 ...

If 1 Channel 2 Full Disk product is in the queue and not fully processed by
an active pattern-action file action, and another large product (e.g.,
any other Full Disk image for another channel) is received, there would
not have been enough room in the queue for the new product, and the
existing product could still be locked while the action was running.
The "interesting" thing about this is that the timing to have a
situation like this would have had to been very tight, but that
would explain why the problem was not experienced for several days
while running with the 500M queue.

I hope that the above make sense!

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: OMZ-874415
Department: Support IDD
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.