[MITgcm-support] Error related to BLING

kunal madkaiker kunal.madkaiker02 at gmail.com
Tue Sep 7 07:23:11 EDT 2021


Thank you Michael and Gus for the debugging suggestions. Based on both of
your suggestions, I have done the compilation and rerun the model with
debug mode true. Though I didn't get any error messages in STDERR files, I
got additional messages as below on screen. It is pointing to the line
numbers in three codes. Also STDOUT file shows that just before the model
crashes it is trying to call the subroutine CALC_PCO2_APPROX several times.
I did a preliminary check of these three codes and the CALC_PCO2_APPROX
subroutine. But I am not able to understand what is causing the error. I
need to thoroughly check these codes again. Meanwhile please give your
suggestions.


A)  Program received signal SIGSEGV: Segmentation fault - invalid memory
reference.

Backtrace for this error:
#0  0x7f1a828562ed in ???
#1  0x7f1a82855503 in ???
#2  0x7f1a820eafcf in ???
#3  0x555923c54713 in bling_bio_nitrogen_
at
/home/adrao/Remy-mitgcm-ii/MITgcm/verification/bling/code/bling_bio_nitrogen.f:4053
#4  0x555923c6b514 in bling_main_
at
/home/adrao/Remy-mitgcm-ii/MITgcm/verification/bling/code/bling_main.f:4199
#5  0x555923d34205 in gchem_forcing_sep_
at
/home/adrao/Remy-mitgcm-ii/MITgcm/verification/bling/code/gchem_forcing_sep.f:3891
#6  0xffffffffffffffff in ???
#0  0x7f09611532ed in ???


The portion of three codes with line numbers mentioned in the error
messages are included below

1) bling_bio_nitrogen.f

C  Initialize output and diagnostics
  DO k=1,Nr
         DO j=1-OLy,sNy+OLy
           DO i=1-OLx,sNx+OLx
              G_DIC(i,j,k)          = 0.D0
              G_ALK(i,j,k)          = 0.D0
              -----------------------------
              ---------------------------- etc
4053    G_SI(i,j,k)             = 0.D0
            ------------------------- etc
              ENDDO
         ENDDO
       ENDDO

2) bling_main.f

C  biological activity
C  call either "BLING" or "BLING + nitrogen"
       CALL BLING_BIO_NITROGEN(
     I                 PTR_O2, PTR_FE, PTR_PO4, PTR_DOP,
     I                 PTR_NO3, PTR_DON,
     I                 PTR_SI,
     U                 G_DIC, G_ALK, G_O2, G_FE,
     U                 G_PO4, G_DOP, G_NO3, G_DON,
     I                 bi, bj, imin, imax, jmin, jmax,
4199   I                 myTime, myIter, myThid)



3) gchem_forcing_sep.f

ccccccccccccccccccccccccccc BLING cccccccccccccccccccccccccccccccc
        IF ( useBLING ) THEN
          CALL BLING_MAIN( pTracer(1-OLx,1-OLy,1,bi,bj,1),
     &                          pTracer(1-OLx,1-OLy,1,bi,bj,2),
     &                          pTracer(1-OLx,1-OLy,1,bi,bj,3),
     &                          pTracer(1-OLx,1-OLy,1,bi,bj,4),
     &                          pTracer(1-OLx,1-OLy,1,bi,bj,5),
     &                          pTracer(1-OLx,1-OLy,1,bi,bj,6),
     &                          pTracer(1-OLx,1-OLy,1,bi,bj,7),
     &                          pTracer(1-OLx,1-OLy,1,bi,bj,8),
     &                          pTracer(1-OLx,1-OLy,1,bi,bj,9),
     &                          bi, bj, iMin, iMax, jMin, jMax,
3891  &                          myTime, myIter, myThid )
        ENDIF
cccccccccccccccccccccccccc END BLING cccccccccccccccccccccccccccccccccc

###################################################################

 B)  The last lines in the STDOUT file

