[yt-dev] ramses length units

Ben Thompson bthompson2090 at gmail.com
Thu Jun 4 15:29:38 PDT 2015


If I recall correctly. The RAMSES frontend has not been tested much with
non-cosmological runs as of right not (correct me if I am wrong).

I haven't got any non-comsological datasets to test with right now..
likewise all of my cosmological runs have boxlen = 1.0.  I think I know
where to get hold of a non-cosmological run and when I get the chance I
will load it up with pymses and see what is needed to be changed to work
with non-cosmological models.

Ben

On Thu, Jun 4, 2015 at 7: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/908cc1cd/attachment.html>


More information about the yt-dev mailing list