[MITgcm-devel] seaice dynamics parameters

Torge Martin torge.martin at gmail.com
Tue Jan 26 07:43:18 EST 2016


Hi Martin,

Sorry, I have not been following your solver implementations in detail.
Explained like this it makes sense to use the same namelist parameter for
different solvers. But then again, in the broad scheme of things, the
parameter has the same meaning for different solvers, doesn't it?

Torge




On Tue, Jan 26, 2016 at 1:31 PM, Martin Losch <Martin.Losch at awi.de> wrote:

> Hi Torge,
>
> in general, I think so too, but here, all three solver have an “outer”
> non-linear loop and an “inner” linear loop and the names would be quite
> transparent: Does it matter, whether I do n non-linear iterations and m
> linear iteration with on or the other solver? Same is true for the
> tolerances.
>
> Martin
>
> > On 26 Jan 2016, at 11:56, Torge Martin <torge.martin at gmail.com> wrote:
> >
> > Hi Martin,
> >
> > In principle I am in favor of any cleaning up. However, I also think
> that a namelist parameter, which has various meanings depending on other
> choices/settings (here: the solver selection), can lead to a lot of
> confusion and user mistakes. For users new to the field or model it would
> be much more helpful if each solver would have its own set of parameters
> and if these would be easily identifiable by their name already. Even if
> this means an extensive namelist.
> >
> > Just my opinion.
> > Cheers,
> > Torge
> >
> >
> > On Tue, Jan 26, 2016 at 11:31 AM, Martin Losch <Martin.Losch at awi.de>
> wrote:
> > Hi Jean-Michel, and other sea ice modellers,
> >
> > I am about to check in yet another (Picard) solver for sea ice dynamics,
> and I find the amount of different parameters that would ensue a little
> annoying. Since I am mostly responsible for them, I’d like to clean them up
> a little, and at the same time get rid of the old parameters for LSR.
> > 1. I would like to have only SEAICEnonLinIterMax and
> SEAICElinearIterMax. They would replace
> NPSEUDOTIMESTEPS/SEAICEnewtonIterMax and SOLV_MAX_ITER/SEAICEkrylovIterMax.
> > 2. I still need to be able to set separater maximum iterations for the
> preconditioner, SEAICEpreconIterMax, and also a nonlinear Iteration of the
> preconditioner, but that could be held fixed for now. Otherwise I would
> need to have SEAICEpreconLinearIterMax and SEAICEpreconNonLinIterMax (very
> long names)
> > 3. I would like to have tolerance for the nonlinear and the linear
> convergence. Currently we have SEAICEgamma_nonlin for JFNK and nothing for
> the LSR-Picard solver, and SEAICEgamma_lin_max, SEAICEgamma_lin_min, from
> which SEAICEgamma_lin is computed for JFNK, and there is LSR_ERROR for the
> LSR solver. I suggest to keep the three parameters of the JFNK solver and
> use SEAICEgamma_lin_max for the linear LSR tolerance (replace LSR_ERROR).
> >
> > The consequence is clear: fewer parameters, but the parameters have a
> slightly different meaing depending on which solver is used.
> >
> > For the changes: I could keep the old parameters in the namelist and do
> some fancy copying the keep the default behavior, or I could just retire
> them, because I believe that most people do not use them anyway (except for
> maybe LSR_ERROR?).
> >
> > What do you think? Do you have a better suggestion? Or is it a bad idea
> to use the same iteration/tolerance parameters for different solvers?
> >
> > Martin
> >
> >
> >
> > _______________________________________________
> > MITgcm-devel mailing list
> > MITgcm-devel at mitgcm.org
> > http://mitgcm.org/mailman/listinfo/mitgcm-devel
> >
> > _______________________________________________
> > MITgcm-devel mailing list
> > MITgcm-devel at mitgcm.org
> > http://mitgcm.org/mailman/listinfo/mitgcm-devel
>
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20160126/76c87b61/attachment-0001.htm>


More information about the MITgcm-devel mailing list