[MITgcm-devel] thsice+seaice question

[Martin Losch]

Hi Jean-Michel,

sorry for the late reply and thanks for looking into that so  
thoroughly (fortunately the advection code seems to work for Dimitris  
in spite of the problems that you discovered).

You are right about 1) but how should we fix that? Compute uTrans as  
uVel*dyG*drF*hFacW and divide by drF*hFacW at the end? I am  
embarrassed about that mistake.
2) you are right about uVel/vVel, but that does not seem so simple to  
me. It does not make sense to  generate 5D fields in seaice_advection.
3) again, you are probably right, I have not thought about that

about your comments:
a) the seaice masks seaiceMaskU/V are dynamic (computed from AREA).  
There for I would like to keep the maskS/W as they are the real  
"landmasks". k = 1 is set in seaice_advection and can easily be  
replayed by k = Nr if pressure coordinates are used, right?
b) I don't understand this comment: seaice_calc_rhs just borrows the  
name from gad_calc_rhs. It computes seaice_advection and diffusion  
for multidim advection schemes. Do you really think we need another  
subroutine seaice_diffusion that just calls gad_diff_x/y? When I  
wrote seaice_calc_rhs, I thought that was overkill.

Let's talk about the 1) and 2) on the phone, good idea. Can you call  
me? But I won't be around for too long today, let's say sometime  
between 2 and 3pm CET (8-9am EST?). Is that OK with you?

M.

On Jun 12, 2006, at 3:51 PM, Jean-Michel Campin wrote:

> 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
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel