[MITgcm-support] Error related to BLING

Gus Correa gus at ldeo.columbia.edu
Wed Sep 8 15:17:43 EDT 2021


Hi Kunal

Hmmm ... interesting ... I took a more careful look at what Michael pointed
out ...

I also have missing G_SI in the call to BLING_BIO_NITROGEN in bling_main.F
in checkpoint_67w.
I enclose the code snippet below.

On other hand, G_SI is present in the subroutine BLING_BIO_NITROGEN
definiition
in bling_bio_nitrogen.F. (See that other code snippet, which I sent
yesterday, down the email pile.)

So, the two don't match.
But they should.

However, since I am not using silica as a ptracer, the bug doesn't affect
anything in the code that is actually compiled in my case.
The preprocessor removes any reference to PTR_SI and to G_SI,
removing the mismatch.
But in your case it does matter.

In any case, it's better to fix the bug.
This snippet:

#ifdef USE_SIBLING
     O           G_SI,
#endif

should be added right after the line

     U                 G_PO4, G_DOP, G_NO3, G_DON,

in the code lines after

call BLING_BIO_NITROGEN

in bling_main.F,
to match the corresponding subroutine code in bling_bio_nitrogen.F,=.

Then recompile fresh.

Regards,
Gus

****** code snippet: call to BLING_BIO_NITROGEN in bling_main.F ***

C  call either "BLING" or "BLING + nitrogen"
#ifndef USE_BLING_V1
       CALL BLING_BIO_NITROGEN(
     I                 PTR_O2, PTR_FE, PTR_PO4, PTR_DOP,
     I                 PTR_NO3, PTR_DON,
#ifdef USE_SIBLING
     I                 PTR_SI,
#endif
#ifdef ADVECT_PHYTO
     I                 PTR_PHY,
#endif
     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,
     I                 myTime, myIter, myThid)
#else
       CALL BLING_BIO(
     I                 PTR_O2, PTR_FE, PTR_PO4, PTR_DOP,
     U                 G_DIC, G_ALK, G_O2, G_FE,
     U                 G_PO4, G_DOP,
     I                 bi, bj, imin, imax, jmin, jmax,
     I                 myTime, myIter, myThid)
#endif
*****

On Wed, Sep 8, 2021 at 9:53 AM kunal madkaiker <kunal.madkaiker02 at gmail.com>
wrote:

> Thanks a lot Gus and Michael. I'll try as per the suggestions and will
> provide an update on this.
>
> Regards,
> Kunal
>
> On Tue, Sep 7, 2021 at 8:13 PM Gus Correa <gus at ldeo.columbia.edu> wrote:
>
>> PS - Not using silica as a ptracer here, so I don't know if it works.
>> To fix the code you need to modify both the subroutine interface in
>> bling_bio_nitrogen.F
>> and the call in bling_main.F.
>> Or switch to a newer MITgcm checkpoint/version that may have fixed it.
>>
>>
>> On Tue, Sep 7, 2021 at 10:18 AM Gus Correa <gus at ldeo.columbia.edu> wrote:
>>
>>> Hi Kunal
>>>
>>> Michael is right.
>>>
>>> However, as I guessed, it is a missing argument (not the tracer itself,
>>> but the tendency G_SI) in a subroutine interface.
>>> The code I have (checkpoint_67w) has the interface below for
>>> the BLING_BIO_NITROGEN subroutine interface,
>>> which includes G_SI (the SI tendency) *IF *you compile with
>>> USE_SIBLING defined in BLING_OPTIONS.h.
>>> (The default is #undef, I think.).
>>> Silica as a passive tracer seems to have been introduced recently,
>>> so it may not have been fully tested.
>>>
>>> So, two possibilities that I can imagine:
>>> 1. You didn't compile with #define USE_SIBLING in BLING_OPTIONS.h
>>> 2. You are using an older code that is really missing G_SI
>>> But it can always be something else.
>>>
>>> Also, take a look at the doc/tag-index file in your main MITgcm code to
>>> see
>>> if there is anything relevant about BLING and silica there.
>>>
>>> I hope this helps,
>>> Gus
>>>
>>> *******
>>>       SUBROUTINE BLING_BIO_NITROGEN(
>>>      I           PTR_O2, PTR_FE, PTR_PO4, PTR_DOP,
>>>      I           PTR_NO3, PTR_DON,
>>> #ifdef USE_SIBLING
>>>      I           PTR_SI,
>>> #endif
>>> #ifdef ADVECT_PHYTO
>>>      I           PTR_PHY,
>>> #endif
>>>      O           G_DIC, G_ALK, G_O2, G_FE,
>>>      O           G_PO4, G_DOP, G_NO3, G_DON,
>>> #ifdef USE_SIBLING
>>>      O           G_SI,
>>> #endif
>>>      I           bi, bj, imin, imax, jmin, jmax,
>>>      I           myTime, myIter, myThid)
>>> *****
>>>
>>>
>>> On Tue, Sep 7, 2021 at 9:00 AM Michael Schaferkotter <
>>> schaferk at bellsouth.net> wrote:
>>>
>>>> without looking at source code,
>>>> it seems that G_SI is missing in the BLING_BIO_NITROGEN call sequence,
>>>> unless it is defined in an include file somewhere. Also check that G_SI is
>>>> declared as an argument in the BLING_BIO_NITROGEN subroutine.
>>>>
>>>> Sent from Here3.
>>>>
>>>> On Sep 7, 2021, at 06:23, kunal madkaiker <kunal.madkaiker02 at gmail.com>
>>>> wrote:
>>>>
>>>> 
>>>>>>>>
>>>> 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)
>>>>
>>>>
>>>>
>>>> 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
>>>>>
>>>> _______________________________________________
>>>> 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/20210908/52bb657c/attachment-0001.html>


More information about the MITgcm-support mailing list