[yt-dev] axes units behaving correctly?

[Nathan Goldbaum]

On Thu, Oct 2, 2014 at 1:40 PM, Chris Malone <chris.m.malone at gmail.com>
wrote:

> My original impression was that code_* units were just intended to be used
> internally.  I can't think of any of my use cases where I'd ever want
> code_* units to be displayed on a plot; I can imagine others possibly
> wanting such a thing if their code is written in non-dimensional units, for
> example.
>

The "code" unit symbols are "fully qualified" unit symbols.  From the point
of view of the unit system they are on the same footing as "physical" units
like cm or gram.

In your example you explicitly specified that you wanted the axes units to
be code units by passing in a width tuple containing YTQuantity instances
with units of code_length.  If you pass in a unitful quantity as the width,
I think the only safe and convenient thing to do is to label the plot using
the provided units.


> On Thu, Oct 2, 2014 at 2:17 PM, Nathan Goldbaum <nathan12343 at gmail.com>
> wrote:
>
>>
>>
>> On Thu, Oct 2, 2014 at 12:47 PM, Nathan Goldbaum <nathan12343 at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Thu, Oct 2, 2014 at 12:45 PM, Chris Malone <chris.m.malone at gmail.com>
>>> wrote:
>>>
>>>> So I should be interpreting code_* units as separate from whatever is
>>>> set as ds.length_unit, ds.time_unit, ds.mass_unit, etc.?
>>>>
>>>
>>> No, they're the same. It just doesn't automatically replace code_length
>>> with whatever ds.length_unit is.
>>>
>>>
>>
>> Something I could get behind (although this would likely break a lot of
>> things) would be presenting Dataset attributes in physical units (i.e.
>> whatever ds.length_unit is).
>>
>> Since we use Dataset attributes at the cython level, this would be a bit
>> of work to change, but I think it's doable.
>>
>>
>>>
>>>> On Thu, Oct 2, 2014 at 1:39 PM, Nathan Goldbaum <nathan12343 at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Oct 2, 2014 at 12:35 PM, Chris Malone <
>>>>> chris.m.malone at gmail.com> wrote:
>>>>>
>>>>>> Yup.  That one was screwy, and I had no idea what to think of it.
>>>>>> Filed here
>>>>>> https://bitbucket.org/yt_analysis/yt/issue/915/sliceplot-fails-with-odd-combination-of
>>>>>>
>>>>>> I'm trying to understand if the second plot is working as intended.
>>>>>> I'm happy to change my intuition about units, but I would like some
>>>>>> clarification.
>>>>>>
>>>>>>
>>>>> I think so, you specified that you wanted the width in code units,
>>>>> since domain_left_edge and domain_right_edge are in code units.  If you
>>>>> explicitly specify a width tuple it will make the plot in whichever units
>>>>> you specify.
>>>>>
>>>>>
>>>>>> On Thu, Oct 2, 2014 at 1:28 PM, Nathan Goldbaum <
>>>>>> nathan12343 at gmail.com> wrote:
>>>>>>
>>>>>>> That last plot looks like you're exposing a bug to me.  Can you file
>>>>>>> an issue?
>>>>>>>
>>>>>>> On Thu, Oct 2, 2014 at 12:26 PM, Chris Malone <
>>>>>>> chris.m.malone at gmail.com> wrote:
>>>>>>>
>>>>>>>> All,
>>>>>>>>
>>>>>>>> I'm seeing some behavior[1] with units of axes that seems
>>>>>>>> counter-intuitive, but maybe I need to change my intuition.
>>>>>>>>
>>>>>>>> In particular, if one makes a slice plot, but specifies the width
>>>>>>>> of the plot in units of 'code_length' - for example, from using
>>>>>>>> domain_right_edge - the units aren't properly converted to whatever was set
>>>>>>>> as `ds.length_unit`.  Is this working as intended?  Are users expected to
>>>>>>>> manually apply `.in_cgs()` to such items that have code_length?  Naively, I
>>>>>>>> would expect that when units are displayed, if they are code_* units, they
>>>>>>>> should be converted to whatever is declared in
>>>>>>>> `ds._set_code_unit_attributes`.
>>>>>>>>
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> http://nbviewer.ipython.org/urls/dl.dropbox.com/s/bf62wclpjduvlit/example.ipynb?dl=0
>>>>>>>>
>>>>>>>> Chris
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>
> _______________________________________________
> 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/418abe5a/attachment.htm>