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