Thanks for going through and looking into this.
On Fri, Aug 29, 2014 at 3:07 PM, Douglas Harvey Rudd firstname.lastname@example.org wrote:
I have a set of fixes for Issue #887 (field detection). Most apply without breaking any tests, but to address all of the problems in that issue I need to add a check to YTDataContainer._determine_fields that doesn't allow a field to be added if it doesn't exist in field_list or derived_field_list.
That sounds good to me.
This fixes my bug, but breaks a test based on code in yt/visualization/volume_rendering/camera.py which adds a field "temp_weightfield" (not a tuple!).
Whoops, that should be a tuple! :) Does it use ds.add_field? That should ensure it gets added to the derived_field_list.
When this field is passed to _determine_fields, _get_field_info first guesses at ("gas","temp_weightfield"), but since that doesn't exist in field_info, it replaces it with ("index","temp_weightfield"), which I don't see as being any better.
I would slightly prefer "index" over "gas" just because "index" indicates it's an internal field.
There are several places where the syntax _get_field_info(*field) is used, which will break when field is a string, not a tuple. Should I fix camera.py to use an explicit fluid type? If so, what? I've tried to use the fluid type of the input field, but that apparently is also not always a tuple.
I think fixing camera.py is good, and I would go with "index".
e.g. fields = [field] if self.weight is not None: self.weightfield = (field, "temp_weightfield") # This is a temporary field, which we will remove at the end. def _make_wf(f, w): def temp_weightfield(a, b): tr = b[f].astype("float64") * b[w] return b.apply_units(tr, a.units) return tr return temp_weightfield ds.field_info.add_field(self.weightfield, function=_make_wf(self.field, self.weight)) # Now we have to tell the dataset to add it and to calculate # its dependencies.. deps, _ = ds.field_info.check_derived_fields([self.weightfield]) ds.field_dependencies.update(deps) fields = [self.weightfield, self.weight]
Douglas Rudd Scientific Computing Consultant Research Computing Center email@example.com
yt-dev mailing list firstname.lastname@example.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org