[yt-dev] Adding new derived fields
Matthew Turk
matthewturk at gmail.com
Thu Jan 23 14:23:29 PST 2014
On Thu, Jan 23, 2014 at 5:13 PM, Nathan Goldbaum <nathan12343 at gmail.com> wrote:
> 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.
Yes, that's an ideal use case we need to support.
>
> 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.
Hmm, reading in units for a field that yt does not know about, that is
actually an outstanding problem with units that predates my changes to
the field system. I don't know what to do about it.
>
>
> 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
>
>
>
> _______________________________________________
> 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