(PID.TID 0009.0001) DEBUG_MSG: CALLING S/R CALC_PCO2_APPROX
(PID.TID 0009.0001) DEBUG_MSG: CALLING S/R CALC_PCO2_APPROX
(PID.TID 0009.0001) DEBUG_MSG: CALLING S/R CALC_PCO2_APPROX
(PID.TID 0009.0001) DEBUG_MSG: CALLING S/R CALC_PCO2_APPROX
(PID.TID 0009.0001) DEBUG_MSG: CALLING S/R CALC_PCO2_APPROX
(PID.TID 0009.0001) DEBUG_MSG: CALLING S/R CALC_PCO2_APPROX

On Mon, Sep 6, 2021 at 9:21 PM Gus Correa <gus at ldeo.columbia.edu> wrote:

> Hi Kunal
>
> Along the line mentioned by Michael.
>
> You can compile fresh adding the -devel flag to genmake2 (do a make CLEAN
> or just delete your build directory beforehand to avoid any leftover).
> Your build options file *probably* already has debug flags that are
> activated if you use -devel in genmake2.
> I think they are flags like FOPT or similar. Check.
>
> Then add a namelist flag (can't remember by the exact name, check) to use
> debug at runtime in the eesupp namelist file ...
> hmmm ...  debugMode-.TRUE. ... I think.
>
> Finally, raise the debug level in the "data" PARM01 namelist debugLevel=4
> (or 5).
>
> This will drop more error messages in STDERR.???? and traceback the call
> stack the point of failure,
> more verbose than it is now.
>
> I would guess some subroutine interface may be missing one of the tracers,
> probably silica, but it can be another thing.
>
> I hope this helps
> Gus
>
> On Sat, Sep 4, 2021 at 9:38 AM Michael Schaferkotter <
> schaferk at bellsouth.net> wrote:
>
>> 1. just to be sure, if parameter values in *.h are altered, you must
>> recompile.
>>
>> 2. for ifort compiler, recompile with:
>>
>>
>> g -check all -fpe0 -warn -traceback -debug extended
>>
>>
>> gfortran
>>
>>
>> -g -Wall -Wextra -Warray-temporaries -Wconversion -fimplicit-none -fbacktrace -ffree-line-length-0 -fcheck=all -ffpe-trap=invalid,zero,overflow,underflow -finit-real=nan
>>
>>
>> rerun.
>>
>> the stack trace will be more meaningful.
>>
>> michael
>>
>> Sent from Here3.
>>
>> On Sep 4, 2021, at 02:14, kunal madkaiker <kunal.madkaiker02 at gmail.com>
>> wrote:
>>
>> 
>> Thank you Matthew and Gus for your valuable suggestions. I could resolve
>> the 2nd query as suggested by Matt by adding apco2file in data.bling.
>>
>> I wanted to add few points regarding my 1st query (about adding silicate
>> as 9th tracer). The PTRACERS_num ( in PTRACER_SIZE.h ), PTRACERS_numInUse,
>> PTRACERS_useGMRedi (in data.ptracers), etc are already 9. So the error may
>> not be due to this. Also the same model setup is running fine for the
>> MITgcm-checkpoint67j (2019/06/18 ) release. This is the version where the
>> USE_SIBLING option is added to the BLING package for the first time.
>> However, I want to use the latest (or recent year) release. As Matthew
>> asked I am also including the detailed message I get on screen when the
>> model crashes. My STDERR files don't contain any error messages. So is this
>> problem related to MITgcm release ?
>>
>> Backtrace for this error:
>> #0  0x7f09681cc2ed in ???
>> #1  0x7f09681cb503 in ???
>> #2  0x7f0967a60fcf in ???
>> #3  0x5636cbe79533 in ???
>> #4  0x5636cbe8c909 in ???
>> #5  0x5636cbf36923 in ???
>> #6  0xffffffffffffffff in ???
>> Program received signal SIGSEGV: Segmentation fault - invalid memory
>> reference.
>>
>> Backtrace for this error:
>>
>> ============================================================
>> =======================
>> =   BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
>> =   PID 63826 RUNNING AT ADRAO
>> =   EXIT CODE: 139
>> =   CLEANING UP REMAINING PROCESSES
>> =   YOU CAN IGNORE THE BELOW CLEANUP MESSAGES
>> ============================================================
>> =======================
>> YOUR APPLICATION TERMINATED WITH THE EXIT STRING: Segmentation fault
>> (signal 11)
>> This typically refers to a problem with your application.
>> Please see the FAQ page for debugging suggestions
>>
>> Regards,
>> Kunal
>>
>> On Sat, 4 Sep 2021, 01:14 Gus Correa, <gus at ldeo.columbia.edu> wrote:
>>
>>>
>>>
>>> On Fri, Sep 3, 2021 at 1:48 PM Matthew Mazloff <mmazloff at ucsd.edu>
>>> wrote:
>>>
>>>> Hello
>>>>
>>>> 1) Do you have some more info on the error? Anything else given?
>>>> My first guess: did you set
>>>>       PARAMETER(PTRACERS_num = 9 )
>>>> in PTRACERS_SIZE.h?
>>>>
>>>> 2) You have to give the exf parameters in data.bling, not data.ext.
>>>>
>>>> -Matt
>>>>
>>>
>>> Yes, as Matthew said, segfault is because
>>> PARAMETER(PTRACERS_num = )
>>> is probably less than 9.
>>> I had the same error before.
>>>
>>> ... and add to data.ptracers:
>>>
>>>  PTRACERS_numInUse=9,
>>>  PTRACERS_useGMRedi=9*.TRUE., (if using GMRedi)
>>>  PTRACERS_useKPP=9*.TRUE., (if using KPP)
>>>
>>> and the ptracers name, long name, units, etc, for instance
>>>
>>>  PTRACERS_names(1)='dic',
>>>  PTRACERS_long_names(1)='Dissolved Inorganic Carbon',
>>>  PTRACERS_units(1)='mol C/m^3',
>>>  PTRACERS_advScheme(1)=77,
>>>  PTRACERS_diffKh(1)=0.E3,
>>>  PTRACERS_diffKr(1)=3.E-5,
>>>
>>> Gus
>>>
>>>>
>>>>
>>>> > On Sep 3, 2021, at 10:38 AM, kunal madkaiker <
>>>> kunal.madkaiker02 at gmail.com> wrote:
>>>> >
>>>> > Dear All,
>>>> >
>>>> >        I have two queries regarding the BLING model.
>>>> >
>>>> > 1) I am running the recent release of MITgcm coupled to the BLING
>>>> module. The model is running fine if I use the default 8 tracer option.
>>>> When I try to add silica as 9th tracer (#define USE_SIBLING in
>>>> BLING_OPTIONS.h), the model crashes in the beginning giving the following
>>>> error message "Program received signal SIGSEGV: Segmentation fault -
>>>> invalid memory reference.".
>>>> >
>>>> > 2) I want the model to read apco2 values from a file via the data.exf
>>>> instead of giving a constant value in data.bling. I enabled it with #define
>>>> USE_EXFCO2 in BLING_OPTIONS.h. However, the model crashes with the error
>>>> "Fortran runtime error: Cannot match namelist object name apco2startdate1."
>>>> >
>>>> > Please suggest some solutions to the above issues.
>>>> >
>>>> > Regards
>>>> > Kunal
>>>> > _______________________________________________
>>>> > MITgcm-support mailing list
>>>> > MITgcm-support at mitgcm.org
>>>> >
>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__mailman.mitgcm.org_mailman_listinfo_mitgcm-2Dsupport&d=DwICAg&c=-35OiAkTchMrZOngvJPOeA&r=HSHS34ROdfL7f2oVxuKB761hrMvWN1RWA5k3SHGts_s&m=iOrbnncxN5Y2dAD0gIwZZlqCaFyQZtz6j7wWPBxR3O8&s=oDRvUUxOSUqUl1gJNzk7caygbs0kdrURo0TiIV6QfqQ&e=
>>>>
>>>> _______________________________________________
>>>> MITgcm-support mailing list
>>>> MITgcm-support at mitgcm.org
>>>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
>>>>
>>> _______________________________________________
>>> MITgcm-support mailing list
>>> MITgcm-support at mitgcm.org
>>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
>>>
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
>>
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
>>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-support/attachments/20210907/6b472885/attachment-0001.html>


More information about the MITgcm-support mailing list