[MITgcm-support] Ice not Moving when Resolution is Very High

[Martin Losch]

Hi again,

after many off-list emails and numerical experiments, it turns out that issue that Senja describes is related to poor convergence of the linear solver (the LSR solver) at high resolution (=small dx). Convergence is always an issue at high resolution (see Lemieux et al 2009, 2010) for any solver, but for the LSR solver in free drift it is quite severe, as the solution method is an restricted additive Schwartz (RAS) method, where in each linear iteration the solution is computed on a tile (subdomain) and then concatenated globally. This can lead to smaller drift along tile edges, as the solution is not converged yet. In the free drift case, it mattered whether your ice flow is completely contained within a tile or touches the tile boundary. In the latter case, it takes much longer for the ice to move, because it is “held up” by the tile boundary, not nice. Most of the time, however, ice simulations are in the pack and this will not be visible. Plus, most of the time, the grid spacing will be order of kilometers (not meters) so that this problem will probably not appear.

How to overcome this, if it appears? Here are some options:

- If you want to keep using LSR (which I recommend, still, in spite of these issues) the following flags:
#define SEAICE_ALLOW_FREEDRIFT (in SEAICE_OPTIONS.h)
and in data.seaice
 LSR_mixIniGuess = 2,
will generate a first guess for the LSR solver that is already close the free drift solution. Disadvantage: the first guess is based on weights that have been computed from global residuals of the momemtum equations, so that this may not be the optimal solution.
- use mEVP or aEVP (see documentation for details, please do not use the original EVP)
- I cannot recommend using the JFNK or KRYLOV solver, because they are just too expensive and won’t converge at high resolution either. They are, however, properly parallelized and do not suffer from RAS-problem of the LSR solver.

I will open an issue on Github and maybe we can find a better solution to this.

Martin

> On 21. Jan 2020, at 08:45, Martin Losch <Martin.Losch at awi.de> wrote:
> 
> Hi Senja,
> 
> this is strange, and I’d like to have closer look at this. Do you think it is possible that you provide the full configuration to me, i.e. code and “input” directory with a case that works and a case that doesn’t.
> I would be really concerned if the implicit Picard solver with LSR turns out to be so unpredictable.
> 
> Martin
> 
>> On 17. Jan 2020, at 22:25, Senja Walberg <senja.w at gmail.com> wrote:
>> 
>> Hello,
>> 
>> I figured out that my issue was somehow related to the LSOR solver. It's not clear to me why that's the case, but switching to EVP fixed the issues I was having.
>> 
>> Oddly, with the LSOR solver things behaved wildly differently depending on the initial configuration of ice-- with a relatively small, single chunk, no motion was observed, but when I added numerous other unconnected chunks to the domain it would move, even when delx was small.
>> 
>> Either way, my solution is simply not to use it, so I believe this problem can be done with.
>> 
>> Regards,
>> Senja
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
> 
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support