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

20011025: remap2.pgm with mcidas version 7.7 and 7.8



>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>&nbsp;&nbsp;&nbsp;<FONT color=#0000ff>&nbsp; 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>&nbsp;</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]&nbsp; 
Yes.&nbsp;</FONT></SPAN></DIV></DIV>
<BLOCKQUOTE>
  <BLOCKQUOTE TYPE="CITE">
    <P><B><FONT color=#003300>dave</FONT></B> <BR><FONT 
    color=#003300></FONT>&nbsp; <BR><FONT color=#0000ff></FONT>&nbsp;<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>&nbsp;</DIV>
      <P><BR><TT>OK.....</TT> 
      <P><TT>The following routine writx, writes the band map into the 
      buffer.</TT> 
      <P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      IMPLICIT INTEGER (A-Z)</TT> <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      INTEGER*4 BUF(*), bndord(*)</TT> <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      INTEGER*4 datbuf(10000)</TT> <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      END=LINE+NLINS-1</TT> <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; call pack(nbands, bndord, 
      datbuf)</TT> <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; doff = nbands + (4 - 
      mod(nbands,4))</TT> <BR>&nbsp; 
      <P><TT>You should check the value of nbytbk, nbands and values in 
      bndord.</TT> <BR>&nbsp; 
      <P><TT>dave</TT> <BR>&nbsp; 
      <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?&nbsp;<SPAN class=424150715-24102001><FONT 
        color=#0000ff>[Craddock, Mary Ellen]&nbsp; 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.&nbsp;</FONT></SPAN> 
        <BLOCKQUOTE><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IF(NBANDS .le. 0) 
          THEN</TT> <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          istat = m0bandmap(srcdir, maxbnd, nbands, bndord)</TT> 
          <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ELSE</TT> 
          <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DO 100 
          NN=1,NBANDS</TT> 
          <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; istat 
= 
          mccmdint('BAN.D', nn, ' ', nn, 1, MAXBND, bndord(nn))</TT> 
          <BR><TT>&nbsp;100&nbsp;&nbsp;&nbsp;&nbsp; CONTINUE</TT> 
          <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ENDIF</TT> <BR>&nbsp; 
          <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>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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.&nbsp; 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?&nbsp;&nbsp; You 
            mentioned that you didn't think the problem was <BR>caused by any 
            low-level mcidas routines.&nbsp; Tom, can you comment on how this 
            <BR>might or might not be different in Unidata's version?&nbsp; 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>&gt; Dave, 
            <P>&gt;&nbsp; I recompiled <BR>&gt; remap2.pgm with mcidas7.7 and 
            mcidas7.8. In both cases, remap2.k runs and <BR>&gt; creates the 
            correct file size but when viewing the imagery (all bands) all 
            <BR>&gt; 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>&gt; So, it now looks like the problem originates when upgrading 
            <BR>&gt; from v7.6 to v7.7.&nbsp; On a side note, I have a note 
that 
            we modified <BR>&gt; remap2.pgm when we upgraded to v7.6 per your 
            instruction to fix the county <BR>&gt; map navigation problem. 
            <P>Refresh my memory on what that change was. 
            <P>&gt; Can you compile remap2.pgm and run successfully <BR>&gt; 
            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>&gt; <BR>&gt; <BR>&gt; Thanks for any help you can provide. 
            <BR>&gt; <BR>&gt; Mary Ellen <BR>&gt; <BR>&gt; Mary Ellen Craddock 
            <BR>&gt; Meteorologist <BR>&gt; Northrop Grumman Information 
            Technology, TASC <BR>&gt; 4801 Stonecroft Boulevard <BR>&gt; 
            Chantilly, VA 20151 <BR>&gt; (703) 633-8300 x4022 <BR>&gt; 
            address@hidden 
            <P>&nbsp; 
            
------------------------------------------------------------------------ 

            <P>&nbsp;&nbsp; ADUMP.TXTName: ADUMP.TXT 
            
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
            Type: Plain Text (text/plain) 
            <P>&nbsp;&nbsp; NAV.TXTName: NAV.TXT 
            <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Type: 
            Plain Text 
      
(text/plain)</P></BLOCKQUOTE><BR>&nbsp;</BLOCKQUOTE></BLOCKQUOTE><BR>&nbsp; 
      <BR>&nbsp;</BLOCKQUOTE></BLOCKQUOTE><BR>&nbsp; <BR>&nbsp; 
</BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C16158.ACEF3A20--


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.