[MITgcm-devel] [MITgcm-cvs] MITgcm/doc CVS Commit

Jean-Michel Campin jmc at ocean.mit.edu
Fri Dec 12 08:58:16 EST 2014 

Hi Martin,

I was failling with open64 & -devel because it does trap un-initialise
variables efficiently: outside iMin:iMax,jMin:jMax BU,BJ were
not initialise and have a type of nan value.
And testing if they are equal to zero resulting in a floating exception.
I think that this last step (producing an error for jsut a test)
depends on how compilers do their "trapuv".

Note that, even if the test BU.EQ.0.d0 does not result in floating excep,
they will not be zet to 1. since, beeing not initialised, there is 
no reason to expect that they are equal to zero.

Cheers,
Jean-Michel

On Fri, Dec 12, 2014 at 09:52:42AM +0100, Martin Losch wrote:
> Hi Jean-Michel,
> 
> thanks for fixing this, but can you explain, why **restricting** the loop ranges to j/imin/max helps? I had put the full ranges to make sure that we don’t have any zeros on BU/BV anywhere in the domain. Or was the problem that in some places outside i/jmin/max BU/BV are unitialized, but never touched, but here they were? I maybe I should have initialized them properly at the beginning of S/R seaice_lsr.F?
> 
> Martin
> 
> On Dec 11, 2014, at 5:35 PM, Jean-Michel Campin <jmc at ocean.mit.edu> wrote:
> 
> > Hi Martin,
> > 
> > I found the problem (for this cluster + compiler + option)
> > and have a fix. I will wait until the other open64 -devel test
> > (that I run on the old geo cluster) finishes and check that the
> > fix works also there; if it's good, will check-in this fix.
> > 
> > Cheers,
> > Jean-Michel
> > 
> > On Thu, Dec 11, 2014 at 10:23:59AM -0500, Jean-Michel Campin wrote:
> >> Hi Martin,
> >> 
> >> I am happy with your explanation below. Thanks.
> >> 
> >> One remaining issue (I going to check this when the cluster is less busy)
> >> is that one global_ocean.cs32x15.seaice test has not yet recover:
> >> it's on cluster acesgrid with open64 compiler and -devel option:
> >> http://mitgcm.org/testing/results/2014_12/tr_acesgrid-tuv_20141211_0/summary.txt
> >> which stops with a floating point exception.
> >> 
> >> Cheers,
> >> Jean-Michel
> >> 
> >> On Thu, Dec 11, 2014 at 02:35:40PM +0100, Martin Losch wrote:
> >>> The point of the restricted additive Schwarz method is, that your don’t limit the calculation to the tile interior, but extend into the overlaps: seaice_lsr needs two points of overlap, so if you have OLx=4 you can still compute a solution 2 points into this overlap. Afterwards you combine the tiles without the overlap (that’s the “restricted” part). I think it should be immediately clear why this would be a better approximation to the global problem than not using the overlaps in the iterative procedure. My implementation works for non-cs grids without the resetting BU,BV and on cs-grids the problem appears only in the corners of the overlaps which not really used in the computation; at least, without the -devel option, the wrong values in the overlapp corners don’t seem to affect the solution. But I agree, it’s strange … I also need to investigate this a little more, …
> >>> 
> >>> Martin
> >>> 
> >>> On Dec 10, 2014, at 8:20 PM, Jean-Michel Campin <jmc at ocean.mit.edu> wrote:
> >>> 
> >>>> Hi Martin,
> >>>> 
> >>>> I would leave this routine (fill_cs_corner_rl.F) there for now.
> >>>> The thing that is not very clear to me (because I did not have time
> >>>> to look at the details of this Schwarz method implementation) is
> >>>> why setting BU,BV to one in these overlap region is going to be more 
> >>>> accurate than limiting the calculation to just the tile interior.
> >>>> 
> >>>> Cheers,
> >>>> Jean-Michel
> >>>> 
> >>>> On Wed, Dec 10, 2014 at 06:06:37PM +0100, Martin Losch wrote:
> >>>>> Hi Jean-Michel,
> >>>>> 
> >>>>> I think I fixed this problem by resetting bu/bv=1 if they are zero (but I do this only for cubedSphere and SEAICE_OLx/y>0). The new fill_cs_corner_rl routine is no longer necessary. Should we still keep it?
> >>>>> 
> >>>>> Martin
> >>>>> 
> >>>>> On Dec 10, 2014, at 4:41 PM, Martin Losch <Martin.Losch at awi.de> wrote:
> >>>>> 
> >>>>>> Hi Jean-Michel,
> >>>>>> 
> >>>>>> thanks for noticing, the reason is the same as before: BU(34,18,2,1) is zero exactly. This should not happen (ever) (see seaice_lsr.F l1259, for seaicemaskU = 0., there should be ONE=1D0 remaining). The quick fix is to reset any BU and BV that are 0 to 1. but then the program stops (within gdb, testreport passes) in seaice_solve4temp because tsurfloc(3,1) = 0 for bi=bj=1, very strange.
> >>>>>> 
> >>>>>> Should I apply the quick fix for now?
> >>>>>> 
> >>>>>> Martin
> >>>>>> 
> >>>>>> On Dec 10, 2014, at 3:31 PM, Jean-Michel Campin <jmc at ocean.mit.edu> wrote:
> >>>>>> 
> >>>>>>> Hi Martin,
> >>>>>>> 
> >>>>>>> Regarding the gfortran -devel fail:
> >>>>>>> there is a "Floating point exception" error, coming from S/R
> >>>>>>> seaice_lsr_tridiagu (in seaice_lsr.F):
> >>>>>>>> Backtrace for this error:
> >>>>>>>> #0  0x2B893F5E8407
> >>>>>>>> #1  0x2B893F5E8A0E
> >>>>>>>> #2  0x3C1C83568F
> >>>>>>>> #3  0x9735E8 in seaice_lsr_tridiagu_ at seaice_lsr.f:14903 (discriminator 16)
> >>>>>>>> #4  0x9A333D in seaice_lsr_ at seaice_lsr.f:4236
> >>>>>>>> #5  0x924475 in seaice_dynsolver_ at seaice_dynsolver.f:4354
> >>>>>>>> #6  0x9AC0F5 in seaice_model_ at seaice_model.f:4545
> >>>>>>>> #7  0xBF45C4 in do_oceanic_phys_ at do_oceanic_phys.f:3370 (discriminator 3)
> >>>>>>>> #8  0xC1DADF in forward_step_ at forward_step.f:2467
> >>>>>>>> #9  0xCD1569 in main_do_loop_ at main_do_loop.f:2145
> >>>>>>>> #10  0xD3DB28 in the_main_loop_ at the_main_loop.f:2163
> >>>>>>>> #11  0xD3DCFB in the_model_main_ at the_model_main.f:2426
> >>>>>>>> #12  0xAF887E in MAIN__ at main.f:3772
> >>>>>>>> Floating exception (core dumped)
> >>>>>>> 
> >>>>>>> Since it's failing on baudelaire with gfortran and -devel,
> >>>>>>> you should be able to reproduce the error.
> >>>>>>> 
> >>>>>>> Cheers,
> >>>>>>> Jean-Michel
> >>>>>>> 
> >>>>>>> On Wed, Dec 10, 2014 at 09:06:44AM -0500, Jean-Michel Campin wrote:
> >>>>>>>> Hi Martin,
> >>>>>>>> 
> >>>>>>>> global_ocean.cs32x15.seaice experiment is failing in few cases
> >>>>>>>> (pgi compiler, other compiler using -devel, also on uv100).
> >>>>>>>> Presently looking at this.
> >>>>>>>> 
> >>>>>>>> Cheers,
> >>>>>>>> Jean-Michel
> >>>>>>>> 
> >>>>>>>> On Tue, Dec 09, 2014 at 09:17:23AM -0500, Martin Losch wrote:
> >>>>>>>>> Update of /u/gcmpack/MITgcm/doc
> >>>>>>>>> In directory forge:/tmp/cvs-serv30680/doc
> >>>>>>>>> 
> >>>>>>>>> Modified Files:
> >>>>>>>>> 	tag-index 
> >>>>>>>>> Log Message:
> >>>>>>>>> document changes in verification/global_ocean.cs32x15/input.seaice
> >>>>>>>>> - add test for strong implicit coupling and restricted addtive Schwarz
> >>>>>>>>> methods for LSR
> >>>>>>>>> - update results/output.seaice.txt
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> _______________________________________________
> >>>>>>>>> MITgcm-cvs mailing list
> >>>>>>>>> MITgcm-cvs at mitgcm.org
> >>>>>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-cvs
> >>>>>>>> 
> >>>>>>>> _______________________________________________
> >>>>>>>> MITgcm-devel mailing list
> >>>>>>>> MITgcm-devel at mitgcm.org
> >>>>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> >>>>>>> 
> >>>>>>> _______________________________________________
> >>>>>>> MITgcm-devel mailing list
> >>>>>>> MITgcm-devel at mitgcm.org
> >>>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> >>>>>> 
> >>>>>> 
> >>>>>> _______________________________________________
> >>>>>> MITgcm-devel mailing list
> >>>>>> MITgcm-devel at mitgcm.org
> >>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> >>>>> 
> >>>>> 
> >>>>> _______________________________________________
> >>>>> MITgcm-devel mailing list
> >>>>> MITgcm-devel at mitgcm.org
> >>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> >>>> 
> >>>> _______________________________________________
> >>>> MITgcm-devel mailing list
> >>>> MITgcm-devel at mitgcm.org
> >>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> >>> 
> >>> 
> >>> _______________________________________________
> >>> MITgcm-devel mailing list
> >>> MITgcm-devel at mitgcm.org
> >>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> >> 
> >> _______________________________________________
> >> MITgcm-devel mailing list
> >> MITgcm-devel at mitgcm.org
> >> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> > 
> > _______________________________________________
> > MITgcm-devel mailing list
> > MITgcm-devel at mitgcm.org
> > http://mitgcm.org/mailman/listinfo/mitgcm-devel
> 
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel

More information about the MITgcm-devel mailing list