[MITgcm-devel] thsice+seaice question

Jean-Michel Campin jmc at ocean.mit.edu
Mon Jun 12 09:51:28 EDT 2006


Hi Martin,

I discover few problems when trying to switch on seaiceDynamics
in the thsice+exf+seaice CS set-up:
1) I think there is a problem with all the DST advection scheme
 (and the problem is present also with seaice only).
 uCFL is wrong because uFld is recomputed from uTrans using the
 wrong formula (/drF and / hFac).
2) Also, in seaice_advection.F, even if uVel is not used inside all the
 GAD_*_ADV_X S/R, I don't like uVel (2D,4.indices) being passed
 to GAD_*_ADV_X where this argument is declared 3.D (Nr) with 5 indices.
3) In the set up you gave me, we have z*+realFreshWater
 and thsice use the sea-ice loading. But in seaice dynamics,
 I saw a gradient of g*etaN in the forcing, which sould be replaced
 by grad.(g*etaN+iceLoading), right ?

Can we talk on the phone before you start to fix 1&2 ?
I think it could be worth to re-write some of the DST interface
so that it can be easier to use in a different context, e.g. for sea-ice.

I have also 2 comments (more about details):
a) I have seen some ice-mask, even for velocity @ W & S faces for u & v,
 being defined, but inside the advection, maskW & maskS and k index
 is still used.
 Do you think it could be possible to make the sea-ice advection
 not to rely on k=1 (thinking also of using pressure coordinate) ?
b) I think the way the tracer (T & S & ptracer) RHS is coded is not
 the best code, with advection sometimes computed separately,
 and sometime within gad_cal_rhs, with fVert(:,:,2) and so on.
 And I would prefer that sea-ice do not follow the same complicated way,
 if there is no good reason.
 Why not to get rid of SEAICE_calc_rhs, and put the diffusion
 stuff in seaice_diffusion ?

See you,
Jean-Michel



More information about the MITgcm-devel mailing list