[yt-dev] Field Parameters Bug

[Matthew Turk]

I'd like to avoid that.

What I was thinking was more along the lines of adding an argument to
get_field_parameter that optionally specified the dimensions.
On Oct 2, 2014 10:08 AM, "Cameron Hummels" <chummels at gmail.com> wrote:

> So we need something akin to adding particle filters?  Define the
> field_parameter and then add the field_parameter?  That seems reasonable to
> me.
>
> On Thu, Oct 2, 2014 at 7:42 AM, Matthew Turk <matthewturk at gmail.com>
> wrote:
>
>> On Thu, Oct 2, 2014 at 9:41 AM, Cameron Hummels <chummels at gmail.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.
>>
>> >
>> > Cameron
>> >
>> > On Thu, Oct 2, 2014 at 5:36 AM, Matthew Turk <matthewturk at gmail.com>
>> 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.
>> >>
>> >> -Matt
>> >>
>> >> On Wed, Oct 1, 2014 at 3:22 PM, Hilary Egan <hilaryye at gmail.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
>> >> > yt-dev at lists.spacepope.org
>> >> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >> >
>> >> _______________________________________________
>> >> yt-dev mailing list
>> >> yt-dev at lists.spacepope.org
>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >
>> >
>> >
>> >
>> > --
>> > Cameron Hummels
>> > Postdoctoral Researcher
>> > Steward Observatory
>> > University of Arizona
>> > http://chummels.org
>> >
>> > _______________________________________________
>> > yt-dev mailing list
>> > yt-dev at lists.spacepope.org
>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>
>
>
> --
> Cameron Hummels
> Postdoctoral Researcher
> Steward Observatory
> University of Arizona
> http://chummels.org
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20141002/a0d154b9/attachment.htm>