Re: Re: ncar error codes -107

A completely portable solution is to recode the block data program(s) to
be real code in a subroutine that sets the values and then call it from
the main program. I know, this is extremely ugly, but it works with
every Fortran compiler I know of.

I first ran into this problem in the late 1970's, so it is not new by
any means.

Cheers,
Craig Douglas

Fred Clare wrote:
>
> On May 21, 2007, at 10:32 AM, Rick Roberts wrote:
>
>>
>> I'm having a LOT of trouble deciphering an NCAR error code,
>> which appears to be the ultimate nanny-nanny, boo-boo error
>> code.
>>
>> You know, "I'm not running and I'm not telling you why; 'nanny-nanny,
>> boo-boo.'"
>>
>> All I get is
>> GKS ERROR NUMBER -107 ISSUED FROM SUBROUTINE :
>>
>> and that's all. No subroutine name, no hint why, no core file.
>> Can't get the program to attach to dbx. Can't get it to compile and
>> link with the -g debug option.
>>
>> all I have is a code that won't run and a mandate to make it run.
>
> Rick,
>
> The GKS error message of -107 is supposed to mean that you
> have exceeded the maximum number of error messages allowed
> for this run (default is ten). However, when this message
> is issued as it is here, it usually means that blockdata has
> not been loaded (the variable storing the maximum number of
> error messages has not been set). We have external statements
> in various places trying to force the load of blockdata, but
> some compiles don't honor this.
>
> This problem has come up before and we have never traced its
> source so that we can improve the error message. We will do
> that in the near future. It is probably the case that, when
> blockdata is not loaded, the maximum number of allowable errors
> is zero and error -107 is triggered immediately. In the meantime
> Mary Haley has provided a detailed analysis of the current
> situation which follows:
>
> This problem has surfaced in situations when a
> non-g77 compiler is used, like Absoft or Intel.
>
> The only thing we can suggest is not to use those compilers,
> or to ask the vendors what they can do for a work-around.
>
> A remote possible work-around is to compile the "ncarbd.f"
> subroutine in $NCARG/ncarg2d/src/liboptional/ncarbd, and try loading
> this on the compile line every time you compile an NCAR Graphics
> program. (I think it needs to be included on the compile line
> *before* any NCAR Graphics libraries.) This doesn't always fix the
> problem, however.
>
> There is a simple blockdata test that can be run to see if your
> compilers have a problem with loading and/or initializing blockdata
> variables. It doesn't depend on NCAR Graphics at all. It is attached.
>
> To generate and run the tests:
>
> tar -xvf Blockdata_test.tar
> cd Blockdata_test
> make main.good
> make main.bad
> ./main.bad
> ./main.good
>
> If the compiler is not correctly initializing blockdata
> variables, then "./main.bad" (and maybe even "./main.good") will
> produce output like:
>
> TESTSUB: WK = 0...it should be 20
>
> If "main.good" gives the correct results:
>
> TESTSUB: WK = 20...it should be 20
>
> and "main.bad" doesn't, then this probably means the Intel
> compiler is being used. This compiler correctly initializes blockdata
> variables as long as you don't load them in via a library. In other
> words, you would have to compile NCAR Graphics programs by linking in
> every single *.o file in the NCAR Graphics library source tree, rather
> than linking in the libraries with "-lncarg_c -lncarg_gks -lncarg".
> Of course, this is an unacceptable and impractical work-around, because
> we have hundreds of *.o files.
>
> The simple answer is to use the g77 compiler, if you aren't doing so.
> If you are, then we have an unexplored problem on our hands.
>
> Fred Clare
>
>
>>
>> --
>>
>>
>>
>> CURRENT DATE IS 21-May-07 AT 12:30:31
>>
>>
>> Rick Roberts
>> CSC Snail Mail =
>> 1-888-677-2272 USAF ASC/HPT
>> or locally at 904-8316 2435 W. 5th St
>> FAX= B676, Area B
>> 937-656-9538 WPAFB, Oh 45433-7802
>> E-mail=
>> roberts_at_asc.hpc.mil
>>
>> http://www.asc.hpc.mil
>>
>> ** Enon spelled backwards is None **
>>
>> ------Your randomized pithy saying follows--------
>>
>> Only a VERY big brain can hold so much ignorance
>>
>>
>>
>>
>> (pithy saying # 4478 of 6142)
>> (pith last modified on 20/09/2006)
>> (program last modified on 8 Sept 2003)
>>
>>
>> _______________________________________________
>> ncarg-talk mailing list
>> ncarg-talk_at_ucar.edu
>> http://mailman.ucar.edu/mailman/listinfo/ncarg-talk
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> ncarg-talk mailing list
> ncarg-talk_at_ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/ncarg-talk
>

-- 
Craig C. Douglas
- mailto:Craig.Douglas@yale.edu, http://www.mgnet.org/~douglas
University of Kentucky, 773 Anderson Hall, Lexington, KY 40506-0046, USA
- Professor of Computer Science and Mechanical Engineering,
- 514H CRMS (Robotics building)                     Tel: +1-859-257-2438
Yale University, CS Dept., P.O. Box 208285, New Haven, CT 06520-8285, USA
- Senior Research Scientist of Computer Science
- 206 Arthur K. Watson Hall, 51 Prospect Street     Tel: +1-203-432-1207
Home: +1-203-625-9449, Cell: +1-203-570-2604, eFAX: +1-203-547-6273
DDDAS: http://www.dddas.org (dynamic data-driven application systems)
MGNet: http://www.mgnet.org (multigrid and related methods)

_______________________________________________
ncarg-talk mailing list
ncarg-talk_at_ucar.edu
http://mailman.ucar.edu/mailman/listinfo/ncarg-talk
Received on Mon May 21 2007 - 17:21:46 MDT