[yt-users] Particle filters and subsequent particle deposition

Matthew Turk matthewturk at gmail.com
Mon Jul 14 16:15:13 PDT 2014


Hi Cameron,

Looks to me like derived_field_list is set initially inside
field_info_container, and then updated in the _setup_filtered_type
function to include the filtered particle types.  When
_setup_particle_type is called in that function, the return value of
that call should be appended to derived_field_list.

-Matt

On Mon, Jul 14, 2014 at 5:53 PM, Cameron Hummels <chummels at gmail.com> wrote:
> Hey Matt,
>
> Thanks for the message.  The deposit fields from the new filter *do* appear
> in ds.field_info.keys(), just not in the ds.derived_field_list.  In fact,
> the desired deposit fields fully exist, so evidently they are being
> deposited on to the grids, and I can use them in Slices and such, but these
> fields just don't appear in the derived_field_list.
>
> I've spent the last two hours trying to figure out where fields are added to
> the derived_field_list after they are created.  I see that in
> _setup_filtered_type() is run after a filter is created, it adds the new
> filtered particle fields to the derived_field_list, but nowhere in the
> deposition infrastructure are those fields seemingly added to the
> derived_field_list, unless perhaps it occurs in the registry.add_field()
> step.  Ideas?
>
> Cameron
>
>
> On Mon, Jul 14, 2014 at 10:40 AM, Matthew Turk <matthewturk at gmail.com>
> wrote:
>>
>> Hi Cameron,
>>
>> So, I've now also dug in.  I think what happens is that the particle
>> fields plugin never gets re-called.  This is the function
>> particle_deposition_functions, which should get called by
>> setup_particle_fields, which gets called by setup_particle_type.  So I
>> don't know why it's not getting called for you.  Are you sure it's not
>> getting called, and is not just not registering it?  Is the field in
>> ds.field_info.keys() ?
>>
>> -Matt
>>
>> On Sun, Jul 13, 2014 at 9:22 PM, Cameron Hummels <chummels at gmail.com>
>> wrote:
>> > So I used pdb to try to track the process of creating a filtered
>> > particle
>> > type.  After the particle filter type namespace is created, all of the
>> > particle fields are added to it and added to the derived_field_list, and
>> > then that _setup_particle_types([filter.name]) is called, however, it
>> > doesn't appear that the infrastructure for creating fields in the
>> > "deposit"
>> > namespace is ever called from this.
>> >
>> > I've confirmed that added particle fields are not propagated to
>> > "deposit"
>> > for either gadget or enzo datasets in the following notebook.  Since
>> > it's
>> > unclear to me how to initiate the deposit field infrastructure (no docs
>> > or
>> > docstrings), I'm not sure how to fix this problem.  Any thoughts from
>> > others
>> > more experienced with writing this code?  Matt?  Britton?
>> >
>> > http://nbviewer.ipython.org/gist/StewardObservatory/918ff0246f1132ef585b
>> >
>> > Cameron
>> >
>> >
>> > On Sat, Jul 12, 2014 at 4:55 AM, Matthew Turk <matthewturk at gmail.com>
>> > wrote:
>> >>
>> >> Hi Cameron,
>> >>
>> >> On Sat, Jul 12, 2014 at 2:52 AM, Cameron Hummels <chummels at gmail.com>
>> >> wrote:
>> >> > Hi John,
>> >> >
>> >> > That is what I figured as well, but it doesn't appear to
>> >> > automatically
>> >> > create those deposit fields when you add the particle field after
>> >> > initialization of the dataset.  Yes, it creates other deposit fields
>> >> > for
>> >> > the
>> >> > particle namespaces (e.g. Gas, Stars, DarkMatter) that are defined at
>> >> > initialization. However, when I create a particle filter which makes
>> >> > its
>> >> > own
>> >> > set of fields after initialization, these are not automatically added
>> >> > as
>> >> > deposit fields.
>> >>
>> >> Hmm.  _setup_filtered_type is called by add_particle_filter, and then
>> >> it in turn calls _setup_particle_types([filter.name]), which should
>> >> eventually create the derived fields.  I would suggest trying to
>> >> figure out at what point the process stops, and then we can figure out
>> >> why it thinks it shouldn't add the deposit fields.
>> >>
>> >> >
>> >> > I can add a notebook demonstrating this if it is easier.  I just
>> >> > thought
>> >> > someone might know of a way to force the generation of the deposit
>> >> > fields
>> >> > for newly derived fields not generated at initialization of a
>> >> > dataset.
>> >> >
>> >> > Cameron
>> >> >
>> >> >
>> >> > On Fri, Jul 11, 2014 at 6:51 PM, John Wise <jwise at physics.gatech.edu>
>> >> > wrote:
>> >> >>
>> >> >> Hi Cameron,
>> >> >>
>> >> >> If the particle filter name is called "bh", you can use the field
>> >> >> ("deposit", "bh_cic").  You can also use the other deposit fields,
>> >> >> like
>> >> >> "bh_count", "bh_density", "bh_mass".
>> >> >>
>> >> >> Cheers,
>> >> >> John
>> >> >>
>> >> >>
>> >> >> On 07/11/2014 08:16 PM, Cameron Hummels wrote:
>> >> >>>
>> >> >>> I'm playing with the new particle filter functionality in yt-3.0,
>> >> >>> but
>> >> >>> I'm running into some problems.  I can successfully create a
>> >> >>> particle
>> >> >>> filter, but how do I get those fields to be subsequently deposited
>> >> >>> on
>> >> >>> the grid (like the other fields in the "deposit" namespace)?
>> >> >>>
>> >> >>> Is there a command for forcing a particle field deposition on to
>> >> >>> the
>> >> >>> grid?
>> >> >>>
>> >> >>> Thanks!
>> >> >>>
>> >> >>> Cameron
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>> Cameron Hummels
>> >> >>> Postdoctoral Researcher
>> >> >>> Steward Observatory
>> >> >>> University of Arizona
>> >> >>> http://chummels.org
>> >> >>>
>> >> >>>
>> >> >>> _______________________________________________
>> >> >>> yt-users mailing list
>> >> >>> yt-users at lists.spacepope.org
>> >> >>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>> >> >>>
>> >> >>
>> >> >> --
>> >> >> John Wise
>> >> >> Assistant Professor of Physics
>> >> >> Center for Relativistic Astrophysics, Georgia Tech
>> >> >> http://cosmo.gatech.edu
>> >> >> _______________________________________________
>> >> >> yt-users mailing list
>> >> >> yt-users at lists.spacepope.org
>> >> >> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Cameron Hummels
>> >> > Postdoctoral Researcher
>> >> > Steward Observatory
>> >> > University of Arizona
>> >> > http://chummels.org
>> >> >
>> >> > _______________________________________________
>> >> > yt-users mailing list
>> >> > yt-users at lists.spacepope.org
>> >> > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>> >> >
>> >> _______________________________________________
>> >> yt-users mailing list
>> >> yt-users at lists.spacepope.org
>> >> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>> >
>> >
>> >
>> >
>> > --
>> > Cameron Hummels
>> > Postdoctoral Researcher
>> > Steward Observatory
>> > University of Arizona
>> > http://chummels.org
>> >
>> > _______________________________________________
>> > yt-users mailing list
>> > yt-users at lists.spacepope.org
>> > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>> >
>> _______________________________________________
>> yt-users mailing list
>> yt-users at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>
>
>
>
> --
> Cameron Hummels
> Postdoctoral Researcher
> Steward Observatory
> University of Arizona
> http://chummels.org
>
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>



More information about the yt-users mailing list