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

Martin Losch Martin.Losch at awi.de
Fri Dec 12 10:33:55 EST 2014 

OK, I thought so. Then it’s probably best to initialize BU/V=1 and A and C to 0 somewhere in the beginning. I’ll probably do that sometime soon. Thanks for your help,

Martin

On Dec 12, 2014, at 2:58 PM, Jean-Michel Campin <jmc at ocean.mit.edu> wrote:

> 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
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel

More information about the MITgcm-devel mailing list