<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 24, 2015 at 8:35 PM, Elizabeth Tasker <span dir="ltr"><<a href="mailto:tasker@astro1.sci.hokudai.ac.jp" target="_blank">tasker@astro1.sci.hokudai.ac.jp</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">Hi Everyone,<div><br></div><div>Nathan — thank you very much for that detailed explanation. </div><div><br></div><div>I like Cameron’s idea of having a force override — much of the code I write isn’t “good” so much as debugging and checking. For that, user checks impede more than help since speed-writing is what I’m after.</div></div></blockquote><div><br></div><div>You can also define them youself, but you'll need to make sure they have units attached to them. For example, if I wanted to define the weight of my pet hamster as a physical constant, I could do:</div><div><br></div><div>    from yt.units import gram</div><div><br></div><div>    m_hamster = 100*gram</div><div><br></div><div>You could also do:</div><div><br></div><div>    from yt import YTQuantity</div><div><br></div><div>    m_hamster = YTQuantity(100, 'g')</div><div><br></div><div><br></div><div>Take a look at the contents of yt/units/__init__.py to see all of the units defined in the yt.units namespace:</div><div><br></div><div><a href="https://bitbucket.org/yt_analysis/yt/src/d7acb82ef45047599a23e3c08805ab2af01c7b32/yt/units/__init__.py?at=stable&fileviewer=file-view-default" target="_blank">https://bitbucket.org/yt_analysis/yt/src/d7acb82ef45047599a23e3c08805ab2af01c7b32/yt/units/__init__.py?at=stable&fileviewer=file-view-default</a><br></div><div><br></div><div>so you can look at yt/units/unit_symbols.py to see all the units in the yt.units namespace:</div><div><br></div><div><a href="https://bitbucket.org/yt_analysis/yt/src/03a54b627189e63eaee9f2bc1d4a36c3ab6b9637/yt/units/unit_symbols.py?at=yt&fileviewer=file-view-default">https://bitbucket.org/yt_analysis/yt/src/03a54b627189e63eaee9f2bc1d4a36c3ab6b9637/yt/units/unit_symbols.py?at=yt&fileviewer=file-view-default</a><br></div><div><br></div><div>On the dev branch (i.e. in the upcoming yt 3.3 release) we do something a little fancier in yt/__init__.py to also include physical constants in the yt.units namespace and ensure that the only symbols defined there are YTQuantity instances:</div><div><br></div><div><a href="https://bitbucket.org/yt_analysis/yt/src/03a54b627189e63eaee9f2bc1d4a36c3ab6b9637/yt/units/__init__.py?at=yt&fileviewer=file-view-default" target="_blank">https://bitbucket.org/yt_analysis/yt/src/03a54b627189e63eaee9f2bc1d4a36c3ab6b9637/yt/units/__init__.py?at=yt&fileviewer=file-view-default</a><br></div><div><br></div><div>If you're on the current stable release of yt and want to use yt's predefined physical constants, you want to import them from the "yt.ulitilies.physical_constants" namespace. If you're on the dev branch you should import physical constants from the "yt.units" namespace. These physical constants are YTQuantity instances that have yt unit objects attached to them.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><span><font color="#888888"><div><br></div><div>Elizabeth</div></font></span><div><div><div><br></div><div><br></div><div><br></div><div><br><div><blockquote type="cite"><div>On 25 Nov 2015, at 10:23, Cameron Hummels <<a href="mailto:chummels@gmail.com" target="_blank">chummels@gmail.com</a>> wrote:</div><br><div><div dir="ltr">I guess what I meant to ask was if the code I put was a solution to the problem, not an example of the problem?</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 24, 2015 at 11:56 AM, Kacper Kowalik <span dir="ltr"><<a href="mailto:xarthisius.kk@gmail.com" target="_blank">xarthisius.kk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On 11/24/2015 12:33 PM, Cameron Hummels wrote:<br>
> On Tue, Nov 24, 2015 at 9:10 AM, Kacper Kowalik <<a href="mailto:xarthisius.kk@gmail.com" target="_blank">xarthisius.kk@gmail.com</a>><br>
> wrote:<br>
>><br>
>><br>
>> I'd be strongly -1 on "force_units". In that scenario you invoke several<br>
>> costly calls to sympy just to disregard the result. IMO you should drop<br>
>> units at the very beginning and create YTArray during return in the<br>
>> derived field's definition.<br>
>><br>
><br>
> By this you mean something like:<br>
><br>
> def _temperature(field, data):<br>
>     tr = array_of_wrong_units<br>
>     data.apply_units(tr, 'K')<br>
>     return tr<br>
><br>
> ds.add_field('temperature', function=_temperature, units='K')<br>
<br>
</span>Nope, if you change units of the array that's cheap (I think), but when<br>
you do:<br>
<br>
def _temp(field, data):<br>
    temp = data["foo"] * constant1 * constant2<br>
    return temp<br>
