<div dir="ltr">Tests are back to normal now: <a href="http://tests.yt-project.org/job/py2.7-yt-3.0_testing/809/">http://tests.yt-project.org/job/py2.7-yt-3.0_testing/809/</a></div><div class="gmail_extra"><br><br><div class="gmail_quote">

On Fri, Jun 27, 2014 at 12:34 PM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="">On Fri, Jun 27, 2014 at 2:28 PM, Nathan Goldbaum <<a href="mailto:nathan12343@gmail.com">nathan12343@gmail.com</a>> wrote:<br>
> Hi Matt,<br>
><br>
> Just to clarify, the new answers should be generated using the current tip<br>
> of the repo?<br>
<br>
</div>No, I mean, with the tip of my corrected version, here:<br>
<br>
<a href="https://bitbucket.org/yt_analysis/yt/pull-request/984/ensure-stable-order-for-data-file" target="_blank">https://bitbucket.org/yt_analysis/yt/pull-request/984/ensure-stable-order-for-data-file</a><br>
<br>
I've been testing this against a version from before your push, but<br>
with the stable iteration order applied.<br>
<div class=""><br>
><br>
> Thanks for your hard work and care on this.  I'm very sorry that my careless<br>
> push forced this to the top of the priority queue.<br>
<br>
</div>No apologies necessary.<br>
<br>
-Matt<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Nathan<br>
><br>
><br>
> On Friday, June 27, 2014, Matthew Turk <<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>> wrote:<br>
>><br>
>> 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="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>><br>
>> 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="mailto: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>
><br>
><br>
> _______________________________________________<br>
> yt-dev mailing list<br>
> <a href="mailto: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>
><br>
_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto: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>
</div></div></blockquote></div><br></div>