[yt-dev] ramses length units

[Desika Narayanan]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20150604/455ed9ca/attachment.htm>