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

20011128: surface data file opening error



Paul,

I believe the problem is that you are using nparm as a 
parameter. Actually, it is the number returned to you
from the SF_OPNF call, and it is variable according to the file.
The segment fault is probably the overwriting of the parms(10) array
since the library is expecting parms(MMPARM) which is parms(40).


Try taking out your parameter line.
and, use:
        INCLUDE         'GEMPRM.PRM'

        character*4     parms(MMPARM)

MMPARM is defined in GEMPRM.PRM, so you want to include
that before your variable declarations. For your test,
you could use:
        character*4     parms(40)
The include file just gives you more flixibility so that you
don't have to worry about maintaining the actual size numbers.

On your g77 compile line, you can add the include directory flags:
-I${GEMPAK}/include -I${GEMPAK}/include/Linux

(that "L" in linux is capitalized).

Steve Chiswell



>From: Paul Markowski <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200111282326.fASNQwN04967

>> Paul,
>>
>> The genaral steps, after calling IN_BDTA are to:
>> 1) open the file with SF_OPNF
>>   (check iret for error return)
>
>Ugh...this is where things go wrong.  IRET = 0 after IN_BDTA is called (so
>far so good), but the "segmentation fault" occurs when SF_OPNF is called.
>I.e., tackling the other tasks is a non-issue right now, b/c it seems I'm
>not doing something right to even open the file.
>
>Here's the code...
>
>      program test
>
>      integer nparm, iret, isffln, iflsrc
>
>      parameter ( nparm = 10 )
>
>      character*4 parms(nparm)
>      character*12 infile
>
>      logical wrtflg
>
>      infile = '19990715.gem'
>
>      call in_bdta(iret)
>
>      call sf_opnf(infile,wrtflg,isffln,
>     >              iflsrc,nparm,parms,iret)
>
>      print*, isffln
>
>      call sf_clos(isffln,iret)
>
>      stop
>      end
>
>
>