[yt-dev] ramses length units

Nathan Goldbaum nathan12343 at gmail.com
Fri Jun 5 10:20:44 PDT 2015


Hi Ricarda,

Please let us know if you need a hand fixing your installation. Will be
eagerly awaiting your pull request.

-Nathan

On Fri, Jun 5, 2015 at 4:25 AM, Ricarda Beckmann <
ricarda.beckmann at astro.ox.ac.uk> wrote:

> I appear to have broken my version of yt in the attempt to push the
> changes to my repo, which might take a while to fix. I promise to to a pull
> request ASAP for this..
>
>
> In the meantime, if you want to be working on this, these are the changes
> you want:
>
> The units are set in frontends/ramses/data_structures.py
>
>
>
> In general, the units output in the info file all still need a factor of
> boxlen folded in, the length unit as well as the density unit. Once this is
> included, they convert directly to cgs. If done correctly, these factors
> cancel back out for the mass unit.
>
> If you have any more questions, feel free to contact me.
>
> Ricarda
>
>
>
>
> On 5 Jun 2015, at 09:26, Ricarda Beckmann <Ricarda.Beckmann at astro.ox.ac.uk>
> wrote:
>
> This is definitely a bug and I have run into it before as well.
>
> I’ll have a look for you, as I happen to have a ramses non-cosmological
> run at hand to test on.
>
> Ricarda
>
> On 5 Jun 2015, at 00:28, Desika Narayanan <dnarayan at haverford.edu> wrote:
>
> Hey All - thanks for this - the PR was useful to look at to get a sense of
> the history of the issue.
>
> The data set is an idealized disk.  Though because this is an Agora
> snapshot, I'm surprised this hasn't been noticed by someone else before.
>  (It's not mine - I got a set of them from Mike Butler and Oscar Agertz for
> testing my radiative transfer code).
>
> Ben - I just shot an email to see if it's okay for me to share the
> snapshot (I assume it probably is) which might help comparison with pymses.
>
> thanks!
> -d
>
> On Thu, Jun 4, 2015 at 6:18 PM, Nathan Goldbaum <nathan12343 at gmail.com>
> wrote:
>
>> This was last touched back in December:
>>
>>
>> https://bitbucket.org/yt_analysis/yt/pull-request/1335/ramses-unit-conversions/diff
>>
>> https://bitbucket.org/yt_analysis/yt/issue/939/units-error-in-ramses-frontend
>>
>> when I updated this, I attempted to set the units in exactly the same way
>> as pymses. Unfortunately since I'm not a ramses user and don't have access
>> to a diversity of test datasets, it's hard to get this exactly right in all
>> cases.
>>
>> Is your dataset cosmological? I wouldn't be surprised if there are subtle
>> differences in the way units are set up for comoving and non-comoving
>> simulations.
>>
>> On Thu, Jun 4, 2015 at 2:59 PM, Desika Narayanan <dnarayan at haverford.edu>
>> wrote:
>>
>>> Hey YT-dev,
>>>
>>> I've discovered something that I think could maybe be a bug (though
>>> maybe not) in the Ramses front end but am unsure about the motivation
>>> behind the code so thought I'd check in and try to learn a bit.
>>>
>>> In frontends/ramses/data_structures.py, I think the length_unit is set
>>> to be the length_unit that comes from the info_xxx.txt file multiplied by
>>> the box length.   For the example yt data sets, this doesn't impact
>>> anything because the box lengths are unity.
>>>
>>> In examining some Agora snapshots, however the box lengths are not unity
>>> - one that I'm looking at for example has a boxlen of 600.  This results in
>>> length units that aren't similar to what the info_xxx.txt file says, and
>>> more dramatically, mass units that are very different.  For example, in one
>>> such snapshot, I read from the info file:
>>>
>>> boxlen      =  0.600000000000000E+03
>>> time        =  0.500035810875167E+00
>>> aexp        =  0.100000000000000E+01
>>> H0          =  0.100000000000000E+01
>>> omega_m     =  0.100000000000000E+01
>>> omega_l     =  0.000000000000000E+00
>>> omega_k     =  0.000000000000000E+00
>>> omega_b     =  0.000000000000000E+00
>>> unit_l      =  0.308656802500000E+22
>>> unit_d      =  0.157339152800000E-25
>>> unit_t      =  0.308687241173998E+17
>>>
>>> but if I load this snapshot in yt, I get:
>>>
>>> >In [2]: print ds.mass_unit
>>> 9.9935115109e+46 g
>>>
>>> >In [3]: print ds.mass_unit.in_units("Msun")
>>> 5.02586592269e+13 Msun
>>>
>>> >In [4]: print ds.length_unit
>>> 1.851940815e+24 cm
>>>
>>> which consequently results in derived quantities from the simulation
>>> (like stellar mass) that are totally off (by a factor boxlen**3).
>>>
>>> So, I'm writing (as a total Ramses novice) to try to understand the
>>> motivation behind multiplying the length unit by the boxlen in the
>>> frontend, and if I should be accounting for this factor of boxlen**3 in my
>>> analysis, or if this is a bona fide bug.
>>>
>>> Thanks,
>>> -desika
>>>
>>> ps I updated this morning:
>>>
>>> thundersnow:yt desika$ hg id
>>> 8d3663ac217d+ (yt) tip
>>>
>>> _______________________________________________
>>> 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/20150605/c44b6781/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.png
Type: image/png
Size: 31025 bytes
Desc: not available
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20150605/c44b6781/attachment.png>


More information about the yt-dev mailing list