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

[Miscellaneous #WUU-316291]: naverror.grb2 file size

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: [Miscellaneous #WUU-316291]: naverror.grb2 file size
  • Date: Tue, 29 May 2018 06:53:45 -0600
Hi Tim,

re: what package is creating naverror.grb2?

> Not exactly sure, but one of the few items listed in a Google search on the 
> name was:
> https://www.unidata.ucar.edu/support/help/MailArschives/mcidas/msg04174.html
> Could be dmbin or dmgrid, but not sure.

OK.  Interestingly, I was the author of the URL that you found via your
Google search... I didn't remember the exchange at all!

Since I was the author, it must be that naverror.grb2 is created by a
McIDAS process.  Based on this, I would say that deleting the file will
be OK, BUT (important BUT), you may need to stop and restart your XCD
processing as some process may be holding the file open.  I would sandwich
the file deletion in the middle of a stop and restart:

stop XCD
delete the file
start XCD

In Unidata McIDAS-X/-XCD this would be accomplished by:

<as 'ldm'>
ldmadmin stop
-- delete the file
ldmadmin start

I am not sure what the exact procedure is if you are running 
SSEC's XCD distribution.

re:
> We did finally try removing it before your reply, and it seems to do no 
> damage.

Now that I know that a McIDAS XCD process creates/updates the file, I
can say that deleting the file should be OK.  The only thing I can
not say for certain is if the file is held open, or if the file is
closed after each write to it.  If it is, deleting the file should
have no deleterious effect.  If the file is still open, it will look
like it is gone after an 'rm', but the disk space will still be
used.

re:
> We have a duplicate system that still has it. So it would be nice to
> be able to read it before I zap that one too. If you know of how to
> read it, that would be great, otherwise I think we have everything we need.

Given the suffix, I would assume that it is a GRIB2 file.  I'd run 'od'
on it first to make sure.  If it is a GRIB2 file, you'd need to use a
GRIB2 reader to dump its contents.

re:
> Thanks!

No worries.

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: WUU-316291
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.