[yt-dev] ramses length units

Ricarda Beckmann ricarda.beckmann at astro.ox.ac.uk
Fri Jun 5 01:26:52 PDT 2015


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 <mailto: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/pull-request/1335/ramses-unit-conversions/diff>
> https://bitbucket.org/yt_analysis/yt/issue/939/units-error-in-ramses-frontend <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 <mailto: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 <mailto:yt-dev at lists.spacepope.org>
> http://lists.spacepope.org/listinfo.cgi/yt-dev-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 <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/6e8f3348/attachment.html>


More information about the yt-dev mailing list