[MITgcm-support] Error related to BLING

Gus Correa gus at ldeo.columbia.edu
Thu Sep 9 17:10:43 EDT 2021


Thank you Jean-Michel for checking that my fix works,
and putting it in the git pipeline for a future release!
Gus

On Wed, Sep 8, 2021 at 3:37 PM 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-support/attachments/20210909/774bfd15/attachment-0001.html>


More information about the MITgcm-support mailing list