[MITgcm-devel] seaice velocity mask
Martin Losch
Martin.Losch at awi.de
Mon Mar 29 05:00:22 EDT 2010
Gael,
I introduced the maskRHS-flag when I was starting to re-invent the LSR solver, because I had many problems and thought that this might be a solution. In the end Jinlun advised to not use this option. The reason is this: LSOR is a "global" solver, basically it's an iterative method to invert a sparse matrix. Therefore, as for cg2d, if you change something anywhere in the domain, it will affect the solution everywhere (maybe only slightly). The sea-ice dynamics are always solved for the entire domain. Where there is no ice (HEFF=AREA=0), the equations reduce to something very simple. Refering to eq. A.3 in the seaice-manuscript (where you found the sign error), with HEFF=0, Pmax=0 and thus zeta=eta=0, so that the entire stress term sigma = 0, further, going back to A.1, m=0 and all that's left is the balance in the air and ocean stresses, something like 0=cdwater*(uocean-uice) + tau_air, so that uice is more or less the same as the wind speed in these areas.
Clearly, you'd mask the velocity fields where AREA=0 in plots.
For the EVP solver (which is explicit in time), masking the rhs makes more sense (and should have a smaller impact on the solution) when you only update the velocities where there is ice. I think this is how it is done in CICE (that's where I stole the idea of masking the rhs), but in the MITgcm-EVP implementation, ice velocities are updated at every single grid point (also over land (o:, as everything else).
I think (and I am surprised I did not do this long ago), especially for adjoint computations, we shoud have a flag like ALLOW_maskRHS that is then put around the respective code-block in seaice_dynsolver, where the masks are updated. That would save a lot of store-directives.
Marrtin
On Mar 23, 2010, at 3:38 AM, gael forget wrote:
> Dear all,
>
> I have been looking at the seaice model and its adjoint recently, and my present focus
> is on the dynamics. I use the next generation ECCO grid (global lat-lon-cap, 1 degree
> resolution). I also run tests with the lab_sea verification experiment.
>
> My questions have to do with the masking of seaice velocities.
> Below I attach two figures that, for some arbitrary model time average,
> show the zonal ice velocity field (computed from SIuice/SIvice) with
> SEAICE_maskRHS=.FALSE. (fig 1) and with SEAICE_maskRHS=.TRUE.
> (fig 2). The two runs are otherwise similar, and use evp. The two runs
> have the "bug fix" that I checked in earlier today.
>
> As shown by fig 1, if I do not use SEAICE_maskRHS, there are "virtual ice velocities"
> (e.g. in the tropics) in the diangostic fields that look silly. With regard to diagnostics (at least)
> I would argue that "virtual ice velocities" velocities should be masked out. For sure I would not
> show a field like fig. 1 to a user and call it an estimate of ice velocities. Any objection?
>
> Yet switching SEAICE_maskRHS to .TRUE. affects not only the diagnostics
> but also the model solution (not shown) which is puzzling (suspicious?).
> My guess is that the "virtual ice velocities" affect the model solution
> through the computation of strain rates at the open ocean/ice boundary.
>
> In that respect, my (likely naive) assumption would have been that SEAICE_maskRHS=.TRUE.
> would be default option... but Dimitris mentioned to me that it is never used and that it may be
> wrong/unsafe. Should I avoid using it? If this is the case, shouldn't the option be removed (or fixed)?
> If we do need those virtual velocities during the model computation, then I would appreciate
> some explanations. Why is it so? What are they? Are they meant to be a first guess somehow?
> Do they imply an adequate boundary condition at the open ocean ice edge somehow?
>
> Thanks in advance,
> Gael
>
>
>
> <spin3y_2010march16_evp_25620.jpg>
> <spin3y_2010march21_evp_25620.jpg>
>
>
>
>
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel
More information about the MITgcm-devel
mailing list