[MITgcm-support] float package datatypes

[Jean-Michel Campin]

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