[yt-dev] ramses length units

Ricarda Beckmann ricarda.beckmann at astro.ox.ac.uk
Fri Jun 5 16:47:38 PDT 2015 

Hi Nathan,

all sorted and pull request sent. Let me know if I need to do something differently, it’s my first attempt at contributing.

Ricarda

> On 5 Jun 2015, at 18:20, Nathan Goldbaum <nathan12343 at gmail.com> wrote:
> 
> 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 <mailto: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
> 
> 
> <PastedGraphic-1.png>
> 
> 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 <mailto: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 <mailto: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 <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 <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/20150606/9978d748/attachment.htm>

More information about the yt-dev mailing list