Hi Matt.<div><br></div><div>Thanks for the reply. And don't worry about me getting stuck - I've been developing frontend stuff on another branch.</div><div><br></div><div>That's a good point - I hadn't thought of data and derived fields with the same name. I think I'm confused about how this is supposed to fit together now. Here's an example from the current version of the code.</div>
<div><br></div><div>In the field_info_container module, you have FieldInfoContainer the class, and FieldInfo, an instantiation of FieldInfoContainer. Then in the enzo frontend fields module, we have:</div><div><br></div>
<div>
<div>EnzoFieldInfo = FieldInfoContainer.create_with_fallback(FieldInfo)</div><div>add_field = EnzoFieldInfo.add_field</div><div><br></div><div>KnownEnzoFields = FieldInfoContainer()</div><div>add_enzo_field = KnownEnzoFields.add_field</div>
</div><div><br></div><div>I think I wrote this when I didn't exactly understand the design. I believe it should be...</div><div><br></div><div>derivable_enzo_fields = FieldInfo</div><div>add_field = derivable_enzo_fields.add_field</div>
<div><br></div><div><div>known_enzo_fields = FieldInfoContainer.create_with_fallback(derivable_enzo_fields)</div><div>add_enzo_field = known_enzo_fields.add_field</div></div><div><br></div><div>The part that is confusing me is in the frontend StaticOutput classes. Here it is in enzo data_structures.</div>
<div><br></div><div><div>class EnzoStaticOutput(StaticOutput):</div><div> ...</div><div> _fieldinfo_fallback = EnzoFieldInfo</div><div> _fieldinfo_known = KnownEnzoFields</div></div><div> ...</div><div> def __init__(...):</div>
<div> ...</div><div> self.field_info = FieldInfoContainer.create_with_fallback(self._fieldinfo_fallback)</div><div><br></div><div>So it looks like _fieldinfo_known is never used and we make a new FieldInfoContainer instead. In this case, how does field_info know which fields can be in an enzo data file and which ones exist in the current staticoutput?</div>
<div><br></div><div>The way I thought about it, each StaticOutput object would have a copy of that frontend's known_field object and customize the fields during __init__. Something like...</div><div><br></div><div>self.field_info = self._fieldinfo_known.setup_for_output(self)</div>
<div><br></div><div>I'll try to stare at the code some more, but if anyone has experience with this part of yt, please let me know what you think and I can code it up.</div>
<div><br></div><div>Best,</div><div>Casey</div><div><br><br><div class="gmail_quote">On Mon, Jul 11, 2011 at 8:55 AM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Casey,<br>
<br>
Sorry for the brief reply; I'm on vacation but have a handful of<br>
minutes to browse my email and I don't want you to get stuck too long.<br>
I don't think I understand the issue -- I think the pf.field_info<br>
object is supposed to contain all of the data fields, with a fallback<br>
for derived. The reason for this is so that adding a derived field<br>
after the instantiation of a parameter file will allow it to be<br>
accessed. i.e.,<br>
<br>
pf = load(...)<br>
add_field("Something")<br>
<br>
"Something" won't be available if the fields are fixed at<br>
instantiation time with no fallback. One of the reasons we have the<br>
"known in data" and "derived" separation is so that if for instance<br>
the code can optionally output a field (like "Dark_Matter_Density") we<br>
should be able to use it, but if it doesn't, then it should make a new<br>
derived field. Does that make sense?<br>
<br>
However, it sounds like something is more broadly wrong than just the<br>
fallbacks -- likely my fault somewhere along the line. If you can<br>
post a slightly more detailed design description maybe I can<br>
understand better and we can then adopt your method.<br>
<br>
-Matt<br>
<div><div></div><div><br>
On Wed, Jul 6, 2011 at 5:46 PM, Casey W. Stark <<a href="mailto:caseywstark@gmail.com" target="_blank">caseywstark@gmail.com</a>> wrote:<br>
> Hello yt.<br>
> I'm working on the deliberate_fields branch and came up with a design idea.<br>
> I want to check in with yt-dev before implementing it.<br>
> I was trying to get the new design to pass tests, but could not get it<br>
> working. It looks like pf.field_info is fine during the first test and is<br>
> empty when the second test starts. I suspect this issue is related to the<br>
> new fallback design, but I could not track it down.<br>
> The new field_info design gives FieldInfoContainer a fallback attribute that<br>
> should be another FieldInfoContainer. The idea is that a parent<br>
> FieldInfoContainer contains all the fields from data, and the fallback<br>
> attribute contains all of the derivable fields. Fields in both of these<br>
> objects are instances of<br>
> `yt.data_objects.field_info_container.DerivedField`, created with the<br>
> add_field method in a frontend fields module.<br>
> I thought it would be easier to have a FieldInfoContainer that contains all<br>
> fields (for a given frontend) and is aware of which fields are from data and<br>
> which are derivable. I think you can get the same behavior as the fallback<br>
> design without modifying the dict behavior. When defining the frontend<br>
> fields, you add fields that might be in data files with<br>
> code_field_info.add_data_field and you add fields that could be derived<br>
> given all dependences with code_field_info.add_derivable_field. When a pf is<br>
> loaded, prune the default field_info to contain only the available fields.<br>
> Of course, I'm pretty new to the yt code, so I don't want to break any<br>
> behavior before 3.0. I would really appreciate any feedback, especially if<br>
> you know this would create problems. I will stash my changes for now and<br>
> come back to it.<br>
> Best,<br>
> Casey<br>
</div></div>> _______________________________________________<br>
> Yt-dev mailing list<br>
> <a href="mailto:Yt-dev@lists.spacepope.org" target="_blank">Yt-dev@lists.spacepope.org</a><br>
> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
><br>
><br>
_______________________________________________<br>
Yt-dev mailing list<br>
<a href="mailto:Yt-dev@lists.spacepope.org" target="_blank">Yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</blockquote></div><br></div>