What is blocking volume_refactor merge?
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
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... On Tue, May 29, 2012 at 7:12 AM, Matthew Turk <matthewturk@gmail.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 yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Tue, May 29, 2012 at 11:47 AM, Sam Skillman <samskillman@gmail.com> 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. -Matt
On Tue, May 29, 2012 at 7:12 AM, Matthew Turk <matthewturk@gmail.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 yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Matt, the easiest test is probably: Set up the renderer to work such that red is opaque to blue and blue is opaque to red. Then take a single brick, render the "x" field with contours added such that you have an opaque red face and an opaque blue face on the opposite side. Then test looking straight at it and you should see either red or blue, which you could evaluate directly from the image array. You then want to filp the looking direction to make sure it still works. I'll make sure that my fork is ready to go, and then maybe you could take a crack at it or we can iterate on it together. I'm happy to let you try to crack this one if you want to. Sam On Tue, May 29, 2012 at 9:50 AM, Matthew Turk <matthewturk@gmail.com> wrote:
On Tue, May 29, 2012 at 11:47 AM, Sam Skillman <samskillman@gmail.com> 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.
-Matt
On Tue, May 29, 2012 at 7:12 AM, Matthew Turk <matthewturk@gmail.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 yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (2)
-
Matthew Turk -
Sam Skillman