[yt-users] RAMSES units bug in yt-3.0

Sam Geen samgeen at astro.ox.ac.uk
Fri May 9 08:50:03 PDT 2014


Yep, that looks like it should work. I'll try to run it on some particle 
data when I get the time, but like I said I'm 99% sure the mass units 
should be identical for both grid hydro and particle data.

On 09/05/14 17:46, Matthew Turk wrote:
> Hi Sam,
>
> Okay, I've looked over a bit, and I think the correct change would be:
>
> mass_unit = rho_u * length_unit**3.
>
> That should include the correct length unit, and I think will reduce
> "density" back to the "unit_d" that's in the parameter file.  If this
> looks okay to you, I will push it, but I really do want to make sure
> the particle masses are correct.  Can Nick or Romain provide a bit of
> guidance here?
>
> -Matt
>
> On Fri, May 9, 2014 at 11:25 AM, Sam Geen <samgeen at astro.ox.ac.uk> wrote:
>> OK, interesting. In theory RAMSES should have identical units for both
>> particles and gas. I can hunt down a run with particles to test if you like.
>>
>> Thanks!
>> Sam
>>
>>
>> On 09/05/14 17:22, Matthew Turk wrote:
>>> Hi Sam,
>>>
>>> On reflection, I think this might be related to getting the *particle*
>>> masses correct.  I will take a look at it as soon as I can.
>>>
>>> -Matt
>>>
>>> On Fri, May 9, 2014 at 11:00 AM, Sam Geen <samgeen at astro.ox.ac.uk> wrote:
>>>> Hmm, that looks like it should be "mass_unit = rho_u * length_unit**3" in
>>>> line 492. You're right that it mentions the boxlength issue, though.
>>>>
>>>>
>>>> On 09/05/14 16:50, Matthew Turk wrote:
>>>>> Hi Sam,
>>>>>
>>>>> Okay, sounds good.  Looking at how code unit attributes are set up:
>>>>>
>>>>>
>>>>>
>>>>> https://bitbucket.org/yt_analysis/yt/src/a14a150c7c81850df81346162bdaff271e77eb50/yt/frontends/ramses/data_structures.py?at=yt-3.0#cl-482
>>>>>
>>>>> suggests to me that length_unit takes into account boxlen, and
>>>>> mass_unit does not.  The comments have some indication why this might
>>>>> be.
>>>>>
>>>>> -Matt
>>>>>
>>>>> On Fri, May 9, 2014 at 10:46 AM, Sam Geen <samgeen at astro.ox.ac.uk>
>>>>> wrote:
>>>>>> Yep; both this and dd["density"] give cgs values that are too small by
>>>>>> roughly a factor of boxlen**3.
>>>>>>
>>>>>> One other thing I need to try is to make sure I'm using the very latest
>>>>>> version of YT; I've been playing around with the Ramses frontend so
>>>>>> it's
>>>>>> possible my version is somehow out of sync. Will let you know if this
>>>>>> fixes
>>>>>> things.
>>>>>>
>>>>>>
>>>>>> On 09/05/14 16:42, Matthew Turk wrote:
>>>>>>> Hi Sam,
>>>>>>>
>>>>>>> Can you verify the units are in fact incorrect in *cgs*?  Something
>>>>>>> like this would work:
>>>>>>>
>>>>>>> ds = load(...)
>>>>>>> dd = ds.all_data()
>>>>>>> print dd.quantities.total_quantitiy("cell_mass").in_cgs()
>>>>>>>
>>>>>>> Your second message makes me wonder if there's just a slipup in how
>>>>>>> the units are returned.
>>>>>>>
>>>>>>> -Matt
>>>>>>>
>>>>>>> On Fri, May 9, 2014 at 10:37 AM, Sam Geen <samgeen at astro.ox.ac.uk>
>>>>>>> wrote:
>>>>>>>> Sorry for the spam; a second bug I've seen is that the density and
>>>>>>>> pressure
>>>>>>>> unit labels on figures appears to be broken; it seems to print a
>>>>>>>> latex-mangled code names for the units rather than the cgs name of
>>>>>>>> the
>>>>>>>> units; see attached example. Temperature is fine.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 09/05/14 16:28, Sam Geen wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Just to say that in the latest version of yt-3.0 (i.e. since various
>>>>>>>>> fields were renamed or re-implemented), I've found a bug in the
>>>>>>>>> implementation of "cell_mass", which is giving results that are too
>>>>>>>>> low
>>>>>>>>> in
>>>>>>>>> my runs; I believe the issue is that it's missing a factor of
>>>>>>>>> pf["boxlen"]**3 (which is of course only a problem if boxlen is not
>>>>>>>>> 1).
>>>>>>>>> The
>>>>>>>>> previous "CellMass_Msun" worked fine. If I get time I might take a
>>>>>>>>> look
>>>>>>>>> and
>>>>>>>>> issue a pull request, but otherwise I'm just flagging this in case
>>>>>>>>> someone
>>>>>>>>> else runs into problems; you can just manually multiply the result
>>>>>>>>> by
>>>>>>>>> pf["boxlen"]**3 until it's fixed.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>>
>>>>>>>>> Sam
>>>>>>>>> _______________________________________________
>>>>>>>>> yt-users mailing list
>>>>>>>>> yt-users at lists.spacepope.org
>>>>>>>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> yt-users mailing list
>>>>>>>> yt-users at lists.spacepope.org
>>>>>>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> yt-users mailing list
>>>>>>> yt-users at lists.spacepope.org
>>>>>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>>>>
>>>>>> _______________________________________________
>>>>>> yt-users mailing list
>>>>>> yt-users at lists.spacepope.org
>>>>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>>> _______________________________________________
>>>>> yt-users mailing list
>>>>> yt-users at lists.spacepope.org
>>>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>>
>>>> _______________________________________________
>>>> yt-users mailing list
>>>> yt-users at lists.spacepope.org
>>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>> _______________________________________________
>>> yt-users mailing list
>>> yt-users at lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>
>> _______________________________________________
>> yt-users mailing list
>> yt-users at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org




More information about the yt-users mailing list