[yt-dev] inline profiles

Matthew Turk matthewturk at gmail.com
Mon Aug 6 18:40:18 PDT 2012


Hi Stephen,

We have the capacity to allow for fallback fields; this is how
Total_Energy and Gas_Energy have been defined.  If you specify a field
that duplicated one in a file, it will use the one in the file or
generate it as needed.  The complication with Dark_Matter_Density is
that it's not *in* every grid, so it may not be correctly detected if
it is there, and yt would re-generate the field on the off chance it
didn't randomyl sample grids that had it.

I think on the whole, though, we should use fields that exist
everywhere.  A complicating factor is that the particle deposition
routines generally don't subselect based on particle types, and when
they do, that is not robust against differences between codes.  So
have a go at overriding Dark_Matter_Density, and if that fails, swap
it out for the dark matter density created by yt in the halo profiler.

The best solution, though, might be just to do what we do for
Temperature; generate it before calling yt.

-MAtt

On Mon, Aug 6, 2012 at 5:56 PM, Stephen Skory <s at skory.us> wrote:
> Hi all,
>
> this is about inline Enzo+yt, but since I think the solution might be
> on the yt end, I'm sending it here.
>
> I am attempting to profile halos located inline, and I am running into
> trouble when I attempt to profile over the 'TotalMassMsun' field. It
> is dying when it tries to access the 'Dark_Matter_Density' field,
> which I think it expects to be available, but isn't because Enzo only
> produces that when it writes to disk (AFAIK?). If this sounds correct
> to those in the know, I'd like to ask if anyone has a good idea how to
> get around this? Should I make a derived field (perhaps over-writing
> the built-in 'Dark_Matter_Density') using CICDeposit? I suppose I
> could try this solution first without emailing y'all, but I was
> thinking that if I/we find a working solution, it could be added to yt
> so the next person doesn't have to figure it out, so I'd like to
> minimize the false starts of poor/incorrect implementations.
>
> Thanks for your comments.
>
> --
> 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