20000929: GRDIMAGE continued

>From: Bill Fingerhut <address@hidden>
>Organization: Lyndon State
>Keywords: 200009251326.e8PDQ1b04272 McIDAS-X GRDIMAGE

Bill,

Well, I finally have the AMS paper out of my hair, so I can get back
to your problem.  Sorry to have taken so long.

>Thanks for explaining when to expect a response to my inquiry.
>It really does help to know such things.

OK.  We try to do this when we know that we won't be able to get to
a question in a "reasonable" amount of time.

>I've been trying to work around the problem with GRDIMAGE,
>and may have a second problem, or another manifestation of
>the first problem. Either way, I thought it best to back up
>and better explain what I am trying to do.

OK.  By the way, the very quick attempts aimed at recreating your
problem last week were unsuccessful for me.  I did not have a data
set where the GRID file elements (grids, that is) were different
from one another.

It may turn out to be useful for me to get on your system and test
things out in your environment.  We can chat about this later.

>Overview - we are running a BATCH file from the cron, on the 
>server, as user LDM. It creates a grid, then an image 
>representation of the grid, and archives the AREA file. 

OK.  What is the original data parameter?

>It was working fine. Then I decided to update from GRDIMG to 
>GRDIMAGE. The old and new commands are:
>
>GRDIMG 5 3005 5 5 GRIDF=2004 RANGE=0 255
>GRDIMAGE MYDATA/GRIDS.4 MYDATA/MIMGS.5 RANGE=0 255 0 255 GRID=5 MAG=5 5

OK.

>Then I noticed that the brightness values in the area file
>were wrong - the values are too big by a constant factor
>close to 2. This was determined by displaying the image,
>running the cursor over the image and observing brightness
>values listed near the bottom of the window.

How do the contours of the grid match up with the image?  Also, are you
sure that the range of data values in the grid vary from 0 to 255?  This
seems like a brightness value more than a grid value.

>I attempted to debug the BATCH file on a workstation as the
>user fingerhutb. This is where I encountered the problem 
>reported previously - GRDIMAGE appears to use position 1
>for input rather than position 4 as specified in the command.

Right.  This is the thing that I was unable to reproduce.

>Next, I thought I would just work around the problem. I
>changed the BATCH file to copy the desired grid from position
>4 to position 1 then input the grid to GRDIMAGE. I tested this
>on my workstation as fingerhutb. Of course it worked. However,
>when the BATCH file runs on the server as LDM, the brightness 
>values are wrong by the same constant factor. This suggests,
>but does not prove a difference between either users or
>machines?

Is the version of GRDIMAGE the same on the workstation and server?
GRDIMAGE was one of the modules updated in an Addendum.  It might
be possible that you are running one version on the workstation
and the other on the server.  The truth of this would be a 'diff'
between the copies of grdimage.pgm on both systems.

>Next, I started McIDAS on the server as fingerhutb; and 
>tested the GRIDIMAGE command. The values were too large
>by the constant factor. So, user fingerhutb gets different
>results on each of the 2 machines. And both fingerhutb and
>LDM get wrong results on the server.

By LDM, I assume that you mean by the PostProcess BATCH file that
runs from the LDM.

>BTW, I have checked the values in the grid using GRDINFO,
>and I have copied the grid file from one directory to another
>to insure that I was using the same data each time. I am
>reasonable sure the grid point values are right and that
>the same data is used in each test.
>
>Next, I changed the BATCH file to use GRDIMG as before. Since,
>the script has run twice and the results on the server are 
>right. So, I am getting what I need, but I "can't" update to 
>the new command GRDIMAGE.
>
>I think that's all the info. I hope you can figure this out !

OK, it really does sound like the versions of GRDIMAGE are different
on your workstation and server.  What I did not catch from you is
whether either copy produces valid output?

Let me know if I can login as you and snoop around.

Tom