No subject

Problem: all but 2 experiments:
global_ocean.cs32x15/input.seaice/data.seaice: SEAICEadvScheme       = 77,
global_ocean.cs32x15/input_ad.seaice/data.seaice: SEAICEadvScheme       = 30,
use the default advection scheme and only one uses
lab_sea/input.salt_plume/data.seaice: SEAICEuseFluxForm  = .TRUE.,
so that all verification experiments will be broken by option(2), so maybe start with option (3).

ocean advection schemes: I can have a look at this, but I cannot promise anything (given my current attention span).

Martin
On Feb 3, 2011, at 2:18 AM, Gael Forget wrote:

> Hi Martin,
> 
> I attach a hacked version of seaice_diffusion.F that fixes that issue.
> I successfully closed budgets with seaice advection (30) and diffusion (k=200.) turned on 
> (in a slightly different setup that the one I posted on faulks -- let me know if you want it).
> The problem was that "*MIN( _dxF(I,J,bi,bj), _dyF(I,J,bi,bj))" is not at velocity points.
> A proper fix could be to average this term to velocity points I think. Or would it be a good time 
> to have seaice_diffusion.F use a proper diffusion coefficient rather than the infamous DIFF1?
> 
> For the rest my statement of 'no limiter in ocean (with 50 levels) => loss of O(10) digits in ice budgets'
> actually refers to the choice of advection schemes in the ocean (not for the ice). My suspicion is that one 
> a non-conservative term in seaice_growth.F gets activated upon switching the ocean advection 
> scheme from 77 (or 33) to 30 (for the setup I posted on faulks). Supposedly it is a term that 
> is conditioned by the ocean surface temperature (getting below freezing point?). Since you are in 
> the lead regarding this thread, would you be willing to narrow it down and find a fix for this one?
> 
> Cheers,
> Gael