[MITgcm-support] Error related to BLING
kunal madkaiker
kunal.madkaiker02 at gmail.com
Thu Sep 9 08:04:52 EDT 2021
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-support/attachments/20210909/7333962a/attachment-0001.html>
More information about the MITgcm-support
mailing list