[yt-dev] Adding new derived fields

[Nathan Goldbaum]

I think I have a use case that this design might make more difficult.

Let's say I'm adding new fields to an existing code for some reason (like
radiation, chemistry, or MHD).  I'd like to make it so users can read in my
fields with yt and then make derived fields of their own using my fields.

Under your proposal, would I need to modify the yt source to be able to
read the fields in properly and assign them units?  If so, that seems a bit
awkward to me since there would need to be upstream changes to yt that only
make sense relative to someone's private fork of a hydro code.


On Thu, Jan 23, 2014 at 1:34 PM, Matthew Turk <matthewturk at gmail.com> wrote:

> Hi all,
>
> The method for adding derived fields has somewhat changed in the
> unitrefactor of 3.0, and we have the opportunity to make it a bit
> easier to add new fields -- especially after a parameter file has been
> created, which previously has been a pain.  Below is a brief summary.
>
> The current way we do this is with:
>
> add_field(...)
>
> or
>
> @derived_field
> def some_function(...
>
> The field system is now plugin based, which means we load plugins for
> different things and fields are dynamically added.  One big advantage
> is that logic for things like strides and whatnot doesn't need to
> happen inside the field functions, but it also provides some
> compartmentalization of things.
>
> I haven't implemented @derived_field and add_field yet in this system,
> but my plan is to do so by creating a "custom" plugin, to which these
> will add field definitions, which will always get loaded.  But if you
> do:
>
> pf = ...
> pf.h.whatever...
>
> @derived_field
> def func(...)...
>
> currently, and in the proposed implementation, this will not let them
> be detected.  But I want to make it so that we *can* do this:
>
> pf.add_field( ... ) and @pf.derived_field, which will both dynamically
> add fields to existing parameter files.  What this means:
>
>  * This will not change behavior of @derived_field and add_field, in
> that they only apply to pfs instantiated *after* the call happens.
>  * There will be a way to dynamically add fields, with field
> dependencies and all, by using pf attributes.
>  * Adding fields *specific to an output type* will no longer be
> possible outside of field plugins.  This means there will be the
> ability to add pf-specific and universal fields dynamically in a
> script, but all fields that are specific to an output type will need
> to be added in the fields.py file for that frontend.  So this means
> that anything you might have used add_enzo_field or add_orion_field on
> *in your scripts* (not in anything inside yt/frontends/*/fields.py)
> will no longer work.
>
> I'm going to be implementing the uncontroversial part of this, which
> is the dynamic field adding to a "custom" plugin, and unless I hear
> otherwise I'll continue on this track with the dynamic pf field
> addition.
>
> -Matt
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20140123/14daf2a9/attachment.html>