[yt-dev] axes units behaving correctly?

Chris Malone chris.m.malone at gmail.com
Thu Oct 2 13:46:06 PDT 2014


That's perfectly acceptable.  I just wanted to make sure I was
understanding it correctly :).

Thanks!

On Thu, Oct 2, 2014 at 2:44 PM, Nathan Goldbaum <nathan12343 at gmail.com>
wrote:

>
>
> 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
>>
>>
>
> _______________________________________________
> 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/e5575987/attachment.htm>


More information about the yt-dev mailing list