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.
>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 >