[MITgcm-devel] After PR #371 (tst_2+2_bug_fix) got merged in

[Jean-Michel Campin]

Hi Martin and Oliver,

As PR #376 (branch: tst_2+2_fix_of_fix) got merged in yesterday, got updated results
from daily test today. Looks like we are back from where we were before PR #371 got merged in,
which means the improvements we saw are gone. 

This indicates that the issue is not with the "sed" command (would have been weird since
since several switches pass <-> fail only appears with -fast and not -devel, everything else
beeing the same). But this does not rule out (although unlikely) a disk system latency.

Cheers,
Jean-Michel

On Wed, Sep 23, 2020 at 04:45:15PM +0200, Martin Losch wrote:
> That???s indeed interesting. This can only mean that the sed commands are not always doing, what they are supposed to do. I cannot inspect this right now, but will do so asap for ollie. I did test this for both POSIX sed and GNU sed.
> 
> Martin
> 
> > On 23. Sep 2020, at 16:12, Jean-Michel Campin <jmc at mit.edu> wrote:
> > 
> > Hi Martin and Oliver,
> > 
> > There is something unclear regarding the effect of this PR #371:
> > Since I merged it after mid-night yesterday, only got used in faily tests
> > last night. And for few restart test where some experiments were failing the 
> > test, I got a big improvement and many more to pass.
> > 
> > I still have not yet all output back, but the one affected are:
> > a) 1 more pass on villon (linux_amd64_gfortran.dvlp):
> > Y Y Y Y  pass   <- global_ocean.gm_k3d
> > ---
> >> Y Y Y Y FAIL (4) - global_ocean.gm_k3d
> > b) 5 more pass on engaging (linux_amd64_open64+mpi.fast):
> > 45c45
> > < Y Y Y Y  pass   <- global_with_exf
> > ---
> >> Y Y Y Y FAIL (4) - global_with_exf
> > 56,59c56,59
> > < Y Y Y Y  pass   <- isomip
> > < Y Y Y Y  pass   <- isomip.htd
> > < Y Y Y Y  pass   <- isomip.icefront
> > < Y Y Y Y  pass   <- isomip.obcs
> > ---
> >> Y Y Y Y FAIL (4) - isomip
> >> Y Y Y Y FAIL (4) - isomip.htd
> >> Y Y Y Y FAIL (4) - isomip.icefront
> >> Y Y Y Y FAIL (4) - isomip.obcs
> > c) and the largest changes are from "ollie" (before/after)i, only the "fast" ones:
> > 46:97  rs_ollie-i_20200922_1                    restart  linux_ia64_ifort_ollie+mpi.fast
> > 94:97  rs_ollie-i_20200923_1                    restart  linux_ia64_ifort_ollie+mpi.fast
> > And:
> > 50:96  rs_ollie-c_20200922_1                    restart  linux_ia64_cray_ollie+mpi.fast
> > 92:96  rs_ollie-c_20200923_1                    restart  linux_ia64_cray_ollie+mpi.fast
> > 
> > The 1 change in "do_tst_2+2" is unlikely to change anything (because it's just 
> > for log file and report, and only excecuted once for the first experiment).
> > So it's something with the 2 changes in "tst_2+2", and may be related to 
> > disk/system missing an updated file (since it's more common with "fast" than "devel") ?
> > Not very clear.
> > 
> > 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