[MITgcm-devel] [MITgcm-cvs] MITgcm/doc CVS Commit
Jean-Michel Campin
jmc at ocean.mit.edu
Thu Dec 11 11:35:36 EST 2014
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
More information about the MITgcm-devel
mailing list