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