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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

On Thu, Jan 23, 2014 at 5:13 PM, Nathan Goldbaum nathan12343@gmail.com wrote:

Yes, that's an ideal use case we need to support.

>

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.

> >