[MITgcm-devel] problem with TAF tang-Lin exp. hs94.1x64x5

Martin Losch Martin.Losch at awi.de
Mon Sep 25 10:19:56 EDT 2023


Hi Dan,

yes, I started PR 773 (https://github.com/MITgcm/MITgcm/pull/773) and you already reviewed it, so all is good (o:

Martin

> On 22. Sep 2023, at 12:09, Daniel Goldberg <Dan.Goldberg at ed.ac.uk> wrote:
> 
> hi both
> 
> very sorry -- i did not see this email yesterday (i think i saw that it was taf tang-lin and figured it was not for me).
> 
> very sorry about this. i considered making the changes to the files contingent on ALLOW_OPENAD being defined but they seemed so harmless i was confident it would not be an issue!
> 
> martin, have you already started a PR? if so would i be able to contribute? the easiest thing is to drop in ifdef's where these temporary string variables are used to avoid string arrays that OpenAD cannot parse. there are just a lot of them, which is annoying, but i can probably remember where they are.
> 
> dan
> From: MITgcm-devel <mitgcm-devel-bounces at mitgcm.org <mailto:mitgcm-devel-bounces at mitgcm.org>> on behalf of Martin Losch <Martin.Losch at awi.de <mailto:Martin.Losch at awi.de>>
> Sent: Friday, September 22, 2023 08:56
> To: MITgcm-devel <MITgcm-devel at mitgcm.org <mailto:MITgcm-devel at mitgcm.org>>
> Subject: Re: [MITgcm-devel] problem with TAF tang-Lin exp. hs94.1x64x5
>  
> This email was sent to you by someone outside the University.
> You should only click on links or attachments if you are certain that the email is genuine and the content is safe.
> 
> PS. I tried halpice_streamice with this ( "./testreport -oad -devel -t halfpipe_streamice”) and it worked, maybe Dan can quickly confirm.
> 
> Shall I submit a quick PR?
> 
> Martin
> 
> > On 22. Sep 2023, at 09:22, Martin Losch <Martin.Losch at awi.de> wrote:
> >
> > Hi Jean-Michel,
> >
> > that makes sense, I was just referring to just changing the two lines in question (which didn’t work), but reverting the entire routine works for me, too.
> >
> > Anyway, based on the current master, these changes work for me, but I don’t know if OpenAD is happy with that. Maybe Dan can quickly try:
> >
> > diff --git a/pkg/ctrl/ctrl_map_ini_gentim2d.F b/pkg/ctrl/ctrl_map_ini_gentim2d.F
> > index 7459b7fda..98dc1f4c7 100644
> > --- a/pkg/ctrl/ctrl_map_ini_gentim2d.F
> > +++ b/pkg/ctrl/ctrl_map_ini_gentim2d.F
> > @@ -57,7 +57,6 @@ C     temporary values in the do loop during reverse pass.
> >        CHARACTER*(MAX_LEN_FNAM) fnamegenIn(1:maxCtrlTim2D)
> >        CHARACTER*(MAX_LEN_FNAM) fnamegenOut(1:maxCtrlTim2D)
> >        CHARACTER*(MAX_LEN_FNAM) fnamegenTmp(1:maxCtrlTim2D)
> > -      CHARACTER*(MAX_LEN_FNAM) fnamebase(1:maxCtrlTim2D)
> >        CHARACTER*(MAX_LEN_FNAM) temp_genarr_fnamA
> >        CHARACTER*(MAX_LEN_FNAM) temp_genarr_fnamB
> >        integer startrec
> > @@ -121,9 +120,8 @@ C--   generic 2D control variables
> >
> >          ilgen=ilnblnk( xx_gentim2d_file(iarr) )
> >          temp_genarr_fnamA = xx_gentim2d_file(iarr)
> > -        fnamebase(iarr) = temp_genarr_fnamA(1:ilgen)
> >
> > -        call ctrl_init_rec ( fnamebase(iarr),
> > +        call ctrl_init_rec ( temp_genarr_fnamA(1:ilgen),
> >       I       xx_gentim2d_startdate1(iarr),
> >       I       xx_gentim2d_startdate2(iarr),
> >       I       xx_gentim2d_period(iarr),
> > @@ -165,9 +163,8 @@ C print statements are removed. See "Automatic Differentiation" chap. in the doc
> >           endif
> >          enddo
> >
> > -        ilgen=ilnblnk( xx_gentim2d_file(iarr) )
> > -        temp_genarr_fnamA = xx_gentim2d_file(iarr)
> > -        fnamebase(iarr) = temp_genarr_fnamA(1:ilgen)
> > +CML        ilgen=ilnblnk( xx_gentim2d_file(iarr) )
> > +CML        temp_genarr_fnamA = xx_gentim2d_file(iarr)
> >          write(temp_genarr_fnamB,'(2a,i10.10)')
> >       &   ctrlDir(1:ilDir)//temp_genarr_fnamA(1:ilgen),'.',optimcycle
> >          fnamegenIn(iarr) = temp_genarr_fnamB
> >
> > M
> >
> >> On 21. Sep 2023, at 20:40, Jean-Michel Campin <jmc at mit.edu> wrote:
> >>
> >> Hi Martin,
> >>
> >>> I tried reverting the code to the previous version, but that does not help.
> >> This does not match what I found:
> >> 1) this test is run every night (e.g., on villon), and was passing on Sep 20 and it's now failing to run.
> >>   And TAF has not been upgraded (both days it's Version 5.8.8).
> >> 2) using the code just after merging PR #751, this test fails but if I use the previous
> >>  (before PR #751 was merged) version of ctrl_map_ini_gentim2d.F it run fine (since
> >>  TAF does not remove the 2 lines I copied in my ealier eamil.
> >>
> >> Cheers,
> >> Jean-Michel
> >>
> >> On Thu, Sep 21, 2023 at 06:46:46PM +0200, Martin Losch wrote:
> >>> Hi Jean-Michel,
> >>>
> >>> I tried reverting the code to the previous version, but that does not help. Going back to version 5.8.0 does not either, not the combination of both.
> >>> Going back to pre PR 517 works.
> >>> Using ???staf -keep??? works, but we don???t want that.
> >>> That???s weird, so TAF is confused.
> >>>
> >>> This works:
> >>>
> >>>        ilgen=ilnblnk( xx_gentim2d_file(iarr) )
> >>>        temp_genarr_fnamA = xx_gentim2d_file(iarr)
> >>>
> >>>        call ctrl_init_rec ( temp_genarr_fnamA(1:ilgen),
> >>> [???]
> >>>
> >>> but does it work with OpenAD/Tapenade?
> >>>
> >>> Looking at the code the character array "fnamebase(1:maxCtrlTim2D)??? is not necessary at all, definitely it does not need to be an array. Maybe that???s what upsets TAF?
> >>>
> >>> Martin
> >>>
> >>> BTW, the second assignment of fnamebase(parr) can be dropped, too, it???s not used after that. I say we drop the entire variable.
> >>>
> >>>> On 21. Sep 2023, at 17:37, Jean-Michel Campin <jmc at mit.edu> wrote:
> >>>>
> >>>> Hi Martin and Dan,
> >>>>
> >>>> With the changes in ctrl_map_ini_gentim2d.F from Dan's PR #751 (got merged yesterday)
> >>>> the TAF tang-lin experiment "hs94.1x64x5" does not run anymore with gfortran and -devel
> >>>> see, without MPI:
> >>>> http://mitgcm.org/testing/results/2023_09/tr_villon-b_20230921_1/summary.txt
> >>>> and with MPI:
> >>>> http://mitgcm.org/testing/results/2023_09/tr_engaging-gfoTlm_20230921_0/summary.txt
> >>>>
> >>>> It looks like a TAF problem, current Version 5.8.8, which remove lines 122 & 124:
> >>>> 122         ilgen=ilnblnk( xx_gentim2d_file(iarr) )
> >>>> 123         temp_genarr_fnamA = xx_gentim2d_file(iarr)
> >>>> 124         fnamebase(iarr) = temp_genarr_fnamA(1:ilgen)
> >>>> in the Tang-Lin version of this routine (i.e., in ctrl_map_ini_gentim2d_tl.f),
> >>>> just before the call to "ctrl_init_rec".
> >>>> And since this experiment is using "debugLevel = 2" (the only TLM test with debugLevel > 1),
> >>>> it triggers an error in ctrl_init_rec (with -devel, local var fnamebase(iarr) is not set at all).
> >>>>
> >>>> With the older version of ctrl_map_ini_gentim2d.F (before PR #751), TAF was keeping
> >>>> these 2 lines:
> >>>>>         ilgen = ilnblnk(xx_gentim2d_file(iarr))
> >>>>>         fnamebase(iarr) = xx_gentim2d_file(iarr)(1:ilgen)
> >>>>
> >>>> If you know a trick to convince TAF to keep these 2 lines, let me know.
> >>>> Otherwise, will likely submit the problem to Ralf Giering.
> >>>>
> >>>> Cheers,
> >>>> Jean-Michel
> >>>> _______________________________________________
> >>>> MITgcm-devel mailing list
> >>>> MITgcm-devel at mitgcm.org
> >>>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-devel
> >>>
> >>> _______________________________________________
> >>> MITgcm-devel mailing list
> >>> MITgcm-devel at mitgcm.org
> >>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-devel
> >> _______________________________________________
> >> MITgcm-devel mailing list
> >> MITgcm-devel at mitgcm.org
> >> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-devel
> >
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-devel
> The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th’ ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336. _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org <mailto:MITgcm-devel at mitgcm.org>
> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-devel/attachments/20230925/c1705d88/attachment-0001.html>


More information about the MITgcm-devel mailing list