I'd like to be able to calculate the column density around a point
similar to the example in the docs
but instead of a single surface, I'd like to generate as something
close to a derived field as I can, where the cell values are the
column density from the specified point. I've never worked with the
internals of ray casting in yt, but it seems that it may be possible
to use this interface to accomplish this. Instead of integrating and
stopping the calculation of column density at a surface, I'd like to
be able to get the value of that integral as it goes along all the way
to the surface (or to the edge of the volume), preferably in
cell-centered fashion. Does this make sense?
My specific question is to those who understand ray casting better
than I do. Can you please give me some hints as to where to look so I
can apply this modification? And any thoughts or comments would be
510.621.3687 (google voice)
I just wanted to relate the experience I just had with Matt's pull request
on the isocontour flux calculations. If you already regard pull requests as
being awesome, you can probably stop reading.
Matt had a fairly large set of changes that added new functionality to yt,
and wanted another pair of eyes before pulling it into the main trunk.
The tool: bitbucket pull requests
Matt developed the changes in his fork of the main yt branch, then requested
that they be pulled into the main repo (even though he had the ability to
This allowed me to pull down his changes, test them, iterate back and forth
with him, and make comments that now forever live in the "Accepted pull
requests" part of the repo so that anyone can see why that was changed.
When it was set to go, I just clicked "Accept" and the changes were all
merged in without incident.
Anyways, very effortless way to handle changes that are more than just one
liners and need a collaborative effort before going into the main branch.
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,
---------- Forwarded message ----------
From: Bitbucket <pullrequests-noreply(a)bitbucket.org>
Date: Tue, Oct 4, 2011 at 10:23 PM
Subject: [OPEN] Pull request #4 for yt_analysis/yt: Addition of flux
Pull request #4 has been updated by Matthew Turk to include new changes.
Title: Addition of flux calculations
Creator: Matthew Turk
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:
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:
Thanks very much,
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.