Thanks for the quick responses, I will try that tomorrow! :)
On 05.01.2017 15:23, John ZuHone wrote:
> Yeah, I was thinking that as I was writing it.
>
>> On Jan 5, 2017, at 8:57 AM, Nathan Goldbaum <nathan12343@gmail.com
>> <mailto:nathan12343@gmail.com>> wrote:
>>
>> We should have a nicer API for this. Something like astropy's def_unit:
>>
>> http://docs.astropy.org/en/stable/api/astropy.units.def_unit.html#astropy.units.def_unit
>>
>> On Thu, Jan 5, 2017 at 7:48 AM John ZuHone <jzuhone@gmail.com
>> <mailto:jzuhone@gmail.com>> wrote:
>>
>> Hi Axel,
>>
>> You can assign new symbols as well. It sounds like you want to do
>> this for a number of datasets, so you could define new symbols and
>> add them to yt’s unit registry (though you could also add them to
>> a specific dataset’s unit registry). To do the former, you could
>> do something like this in your plugins [1] file (which would
>> ensure they got loaded every time you used yt):
>>
>> ```python
>> from yt.units.unit_object import default_unit_registry
>> from yt.units import dimensions
>>
>> default_unit_registry.add("lambda_0", 8.0e-5, dimensions.length,
>> 0.0, r"$\lambda_0$")
>> default_unit_registry.add("omega_pe", 1.0e15, dimensions.rate,
>> 0.0, r"$\omega_\text{pe}$")
>> ```
>>
>> The arguments in .add are the name of the symbol, the conversion
>> to CGS+Ampere, the dimensions of the unit, the unit offset (only
>> used for temperature and angle units), and the last is the LaTeX
>> representation.
>>
>> Note that I defined omega_pe as a rate, so you’d have to use its
>> inverse when creating your unit system to define the base time units.
>>
>> And yes, as I mentioned above the internal base by which all yt
>> units reference is cgs units + Amperes for current (for historical
>> reasons, mostly).
>>
>> Best,
>>
>> John
>>
>> [1] http://yt-project.org/doc/reference/configuration.html#the-plugin-file
>>
>>> On Jan 5, 2017, at 8:24 AM, Axel Huebl <a.huebl@hzdr.de
>>> <mailto:a.huebl@hzdr.de>> wrote:
>>>
>>> Ha, I oversaw a link in [1] linking to [2].
>>>
>>> Ok, so I can just specify my own unit system in user-code with that.
>>> But anyhow, I can't assign it new symbols. Also, do all conversion
>>> factors need to go through CGS?
>>>
>>> Also, microns turns out to be
>>> .in_units("um")
>>> :)
>>>
>>>
>>> Axel
>>>
>>> [2] http://yt-project.org/docs/dev/analyzing/units/unit_systems.html
>>>
>>> On 05.01.2017 13:59, Axel Huebl wrote:
>>>> Hi yt-devs!
>>>>
>>>> I have a quick user-question (sorry) and a devel question:
>>>>
>>>> First, how to convert to a unit like microns (10^-6 meters) or
>>>> pico-seconds? I can't find an example here [1]. I tried
>>>>
>>>> .in_units("mum")
>>>> .in_units("mu m)
>>>> .in_units("1.e-6 m")
>>>> .in_units("microns")
>>>> .in_units("micro meter")
>>>> .in_units("micro meters")
>>>> .in_units("micro m")
>>>> .in_units("μm")
>>>>
>>>> and only
>>>> .in_units("1.e-6 * m")
>>>>
>>>> does not fail but looks ugly.
>>>>
>>>> An orthogonal question: in our domain (laser-plasma physics) unit
>>>> systems are scaled by something like the applied laser
>>>> wavelength or the
>>>> plasma density (and more to make a full set).
>>>>
>>>> Following again [1] I would implement something like
>>>> .in_base('plasma')
>>>> or .in_base('laserplasma') but those are not scaled to "fixed"
>>>> reference
>>>> quantities as the other base systems but are depending on either
>>>> user input
>>>> [ length = ("$\lambda_0$", "800 nm"),
>>>> time = ("$\omega_\text{pe}^{-1}$", "1.e-15 s"),
>>>> ...]
>>>> or alternatively scalings the data file already provided. (Ok, the
>>>> symbol is always fixed per "in_base" but the value to scale with
>>>> needs
>>>> to be provided.)
>>>>
>>>> Is that already possible or any ideas how we could implement that?
>>>>
>>>>
>>>> Thanks,
>>>> Axel
>>>>
>>>> [1]
>>>> http://yt-project.org/docs/dev/analyzing/units/fields_and_unit_conversion.html#data-selection-and-fields
>>>>
>>>
>>> --
>>>
>>> Axel Huebl
>>> Phone +49 351 260 3582
>>> https://www.hzdr.de/crp
>>> Computational Radiation Physics
>>> Laser Particle Acceleration Division
>>> Helmholtz-Zentrum Dresden - Rossendorf e.V.
>>>
>>> Bautzner Landstrasse 400, 01328 Dresden
>>> POB 510119, D-01314 Dresden
>>> Vorstand: Prof. Dr.Dr.h.c. R. Sauerbrey
>>> Prof. Dr.Dr.h.c. P. Joehnk
>>> VR 1693 beim Amtsgericht Dresden
>>> _______________________________________________
>>> yt-dev mailing list
>>> yt-dev@lists.spacepope.org <mailto:yt-dev@lists.spacepope.org>
>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>> _______________________________________________
>>
>> yt-dev mailing list
>>
>> yt-dev@lists.spacepope.org <mailto:yt-dev@lists.spacepope.org>
>>
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev@lists.spacepope.org <mailto:yt-dev@lists.spacepope.org>
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev@lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
--
Axel Huebl
Phone +49 351 260 3582
https://www.hzdr.de/crp
Computational Radiation Physics
Laser Particle Acceleration Division
Helmholtz-Zentrum Dresden - Rossendorf e.V.
Bautzner Landstrasse 400, 01328 Dresden
POB 510119, D-01314 Dresden
Vorstand: Prof. Dr.Dr.h.c. R. Sauerbrey
Prof. Dr.Dr.h.c. P. Joehnk
VR 1693 beim Amtsgericht Dresden
_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org