[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