Hi Matt,<div><br></div><div>Just to clarify, the new answers should be generated using the current tip of the repo?</div><div><br></div><div>Thanks for your hard work and care on this.  I'm very sorry that my careless push forced this to the top of the priority queue.</div>
<div><br></div><div>Nathan<span></span><br><br>On Friday, June 27, 2014, Matthew Turk <<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Final update:<br>
<br>
I have convinced myself that the new answers are higher fidelity.<br>
<br>
 1) There are fewer unit conversion roundtrips.<br>
 2) We are now able to directly alias position to coordinates, which<br>
speeds things up and reduces memory overhead, as well as decreasing<br>
number of unit roundtrip conversions.<br>
 3) The differences, when I reduce everything to the most basic<br>
settings I can, are negligible.  This is primarily by using rint<br>
inside the octree getter.<br>
<br>
So unless anyone has a strong objection, I'm ready to get on with my<br>
life!  :)  So maybe we should regenerate the answer tests and move on?<br>
<br>
-Matt<br>
<br>
On Fri, Jun 27, 2014 at 9:26 AM, Matthew Turk <<a href="javascript:;" onclick="_e(event, 'cvml', 'matthewturk@gmail.com')">matthewturk@gmail.com</a>> wrote:<br>
> Hi all,<br>
><br>
> I'm looking over the answer test failures which came from the change<br>
> in output/input units.  I spent a good portion of yesterday and some<br>
> of this morning digging into this, examining which mesh cells each<br>
> particle got deposited in, and I think I've come up with a *reason*,<br>
> if not an *answer*.<br>
><br>
> What seems to be happening is that at some point as a result of the<br>
> additional convert_to_units calls, there is a drift in particle<br>
> positions at the scale of a few NULP.  Unfortunately, there are a<br>
> handful of particles that this causes to shift between zones in the<br>
> mesh of the octree -- not enough to change the octree structure, but<br>
> enough to cause a difference.  I was able to reduce the number of<br>
> differences by using IEEE754 rounding, rather than simple truncation,<br>
> during cell assignment.<br>
><br>
> When the deposition is done, this is only a relative difference of<br>
> ~1e-16, but when projected (and especially, when projected with a<br>
> *weight*) this gets amplified to the point that it triggers our answer<br>
> tests to fail.<br>
><br>
> I was able to prove to myself that this is the case by comparing the<br>
> results of truncating to float32 precision inside the get() function,<br>
> which means all oct-identification for deposition occurs at the scale<br>
> of 32 bits rather than 64.  I then compared the old results (with the<br>
> truncation in precision) to the new results (with the same truncation<br>
> in precision) and got identical results, all of which passed the<br>
> answer test suite.  This doesn't solve the problem, but it points to a<br>
> reason for it.<br>
><br>
> Even with that reason, however, I'm really quite dissatisfied with the<br>
> idea that we're introducing this jitter in the first place.  It seems,<br>
> to my eye, to be coming from multiple calls to unit conversion, etc<br>
> etc, that introduce slight differences.  I've attempted to reduce<br>
> these calls in the PR.<br>
><br>
> There was an additional issue, in that we were iterating over sets of<br>
> files, which introduced the possibility of iteration order<br>
> differences.  That's been addressed in an outstanding PR.<br>
><br>
> Anyway, I'll send an update once I've completely tracked this down.<br>
><br>
> -Matt<br>
_______________________________________________<br>
yt-dev mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'yt-dev@lists.spacepope.org')">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</blockquote></div>