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

[McIDAS #IWJ-443798]: MCIDAS Software Upgrade at NGC



Hi Martha, Mary Ellen and Randy,

Martha wrote:

> I am attaching the image I am trying to use with remap2_tasc - this is the 
> result I get:

> /home/mcidas/bin/REMAP2_TASC 1000 5000 BANDS=1 2 3 4 5 LAT=30.0 50.0 
> LON=105.0 125.0 
> REMAP - TRANFORMATIONS COMPLETE..BEGIN DATA MOVE
> Program terminated, segmentation violation
> /home/mcidas/bin/REMAP2_TASC failed, RC=1

> I should note that this happens with at least one other image as well. 

I poked around in the remap2_tasc souce code yesterday afternoon
and found the reason for the segmentation violations.  In the C routine
cloudp_tasc.c the first instance of calling kbxcal specifies NULL as the
first parameter (line 132):

/* DUMMY array send to kb1cal and kb3cal inorder to run the new calibration in 
Mcidas7.5 rja 12/8/98 */
status = kb2cal_(NULL, areadir, &one, &one,  ch1_buf);
status = kb1cal_(dummy,areadir, &one, &two,  ch2_buf);
status = kb1cal_(dummy,areadir, &one, &four, ch4_buf);
status = kb3cal_(dummy,areadir, &one, &five, ch5_buf);

kbxcal (kb2cal_ that is) is evidently trying to write to the address
specified by the first passed parameter, and this being NULL (zero) is
causing the core dump.  Without really investigating what should be
passed, I changed the first kb2cal_ invocation to read:

status = kb2cal_(dummy,areadir, &one, &one,  ch1_buf);

rebuilt remap2_tasc.k and ran Martha's invocation on the image that
she provided to me (AREA1000). remap2_tasc.k ran to completion with
no obvious problems.  I tried displaying the various bands in the
remapped image, and the only one that seemed to contain anything
non-zero was band 2.

By the way, I also did a side-by-side comparison of remap2.pgm and
remap2_tasc.pgm (since it seems that remap2_tasc.pgm is a modified
version of remap2.pgm) and see that there are several parameters definitions
that are significantly larger in remap2.pgm than in remap2_tasc.pgm.
It is likely that these should be increased as they typically define
the dimensionality of arrays used during the remapping process.

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: IWJ-443798
Department: Support McIDAS
Priority: Normal
Status: Closed