On Thu, Oct 2, 2014 at 9:41 AM, Cameron Hummels <email@example.com> wrote:
> I like the option of just adding a "dimension" argument to when you
> declare/add a field_parameter. That retains the freedom of making your own
> field_parameters, but seems to fix this dimensional problem.
We'd also need to add a step where they are added or declared that
isn't inside userspace code.
> On Thu, Oct 2, 2014 at 5:36 AM, Matthew Turk <firstname.lastname@example.org> wrote:
>> Hi Hilary,
>> Maybe we ought to have a registry of known field parameters,
>> affiliated with dimensions. A while back I looked at the known ones,
>> and there were not many in use. It might be relatively
>> straightforward to set up a simple registry. My concern is then that
>> individuals wanting to define their own are going to run into an issue
>> of the behavior changing, not knowing how to fix it, and so on.
>> Alternately, we could use a default parameter in those failing fields.
>> Or, we could add an argument to the add_field call of the dimensions
>> of the field parameter.
>> On Wed, Oct 1, 2014 at 3:22 PM, Hilary Egan <email@example.com> wrote:
>> > Hi all,
>> > I've encountered a bug with this example in the docs of getting/setting
>> > field parameters of a dataset for use in a derived field. The example
>> > works
>> > fine for known yt field parameters like bulk_velocity, but if you change
>> > every instance of "bulk_velocity" to "my_bulk_velocity" (sample script),
>> > then it breaks with this error.
>> > It seems as though this breaks because `has_field_parameter` always
>> > returns
>> > True, and there is no way to know ahead of time what units a
>> > user-defined
>> > field parameter will take, so the mock field data can't be set up
>> > correctly.
>> > Nathan suggested via IRC that this might necessitate creating a way to
>> > register user-defined field parameters, but it's probably worth
>> > brain-storming about if anyone else has any other suggestions!
>> > -Hilary
>> > _______________________________________________
>> > yt-dev mailing list
>> > firstname.lastname@example.org
>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> yt-dev mailing list
> Cameron Hummels
> Postdoctoral Researcher
> Steward Observatory
> University of Arizona
> yt-dev mailing list
yt-dev mailing list