[MITgcm-support] ECCOv4 Configurations: R-Star Coordinate Error with Modified Wind Forcing

Tue Feb 13 10:00:39 EST 2024

Hi Martin,

Thanks for the quick response and links. Yes, if you have time I’d like to proceed with modifying global_oce_llc90/input.ecmwf/data.seaice to the one that you’d recommend. The one from your idemix_test <https://github.com/mjlosch/MITgcm/blob/idemix_test_runs/idemix_test/llc90/input/data.seaice> minus all of the commented stuff maybe? Should not require any change to SEAICE_OPTIONS.h as far as I can see, so this wont affect the other tests in verification/global_oce_llc90. Seems to me that it would be great to have your recommended data.seaice config for llc90 in the verif_other repo; to be able to point people to it, know it is regularly tested & maintained, etc. Later on (e.g. this spring) I could run a full suite of ECCO diagnostics using it, send you feedback over at the GitHub repo, and we can always iterate on improving things further if needed. What do you think?

Best,
Gaël

> On Feb 13, 2024, at 1:29 AM, Martin Losch <Martin.Losch at awi.de> wrote:
> 
> Hi,
> 
> I do not run ECCO4-v2 exactly, but I run somethihng “Ecco-like” (i.e. llc90 with topography, initial conditions etc borrowed from ECCO4), where I modified a couple of parameter settings to my liking. I did not check the results as carefully as the ECCO4 solution is checked, and it is certainly not fit to observations, so that the solution will not have the degree of realism of any constrained ECCO solution. I have a branch for this with sample configuration here: https://github.com/mjlosch/MITgcm/tree/idemix_test_runs/idemix_test/llc90
> 
> This is meant for long integrations (I run this for >1200 years).
> 
> I have a different llc90 setup here: https://github.com/mjlosch/MITgcm/tree/myraslyboca/llc90 that I used for AD sensitivity simulations, but not optimisations. I am running this for order 20years. You’ll notice that it’s not so different from the other one. And then there’s another one here, also used for AD-simulations, but only in the Weddell Sea: https://github.com/mjlosch/MITgcm/tree/sochic/ws135x120
> 
> In all of these I use SEAICEpresReplFac = 0. and no diffusion of sea ice.
> 
> Since I do not run any optimisations with this, I am not sure how well this will work. @Gael, do you still think that it is worth modifying, e.g. verification/global_oce_llc90/input.ecmwf/data.seaice according to this? The current setup is not broken, it just uses sea ice flags that are differetn from what I would use, if I were to start a run with sea ice. I am sure that there were good reasons for the parameter settings.
> 
> Martin
> 
>> On 12. Feb 2024, at 17:24, Gael Forget <gforget at mit.edu> wrote:
>> 
>> Hi Martin,
>> 
>> What is your recommended data.seaice configuration for the ECCO4/LLC90 setup? 
>> 
>> It would be great if we could update one of the fwd + adjoint llc90 configuration (the input.ecmwf + input_ad.ecmwf) 
>> that we maintain and test daily in MITGcm to ensure that the ECCO4 configuration does not break
>> — updating to use the data.seaice that you recommend I mean. 
>> 
>> Would you mind opening a PR to that effect on the repo below?
>> 
>> https://github.com/MITgcm/verification_other/tree/master/global_oce_llc90
>> 
>> Once that’s done, we will be able to continue the discussion over on github and eventually I should be able to post an 
>> update to the production-ready ECCO4 setups that I maintain separately @ https://eccov4.readthedocs.io/en/latest/ 
>> 
>> Best,
>> Gaël
>> 
>>> On Feb 12, 2024, at 7:55 AM, Yohei Takano - BAS <yokano at bas.ac.uk> wrote:
>>> 
>>> Hi Martin,
>>> 
>>> Thank you for your advice, and yes, I am using the ECCOv4-r2 sea ice parameters (from Gael's
>>> setup). It could be the sea ice (thinking of what I wrote in the previous e-mail) so I will try setting
>>> the SEAICEpressReplFac = 0., and rerun the model from the beginning.
>>> 
>>> Regarding the sea ice related diffusivities, are you talking about this part in the parameters?
>>> 'SEAICEdiffKhHeff = 400., SEAICEdiffKhArea = 400., SEAICEdiffKhSnow = 400.,'. Just to confirm so
>>> should I also turn these off after turning on the SEAICEpressReplFac = 0.,? (please let me know if 
>>> I misunderstand something).
>>> 
>>> I am also curious about Gael's thoughts behind this setting.
>>> 
>>> Thank you again, I appreciate your input.
>>> 
>>> Regards,
>>> 
>>> Yohei
>>> 
>>> From: MITgcm-support <mitgcm-support-bounces at mitgcm.org <mailto:mitgcm-support-bounces at mitgcm.org>> on behalf of Martin Losch <Martin.Losch at awi.de <mailto:Martin.Losch at awi.de>>
>>> Sent: 12 February 2024 06:28
>>> To: MITgcm Support <mitgcm-support at mitgcm.org <mailto:mitgcm-support at mitgcm.org>>
>>> Subject: Re: [MITgcm-support] ECCOv4 Configurations: R-Star Coordinate Error with Modified Wind Forcing
>>>  
>>> You don't often get email from martin.losch at awi.de <mailto:martin.losch at awi.de>. Learn why this is important <https://aka.ms/LearnAboutSenderIdentification>	
>>> Hi Yohei,
>>> 
>>> if this is related to sea ice and if you are using the ECCOv4-r2 sea ice parameters (thi is what I found:https://github.com/gaelforget/ECCOv4/blob/master/input/data.seaice), then you could try to set 
>>>  SEAICEpressReplFac = 0.,
>>> and rerun (from the beginning). I have also tried to get rid of landpoints where wind forcing “pushes” ice into corners where it cannot escape. The eccov4-r2 data.seaice contains large (400) diffusivities for seaice variables, which probably were used to alleviate this problem (@Gael, correct me if I’m wrong). In my experience, this is no longer necessary with SEAICEpressReplFac = 0.,
>>> 
>>> Martin
>>> 
>>> 
>>> On 11. Feb 2024, at 18:00, Yohei Takano - BAS <yokano at bas.ac.uk> wrote:
>>> 
>>> Dear all,
>>> 
>>>    I am working on setting up a simulation with the ECCOv4-r2 configuration. The first step is to
>>> run (spin-up) the model with this configuration, except I detrended the atmospheric wind forcing
>>> (including zonal, meridional wind stress and surface wind speed). The model ran for a while (~ 10 years)
>>> but stops after that with "STOP ABNORMAL END: S/R CALC_R_STAR", which is related to the r* coordinate
>>> from my understanding. More specifically it is "too SMALL rStarFac[C,W,S]" and I see very small 
>>> hFactorC (from diagnostics) at a grid point near the continent (or perhaps sea ice related since it is in the Southern Ocean).
>>> 
>>>    The reason behind the error is this modified atmospheric wind forcing but I am a bit stuck on how I can
>>> fix this issue (i.e. how can I further modify the forcing to prevent this error) and would like to ask for advice on dealing with
>>> this issue. I saw comments in the previous question (in this list) lowering deltaT but I don't think that will solve the issue in this case. 
>>> 
>>>     rStarFac error actually happens quite often in my case modifying the atmospheric forcing and for those
>>> who have experienced similar challenge, I would like to ask for some advice how to deal with this.
>>> Thank you in advance.
>>> 
>>> Regards,
>>> 
>>> Yohei
>>> 
>>> 
>>> This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses.
>>> 
>>> _______________________________________________
>>> MITgcm-support mailing list
>>> MITgcm-support at mitgcm.org <mailto: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
>> 
>> _______________________________________________
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-support/attachments/20240213/5f699d27/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1859 bytes
Desc: not available
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-support/attachments/20240213/5f699d27/attachment-0001.p7s>