[MITgcm-support] internal wave verification: problem with output for delX

Thu Apr 8 03:05:34 EDT 2021

Hi Martin,

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.
The python code is attached in case it interests you or anyone with similar
problems.
Best
Jeremy

On Wed, 7 Apr 2021 at 12:36, Jeremy Miller <jeremysharonmiller at gmail.com>
wrote:

> Dear Martin,
>
> 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
>
> SOLUTION IS HEADING OUT OF BOUNDS: tMin,tMax= -2.113E+20  5.090E+20
>   exceeds allowed range (monSolutionMaxRange=  1.000E+03)
> MON_SOLUTION: STOPPING CALCULATION at Iter=        10
> S/R ALL_PROC_DIE: ending the run
> STOP ABNORMAL END: S/R MON_SOLUTION, stops due to EXTREME Pot.Temp
>
> Best
>
> Jeremy
>
> On Wed, 7 Apr 2021 at 11:57, Jeremy Miller <jeremysharonmiller at gmail.com>
> wrote:
>
>> Hi Martin,
>>
>> Do you mean run >>> cksum delVar T.init topog.slope in ther terminal
>> window?
>> This is what I got from the files that I generated:
>>
>> 1850524193 480 delXvar
>> 2935439697 9600 T.init
>> 1755756548 480 topog.slope
>>
>> This is what I got from the clean copy of MITgcm:
>>
>> 1850524193 480 delXvar
>> 14523600 9600 T.init
>> 638984401 480 topog.slope
>>
>> 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?
>> Best
>> Jeremy
>>
>>
>>
>> On Wed, 7 Apr 2021 at 11:33, Martin Losch <Martin.Losch at awi.de> wrote:
>>
>>> Hi Jeremy,
>>>
>>> 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).
>>>
>>> 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.
>>> >>> cksum delVar T.init topog.slope
>>>  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).
>>>
>>> Martin
>>>
>>> > On 7. Apr 2021, at 08:26, Jeremy Miller <jeremysharonmiller at gmail.com>
>>> wrote:
>>> >
>>> > Hi Martin,
>>> > Thanks for your reply. Your suggestion did cure the problem of all the
>>> delX values being read in as '0'. Thanks.
>>> > But now running the code (using ./mitgcmuv > output.txt ) gives me the
>>> error
>>> >
>>> > SOLUTION IS HEADING OUT OF BOUNDS: tMin,tMax= -7.361E+22  5.849E+22
>>> >   exceeds allowed range (monSolutionMaxRange=  1.000E+03)
>>> > MON_SOLUTION: STOPPING CALCULATION at Iter=        10
>>> > S/R ALL_PROC_DIE: ending the run
>>> > STOP ABNORMAL END: S/R MON_SOLUTION, stops due to EXTREME Pot.Temp
>>> >
>>> > I have attached the python script used to generate the data again.
>>> >
>>> > Best
>>> > Jeremy
>>> >
>>> > On Tue, 6 Apr 2021 at 14:13, Martin Losch <Martin.Losch at awi.de> wrote:
>>> > Hi Jeremy,
>>> >
>>> > 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.
>>> > (alternatively you could set readBinaryPrec=32,)
>>> >
>>> > Martin
>>> >
>>> > > On 6. Apr 2021, at 09:06, Jeremy Miller <
>>> jeremysharonmiller at gmail.com> wrote:
>>> > >
>>> > > Dear MITgcm support forum,
>>> > >
>>> > > 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 .
>>> > > After running genedata_IWs.py and subsequently running ./mitgcmuv >
>>> output.txt, I receive the following message in the terminal window:
>>> > >
>>> > > S/R LOAD_GRID_SPACING: delX(i=   31)=  0.00000000E+00 : MUST BE >0
>>> > > S/R LOAD_GRID_SPACING: delX(i=   32)=  0.00000000E+00 : MUST BE >0
>>> > > .
>>> > > .
>>> > > .
>>> > >
>>> > > S/R LOAD_GRID_SPACING: delX(i=   60)=  0.00000000E+00 : MUST BE >0
>>> > > S/R LOAD_GRID_SPACING: found   30 invalid delX values
>>> > >
>>> > > 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.
>>> > > Best
>>> > > Jeremy Miller
>>> > >
>>> > >
>>> > > <gendata_IWs.py>_______________________________________________
>>> > > 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
>>> > <gendata_IWs.py>_______________________________________________
>>> > 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/20210408/f2d85d05/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gendata_IWs_1.py
Type: text/x-python
Size: 2869 bytes
Desc: not available
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-support/attachments/20210408/f2d85d05/attachment-0001.py>