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

Wed Feb 14 07:40:04 EST 2024

Hi Martin, all,

   Thank you again for the support and glad to see discussion going on.
Just to update, I reran the model with sea ice options changed, the model still crashes with r* coordinate
error so must be because of the atmospheric forcing file I modified. I will continue on testing with further checking
the forcing file but great to know the sea ice options.

    I will post on this mailing list once I fixed the problem.

Regards,

Yohei

________________________________
From: MITgcm-support <mitgcm-support-bounces at mitgcm.org> on behalf of Martin Losch <Martin.Losch at awi.de>
Sent: 13 February 2024 17:31
To: MITgcm Support <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. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Sure, I’ll open a PR later this week.

Martin

On 13. Feb 2024, at 16:00, Gael Forget <gforget at mit.edu> wrote:

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

_______________________________________________
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/20240214/034c172f/attachment-0001.html>