[Yt-dev] field_info refactor design

[Matthew Turk]

Hi Casey,

Sorry for the brief reply; I'm on vacation but have a handful of
minutes to browse my email and I don't want you to get stuck too long.
 I don't think I understand the issue -- I think the pf.field_info
object is supposed to contain all of the data fields, with a fallback
for derived.  The reason for this is so that adding a derived field
after the instantiation of a parameter file will allow it to be
accessed.  i.e.,

pf = load(...)
add_field("Something")

"Something" won't be available if the fields are fixed at
instantiation time with no fallback.  One of the reasons we have the
"known in data" and "derived" separation is so that if for instance
the code can optionally output a field (like "Dark_Matter_Density") we
should be able to use it, but if it doesn't, then it should make a new
derived field.  Does that make sense?

However, it sounds like something is more broadly wrong than just the
fallbacks -- likely my fault somewhere along the line.  If you can
post a slightly more detailed design description maybe I can
understand better and we can then adopt your method.

-Matt

On Wed, Jul 6, 2011 at 5:46 PM, Casey W. Stark <caseywstark at gmail.com> wrote:
> 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
> _______________________________________________
> Yt-dev mailing list
> Yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>