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

20030623: TASC remap2 bugs (cont.) -- Problem Solved!

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: 20030623: TASC remap2 bugs (cont.) -- Problem Solved!
  • Date: Mon, 23 Jun 2003 07:22:29 -0600
>From: "Craddock, Mary Ellen" <address@hidden>
>Organization: Northrop Grumman Information Technology, TASC
>Keywords: 200306121159.h5CBxXLd023117 TASC remap2

Mary Ellen,

>       I'm sorry it has been over a week since I responded to your last
>email. I was out of town last week in CA for business. Before I left for CA,

No worries.  I had plenty to do :-)

>I was planning to send you a GOES East image so that you could run
>remap2.pgm on it per your suggestion. When I ran remap2.k on it to record
>the output errors to pass along to you, I was amazed to see that there were
>no errors. I ran remap2.k for several different AREA files all generated and
>located on our AIX system and could not reproduce the problem.  The only
>thing different was that I had logged out of the Linux box and restarted
>McIDAS before I ran these tests. Perhaps the McIDAS environment was
>disrupted.

The only thing that I could imagine being different with the
environment is your MCPATH or possibly your set of file REDIRECTions if
you use them.

>Regardless, it is working as it should since as you pointed out
>READD() does indeed check and correct for the byte swap issue if needed.

I'm glad to hear it!

>       Thanks for you continued support on this matter! I appreciate all
>your time and efforts to help us find the solution.

I did run into one other thing when building your version of remap2 on
a Sun.  The routine cloudp.c uses an array named 'sun', and this causes
a problem on Sun since 'sun' is a C define there.  In order to get this
to work, I changed the name of your array to 'sun_t' and then
everything worked.

By the way, I was thinking of adding your remap2 routine to my McIDAS
distribution renamed to remap2_tasc.pgm.  In order to do this, I would
rename cloudp.c to cloudp_tas.c and go ahead and include sza.c in
cloudp_tasc.c.  I would add the routine in my XRD section of the
makefile (build the XRD/MDF routines I include by running 'make xrd'
and 'make install.xrd' from the distribution src directory) if I have
your/TASC's permission to do so.

Please let me know if the inclusion of your routine is OK.  Thanks.

Tom