[yt-dev] Unitrefactor versus old-school units

[Nathan Goldbaum]

Hi all,

I've spent a bit of time today comparing the current tip of 3.0 to the
current unitrefactor, in an attempt to see whether field accesses on
data objects will return answers that are consistent with what we were
returning before.

The specific comparison I'm doing is based on the IsolatedGalaxy
dataset.  This dataset has a large number of on-disk fields and is a
good exercise of yt's field detection and derived fields machinery.
I'm looking at whether field accesses on data objects return results
that are identical to the results we get in the current 3.0 tip.

The full testing script has been pasted here:
http://paste.yt-project.org/show/4250

The results (just what the script printed to my terminal) are pasted
here: http://paste.yt-project.org/show/4251

There appear to be three things that happened in this test:

1. The field access returned bitwise identical results
2. The field access returned results that are slightly different (~1e-6 level).
3. The field access returned results that are order-unity different.

Obviously the first case isn't an issue.  I believe all instances of
the third case are due to comparing quantities that have different
units (for example, particle_position_[x,y,z] used to return data in
code units, but now does so in CGS).

Case 2 is a little bit more involved and I'm not sure what to do about
it in general -- thus this message ;)

I'll take the density field as an example to illustrate what is happening.

In the parameter file for this dataset, I see the following:

MassUnits = 8.11471e+43
DensityUnits    = 2.76112e-30
TimeUnits    = 2.32946e+18
LengthUnits  = 3.086e+24

Right now, unitrefactor is using the values of MassUnits and
LengthUnits to construct the YTArray that contains the field data for
the ('enzo', 'Density') field since this field has units of
`code_mass/code_length**3`.  The conversion factors from `code_mass`
and `code_length` to CGS are exactly the MassUnits and LengthUnits
variables from the dataset parameter file.  So, the CGS conversion
factor for the array is:

MassUnits / LengthUnits**3 = 2.761197257954595e-30 g / cm**3

A careful reader will note that this is only equal to the DensityUnits
in the parameter file up to rounding in the fifth decimal place.  This
difference, it turns out, is the source of the differences I saw in
the comparison.

I haven't gone through the rest of the fields in detail, but i suspect
the all the remaining fields showing small differences to all have
issues of this sort.  My guess is the fields that compare exactly will
either have a CGS conversion factor of unity, or the conversion factor
was derived directly from MassUnits, LengthUnits, and TimeUnits in the
data file.

I'm not sure what the proper way to handle this is.

Right now unitrefactor is ignoring the on-disk CGS conversion factor
for Density. I don't think this choice should matter in principle,
since mass and density units should be algebraically related via the
LengthUnits.  Unfortunately, rounding errors in the parameter file
mean there will likely be a small amount of disagreement.

Should we attempt to be more fastidious about adopting the proper
conversion factors in the enzo frontend, if a conversion factor is
available on disk?  Should we not worry about these minor differences
in field accesses that unitrefactor is introducing?  Should we have
units like `code_density` for all on-disk fields with available CGS
conversion factors?  If so, how do we deal with the fact that the
conversion from code_density to code_mass/code_length**3 is not
straightforward?

Thanks for any help or advice anyone who has gotten this far can provide :)

Cheers,

Nathan