<br>
only to disregard units, that's a huge waste of cycles.<br>
Cheers,<br>
Kacper<br>
<div><div><br>
> ?<br>
><br>
> Or is the syntax wrong here?  I'm not really sure how to use this.<br>
><br>
><br>
><br>
><br>
>> Cheers,<br>
>> Kacper<br>
>><br>
>>> On Tue, Nov 24, 2015 at 7:32 AM, Matthew Turk <<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>>> If absolutely necessary, you can "force" units with:<br>
>>>><br>
>>>> data.apply_units(array_to_override, unit_string)<br>
>>>><br>
>>>> On Tue, Nov 24, 2015 at 9:31 AM, Cameron Hummels <<a href="mailto:chummels@gmail.com" target="_blank">chummels@gmail.com</a>><br>
>>>> wrote:<br>
>>>>> I would be a fan of making a "force_units" kwarg to enable one to<br>
>> create<br>
>>>> a<br>
>>>>> new field with different units than those specified.  This could<br>
>> resolve<br>
>>>>> some of the problems with native frontend fields being stuck in the<br>
>> wrong<br>
>>>>> unit, like I was running into last week.  As long as force_unit is off<br>
>> by<br>
>>>>> default, it would just enable us to give full control to the user.<br>
>>>>><br>
>>>>> On Tue, Nov 24, 2015 at 4:25 AM, Nathan Goldbaum <<br>
>> <a href="mailto:nathan12343@gmail.com" target="_blank">nathan12343@gmail.com</a>><br>
>>>>> wrote:<br>
>>>>>><br>
>>>>>> Hi Elizabeth,<br>
>>>>>><br>
>>>>>> This is discussed in the docs here:<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>><br>
>> <a href="http://yt-project.org/doc/developing/creating_derived_fields.html#defining-a-new-field" rel="noreferrer" target="_blank">http://yt-project.org/doc/developing/creating_derived_fields.html#defining-a-new-field</a><br>
>>>>>><br>
>>>>>> You can do one of two things. First, the way I'd handle this is to<br>
>>>> ensure<br>
>>>>>> that your field definition is returning data that have units of<br>
>> Kelvin.<br>
>>>>>><br>
>>>>>> For example, something like:<br>
>>>>>><br>
>>>>>>     from yt.utilities.physical_constants import kb, mh<br>
>>>>>><br>
>>>>>>     mu = 0.6<br>
>>>>>><br>
>>>>>>     @derived_field(name=‘Temp’, units=“K”)<br>
>>>>>>     def _Temp(field, data):<br>
>>>>>>         return data['thermal_energy'] / kb * mu * mh<br>
>>>>>><br>
>>>>>> You could also make mu a field parameter rather than a constant, or if<br>
>>>> you<br>
>>>>>> have a simulation where mu varies with position, make a mean molecular<br>
>>>>>> weight derived field.<br>
>>>>>><br>
>>>>>> You can also ensure that your field definition returning a<br>
>> dimensionless<br>
>>>>>> value by stripping the units:<br>
>>>>>><br>
>>>>>>     @derived_field(name=‘Temp’, units=“K”)<br>
>>>>>>     def _Temp(field, data):<br>
>>>>>>         ret = data['thermal_energy'])<br>
>>>>>>         return ret.ndarray_view()<br>
>>>>>><br>
>>>>>> We don't currently have a way to *force* the units to be whatever you<br>
>>>>>> specify in add_field. That said, I don't think it would be terribly<br>
>>>> hard to<br>
>>>>>> implement.<br>
>>>>>><br>
>>>>>> We already have units='auto', which forces the units to be the same as<br>
>>>> the<br>
>>>>>> return value of your field function. We might add a keyword<br>
>>>>>> 'force_units=True' to add_field which does what you're looking for.<br>
>> I'd<br>
>>>> be<br>
>>>>>> happy to review a pull request adding this, or feel free to open an<br>
>>>> issue<br>
>>>>>> about it to add to our project backlog.<br>
>>>>>><br>
>>>>>> Also, worth pointing out that this was designed this way not to anger<br>
>>>>>> users, but to protect them from making mistakes in their field units,<br>
>>>> which<br>
>>>>>> we found to be a common cause of bugs in yt-2. It does mean you need<br>
>> to<br>
>>>> "buy<br>
>>>>>> into" the unit system in your field definition, but the bonus is that<br>
>>>> you<br>
>>>>>> can be much more sure that you're not making a mistake.<br>
>>>>>><br>
>>>>>> Hope that helps,<br>
>>>>>><br>
>>>>>> Nathan<br>
>>>>>><br>
>>>>>> On Tue, Nov 24, 2015 at 12:41 AM, Elizabeth Tasker<br>
>>>>>> <<a href="mailto:tasker@astro1.sci.hokudai.ac.jp" target="_blank">tasker@astro1.sci.hokudai.ac.jp</a>> wrote:<br>
>>>>>>><br>
>>>>>>> Hi everyone,<br>
>>>>>>><br>
>>>>>>> While using yt-3, I created a derived field:<br>
>>>>>>><br>
>>>>>>> @derived_field(name=‘Temp’, units=“K”)<br>
>>>>>>> def _Temp …..<br>
>>>>>>><br>
>>>>>>> It crashes with a YTFieldUnitError because it believes the units<br>
>> should<br>
>>>>>>> be cm**2/s**2. I understand why yt thinks this — I’m using<br>
>>>> thermal_energy in<br>
>>>>>>> the definition for Temp. However, the units are truly Kelvin and I<br>
>>>> think I<br>
>>>>>>> should be able to specify whatever I like in “units”!<br>
>>>>>>><br>
>>>>>>> Is there a way to stop yt crashing when it disagrees with your life<br>
>>>>>>> choices?<br>
>>>>>>><br>
>>>>>>> Elizabeth<br>
>>>>>>> _______________________________________________<br>
>>>>>>> yt-users mailing list<br>
>>>>>>> <a href="mailto:yt-users@lists.spacepope.org" target="_blank">yt-users@lists.spacepope.org</a><br>
>>>>>>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" rel="noreferrer" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> yt-users mailing list<br>
>>>>>> <a href="mailto:yt-users@lists.spacepope.org" target="_blank">yt-users@lists.spacepope.org</a><br>
>>>>>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" rel="noreferrer" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
>>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> --<br>
>>>>> Cameron Hummels<br>
>>>>> NSF Postdoctoral Fellow<br>
>>>>> Department of Astronomy<br>
>>>>> California Institute of Technology<br>
>>>>> <a href="http://chummels.org/" rel="noreferrer" target="_blank">http://chummels.org</a><br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> yt-users mailing list<br>
>>>>> <a href="mailto:yt-users@lists.spacepope.org" target="_blank">yt-users@lists.spacepope.org</a><br>
>>>>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" rel="noreferrer" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
>>>>><br>
>>>> _______________________________________________<br>
>>>> yt-users mailing list<br>
>>>> <a href="mailto:yt-users@lists.spacepope.org" target="_blank">yt-users@lists.spacepope.org</a><br>
>>>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" rel="noreferrer" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
>>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> yt-users mailing list<br>
>>> <a href="mailto:yt-users@lists.spacepope.org" target="_blank">yt-users@lists.spacepope.org</a><br>
>>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" rel="noreferrer" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
>>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> yt-users mailing list<br>
>> <a href="mailto:yt-users@lists.spacepope.org" target="_blank">yt-users@lists.spacepope.org</a><br>
>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" rel="noreferrer" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
>><br>
>><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> yt-users mailing list<br>
> <a href="mailto:yt-users@lists.spacepope.org" target="_blank">yt-users@lists.spacepope.org</a><br>
> <a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" rel="noreferrer" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
><br>
<br>
<br>
</div></div><br>_______________________________________________<br>
yt-users mailing list<br>
<a href="mailto:yt-users@lists.spacepope.org" target="_blank">yt-users@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" rel="noreferrer" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div>Cameron Hummels<div><span style="font-size:12.8px">NSF Postdoctoral Fellow</span></div><div><span style="font-size:12.8px">Department of Astronomy</span></div><div><span style="font-size:12.8px">California Institute of Technology</span><br></div><div><a href="http://chummels.org/" style="font-size:12.8px" target="_blank">http://chummels.org</a><br></div></div></div></div>
</div>
_______________________________________________<br>yt-users mailing list<br><a href="mailto:yt-users@lists.spacepope.org" target="_blank">yt-users@lists.spacepope.org</a><br><a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br></div></blockquote></div><br></div></div></div></div><br>_______________________________________________<br>
yt-users mailing list<br>
<a href="mailto:yt-users@lists.spacepope.org" target="_blank">yt-users@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" rel="noreferrer" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
<br></blockquote></div><br></div></div>