[MITgcm-support] Error related to BLING
Gus Correa
gus at ldeo.columbia.edu
Thu Sep 9 17:06:26 EDT 2021
Hi Kunal
Glad to know that it is working for you now.
Regards,
Gus
On Thu, Sep 9, 2021 at 8:05 AM kunal madkaiker <kunal.madkaiker02 at gmail.com>
wrote:
> Thank you Jean-Michel, Gus, Michael, Matt and everyone else !
> As Gus suggested, I have included the G_SI argument (with ifdef
> use_sibling .. endif) to the bling_bio_nitrogen subroutine call in the
> bling_main.F code.
> As Jean-Michel mentioned, now the model is running without any problem for
> me as well. I'll keep monitoring the simulation.
> Thanks again for your time and patience.
>
> Regards,
> Kunal
>
> On Thu, Sep 9, 2021 at 1:22 AM Jean-Michel Campin <jmc at mit.edu> wrote:
>
>> Hi Kunal,
>>
>> I put Gus' fix into my branch "fix_sibling_attempt", see:
>>
>> https://github.com/jm-c/MITgcm/blob/fix_sibling_attempt/pkg/bling/bling_main.F
>>
>> I also try to turn on useSIBLING (i.e., #define useSIBLING in
>> BLING_OPTIONS.h)
>> in verification/global_oce_biogeo_bling and was getting the same error as
>> you ;
>> After adding the fix in bling_main.F, I can run for 4 time-step but it
>> was
>> without any specific Silica forcing or initial conditions.
>>
>> Cheers,
>> Jean-Michel
>>
>> On Wed, Sep 08, 2021 at 03:17:43PM -0400, Gus Correa wrote:
>> > 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
>> > >
>>
>> > _______________________________________________
>> > 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/20210909/1c0149d2/attachment-0001.html>
More information about the MITgcm-support
mailing list