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

20001220: number of times in file in nmap2

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: 20001220: number of times in file in nmap2
  • Date: Wed, 20 Dec 2000 10:10:03 -0700
John,

I encountered similar problems when placing all the radar coded message
grids (HAXA00 KWBC) in a single daily file.

The problem was the length of the string that is used to return all the times
in a file. In the 5.6.A release I made yesterday:
$GEMPAK/source/programs/gui/nmap2/nmap_dslw.c,
you will find in: void dslw_layerSet(layer)

 * Chiz/Unidata         12/00   Increased gdclst size 1024->4096        *

You can see if this value is large enough, or you need to increase it some more.

Steve Chiswell
Unidata User Support


On Wed, 20 Dec 2000, john horel wrote:

> Folks-
> 
> I'm trying to get NMAP2 to handle input grid files that have many times in
> the same daily file, i.e., we have gridded analyses every 15 minutes (192
> total times, as we compute 3-h pressure differences every 15 minutes).
> NMAP2 core dumps at the point when it is figuring out the number of times
> available to select from. I've bumped up the only obvious parameter to me,
> MAX_PIXMAP=88 in xwprm.h). Has anyone resolved this problem for similar
> nmap2 applications? For example, we run into the same type of  problem when
> we have too many days of eta grid files in the appropriate directory- in
> that case, the work-around is to scrub the older files and keep nmap2 happy.
> 
> Thanks
> 
> John
>