[MITgcm-devel] (not so) funny things happen in seaice_lsr and pickups

[Martin Losch]

Hi Jean-Michel,

now I have tested restarts in lab_sea, I have attached 2 std-outfiles  
for each experiment for you to check (I might not look for the correct  
numbers, output.0-10 is the full integration, output.5-10 from pickup  
at nIter0=5)

1. 1cpunompi.tgz, current code, 1CPU, no MPI, restart is OK, even  
Sum(rhs) of cg2d
2. 1cpumpi.tgz, current code, 1CPU, w/ MPI,  Sum(rhs) of cg2d is not  
correct, everything else seems OK
3. 2cpu.tgz, current code, 2CPU, w/ MPI, Sum(rhs) of cg2d is not  
correct, everything else seems OK
4. 2cpufix.tgz, current code with minor change (u(3)=u(1) includes  
overlaps) 2CPU, w/MPI, restart is OK, even for Sum(rhs), but result is  
different

So basically the restart works, except that the behavior of Sum(rhs)  
is not clear to me, and I don't understand, why the "fix" in the loop  
ranges changes the result and fixes the Sum(rhs) numbers. Any comments?

In my Arctic configuration (however will all packages including seaice  
turned off) I find this (output.4 is full 4 steps from a pickup at  
niter0=368208, output.2 is two steps from a pickup at 368210:
sx8::crash> grep dynstat_theta_mean output.2
(PID.TID 0000.0001) %MON dynstat_theta_mean           =    
1.7113470942954E+00
(PID.TID 0000.0001) %MON dynstat_theta_mean           =    
1.7113515012346E+00
(PID.TID 0000.0001) %MON dynstat_theta_mean           =    
1.7113592136171E+00
sx8::crash> grep dynstat_theta_mean output.4 | tail -3
(PID.TID 0000.0001) %MON dynstat_theta_mean           =    
1.7113470942954E+00
(PID.TID 0000.0001) %MON dynstat_theta_mean           =    
1.7113515012996E+00
(PID.TID 0000.0001) %MON dynstat_theta_mean           =    
1.7113592137131E+00
sx8::crash>
sx8::crash> grep cg2d: output.2
cg2d: Sum(rhs),rhsMax =  -1.04063452429415E+04  1.87024026069452E+00
cg2d: Sum(rhs),rhsMax =  -1.08304200461241E+04  1.79700912294982E+00
sx8::crash> grep cg2d: output.4
cg2d: Sum(rhs),rhsMax =  -1.03691133125411E+04  1.87695591610873E+00
cg2d: Sum(rhs),rhsMax =  -8.68378231485560E+03  2.24123163741810E+00
cg2d: Sum(rhs),rhsMax =  -1.04063454274639E+04  1.87024026069452E+00
cg2d: Sum(rhs),rhsMax =  -1.08304200914664E+04  1.79700914731815E+00

To me, it looks like the pickup itself is OK, but then the model  
diverges in the first time step. OK, I then redid this test after  
change a couple of parameters, and look and behold the problem goes  
away when I do not rotate the coordinates (everything else is turned  
off, so exf cannot be blamed this time). That would mean that before a  
pickup is read, some grid parameters are already wrong, but I cannot  
see any difference in the stuff that's written to STDOUT. Also I do  
not see, why the grid parameters (including the rotation, which is  
completely local) can be different between two different restarts? Any  
idea?

Martin



-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1cpumpi.tgz
Type: application/octet-stream
Size: 76058 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20090227/621ab3a8/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1cpunompi.tgz
Type: application/octet-stream
Size: 75743 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20090227/621ab3a8/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2cpu.tgz
Type: application/octet-stream
Size: 80800 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20090227/621ab3a8/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2cpufix.tgz
Type: application/octet-stream
Size: 81177 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20090227/621ab3a8/attachment-0003.obj>