Mailman 3 October 2011 - yt-dev

Density Column calculation
by Stephen Skory Oct. 10, 2011

Oct. 10, 2011

Hi all, I'd like to be able to calculate the column density around a point similar to the example in the docs http://yt-project.org/doc/visualizing/volume_rendering.html#healpix-volume-… 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 appreciated! Thanks! -- Stephen Skory s(a)skory.us http://stephenskory.com/ 510.621.3687 (google voice)

2 6

pull requests and their awesomeness
by Sam Skillman Oct. 7, 2011

Oct. 7, 2011

Hi all, 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. The situation: 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 push directly). The benefit: 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. Sam

5 5

Fwd: [OPEN] Pull request #4 for yt_analysis/yt: Addition of flux calculations
by Matthew Turk Oct. 5, 2011

Oct. 5, 2011

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(a)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-calcul… 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.

1 0