[Yt-dev] Fwd: [OPEN] Pull request #4 for yt_analysis/yt: Addition of flux calculations

[Matthew Turk]

Hi all,

Any suggestions about testing flux calculations over marching cubes
would be greatly appreciated.  The URL for the pull request is below;
please feel encourage to leave a comment on it with ideas,
corrections, etc.

Thanks,

Matt


---------- Forwarded message ----------
From: Bitbucket <pullrequests-noreply at bitbucket.org>
Date: Tue, Oct 4, 2011 at 10:23 PM
Subject: [OPEN] Pull request #4 for yt_analysis/yt: Addition of flux
calculations


Pull request #4 has been updated by Matthew Turk to include new changes.

https://bitbucket.org/yt_analysis/yt/pull-request/4/addition-of-flux-calculations

Title: Addition of flux calculations

Creator: Matthew Turk

Hi all,

Sam said he'd try to take a look at this one, but I'd greatly
appreciate eyes from everyone else that can spare some time.  It's a
lot bigger than the previous ones.  I committed it on the end of my
previous one, so I'm going to just update/replace the data_coords pull
request with this combined one.

This pull request includes the addition of two new pieces of functionality:

 * Calculating the isocontour vertices for grids instead of just
partitioned grids, and wrapping that in a function on AMR3DData.
 * Calculating the flux (centroid_value * code_area * (normal dot
vector_field)) over isocontours, and wrapping this in a helper
function on AMR3DData.

There are a couple points to the second item that I'm not sure about.
The main one is that of units: normally, we would want to multiply by
something like cm.  We know how to do this for projections, but it's
not clear that projection_conversion**2.0 gives us an appropriate
area_conversion.  So right now, it's all calculated in the natural
units of the field (i.e., CGS) and code units of the area.  I believe
it should be left up to the user to correct this.

The other item is that I am not yet sure how to test this for
accuracy; I did go through quite carefully to make sure that the
internal normal vectors and whatnot are reasonable, but suggestions
for actually testing correctness would be greatly appreciated.
Visualizing using meshlab the output from the isocontours suggest it
is correct, for the marching cubes algorithm.

I'm very excited about using this functionality, and I'd like to make
sure it is correct.  An example script is here:

http://paste.yt-project.org/show/1846/

I think there may be a corner case with particularly odd choices of
data objects, but I'm still thinking about how to work around that.
You can see the usage in a data_object if you uncomment the sphere
line, but you might want to make it ~100 kpc.

Note that this pull request also includes updates to data_coords,
which can be tested with this script:
http://paste.yt-project.org/show/1845/ .

Thanks very much,

Matt

Updated list of changes:



--
This is an issue notification from bitbucket.org.
You are receiving this either because you are the participating
in a pull request, or you are following it.