[Yt-dev] Density Column calculation

Matthew Turk matthewturk at gmail.com
Mon Oct 10 11:23:03 PDT 2011


Hi Stephen,

I honestly don't know how to do what you're suggesting.  You may want
to do it inside Enzo, if you are already using the radiation, and
simply ask it to store the fields.  For a while I was working on an
adaptive healpix integrator, which would get you want you want, but I
haven't looked at it in a while and I wasn't able to get it to work
when it refined and moved the resulting refined packed outside of the
original cell.  Anyway, we can talk about your ideas etc this week,
and maybe at the (enzo) workshop Tom or John will have some ideas how
to accomplish this.

Best,

Matt

On Mon, Oct 10, 2011 at 1:11 PM, Stephen Skory <s at skory.us> wrote:
> Hi Matt,
>
> thanks for the stupid-check in the last email. I probably could have
> figured that out but I had a mental block.
>
> Now to my next questions, but first the set-up. I think I essentially
> have this working in my test case. I've vectorized most of the Python
> calculations so it doesn't feel excessively slow. Using the 'Ones'
> field and centering at [0.5,0.5,0.5], I calculate four column density
> spheres with radii between pf.h.get_smallest_dx() and 0.5 (spheres
> with radii outside the box are... troublesome, I'm avoiding that for
> now) using HEALPix. The 'Ones' field means that the values on these
> spheres are the radii of the spheres themselves. Handy. Then I
> interpolate the values on those spheres to all the points on each grid
> that are on or inside the largest sphere. Points outside are given
> values of 0 for now.
>
> For now I'm just attaching the new fields manually to the grids like this:
>
> pf.h.grid[grid_num]['NewColumnDensityField'] = result_for_this_grid
>
> which works fine in the respect that I can then compare this field to
> a manual cell-to-[0.5,0.5,0.5] calculation and the answers make sense.
>
> My feeling is that this might be the way to go because it will allow
> people to use this new field in as many ways as possible. I don't see
> how this can be a derived field. Do you agree, Matt? If not, what else
> could work?
>
> If this is a good approach, then there are more questions (that can be
> skipped if this is not a good approach). How do I add this field in
> all the right places? I know it should be added to pf.h.field_list,
> and that there are other stuff that field_info_container.py is related
> to. Can you point me to a place in the code where fields are added?
> I've never worked with that part of yt before.
>
> Also, there's the question of parallelism, and if attaching to the
> grids like this works. I'm thinking probably.
>
> Thanks for your help, Matt.
>
> --
> Stephen Skory
> s at skory.us
> http://stephenskory.com/
> 510.621.3687 (google voice)
> _______________________________________________
> Yt-dev mailing list
> Yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>



More information about the yt-dev mailing list