[MITgcm-support] Error related to BLING
Gus Correa
gus at ldeo.columbia.edu
Tue Sep 7 10:18:31 EDT 2021
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-support/attachments/20210907/e8b5cb26/attachment-0001.html>
More information about the MITgcm-support
mailing list