[yt-dev] Microns & Simulation-Specific Unit Base

Axel Huebl a.huebl at hzdr.de
Thu Jan 5 07:47:03 PST 2017


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 at gmail.com
>> <mailto:nathan12343 at 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 at gmail.com
>> <mailto:jzuhone at 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 at hzdr.de
>>>     <mailto:a.huebl at 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 at lists.spacepope.org <mailto: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 <mailto: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 <mailto: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
> 

-- 

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



More information about the yt-dev mailing list