[MITgcm-support] flt package input problem

[Ryan Abernathey]

Emily,

Working the the float package is a bit of a black art, due to the lack of
documentation.

It sounds like your input .bin file is not being created / read correctly.
The third line of the output your run shows npart=2.5625 and max_npart=0.
This is not what you want: since you have 10 floats, you want both these
numbers to be 10.

It may be helpful to you to look at the python code we use to write float
input files for MITgcm:
https://github.com/rabernat/floater/blob/master/floater/generators.py#L193-L239

I think this code is pretty readable and explains what MITgcm expects to
find in the float input files. You also need to be sure that the data type
and endianness of the input binary file is correct.

Good luck! You will soon become a master of this black magic.

Best,
Ryan

On Thu, Apr 26, 2018 at 8:26 PM, Emily Zakem <ezakem at mit.edu> wrote:

> Hello,
>
>
> I'm trying to use the flt package, and getting errors reading in my binary
> input file. First, when I use the .bin file already in the flt_example
> verification folder, I can run the example fine (the physical set-up is of
> a channel running on one tile).
>
>
> #2: When I create my own binary file -- I run write_float.F (in "extra"
> folder, as is) to write the inital positions into flt_ini_pos.input, and
> then convert to big-endian (also in "extra" folder; I inferred that this
> was an intermediate step) to get the file flt_ini_pos.bin -- and then run
> this in the channel set-up, in the output, I get:
>
>
> (PID.TID 0000.0001) FLT_INIT_VARIA: reading Floats from: float_pos_426.bin
> (PID.TID 0000.0001)  MDS_READVEC_LOC: open file: float_pos_426.bin
> (PID.TID 0000.0001)  bi,bj=   0   0 , npart,max_npart= 1.26000000E+02
> 1.26000000E+02
> (PID.TID 0000.0001) FLT_INIT_VARIA: max npart=      126 , sum npart_tile=
>     126
>
> which reflects that there are 126 floats initialized in that .bin file.
> However, it introduces an error (STOP ABNORMAL END: S/R FLT_BILINEAR) and
> doesn't finish, though I don't particularly care about debugging this one--
> just included bc it may help narrow down the below.
>
>
> #3: My main problem: when I modify write_float to start with 10 floats,
> and create a binary file with indices for the eccov3 setup, and run offline
> (via my Darwin/gud setup), I get the following:
>
>
> (PID.TID 0001.0001) FLT_INIT_VARIA: reading Floats
> from: float_pos_gud_mod.bin
> (PID.TID 0001.0001)  MDS_READVEC_LOC: open file: float_pos_gud_mod.bin
> (PID.TID 0001.0001)  bi,bj=   0   0 , npart,max_npart= 2.56250000E+00
> 0.00000000E+00
> (PID.TID 0001.0001) FLT_INIT_VARIA: max npart=        0 , sum npart_tile=
>       2
>
> though the run finishes correctly. Here, only one of the 32 tiled files
> resulting from this gets any input: only float_trajectories.001.003.data gets
> larger than a blank file, and I can't read the output of this file. I CAN
> read the input .bin file in Matlab and it looks as it should, i.e., there
> are 9*11 items: 9 for each of the 10 floats, and the first 9 items have
> "10" and "10" in the 1st and 6th position as it should. (Though of course
> it was Matlab that created this file in the first place, but note how it
> sort of worked in #2.)
>
>
> I diagnosed whether flt_init_varia.F was trying to read a global file or
> an already tiled file, and it was global (and so this output is coming from
> lines ~120-123). I have also tried converting in Matlab using fwr
> ite(fid,var,'float64')instead of fwrite(fid,var,'real*8') to create the
> .bin file but got the same error. Is it an mpi issue?
>
>
> Thanks for any help! Happy to be pointed to a different workflow.
>
>
> -Emily
>
>
> PS. I skimmed through https://github.com/rabernat/floater/issues/20,
> which may be related, but didn't see anything directly helpful there.
>
>
> _______________________________________________
> 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/20180427/1275189a/attachment-0001.html>