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

Martin Losch Martin.Losch at awi.de
Fri Dec 12 03:52:42 EST 2014 

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

More information about the MITgcm-devel mailing list