[Yt-dev] field_info refactor design

Casey W. Stark caseywstark at gmail.com
Wed Jul 6 17:46:40 PDT 2011


Hello yt.

I'm working on the deliberate_fields branch and came up with a design idea.
I want to check in with yt-dev before implementing it.

I was trying to get the new design to pass tests, but could not get it
working. It looks like pf.field_info is fine during the first test and is
empty when the second test starts. I suspect this issue is related to the
new fallback design, but I could not track it down.

The new field_info design gives FieldInfoContainer a fallback attribute that
should be another FieldInfoContainer. The idea is that a parent
FieldInfoContainer contains all the fields from data, and the fallback
attribute contains all of the derivable fields. Fields in both of these
objects are instances of
`yt.data_objects.field_info_container.DerivedField`, created with the
add_field method in a frontend fields module.

I thought it would be easier to have a FieldInfoContainer that contains all
fields (for a given frontend) and is aware of which fields are from data and
which are derivable. I think you can get the same behavior as the fallback
design without modifying the dict behavior. When defining the frontend
fields, you add fields that might be in data files with
code_field_info.add_data_field and you add fields that could be derived
given all dependences with code_field_info.add_derivable_field. When a pf is
loaded, prune the default field_info to contain only the available fields.

Of course, I'm pretty new to the yt code, so I don't want to break any
behavior before 3.0. I would really appreciate any feedback, especially if
you know this would create problems. I will stash my changes for now and
come back to it.

Best,
Casey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20110706/b5a7fa06/attachment.htm>


More information about the yt-dev mailing list