[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20011025: remap2.pgm with mcidas version 7.7 and 7.8
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: 20011025: remap2.pgm with mcidas version 7.7 and 7.8
- Date: Thu, 25 Oct 2001 18:44:39 -0600
>From: "Craddock, Mary Ellen" <address@hidden>
>Organization: TASC
>Keywords: 200110221732.f9MHW7119481 McIDAS-X 7.8
Mary Ellen,
>Our sys admin installed SSEC McIDAS7.8 on our IBM machine and I
>successfully compiled and ran our old version of remap2.pgm as well as the
>version with the code modifications you have suggested this week. Both yield
>the same result as confirmed by image comparisons as well as ADUMP output.
>So, it looks like there might be an issue when we compile with Unidata
>McIDAS somehow. Any suggestions?
I was under the impression that the remap2 code worked on other machines
at TASC failing only on OSF/1. Am I wrong in this?
For curiosity sake, what happens when you remap2 a single banded image
on your OSF/1 platform?
Can you send detailed output from the compile and link on your OSF/1
machine of remap2.f? This might give us some clues as to what may be
happening.
Just for my sanity sake, I did a diff between the sources of the
original routines you named in your first email in my distribution and
the ones in the SSEC distribution:
> extern void readd_*
> extern void araopt_ *
> extern void redara_ *
> extern void clsara_
> extern int nvset_
> extern int nv1sae_
> extern int opnara_ *
The diffs showed that the sources are identical.
...
I just downloaded remap2.f from the XRD repository at SSEC and compiled
and linked it on a Linux box using g77. A warning I got about the next
to the last parameter in the WRITX call at line 757 and the WRITX
subroutine looks pretty suspicious especially on OSF/1.
The warning reads:
remap2.f:757: warning:
CALL WRITX
1
remap2.f:1265: (continued):
SUBROUTINE WRITX(IA,LINE,NLINS,NBYTEL,NBANDS,NELE,BUF,bndord)
2
Argument #7 (named `buf') of `writx' is one type at (2) but is some other type
at (1) [info -f g77 M GLOBALS]
The WRITX call at line 757 is:
CALL WRITX
& (DAN,DLOC,MIN0(DLB,DNL-DLOC+1),NBYTEL,NBANDS,DNE,DEST,BNDORD)
Tracing the declaration of 'DEST' (argument #7) back to its origin shows
it to be dimensioned as:
LOGICAL*1 READ,SOURCE,DEST
...
COMMON/DCOM/DEST(BFWD)
(By the way, putting DEST into a common block seems to have no purpose).
The dimensioning in subroutine WRITX for argument #7 reads as:
SUBROUTINE WRITX(IA,LINE,NLINS,NBYTEL,NBANDS,NELE,BUF,bndord)
IMPLICIT INTEGER (A-Z)
INTEGER*4 BUF(*), bndord(*)
(BUF is argument #7)
So, in one place the argument is a LOGICAL*1 and in the other it is
an INTEGER*4.
I am highly suspicious that there may be a discrepency in the word
length for this array on the calling and function sides. This is
the exact kind of thing that surfaces when going from platforms
where the word length for LOGICALs is 4-bytes (e.g., Solaris, Linux,
AIX, etc.) to platforms where word lengths for LOGICALs is 8-bytes
(I _think_ that this includes OSF/1).
My first inclination is to change the dimensioning of BUF in SUBROUTINE
WRITX to be LOGICAL*1. This will make it match the dimensioning in
SUBROUTINE DOMAP and SUBROUTINE READX. However, this may not work
given the use of argument #7 in SUBROUTINE WRITX:
call movc(nbytbk, buf, j, datbuf, doff)
The MOVC routine is treating bytes in consecutive words of 'buf' as a
character array and is moving them into consecutive byte locations
of the destination buffer, 'datbuf'. There is an explicit statement
in the WRITX code that the word length of 'buf' and 'datbuf' are the
same:
INTEGER*4 BUF(*), bndord(*)
INTEGER*4 datbuf(10000)
This will break when the word length in the call to WRITX does not match
the assumption. Again, I _think_ that the word length for LOGICALs
on OSF/1 is 8-bytes.
If I am correct in the above, remap2 needs some significant modifications
to work correctly on OSF/1 and any other machine where default word
lengths do not match the age old 4-byte "rule".
Tom
>From address@hidden Tue Oct 30 08:39:39 2001
>Subject: RE: remap2.pgm with mcidas version 7.7 and 7.8
Dave,
Thanks for the email. In answer to your question.....
Is this Unidata McIDAS only on the DEC?
[Craddock, Mary Ellen] Yes.
dave
Thanks,Mary Ellen
-----Original Message-----
From: Dave Santek [ mailto:address@hidden
<mailto:address@hidden> ]
Sent: Thursday, October 25, 2001 8:55 AM
To: Craddock, Mary Ellen
Cc: 'address@hidden'; 'address@hidden'
Subject: Re: remap2.pgm with mcidas version 7.7 and 7.8 RESEND WITH
ATTACHMENTS
OK.....
The following routine writx, writes the band map into the buffer.
SUBROUTINE WRITX(IA,LINE,NLINS,NBYTEL,NBANDS,NELE,BUF,bndord)
C *** McIDAS Revision History ***
C 1 WRITX.FOR 19-Mar-90,21:36:50,`SSEC' PC-McIDAS ver 5.00
C 2 WRITX.FOR 25-Sep-90,7:34:04,`SMG' First Release into COMmon
C *** McIDAS Revision History ***
IMPLICIT INTEGER (A-Z)
INTEGER*4 BUF(*), bndord(*)
INTEGER*4 datbuf(10000)
END=LINE+NLINS-1
NBYTBK = NBYTEL * NBANDS * NELE
c
c--- insert the level section according to bndord
c
call pack(nbands, bndord, datbuf)
doff = nbands + (4 - mod(nbands,4))
You should check the value of nbytbk, nbands and values in bndord.
dave
"Craddock, Mary Ellen" wrote:
Dave,Do you have this code in DOMAP? [Craddock, Mary Ellen] No. This code
is not in the DOMAP subroutine per say, but in another code segment. I have
attached what we do have for comparison in the file domap.txt.
IF(NBANDS .le. 0) THEN
istat = m0bandmap(srcdir, maxbnd, nbands, bndord)
ELSE
DO 100 NN=1,NBANDS
istat = mccmdint('BAN.D', nn, ' ', nn, 1, MAXBND, bndord(nn))
100 CONTINUE
ENDIF
dave
We did not have the filter map code in its entirety. I added the lines and
reran remap2.pgm which ran successfully. The size of the resulting AREA file
decreased by 896 bytes and when I tried to view it in McIDAS, I got the
ERROR message "unable to allocate memory". I was able to run ADUMP on the
AREA file which looked similar to the file I sent you yesterday,
specifically the level section does not list all the bands but rather just
zeros.
"Craddock, Mary Ellen" wrote:
Dave,
The NAV module in remap2.pgm was modified to work with v7.6. I have
attached a file, nav.txt, which shows the NAV module before and after the
change. I also ran ADUMP on the resulting AREA file which you suggested and
attached is the file, adump.txt, which shows the output. I don't see any
clues here, do you? You mentioned that you didn't think the problem was
caused by any low-level mcidas routines. Tom, can you comment on how this
might or might not be different in Unidata's version? The only other
thought I have is that we call the c program, cloudp.c from remap2.pgm,
which scales the band data and calculates the fog and reflectivity products
which replace channel 3. Again, any help here would be great.
Thanks,
Mary Ellen
-----Original Message-----
From: Dave Santek [ mailto:address@hidden
<mailto:address@hidden> ]
Sent: Tuesday, October 23, 2001 11:04 AM
To: Craddock, Mary Ellen
Cc: 'address@hidden'; 'address@hidden';
'address@hidden'
Subject: Re: remap2.pgm with mcidas version 7.7 and 7.8
Hi Mary Ellen,
"Craddock, Mary Ellen" wrote:
> Dave,
> I recompiled
> remap2.pgm with mcidas7.7 and mcidas7.8. In both cases, remap2.k runs and
> creates the correct file size but when viewing the imagery (all bands) all
> values are 0.
Try using ADUMP to list out the data file. A number of things can go wrong
that will result in zeros on the screen.
> So, it now looks like the problem originates when upgrading
> from v7.6 to v7.7. On a side note, I have a note that we modified
> remap2.pgm when we upgraded to v7.6 per your instruction to fix the county
> map navigation problem.
Refresh my memory on what that change was.
> Can you compile remap2.pgm and run successfully
> with v7.7 and v7.8?
I can run the XRD version of remap2 just fine on v7.8, so I don't think it's
related to any low-level routine.
dave
>
>
> Thanks for any help you can provide.
>
> Mary Ellen
>
> Mary Ellen Craddock
> Meteorologist
> Northrop Grumman Information Technology, TASC
> 4801 Stonecroft Boulevard
> Chantilly, VA 20151
> (703) 633-8300 x4022
> address@hidden
------------------------------------------------------------------------
ADUMP.TXTName: ADUMP.TXT
Type: Plain Text (text/plain)
NAV.TXTName: NAV.TXT
Type: Plain Text (text/plain)
------_=_NextPart_001_01C16158.ACEF3A20
Content-Type: text/html;
charset="iso-8859-1"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4807.2300" name=GENERATOR></HEAD>
<BODY>
<DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT color=#003300><SPAN
class=322382215-30102001><FONT color=#0000ff>Dave,</FONT></SPAN></FONT></DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT color=#003300><SPAN
class=322382215-30102001> <FONT color=#0000ff> Thanks
for
the email. In answer to your question.....</FONT></SPAN></FONT></DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT color=#003300><SPAN
class=322382215-30102001> </SPAN><STRONG>Is this Unidata McIDAS only on
the
DEC?</STRONG></FONT><FONT color=#003300></FONT> <BR><SPAN
class=322382215-30102001><FONT color=#0000ff>[Craddock, Mary Ellen]
Yes. </FONT></SPAN></DIV></DIV>
<BLOCKQUOTE>
<BLOCKQUOTE TYPE="CITE">
<P><B><FONT color=#003300>dave</FONT></B> <BR><FONT
color=#003300></FONT> <BR><FONT color=#0000ff></FONT> <SPAN
class=226064218-25102001></SPAN><SPAN class=226064218-25102001><FONT
color=#0000ff>Thanks,</FONT></SPAN><SPAN class=226064218-25102001><FONT
color=#0000ff>Mary Ellen</FONT></SPAN>
<BLOCKQUOTE>
<DIV class=OutlookMessageHeader dir=ltr><FONT face=Tahoma><FONT
size=-1>-----Original Message-----</FONT></FONT> <BR><FONT
face=Tahoma><FONT size=-1><B>From:</B> Dave Santek [<A
href="mailto:address@hidden";>mailto:address@hidden</A>]</FONT></FONT>
<BR><FONT face=Tahoma><FONT size=-1><B>Sent:</B> Thursday, October 25,
2001 8:55 AM</FONT></FONT> <BR><FONT face=Tahoma><FONT size=-1><B>To:</B>
Craddock, Mary Ellen</FONT></FONT> <BR><FONT face=Tahoma><FONT
size=-1><B>Cc:</B> 'address@hidden';
'address@hidden'</FONT></FONT> <BR><FONT face=Tahoma><FONT
size=-1><B>Subject:</B> Re: remap2.pgm with mcidas version 7.7 and 7.8
RESEND WITH ATTACHMENTS</FONT></FONT> <BR> </DIV>
<P><BR><TT>OK.....</TT>
<P><TT>The following routine writx, writes the band map into the
buffer.</TT>
<P><TT> SUBROUTINE
WRITX(IA,LINE,NLINS,NBYTEL,NBANDS,NELE,BUF,bndord)</TT> <BR><TT>C ***
McIDAS Revision History ***</TT> <BR><TT>C 1 WRITX.FOR
19-Mar-90,21:36:50,`SSEC' PC-McIDAS ver 5.00</TT> <BR><TT>C 2 WRITX.FOR
25-Sep-90,7:34:04,`SMG' First Release into COMmon</TT> <BR><TT>C ***
McIDAS Revision History ***</TT> <BR><TT>
IMPLICIT INTEGER (A-Z)</TT> <BR><TT>
INTEGER*4 BUF(*), bndord(*)</TT> <BR><TT>
INTEGER*4 datbuf(10000)</TT> <BR><TT>
END=LINE+NLINS-1</TT> <BR><TT> NBYTBK =
NBYTEL * NBANDS * NELE</TT> <BR><TT>c</TT> <BR><TT>c--- insert the level
section according to bndord</TT> <BR><TT>c</TT>
<BR><TT> call pack(nbands, bndord,
datbuf)</TT> <BR><TT> doff = nbands + (4 -
mod(nbands,4))</TT> <BR>
<P><TT>You should check the value of nbytbk, nbands and values in
bndord.</TT> <BR>
<P><TT>dave</TT> <BR>
<P>"Craddock, Mary Ellen" wrote:
<BLOCKQUOTE TYPE="CITE"><SPAN class=424150715-24102001><FONT
color=#0000ff>Dave,</SPAN><SPAN class=424150715-24102001></SPAN><SPAN
class=424150715-24102001></SPAN></FONT>Do you have this code in
DOMAP? <SPAN class=424150715-24102001><FONT
color=#0000ff>[Craddock, Mary Ellen] No. This code is not in the
DOMAP subroutine per say, but in another code segment. I have attached
what we do have for comparison in the file
domap.txt. </FONT></SPAN>
<BLOCKQUOTE><TT> IF(NBANDS .le. 0)
THEN</TT> <BR><TT>
istat = m0bandmap(srcdir, maxbnd, nbands, bndord)</TT>
<BR><TT> ELSE</TT>
<BR><TT> DO 100
NN=1,NBANDS</TT>
<BR><TT> istat
=
mccmdint('BAN.D', nn, ' ', nn, 1, MAXBND, bndord(nn))</TT>
<BR><TT> 100 CONTINUE</TT>
<BR><TT> ENDIF</TT> <BR>
<P><TT>dave</TT> <BR><SPAN class=424150715-24102001></SPAN>
<P><SPAN class=424150715-24102001><FONT color=#0000ff>We did not have
the filter map code in its entirety. I added the lines and reran
remap2.pgm which ran successfully. The size of the resulting AREA
file
decreased by 896 bytes and when I tried to view it in McIDAS, I got
the ERROR message "unable to allocate memory". I was able to run
ADUMP
on the AREA file which looked similar to the file I sent you
yesterday, specifically the level section does not list all the bands
but rather just zeros.</FONT></SPAN>
<P>"Craddock, Mary Ellen" wrote:
<BLOCKQUOTE TYPE="CITE">Dave,
<BR> The NAV module in
remap2.pgm was modified to work with v7.6. I have <BR>attached a
file, nav.txt, which shows the NAV module before and after the
<BR>change. I also ran ADUMP on the resulting AREA file which
you suggested and <BR>attached is the file, adump.txt, which shows
the output. I don't see any <BR>clues here, do you? You
mentioned that you didn't think the problem was <BR>caused by any
low-level mcidas routines. Tom, can you comment on how this
<BR>might or might not be different in Unidata's version? The
only other <BR>thought I have is that we call the c program,
cloudp.c from remap2.pgm, <BR>which scales the band data and
calculates the fog and reflectivity products <BR>which replace
channel 3. Again, any help here would be great.
<P>Thanks, <BR>Mary Ellen
<P>-----Original Message----- <BR>From: Dave Santek [<A
href="mailto:address@hidden";>mailto:address@hidden</A>]
<BR>Sent: Tuesday, October 23, 2001 11:04 AM <BR>To: Craddock, Mary
Ellen <BR>Cc: 'address@hidden';
'address@hidden'; <BR>'address@hidden'
<BR>Subject: Re: remap2.pgm with mcidas version 7.7 and 7.8
<P>Hi Mary Ellen,
<P>"Craddock, Mary Ellen" wrote:
<P>> Dave,
<P>> I recompiled <BR>> remap2.pgm with mcidas7.7 and
mcidas7.8. In both cases, remap2.k runs and <BR>> creates the
correct file size but when viewing the imagery (all bands) all
<BR>> values are 0.
<P>Try using ADUMP to list out the data file. A number of things
can
go wrong <BR>that will result in zeros on the screen.
<P>> So, it now looks like the problem originates when upgrading
<BR>> from v7.6 to v7.7. On a side note, I have a note
that
we modified <BR>> remap2.pgm when we upgraded to v7.6 per your
instruction to fix the county <BR>> map navigation problem.
<P>Refresh my memory on what that change was.
<P>> Can you compile remap2.pgm and run successfully <BR>>
with v7.7 and v7.8?
<P>I can run the XRD version of remap2 just fine on v7.8, so I
don't
think it's <BR>related to any low-level routine.
<P>dave
<P>> <BR>> <BR>> Thanks for any help you can provide.
<BR>> <BR>> Mary Ellen <BR>> <BR>> Mary Ellen Craddock
<BR>> Meteorologist <BR>> Northrop Grumman Information
Technology, TASC <BR>> 4801 Stonecroft Boulevard <BR>>
Chantilly, VA 20151 <BR>> (703) 633-8300 x4022 <BR>>
address@hidden
<P>
------------------------------------------------------------------------
<P> ADUMP.TXTName: ADUMP.TXT
<BR>
Type: Plain Text (text/plain)
<P> NAV.TXTName: NAV.TXT
<BR> Type:
Plain Text
(text/plain)</P></BLOCKQUOTE><BR> </BLOCKQUOTE></BLOCKQUOTE><BR>
<BR> </BLOCKQUOTE></BLOCKQUOTE><BR> <BR>
</BLOCKQUOTE></BODY></HTML>
------_=_NextPart_001_01C16158.ACEF3A20--
- Prev by Date: 20011025: GINI conversion to AREA (cont.)
- Next by Date: 20011025: GINI conversion to AREA (cont.)
- Previous by thread: 20011025: GINI conversion to AREA (cont.)
- Next by thread: 20011026: specific humidity grids FTPed from NCAR MassStore
- Index(es):