[Yt-dev] Field definitions, derived fields, whats-in-a-file and the "deliberate_fields" branch

[Matthew Turk]

Hi Stephen,

That's a good question.  Here's how it goes.

At initialization of yt, two FieldInfoContainers are set up for each frontend.

1) Known fields
2) Derived fields specific to a code

Additionally, a universal set of derived fields is initialized.  To
the frontend-specific codes are added the various fields we know may,
somewhere, in a universe like ours, exist for a given simulation code.
 For Enzo, this would be things like "Density", "Temperature", and so
on.

When a static output object is initialized, a new instance of
field_info is created.  It starts as empty, with a fallback to the
global "derived fields" field info container.  The simulation output
is then queried.  Every field yt encounters is compared against the
Known fields container.  If it is found, that field is then added to
the new instance of field_info.  If it is not, a new "largely unknown"
field is created, with empty units and names and whatnot.  The list of
fields yt found are added to field_list.  Then, from the fields that
yt knows about, the list of derived fields is calculated and appended
to derived_field_list.

The most visible thing this will fix is infinite recursion while
"Gas_Energy" looks for "GasEnergy" and then "GasEnergy" looks for
"Gas_Energy".  The less visible things are that it will be clearer
which fields are known about in advance, and which aren't, which will
help with unit validation.

Does that make sense?  I think part of the problem is that the old
method was "magic" and this is a simplification.  But it's hard to see
it as simplifying unless the old complex way is also known.  :-)

-Matt

On Wed, Nov 9, 2011 at 3:43 PM, Stephen Skory <s at skory.us> wrote:
> Matt,
>
>> I see no big problems with this change conceptually. I agree with Jeff
>> that an example of this new method of doing things would be nice
>> (perhaps a list of operations with which .py file they happen in?) and
>> contingencies used/passed over. What happens for a successful field in
>> the dataset? Unsuccessful field that (should?) be in the dataset? A
>> derived field?
>
> Let me add, very quickly after just sending, that I'm curious about
> how it works, not putting you on the spot. I'm thinking ahead to
> modifications I may make some day!
>
> --
> 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
>