<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi again Martin,</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Really sorry, I've hit a problem again. I hope I am clear in my explanation and please just let me know if not.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I've taken your suggestion of having all the forcing in one long T_air.bin file (expecting that with the correct values in data.cal's "startDate_1" and data.exf's "atempstartdate1", the model can figure out where to correctly begin reading the forcing from).
However, in a little test of this, I've produced an odd error. </div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Read on below for the details of that, but I'll cut to the chase of what I think the problem is - could the issue be that my data.cal "TheCalendar" is set to "model" which represents a 360-day year, but I've been handling my iteration-numbers, pickup files,
nIter0 etc. assuming a 365-day year? I did this because I started my study based on a previous study's work and model configuration. Their pickup files' iteration numbers made sense and corresponded to 250-year intervals when assuming a 365-day year (e.g.,
iter# * deltaT /60/60/24/365 gave pickup files at years 25000, 25250, 25500, 25750, etc.) but gave odd decimal-year values assuming a 360-day year. So, I carried on from their work and ran an additional ~10,000 years of model time (working under the 365day
assumption) to re-stabilise the model on my machine and now I'm beginning new experiments at model yr39500 (assuming a 365day year). I think I'm therefore having trouble with the time-varying forcing because of this 365day-vs-360day issue introduced by turning
on the data.cal package and using "TheCalendar = 'model' ".</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Please read on (if it helps) to see how my test below led me to this conclusion, otherwise I'd appreciate any advice as to how to make this jump from 365-day iteration-numbers in my spin-up simulations to now experiments that need to be run on a 360day year.
[E.g. I start from iteration number 86505000, which corresponds to a decimal year 40048.611 in this new 360day framework, which is odd and I don't know how to resolve. Perhaps I need to run another ~0.399 of a year of spin-up to get to an iteration number
that corresponds to a whole-number year in this new 360d framework? But I'm confused - does all my spin-up output to date (before this time-varying forcing work) truly represent 39500 years of total model run time or is it actually 40048.6111? (Note that my
deltaT is 14400 sec.)] </div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
My test was to make an 18-year-long "T_air.bin" forcing file and to run three separate 6-year-long simulations, to see whether the model would pick up from the correct place in T_air.bin each time. Below are my settings:</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
data</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
--> nIter0 = 86505000 (the last pickup file from my spin-up, represents year 39500 (iter86505000 * 14400sec (my deltaT) / 60/60/24/365 = yr39500 (although perhaps this use of 365days is wrong. Represents year 40048.61111... in 360d framework.)</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
--> nTimeSteps = 13140 ( = 6 years. 13140 steps *14400sec (deltaT) /60/60/24/365 = 18 years. Again perhaps 365days is wrong.)</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
data.cal</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
--> startDate_1 = 00010101 (for nIter0==0)</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
data.exf </div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
--> atempperiod = 31536000 (1 year in 365d framework)</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
--> atempstartdate1 = 395000101 <-- !! This gives error "Tried to read non-existent record (543)". Changing atempperiod to 31104000 (1yr in 360d framework) gives "Tried to read non-existent record (550)". And note, 550 and 543 are close to the offset between
nIter0=86505000 converted to years using 365d (39500yrs) vs 360d (40048.611) (diff = 548.6111). I therefore changed atempstartdate1 to = 400480101 as a test and the simulation ran without errors. (Though note, 40048.611 does not == 400480101. **Perhaps I
need to run my spin-up another 0.3999 of a year longer to get to an iteration number that corresponds to whole-number year under the new 360d framework?)</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Best,</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Maddie</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="appendonsend"></div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<hr style="display: inline-block; width: 98%;">
<div id="divRplyFwdMsg" dir="ltr"><span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"><b>From:</b> MITgcm-support <mitgcm-support-bounces@mitgcm.org> on behalf of mitgcm-support-request@mitgcm.org <mitgcm-support-request@mitgcm.org><br>
<b>Sent:</b> Wednesday, January 10, 2024 5:00 PM<br>
<b>To:</b> mitgcm-support@mitgcm.org <mitgcm-support@mitgcm.org><br>
<b>Subject:</b> MITgcm-support Digest, Vol 247, Issue 3</span>
<div> </div>
</div>
<div><span style="font-size: 11pt;">Send MITgcm-support mailing list submissions to<br>
mitgcm-support@mitgcm.org<br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support" id="OWA4601107e-4859-18e7-5a42-10870cd70308" class="OWAAutoLink" data-auth="NotApplicable" data-loopstyle="linkonly"><font color="red"><b>MailScanner has detected a possible fraud attempt from "mailman.mitgcm.org" claiming to be</b></font>
https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailman.mitgcm.org%2Fmailman%2Flistinfo%2Fmitgcm-support&data=05%7C02%7Cmgs23%40st-andrews.ac.uk%7C9dfd3518ce0e4493fdc208dc11fda29d%7Cf85626cb0da849d3aa5864ef678ef01a%7C0%7C0%7C638405029262699358%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C62000%7C%7C%7C&sdata=iF1gXMdqY5yBRVFrS5Qb4dVRd2K8Yzt2vW03batcPGQ%3D&reserved=0</a><br>
or, via email, send a message with subject or body 'help' to<br>
mitgcm-support-request@mitgcm.org<br>
<br>
You can reach the person managing the list at<br>
mitgcm-support-owner@mitgcm.org<br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of MITgcm-support digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Time-varying forcing and EXF package (Martin Losch)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 10 Jan 2024 10:31:40 +0100<br>
From: Martin Losch <Martin.Losch@awi.de><br>
To: MITgcm Support <mitgcm-support@mitgcm.org><br>
Subject: Re: [MITgcm-support] Time-varying forcing and EXF package<br>
Message-ID: <19D56223-1E94-42AF-833F-45CFBFA93AD1@awi.de><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi Madison,<br>
<br>
see anwers below:<br>
<br>
> On 10. Jan 2024, at 01:15, Madison Shankle <mgs23@st-andrews.ac.uk> wrote:<br>
><br>
> Hi Martin,<br>
><br>
> Thank you so much; that's clarified a lot of things for me. Can I ask a few follow-up questions? 3 small clarifying ones, and 1 further advice one (much appreciated).<br>
><br>
> (1) I misunderstood that data.cal's "startDate1" corresponded to nIter0=0, instead of just nIter0. Can I just check that that's correct? See the documentation that says: "Note that the first record read and used by the EXF package corresponds to the value
?startDate1? set in data.cal." (<a href="https://mitgcm.readthedocs.io/en/latest/phys_pkgs/exf.html#compile-time-options" id="OWAce06346f-e197-9553-8039-e5f2df5a9331" class="OWAAutoLink" data-auth="NotApplicable" data-loopstyle="linkonly"><font color="red"><b>MailScanner has detected a possible fraud attempt from "mitgcm.readthedocs.io" claiming to be</b></font> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmitgcm.readthedocs.io%2Fen%2Flatest%2Fphys_pkgs%2Fexf.html%23compile-time-options&data=05%7C02%7Cmgs23%40st-andrews.ac.uk%7C9dfd3518ce0e4493fdc208dc11fda29d%7Cf85626cb0da849d3aa5864ef678ef01a%7C0%7C0%7C638405029262699358%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C62000%7C%7C%7C&sdata=PMiwJQTX5KNMYTyh%2FZa9w4FgDwfZFnjUfXu2M%2FveGGg%3D&reserved=0</a>)<br>
<br>
<br>
Yes taht?s correct and I think that this statement is misleading and should be changed. If you have a good suggestion (based on your experience) for this paragraph, please feel free to contribute a pull request, and we can work on this together.<br>
<br>
><br>
> (2) I also missed that MITgcm interpolated between records provided in T_air.bin! Would that maybe explain why I was getting an error "lib-4016 : UNRECOVERABLE library error. A READ operation tried to read a nonexistent record (1002)." in a 1000yr long
run? (However, my T_air.bin file in that case was 1001 records long, so I'm still not sure what the problem is.<br>
I am not sure, what causes this. ?in theory?, it should have worked.<br>
<br>
><br>
> (3) Also didn't know about "repeatPeriod" in &EXF_NML_01 of data.exf - thank you!! This will likely do exactly what I want to do. So if I set this to 31104000000.0 (1000yr in seconds) and set atempperiod = 31104000.0 (360 days in seconds) and have all other
exf periods set as 0, does MITgcm know that that repeatPeriod parameter should only be applied to T_air.bin and won't throw an error? (And in this scenario, the T_air input file doesn't need an additional entry like you mentioned, correct?)<br>
<br>
Yes, that should work ( "repeatPeriod? can be found in the admittedly sparse documentation (o: ).<br>
<br>
><br>
> (4) Do you have any advice for running a simulation with time-varying T_air whose period is greater than 1000yr, given that I run simulations that last 1000 years, one after another, continuing on from pickup files. Say I want T_air with a periodicity of
10,000yr. And my simulation will be something like 20 or 40,000 years in total. I could make 10 separate T_air files to represent years 1-1000, 1001-2000, 2001-3000, and so on to 10,000 when the temp reaches its starting point again, and then just be very
careful to just use the correct T_air file with each simulation. But there must be an easier way than this? (However your method of making use of the "repeatPeriod" parameter seems perfect for my experiments where T_air varies with periods of 500yr and 1000yr.)<br>
pkg/exf was not really written with these long periods in mind. If possible, I would have all forcing in one file T_air, and then the model should be able to figure out, which record to read when with the correct startdate in data.cal and the correct atemp_startdate*
in data.exf. The start dates should not be changed during the integration and restarts.<br>
If a single T_air.bin is too big, you?d have to do it as you implied, being very careful, which file to use when (and modify the atemp_startdate* in data.exf accordingly. That sounds like a recipe for failure ?<br>
The model can deal with yearly fields (one file per year, say T_air.bin_2035, etc.) but this only works for years up to 9999, I guess. You?d have to modify the code to accomodate your long runs.<br>
<br>
Martin<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
MITgcm-support mailing list<br>
MITgcm-support@mitgcm.org<br>
<a href="http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support" id="OWA2d8503a0-90d7-188d-5f7b-c7baf71eed78" class="OWAAutoLink" data-auth="NotApplicable" data-loopstyle="linkonly"><font color="red"><b>MailScanner has detected a possible fraud attempt from "mailman.mitgcm.org" claiming to be</b></font> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailman.mitgcm.org%2Fmailman%2Flistinfo%2Fmitgcm-support&data=05%7C02%7Cmgs23%40st-andrews.ac.uk%7C9dfd3518ce0e4493fdc208dc11fda29d%7Cf85626cb0da849d3aa5864ef678ef01a%7C0%7C0%7C638405029262699358%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C62000%7C%7C%7C&sdata=iF1gXMdqY5yBRVFrS5Qb4dVRd2K8Yzt2vW03batcPGQ%3D&reserved=0</a><br>
<br>
<br>
------------------------------<br>
<br>
End of MITgcm-support Digest, Vol 247, Issue 3<br>
**********************************************</span></div>
</body>
</html>