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

20010403: 20010321: rebuilding gempak for large gribs



Art,

If the program core dumps without any input etc, then it is likely 
running into stack size problems in allocating the space required.

You might try checking any stack size limits you have.
You can compile with -g to see where the dcgrib2 program is dumping.
It may be that an array size is larger than allowed by the system.

I have defined MAXGRIBSIZE as 1000000 here for an ECMWF data set 
(.5 degree global grid) and that works for the product size, however
the data size is only 720x361, so not using very large arrays in the
gemlib defined LLMXGD.


Steve Chiswell
Unidata User Support



>From: "Arthur A. Person" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200104032111.f33LBAL14985

>On Wed, 21 Mar 2001, Unidata Support wrote:
>
>> >From: "Arthur A. Person" <address@hidden>
>> >Organization: UCAR/Unidata
>> >Keywords: 200103211815.f2LIFnL03774
>>
>> >Hi,
>> >
>> >I want to decode 4km precip grib data from NCEP using dcgrib2 but need to
>> >make mods to allow for larger gribs and grids (1160 X 880).  The NCEP
>> >instructions said to use nagrib but I should be able to use dcgrib2,
>> >correct?  I've identified that I need to make MAXGRIBSIZE larger in
>> >decode_grib.c and I think I need to make LLMXGD larger for the overall
>> >grid size.  Can you tell me if LLMXGD is the only other thing I need to
>> >modify to make this work correctly?  Do I then need to rebuild the whole
>> >gempak package, or can I just build part of it to get dcgrib2 to work?
>> >
>> >                                     Thanks.
>> >
>> >                                       Art.
>> >
>> >Arthur A. Person
>> >Research Assistant, System Administrator
>> >Penn State Department of Meteorology
>> >email:  address@hidden, phone:  814-863-1563
>> >
>>
>>
>> Art,
>>
>> You need to rebuild the entire package (including all the $GEMLIB library
>> files) whenever changing any array sizes defined in the $GEMPAK/include
>> files (since this will change common block sizes and sizes passed in
>> subroutine calls). You can run "make distclean" from $NAWIPS to
>> remove the $GEMLIB files as well as any other build files from the tree.
>>
>> LLMXGD should be changed in both the fortran GEMPRM.xxx file as well as
>> the C gemprm.h file. The computation heap for grids defined as LLMDGG
>> is related since this is the amount of space used by computations
>> (eg each grid in the computation uses this space) that
>> use more than 1 grid- so it should be large enough to allow you to
>> hold at least 4x the grid size probably.
>>
>> The MAXGRIBSIZE parameter in decode_grib.c is the size of the buffer
>> for the largest "grib message" you will encounter in the data stream
>> (that is the grib packed message).
>
>Okay, I made a new gempak installation tree called NAWIPS-5.6.a-big and
>put a fresh copy of gempak there.  I modified the following:
>
>       gempak/include/MCHPRM.SunOS -> LLMXGD=1200000
>       gempak/include/gemprm.h     -> LLMXGD=1200000
>       gempak/include/GEMPRM.PRM   -> LLMDGG=7200000
>       unidata/ldmbridge/dcgrib2/decode_grib.c -> MAXGRIBSIZE=500000
>
>I re-make'd and re-install'd (on Solaris 2.7) and tried running the
>dcgrib2 decoder and it core dumps.  I tried just an empty command to see
>what it would do and I get:
>
>        [16863] 010403/1658 [DC 3]  Starting up.
>        [16863] 010403/1658 [DC -11]  No command line arguments found.
>        Segmentation Fault (core dumped)
>
>I've apparently missed something else that needs modified... any clues?
>
>                                Thanks.
>
>                                  Art.
>
>
>Arthur A. Person
>Research Assistant, System Administrator
>Penn State Department of Meteorology
>email:  address@hidden, phone:  814-863-1563
>