[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
20020207: remap2.pgm
- Subject: 20020207: remap2.pgm
- Date: Fri, 08 Feb 2002 07:56:46 -0700
>From: "Craddock, Mary Ellen" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200202071831.g17IV5x09142
Mary Ellen,
The questions you pose in this email:
>Questions:
>1. Which version of map filter code fragment is correct?
>
>2. What is it about that code fragment that would cause v7.7 to work and
> v7.804 to not work?
>
>3. Should we take the latest version of remap2.pgm (Version III) and
> interleave the TASC specific changes? Is this even possible or have
> their been enough changes to the code that the TASC specific changes
> would cause further errors?
really seem to be for SSEC.
As soon as you settle on which version of remap2.pgm you want to use, I
am willing to grab that copy and see exactly why it won't run on
OSF/1. My previous attempt at troubleshooting remap2.pgm was
relatively half-hearted since I was swamped at the time (a situation
that has not changed, but I am willing to free some time now).
It would make the most sense to do the initial troubleshooting _before_
you make any changes to the code. That way, assuming that I can get
the "pristing" copy to build and run correctly, any additional problems
would be isolated to the mods that you make.
So, once you settle on a particular version of remap2.pgm to use, let
me know (and provide me with a reasonably sized test image/images)
and I will see if I can figure out exactly what is happening on OSF/1.
The other thing to remind me of is exactly which compilers you are using
to build your executable. I can use either the vendor-supplied ones
from Compaq, or gcc/g77.
Finally, please remember that the only OSF/1 machine that I have access
to is a newer Compaq that is running Tru64 5.1. This may not make any
difference, but, then again, it may.
Tom
>I have included you both in this email as the problem I am describing
>is not 100% supported by either SSEC or Unidata but rather it is
>shared. The program in question (remap2.pgm) is supported only by SSEC
>and the machine I am running this program on (Compaq Tru Unix 4.0f) is
>supported only by Unidata.
>
>Thanks for any help you can provide!
>Mary Ellen
>
> <<remap_readme.txt>>
>
>Mary Ellen Craddock
>Meteorologist
>Northrop Grumman Information Technology, TASC
>4801 Stonecroft Boulevard
>Chantilly, VA 20151
>(703) 633-8300 x4022
>address@hidden
>
>
>------_=_NextPart_000_01C1B005.0F0BC840
>Content-Type: text/plain;
> name="remap_readme.txt"
>Content-Disposition: attachment;
> filename="remap_readme.txt"
>
>2/7/02 From Mary Ellen Craddock
>
>
>Here is some backgroud information...We now have 3 versions of
>remap2.pgm. Version I is the oldest version we own, the last
>modification being made in August 1999 to fix the county map navigation
>problem. Version II is the newest version we own, the last
>modification being made on an unknown date to modify the "map filter"
>section of the code. Version III is the latest SSEC version sent out
>in McIDAS XRD7.8. This version is VERY different from versions 1 and 2
>in many more areas than just the TASC specific modifications that were
>made at the beginning of this journey in 1998.
>
>Version I of remap2.pgm differs from Version II in only one place, the
>filter map section of the code shown below.
>
>Version I:
>
> 529 c
> 530 c--- set the bits for the filter map
> 531 c
> 532 do 150 jj=1,nbands
> 533 iband = bndord(jj)
> 534 ibit = ibset(ibit, iband-1)
> 535 150 continue
> 536 c
> 537 odir(19) = ibit
> 538 c
>
>Version II:
>NOTE: This code fragment is identical to Version III (mcxrd7.8 code)
>
> 537 c
> 538 c--- set the bits for the filter map
> 539 c
> 540 ibit = 0
> 541 ibit2 = 0
> 542
> 543 do 150 jj=1,nbands
> 544 iband = bndord(jj)
> 545 if (iband .le. 32) then
> 546 ibit = ibset(ibit, iband-1)
> 547 else
> 548 ibit2 = ibset(ibit2, iband-33)
> 549 endif
> 550 150 continue
> 551 c
> 552 odir(19) = ibit
> 553 odir(20) = ibit2
>
>
>We have online the latest verions and upgrades to both UMcidas7.7 and
>UMcidas7.8 (v7.804). Currently, V7.804 is built and installed but
>access to v7.7 is still possible by modifying paths in the compile
>scripts. (V7.804 was built using vendor compilers.) Oddly enough
>depending on the version of UMcIDAS we compile with, remap2.pgm does or
>does not work.
>
>Compiling with UMcIDAS7.7
> - Version I compiles successfully and the resulting imagery looks good.
> - Version II compiles successfully but when attempting to display the
> resulting imagery, the following error is received:
>
> "IMGDISP: Unable to allocate memory" is produced.
>
>Compiling with UMcIDAS7.804
> - Version I compiles successfully but when attempting to display the
> resulting imagery, all values are 0 (zero).
>
> - Version II compiles successfully but when attempting to display the
> resulting magery, the following error is received:
>
> "IMGDISP: Unable to allocate memory" is produced.
>
>
>Questions:
>1. Which version of map filter code fragment is correct?
>
>2. What is it about that code fragment that would cause v7.7 to work and
> v7.804 to not work?
>
>3. Should we take the latest version of remap2.pgm (Version III) and
> interleave the TASC specific changes? Is this even possible or have
> their been enough changes to the code that the TASC specific changes
> would cause further errors?
>
>------_=_NextPart_000_01C1B005.0F0BC840--
>
>From address@hidden Fri Feb 8 07:46:30 2002
>To: "Dave Santek (E-mail)" <address@hidden>,
> "Unidata (E-mail)" <address@hidden>
>Cc: "MUG (E-mail)" <address@hidden>
>Subject: updated information re: remap2.pgm
>Date: Fri, 8 Feb 2002 09:42:38 -0500
Dave & Tom,
Here is some additional information that I have gathered by digging
deeper...I'm running into McIDAS source code differences which may or may
not be clues to the real problem. Please let me know what you think after
you read the attached.
Thanks for your help.
Mary Ellen
Review of the Problem :
Version I of remap2.pgm differs from Version II in only one place, the
filter map section of the code shown below.
Version I:
529 c
530 c--- set the bits for the filter map
531 c
532 do 150 jj=1,nbands
533 iband = bndord(jj)
534 ibit = ibset(ibit, iband-1)
535 150 continue
536 c
537 odir(19) = ibit
538 c
Version II:
NOTE: This code fragment is identical to Version III (mcxrd7.8 code)
537 c
538 c--- set the bits for the filter map
539 c
540 ibit = 0
541 ibit2 = 0
542
543 do 150 jj=1,nbands
544 iband = bndord(jj)
545 if (iband .le. 32) then
546 ibit = ibset(ibit, iband-1)
547 else
548 ibit2 = ibset(ibit2, iband-33)
549 endif
550 150 continue
551 c
Results of running remap2.pgm VI and VII:
* AREA files created by versionI of remap2.pgm code linking to v7.7
library look good
* AREA files created by versionI of remap2.pgm code linking to v7.804
library gives error:
"unable to allocate memory" when you try to display it in McIDAS
* AREA files created by versionII of remap2.pgm linking to v7.7 library
contain have values of zero for all pixels and all bands
* AREA files created by versionII of remap2.pgm linking to v7.804
library gives error:
"unable to allocate memory" when you try to display it in McIDAS
New Information:
Differences in mccomp between Unidata Mcidasv7.7 and v7.804
v7.804 OSF1) ccopts= "-std -DFUNCPROTO=15"
v7.7 OSF1) ccopts= "-std -DFUNCPROTO=15 -ieee_with_inexact"
As long as we use VersionI of remap2.pgm using either mccomp from
v7.804 or v7.7 does not make any difference.
I have a c program read4kmRemap.c which reads an AREA file and prints
out a 5x5 box of values for each band of the image centered on a user
specified row and column.
This program uses the following core McIDAS functions:
opnara.for
readd.for
araopt.for
nvset.for
readara.for
clsara.for
nv1sae.for
I have compared the above functions between v7.7 and v7.804 and
nvset.for is \b different\b0 in each version. For grins I checked the
source code on our AIX box which has the latest SSEC MciDAS v7.8 and it
does not even have nvset.for Also, there does not appear to be any
existence of the function nv1sae.for. I grepped for the function
prototype assuming it might be contained in another program but the
nearest I found was nv1saesin() in nv1sin.for.
Summary & Questions:
I'm not sure if the above information will shed some light or give us
clues to the source of the problem.
1. Would the differences in nvset.for have anything to do with this
problem?
2. Would the filter map code fragment differences in version I and II
be a source of the problem?
3. Is this a compilation issue and not a code issue?
4. What happenned to nv1sae.for and nvset.for? Are there new
functions?
I am digging around furiously trying to figure this out but obviously
the source code is not my specialty. If either of you have any
thought/advice on what to try next please let me know.
Thanks for your help. Mary Ellen
>From address@hidden Fri Feb 8 12:14:45 2002
>Subject: RE: 20020207: remap2.pgm
Tom,
I think you'll find the questions posed and information shared in my
second email more "Unidata" specific. I appreciate your prompt response and
willingness to help. Dave has mentioned that he will look at the questions I
have posed in detail next week. So I'll wait to hear from him and if you
have any questions or thoughts about the info in my second email please let
me know.
In response to your questions.... we have compiled McIDAS and all
addendums with the vendor compilers which are: f77 and cc. I will supply you
with the code, the compilers and example AREA files based on Dave's response
next week.
Thanks again.
Mary Ellen
>From address@hidden Wed Feb 13 08:03:44 2002
Compiling with UMcIDAS7.7
- Version I compiles successfully and the resulting imagery looks good.
- Version II compiles successfully but when attempting to display the
resulting
imagery, the following error is received:
"IMGDISP: Unable to allocate memory" is produced.
I think there are more differences than just this. I'll look at
next email.
Compiling with UMcIDAS7.804
- Version I compiles successfully but when attempting to display the
resulting imagery,
all values are 0 (zero).
- Version II compiles successfully but when attempting to display the
resulting
magery, the following error is received:
"IMGDISP: Unable to allocate memory" is produced.
Questions:
1. Which version of map filter code fragment is correct?
The second version is more general and was put in there for
MODIS data which has more than 32 bands. It shouldn't affect you either way.
2. What is it about that code fragment that would cause v7.7 to work and
v7.804 to not work?
Nothing. There almost has to be something else different.
3. Should we take the latest version of remap2.pgm (Version III) and
interleave the TASC specific
changes? Is this even possible or have their been enough changes to the
code that
the TASC specific changes would cause further errors?
I don't think that is necessary. Most of those additional changes were made
for other data [AVHRR, MODIS, HIRS, etc.]
dave
>From address@hidden Wed Feb 13 08:24:05 2002
>To: "Craddock, Mary Ellen" <address@hidden>
>CC: "Unidata (E-mail)" <address@hidden>,
> "MUG (E-mail)" <address@hidden>
>Subject: Re: updated information re: remap2.pgm
"Craddock, Mary Ellen" wrote:
> Dave & Tom,
> Here is some additional information that I have gathered by digging
> deeper...I'm running into McIDAS source code differences which may or may
> not be clues to the real problem. Please let me know what you think after
> you read the attached.
>
> Thanks for your help.
> Mary Ellen
> Summary & Questions:
> I'm not sure if the above information will shed some light or give us clues
> to the source of the problem.
> 1. Would the differences in nvset.for have anything to do with this problem?
>
Seems unlikely. But, could you send me the 'diff' output?
> 2. Would the filter map code fragment differences in version I and II be a
> source of the problem?
>
No. This only changes the value of word 19 in the area directory. If those
numbers are the
same, then there almost has to be a difference in the code somewhere else.....
> 3. Is this a compilation issue and not a code issue?
>
Could be......but I still think there almost has to be another code difference.
> 4. What happenned to nv1sae.for and nvset.for? Are there new functions?
>
A better question is, "Where is your version of nvset.for?" It has to be there,
somewhere,
or any McIDAS application that uses navigation will not link! The nv1sae, etc.
are all hidden
in nvprep.for.
dave
>From address@hidden Wed Feb 13 12:13:55 2002
Dave,
1. Would the differences in nvset.for have anything to do with this
problem?
>Seems unlikely. But, could you send me the 'diff' output?
I have attached the 'diff' output for nvset.for when comparing v7.7 and v7.8.
2. Would the filter map code fragment differences in version I and
II be a source of the problem?
>No. This only changes the value of word 19 in the area directory.
>If those numbers are the same, then there almost has to be a difference in
>the code somewhere else.....
The only differences in remap2.pgm versionI and versionII is the filter
map code fragment. You indicated that this only changes the value of
word 19 which is the same in both versions so this is likely not the
problem.
3. Is this a compilation issue and not a code issue?
>Could be......but I still think there almost has to be another code
>difference.
Are there any other McIDAS source functions that remap2.pgm calls
that have changed?
4. What happenned to nv1sae.for and nvset.for? Are there new functions?
>A better question is, "Where is your version of nvset.for?" It has to be
>there, somewhere, or any McIDAS application that uses navigation will not
>link! The nv1sae, etc. are all hidden in nvprep.for.
Found it right where it should be.
Your earlier email indicated that it almost has to be a code difference but
I'm not sure that it is. Can you comment on any possible compilation
differences?
MaryEllen
Differences in nvset.for from Unidata v77 and Unidata v78 McIDAS
v77< C *** $Id: nvset.f,v 1.14 2000/03/31 19:40:54 russd Tst $ ***
---
v78> C *** $Id: nvset.f,v 1.15 2001/04/16 13:32:04 daves Exp $ ***
< CALL DDEST('AREA TYPE$$',0)
---
> CALL DDEST('AREA TYPE',0)
< NAVSIZ = DIR(63) - DIR(35)
< IF (DIR(63).EQ.0) NAVSIZ = DIR(34) - DIR(35)
---
> NAVSIZ = m0arasize('NAV', dir)
> c
> c---- If the input file is not native byte-ordering
> c---- and this is GMS, preserve byte ordering in file
>
> if(iarr(1) .eq. lit('GMSX') .and.
> * isafmt(num) .ne. 0) call fbytec(iarr, navsiz/4)
>
>From address@hidden Thu Feb 14 14:44:09 2002
>Subject: Re: updated information re: remap2.pgm
"Craddock, Mary Ellen" wrote:
> Dave,1. Would the differences in nvset.for have anything to do with
> this problem?
> Seems unlikely. But, could you send me the 'diff' output?
> I have attached the 'diff' output for nvset.for when
> comparing v7.7 and v7.8.
>
>
It is what I expected.....so that shouldn't be the
cause of the problem.
>
>
> 2. Would the filter map code fragment differences in version I and II
> be a source of the problem?
> No. This only changes the value of word 19 in the area directory. If
> those numbers are the
> same, then there almost has to be a difference in the code somewhere
> else.....
> The only differences in remap2.pgm versionI and versionII is
> the filter map code fragment. You indicated that this only changes the
> value of word 19 which is the same in both versions so this is likely
> not the problem.
>
Correct!
>
> 3. Is this a compilation issue and not a code issue?
> Could be......but I still think there almost has to be another code
> difference.
> Are there any other McIDAS source functions that remap2.pgm
> calls that have changed?
>
>
I'm sure many modules have changed.....but I don't
think they would
would have the effect you're seeing. What if you
do the same build
on a different platform, AIX for example? Do you
see the same
behavior?
>
>
> Your earlier email indicated that it almost has to be a
> code difference but I'm not sure that it is. Can you
> comment on any possible compilation differences?
>
>
The first think I would try is turning off
optimization and see how things
work. We just had a case this week where WWDISP
does not work
correctly over a GOES satellite image unless the
optimization is turned
off for the navigation [on Solaris Intel].
>
> dave
> MaryEllen
>
