<div dir="ltr">Hi Martin,<div><br></div><div>I resolved that problem. The problem was the ordering of indices as you said, plus a missing line of code to make the slop flat at the end of the x range that I filled in.</div><div>The python code is attached in case it interests you or anyone with similar problems.</div><div>Best</div><div>Jeremy</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 7 Apr 2021 at 12:36, Jeremy Miller <<a href="mailto:jeremysharonmiller@gmail.com">jeremysharonmiller@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Dear Martin,<div><br></div><div>I have changed the python script like you suggested with the indices reversed ( it is attached in gendata_IWs_1.py). The numbers from  >>> cksum delVar T.init topog.slope still do not match, and when I run the code I now get the error</div><div><br></div><div>SOLUTION IS HEADING OUT OF BOUNDS: tMin,tMax= -2.113E+20  5.090E+20<br>  exceeds allowed range (monSolutionMaxRange=  1.000E+03)<br>MON_SOLUTION: STOPPING CALCULATION at Iter=        10<br>S/R ALL_PROC_DIE: ending the run<br>STOP ABNORMAL END: S/R MON_SOLUTION, stops due to EXTREME Pot.Temp<br></div><div><br></div><div>Best</div><div><br></div><div>Jeremy</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 7 Apr 2021 at 11:57, Jeremy Miller <<a href="mailto:jeremysharonmiller@gmail.com" target="_blank">jeremysharonmiller@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Martin,<div><br></div><div>Do you mean run >>> cksum delVar T.init topog.slope in ther terminal window?</div><div>This is what I got from the files that I generated:</div><div><br></div><div>1850524193 480 delXvar<br>2935439697 9600 T.init<br>1755756548 480 topog.slope<br></div><div><br></div><div>This is what I got from the clean copy of MITgcm:</div><div><br></div><div>1850524193 480 delXvar<br>14523600 9600 T.init<br>638984401 480 topog.slope<br></div><div><br></div><div>Looking at the script I sent you in the last email, following your comment about the order of indices, do they need to be reversed?</div><div>Best</div><div>Jeremy</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 7 Apr 2021 at 11:33, Martin Losch <<a href="mailto:Martin.Losch@awi.de" target="_blank">Martin.Losch@awi.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Jeremy,<br>
<br>
the experiment runs with the original input files for more than 10 timesteps (by co-incidence I had just run it for 1000 time steps before I read your first email).<br>
<br>
To debug this, I would check out a clean copy of MITgcm and compare the original input files, by the ones that you generated with you python script. The should be exactly the same (e.g. <br>
>>> cksum delVar T.init topog.slope<br>
 should give exactly the same numbers). If they don’t then you need to fix your python script. Keep in mind that the order of dimensions in python is probably different from the ones in the genmake.m script. So where in matlab your would woud define a field as ones(nx,ny,nz), you would in python define it as np.ones((nz,ny,nx)), etc. see verification/seaice_itd/input/gendata.py for an example (and also for an example of a less elegant solution of writing a big endian file, I like your “astype().tofile()” is much better).<br>
<br>
Martin<br>
<br>
> On 7. Apr 2021, at 08:26, Jeremy Miller <<a href="mailto:jeremysharonmiller@gmail.com" target="_blank">jeremysharonmiller@gmail.com</a>> wrote:<br>
> <br>
> Hi Martin,<br>
> Thanks for your reply. Your suggestion did cure the problem of all the delX values being read in as '0'. Thanks.<br>
> But now running the code (using ./mitgcmuv > output.txt ) gives me the error<br>
> <br>
> SOLUTION IS HEADING OUT OF BOUNDS: tMin,tMax= -7.361E+22  5.849E+22<br>
>   exceeds allowed range (monSolutionMaxRange=  1.000E+03)<br>
> MON_SOLUTION: STOPPING CALCULATION at Iter=        10<br>
> S/R ALL_PROC_DIE: ending the run<br>
> STOP ABNORMAL END: S/R MON_SOLUTION, stops due to EXTREME Pot.Temp<br>
> <br>
> I have attached the python script used to generate the data again.<br>
> <br>
> Best<br>
> Jeremy<br>
> <br>
> On Tue, 6 Apr 2021 at 14:13, Martin Losch <<a href="mailto:Martin.Losch@awi.de" target="_blank">Martin.Losch@awi.de</a>> wrote:<br>
> Hi Jeremy,<br>
> <br>
> I believe that this experiment expects double precision input (in data: readBinaryPrec=64,), but in your script you write everything as “>f4”. Probably changing to “>f8” will fix the problem.<br>
> (alternatively you could set readBinaryPrec=32,)<br>
> <br>
> Martin<br>
> <br>
> > On 6. Apr 2021, at 09:06, Jeremy Miller <<a href="mailto:jeremysharonmiller@gmail.com" target="_blank">jeremysharonmiller@gmail.com</a>> wrote:<br>
> > <br>
> > Dear MITgcm support forum,<br>
> > <br>
> > I am attempting to run the internal wave verification. Being a python user I transcribed gendata.m to python. The script I am using is attached here in the file gendata_IWs.py .<br>
> > After running genedata_IWs.py and subsequently running ./mitgcmuv > output.txt, I receive the following message in the terminal window:<br>
> > <br>
> > S/R LOAD_GRID_SPACING: delX(i=   31)=  0.00000000E+00 : MUST BE >0<br>
> > S/R LOAD_GRID_SPACING: delX(i=   32)=  0.00000000E+00 : MUST BE >0<br>
> > .<br>
> > .<br>
> > .<br>
> > <br>
> > S/R LOAD_GRID_SPACING: delX(i=   60)=  0.00000000E+00 : MUST BE >0<br>
> > S/R LOAD_GRID_SPACING: found   30 invalid delX values<br>
> > <br>
> > I have read back in the delXVar file that I output and checked that the values do match the values in the original array dx.<br>
> > Best<br>
> > Jeremy Miller<br>
> > <br>
> > <br>
> > <gendata_IWs.py>_______________________________________________<br>
> > MITgcm-support mailing list<br>
> > <a href="mailto:MITgcm-support@mitgcm.org" target="_blank">MITgcm-support@mitgcm.org</a><br>
> > <a href="http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support" rel="noreferrer" target="_blank">http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support</a><br>
> <br>
> _______________________________________________<br>
> MITgcm-support mailing list<br>
> <a href="mailto:MITgcm-support@mitgcm.org" target="_blank">MITgcm-support@mitgcm.org</a><br>
> <a href="http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support" rel="noreferrer" target="_blank">http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support</a><br>
> <gendata_IWs.py>_______________________________________________<br>
> MITgcm-support mailing list<br>
> <a href="mailto:MITgcm-support@mitgcm.org" target="_blank">MITgcm-support@mitgcm.org</a><br>
> <a href="http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support" rel="noreferrer" target="_blank">http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support</a><br>
<br>
_______________________________________________<br>
MITgcm-support mailing list<br>
<a href="mailto:MITgcm-support@mitgcm.org" target="_blank">MITgcm-support@mitgcm.org</a><br>
<a href="http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support" rel="noreferrer" target="_blank">http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>