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

19990712: Unidata/Wisc upgrade finished (cont.)

>From: Chad Johnson <address@hidden>
>Organization: SSEC
>Keywords: 199907121618.KAA19637 unidata IDD

Chad,

re: problems in the upgrade
>The floater McBASI script was modified to correctly deal with the
>DATE$. I don't remember the details, but I think it had something to do
>with the date string not getting correctly converted back to a value.

Sounds easy enough.

>The other problem was a bug in scana.pgm. This is a program that we use
>to create a QC display. There was an array overrun that didn't surface
>until I compiled it under f2c and gcc.

I ran into a very strange problem in dcolin.for (called by lwtoa3) that
only surfaced when compiled with gcc/f2c.  This does not affect you
guys at all since you no longer use lwtoa3 for anything.  Images
unravelled from the datastream would have streaks in them (horizontal
lines of varying lengths) and the space part of VIS images would be
speckled.  I had to redo the dcolin.for code that called crackb a
second time.  I never did understand exactly what was happening, and I
was not real interested in finding out since the change I made actually
improved performance.

re: two images of same kind back-to-back
>This was because during this testing period I am generating the
>products on both gold and unidata. The LDM on unidata was configured to
>receive products from gold, so unidata was receiving it's own products
>plus the products generated on gold. This has been corrected.

I just checked and see that things appear to be working very smoothly
now.  So, it looks like it is time to let your downstream sites know
that they should switch back to unidata from gold.  Nice work!

re: let's keep sticking the non-image products out in the archive
>Shouldn't be a problem. I have the BROADCAST=YES|NO keyword on the jobs
>that produce this products. I've added BROADCAST=NO to the invocations
>of these jobs.  The products should be created and archived, but not
>sent out the broadcast.

OK, thanks.  I will probably want to discontinue this by mid-August.

re: displaying NIDS images
>I haven't played with this too much yet. Currently we have two commands
>NIDSDISP and NIDSLIST which perform NIDS listing and displaying. I was
>thinking of simply making the necessary modifications to these apps to
>add the ID= sort clause to the server request. This may or may not work
>- I'll let you know.

Hmm...  My slant on this is that it seems like a waste to have to write
completely different list/display routines for 'image' dataset data.
Does this mean that someone will need to develop a NOWRDISP to look
at the "squished" Lambert Conformal NOWrad (tm) imagery (bad idea!)?

I realize that SSEC doesn't really like modifying core routines, but I
think that simply adding more new routines is the wrong way to go
(McIDAS is way too big already).  A perfect case in point for this is
the new ERASE command.  ERASE simply calls EG consecutively to erase
both image and graphics.  Our solution to the EG problem  was to press
back into service the old 'B' option on EG:

EG   - erase graphics
EG I - erase image
EG B - erase both graphics and image

Is the idea to eventually suck the EG code into ERASE, or will ERASE
always be a 'macro' command?

I know that these sorts of things are not your decision, but...

On another note, sometime soon I will be working on a new ADDE server
that will be able to handle:

o McIDAS imagery in files that do not follow the AREA naming convention
  (perhaps even allow compressed formats (.Z and .gz?))

o GINI imagery from NOAAPORT

o TeraScan (tm) imagery (will probably wait for some work from you guys
  since Dave S. said that there is to be some work done there on
  conversion of TeraScan (tdf) imagery to AREA)

Thanks for all the good work!

Tom