[MITgcm-support] float package datatypes

[Ryan Abernathey]

I'm not sure I have a clean and robust solution, because I don't want to
rewrite the float exchange code. Right now that code just exchanges _RL
type arrays.

I have successfully switched the datatype on npart to INT in my code, while
leaving the exchange code untouched. It seems to work, since I am on a
64-bit system and the INTs can be safely cast to FLT. But I doubt this
would work on a 32-bit system.

-Ryan

On Wed, Mar 29, 2017 at 4:29 PM, Jean-Michel Campin <jmc at mit.edu> wrote:

> Hi Ryan,
>
> If I understand correctly, the problem is only in 32-bits output files
> (not in pickup files), right ?
>
> If you have a clean and robust (across platform & compiler) alternative
> solution that is not much slower than switching to 64-bits output files
> (this obviously depend on disk system and may vary a lot)
> and handle nicely the byte-swap thing, then we could add this to pkg/flt
> as an alternative option.
>
> Cheers,
> Jean-Michel
>
> On Thu, Mar 16, 2017 at 12:41:13PM -0400, Ryan Abernathey wrote:
> > Hello,
> >
> > We are using the MITgcm float package to do particle advection of ~50
> > million floats. We have hit a problem related to the "npart" variable:
> >
> > >From FLT.h:
> > C     npart       :: float identifier
> >       _RL     npart(max_npart_tile,nSx,nSy)
> >
> > npart is a crucial variable, since it is used to identify the floats both
> > internally and in pre / postprocessing scripts.
> >
> > The problem is that npart is a floating point data type, but it is
> treated
> > logically as an integer. A 32-bit float can only accurately represent
> > integers up to 16777215
> > (
> > http://cottonvibes.blogspot.com/2010/08/32bit-floats-
> integer-accuracy-and.html
> > )
> > This causes big problems when there are more than this number of floats
> to
> > track.
> >
> > We could use 64 bit precision, but that would double our data volume,
> which
> > is already huge.
> >
> > I am curious if there is some historical reason why a floating point type
> > was used here.
> >
> > Would anyone object to me changing this to integer? It would likely break
> > some pre / post processing code.
> >
> > -Ryan
>
> > _______________________________________________
> > MITgcm-support mailing list
> > MITgcm-support at mitgcm.org
> > http://mitgcm.org/mailman/listinfo/mitgcm-support
>
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20170329/dc394566/attachment.htm>