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

20000428: update on 17 April McIDAS bugfix and AVN 12Z run (cont.)

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: 20000428: update on 17 April McIDAS bugfix and AVN 12Z run (cont.)
  • Date: Fri, 28 Apr 2000 02:33:33 -0600
>From: weather <address@hidden>
>Organization: NMSU/NSBF
>Keywords: 199909242206.QAA23500 McIDAS-XCD DMGRID AVN grid missing

Robert,

>I think my RTMODELS.CFG was wiped out.

Right.  I need to revisit and most likely change the XCD install
portion of the McIDAS-X makefile so that site configured files do not
get overwritten unless explicitly desired.

>BTW does this mean that my
>two machines are "slow", the fact that HRS.SPL had to be increased
>in size.

I am not convinced that your machines actually needed a 32 MB grid
spool file.  Since I have no way of telling if a system would need a
really large spool file, I have to try and come up with a value for the
spool that will work for all systems.  A fast system that is doing a
lot of processing when the bulk of the model data streams in over the
IDD will need a large spool just like a really slow system.

The problem on your systems was most likely related to the buffer size
in the DMGRID support routines that was addressed in the addendum.  If
you feel like experimenting AFTER determining that the grid decoding is
now working correctly, you might want to try returning to use of a 16
MB spool file.  If you decide to play with this, you have to:

stop the LDM
delete HRS.SPL
delete GRIBDEC.PRO
edit GRIBDEC.CFG and change SPOOLENG from 32 back to 16
restart the LDM

>By current standards they are slow I guess, single processors
>and only ~400Mhz.

These are not what I would consider to be slow at all.  I have several
sites that are running original Sun SPARC 20 class machines, and they
_are_ slow especially given what the people are trying to do with
them.

>We are in a tight money period, so I would
>imagine no upgrades for the next 2 years or so (unless we can get a 
>nice electrical fire going..only kidding).  

I would not worry about needing to replace these machines just yet.
When we get our Java applications out, however, this will have to be
revisited.  By that time, however, dual 1 Ghz processor machines will
be common.

>Thanks for finding the problem.

I am writing this reply as the 0Z AVN grids are rolling in.  So far,
psnldm appears to be decoding everything, but I'll know more in the
morning.

Later...

Tom