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

[Jeremy Miller]

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/20210407/1dc3c36a/attachment.html>