No subject


Thu Dec 8 10:16:28 EST 2016


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

--001a11378912b97872054adbbae8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello,<div><br></div><div>We are using the MITgcm float pa=
ckage to do particle advection of ~50 million floats. We have hit a problem=
 related to the &quot;npart&quot; variable:</div><div><br></div><div>From F=
LT.h:</div><div>C =C2=A0 =C2=A0 npart =C2=A0 =C2=A0 =C2=A0 :: float identif=
ier<br></div><div>=C2=A0 =C2=A0 =C2=A0 _RL =C2=A0 =C2=A0 npart(max_npart_ti=
le,nSx,nSy)<br></div><div><br></div><div>npart is a crucial variable, since=
 it is used to identify the floats both internally and in pre / postprocess=
ing scripts.</div><div><br></div><div>The problem is that npart is a floati=
ng point data type, but it is treated logically as an integer. A 32-bit flo=
at can only accurately represent integers up to 16777215</div><div>(<a href=
=3D"http://cottonvibes.blogspot.com/2010/08/32bit-floats-integer-accuracy-a=
nd.html">http://cottonvibes.blogspot.com/2010/08/32bit-floats-integer-accur=
acy-and.html</a>)<br></div><div>This causes big problems when there are mor=
e than this number of floats to track.</div><div><br></div><div>We could us=
e 64 bit precision, but that would double our data volume, which is already=
 huge.</div><div><br></div><div>I am curious if there is some historical re=
ason why a floating point type was used here.</div><div><br></div><div>Woul=
d anyone object to me changing this to integer? It would likely break some =
pre / post processing code.</div><div><br></div><div>-Ryan=C2=A0<br></div><=
/div>

--001a11378912b97872054adbbae8--



More information about the MITgcm-support mailing list