[yt-dev] convert_to_cgs

[Nathan Goldbaum]

Hi Tom,

On Sun, Nov 16, 2014 at 3:29 PM, Abel, Tom <tabel at slac.stanford.edu> wrote:

>  Hi Matt,
> User Customization is definitely a nice aspect!
> Perhaps you could leverage the effort that has gone into these cool
> packages?
> http://pint.readthedocs.org/en/0.6/
>

This one is cool, but it doesn't fully support numpy ufuncs like we do.
It's also not as fast.


> https://pypi.python.org/pypi/numericalunits
>

This one is interesting, but is implemented in an odd way, IMO.  It uses
randomly selected floating point numbers to represent a unit symbol.  For a
dimensionally correct expression, these random numbers will cancel out, but
for an incorrect expression, the result will be contaminated with random
garbage.


Our unit system is probably not as fast as this approach, but I'd say there
is a much smaller danger for a result to be contaminated with bad results,
so long as a calculation stays within the unit system.

See this scipy talk for more info about the plethora of python unit
packages:
https://conference.scipy.org/scipy2013/presentation_detail.php?id=17

For more technical details about yt's unit system, take a look at the unit
YTEP: http://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0011.html

What Matt is talking about would (I think) mean adding a way to change the
underlying unit representation from CGS to a user-selected set of units.
This is interesting, and probably doable, but will require some thought.
Things like E&M units, which are dimensionally different in different unit
systems.  We would also need to make sure we're not relying on things being
in CGS inside yt, separate from the unit system.


>
>  Normally you never want to actually multiply the actual data right? It
> is just for outputting ranges and labels etc. isn't it?
>

We need to multiply the data anyway to get it into CGS, usually.  So long
as the user-selected unit system is different from the code units of the
simulation, we always need to do at least one conversion.

If you want to avoid multipying the data, you can keep everything in code
units, which we tend to do internally.  Interestingly, Matt's proposal
would probably make us convert data less often, because we could create
custom unit systems on a dataset by dataset basis, and default to code
units internally.


>
>  Best,
> Tom
>
>
> Sent from my iPhone
>
> On Nov 16, 2014, at 3:17 PM, Cameron Hummels <chummels at gmail.com> wrote:
>
>   I'm a big fan of what Matt is suggesting.
>
> On Sun, Nov 16, 2014 at 3:57 PM, Ben Thompson <bthompson2090 at gmail.com>
> wrote:
>
>>  Personally, with the amount of codes (and the different astrophysics
>> people are doing with those code). Some sort of config/user-set-defaults
>> system would be cool ... Which is what I think you are suggesting? cgs is a
>> nice "default go-to".. but it would be cool to have a few settings
>> pre-saved (maybe into a JSON file or something).. in which a user can
>> provide at anytime.. so that there is no need to add on .in_units(MSun,
>> Gyr, Mpc).
>>
>>  Ben.
>>
>> On Sun, Nov 16, 2014 at 7:08 PM, Nathan Goldbaum <nathan12343 at gmail.com>
>> wrote:
>>
>>> I don't think it will be simple - there are almost certainly places
>>> where we assume the underlying representation is CGS. That said, I think it
>>> would be possible.
>>>
>>> Matt, can you write up a YTEP for this first so we have a better idea of
>>> your implementation and design ideas?
>>>
>>> On Sun, Nov 16, 2014 at 10:40 AM John Zuhone <jzuhone at gmail.com> wrote:
>>>
>>>> I'm assuming that "underneath the hood" everything would still have to
>>>> be based on *something* by default, which would be cgs?
>>>> On Sun, Nov 16, 2014 at 10:09 AM Matthew Turk <matthewturk at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>>  Would it be feasible (I am volunteering to do this if so) to change
>>>>> instances of convert_to_cgs to something like convert_to_native, and then
>>>>> adding a new set of unit collections?  This would basically mean if we
>>>>> wanted units to be in 10^10MSun + Mpc + GYr, it would convert to that,
>>>>> rather than cgs.  My naive assumption is that if we had string keys for
>>>>> unit collections, this would be simple, and the unit object would simply
>>>>> check the string key, get the units, and go.
>>>>>
>>>>>  -Matt
>>>>> _______________________________________________
>>>>> 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
>>
>>
>
>
>  --
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20141116/7f85992f/attachment.html>