On Tue, May 29, 2012 at 11:47 AM, Sam Skillman firstname.lastname@example.org wrote:
i struck out my last at bat. but yes, i think the b2f/f2b is the only remaining issue. at this point i'm not convinced that my flipping minus random minus signs is not going to work out...
Since we need to delay any type of release for a couple weeks following a merge like this, is there any chance we could isolate this problem into either the ray casting of a single brick (and something like a constant absoprtion or constant emissivity, which should show the problem analytically) or into a very simple field description that can be checked other than by visual inspection? I'd like to take a pass at doing this.
The volume refactor could potentially be a disruptive change; I'd like to have enough time to shake out the kinks before any major release, or any major upgrade of the code.
On Tue, May 29, 2012 at 7:12 AM, Matthew Turk email@example.com wrote:
Hi all (especially Sam),
What is blocking the merge of volume_refactor into the main dev branch? My recollection is that the only remaining issue was the b2f/f2b ordering, which I thought Sam had taken a successful swing at.
-Matt _______________________________________________ yt-dev mailing list firstname.lastname@example.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list email@example.com http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org