@amc2507 thanks for this. To me this already looks good, and we tested it in independent simulations where it definitely improved the stability of the run.

I would like to have a test that uses this code (or at least compiles it). These are the ocean experiments that compile EVP:

1. 1D_ocean_ice_column, lab_sea, offline_exf_seaice: forward and AD
2. global_ocean.cs32x15: only AD
3. seaice_itd, seaice_obcs : forward

Currently only lab_sea.hb87 actively tests EVP. We could compile the code in any of these but lab_sea, or we can actually test it, for which I would suggest modifying seaice_itd.lipscomp07. @jm-c what do you think?

@mjlosch I did not look at code changes, but have a basic question: why is this new option implemented at pre-processor level (CPP option) and not as a run-time switch ? This would make it easier to switch on/off and to include in a verification exp. secondary test.

I guess, because it's in a stupidly long loop and for performance reasons inserting more fortran if-statements may not be good? But I see that there are already two if-statements in the same loop, so maybe it's not so much of an issue?
@amc2507, what do you think about it? Having another runtime flag is a bit more complicated to introduce, but would still be possible, right?

@mjlosch Yeah using the CPP flag might be quicker, so the CPP flag was adapted in the beginning. But a run-time flag also sounds good if it's more convenient easier to use. Here is the run-time switch version of the code.

The new run-time flag is named as "SEAICEuseEVPreg", following the naming convention of other parameters. However, there has been a existing flag called "SEAICEuseEVPrev". I'm not sure whether it would cause confusion. Do you think if we should consider a more distinct name, such as "SEAICEuseEVPregularization", to better differentiate the two parameters?

Thanks for the update. I agree that the parameter name SEAICEuseEVPreg can easily be confused with SEAICEuseEVPrev. Also, there could be other regularisations in the future. We could have a more specific name (since denomU/V are regularised), e.g. something like SEAICEevpRegDenomUV.

Thanks for the updates. I'll review this later this week. In general, it would have been possible (and totally OK) to first discuss my suggestion before implementing it (i.e. it was not a "please-do-that"-suggestion, but rather a "what-do-we-think-about- this" suggestion), but now that you've already done it, it provides additional information, thanks.

Thanks for the updates. I'll review this later this week. In general, it would have been possible (and totally OK) to first discuss my suggestion before implementing it (i.e. it was not a "please-do-that"-suggestion, but rather a "what-do-we-think-about- this" suggestion), but now that you've already done it, it provides additional information, thanks.

Also thank you for the review and the further modification!