[MITgcm-devel] lab_sea sensitivity between platforms/compilers

Jean-Michel Campin jmc at ocean.mit.edu
Fri Jul 17 17:48:36 EDT 2009


Hi Martin,

Are you sure that this lab_sea "sensitivity" to compiler 
is not comming from the thermodynamics part ?
If I look at the results of ifort/ifc (or pgi) test, compared
with g77/gfortran, I still get a good results for 
global_ocean.cs32x15.icedyn (10 or 11 digits for cg2d)
but all the lab_sea are failing with only 5 digits.

I don't feel enough courage now to look in details in seaice_growth.F
but do we still apply instantaneous melting when SST > t_freeze ?
and do we still start from 1.m ice thickness everywhere 
in all those lab_sea test ?

Cheers,
Jean-Michel

On Fri, Jul 17, 2009 at 10:00:16PM +0200, Martin Losch wrote:
> Hi David (and others),
>
> your are right, SQRT(deltaC)/(SQRT(deltaC)+SEAICE_EPS) is order one or  
> zero (if deltaC=0), the correct expression would have been
>>> deltaCreg = SQRT(deltaC)+SEAICE_EPS
> to avoid divisions by zero.
> And consequently, when I do that, then the sensitivity returns.
> I found that when I fix zetaC to a small value (say 1.), the sensitivity 
> goes away, but since zetaC is a factor that scales everything, it just 
> means that the entire stress term is scaled down by orders of magnitude 
> (normally zetaC is order 1e10 and more), and the dynamics solver gives 
> nothing much. All that means, is that the dynamics solver is very 
> sensitive; and I still cannot figure out why (the same is true for LSR of 
> course), rats.
>
> Martin
>
> On Jul 17, 2009, at 4:32 PM, David Ferreira wrote:
>
>> Hi Martin,
>>> In the EVP code there is a line
>>>            deltaCreg = SQRT(MAX(deltaC,SEAICE_EPS_SQ))
>>> If you replace this line with
>>>            deltaCreg = SQRT(deltaC)/(SQRT(deltaC)+SEAICE_EPS)
>> It doesn't look like these 2 are equivalent.
>> Also, what about something like :
>>
>> IF deltaC >= SEAICE_EPS_SQ
>>   deltaCreg =SQRT(deltaC)
>> else
>>   deltaCreg = SEAICE_EPS
>> end
>>
>> it adds a "IF" but remove a "MAX" ... Not sure which one costs more
>> david
>>
>>
>>
>>> the number of matching digits increase from 5 to 12 (for cg2d) for  
>>> the lab_sea/input experiment, between a
>>> Linux csysl18 2.6.22.19-0.2-bigsmp #1 SMP 2008-12-18 10:17:03 +0100  
>>> i686 i686 i386
>>> gfortran (gcc version 4.2.1)
>>> and a
>>> Darwin csysm15.dmawi.de 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar  
>>> 31 22:52:17 PDT 2009; gfortran (gcc version 4.3.1)
>>>
>>> Both expressions give about the same results for large DeltaC, but  
>>> still I would like to find out what would be the correct replacement 
>>> of the SQRT(MAX(deltaC,SEAICE_EPS_SQ)). Here's what did *NOT* work:
>>>            deltaCreg = max(sqrt(deltaC),seaice_eps)
>>>            deltaCreg = sqrt(dmax1(deltaC,seaice_eps_sq))
>>>            deltaCreg = SQRT(MAX(DBLE(deltaC),DBLE(SEAICE_EPS_SQ)))
>>>            deltaCreg = SQRT(MAX(SEAICE_EPS_SQ,deltaC))
>>>
>>> Any idea, what might be going on? If I cannot solve this problem I  
>>> would suggest replacing this expression with the more stable one,  
>>> also in seaice_calc_viscosities (although it will change all  
>>> results).
>>>
>>> Martin
>>> _______________________________________________
>>> 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