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
This was last touched back in December: https://bitbucket.org/yt_analysis/yt/pull-request/1335/ramses-unit-conversio... https://bitbucket.org/yt_analysis/yt/issue/939/units-error-in-ramses-fronten... 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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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@gmail.com> wrote:
This was last touched back in December:
https://bitbucket.org/yt_analysis/yt/pull-request/1335/ramses-unit-conversio...
https://bitbucket.org/yt_analysis/yt/issue/939/units-error-in-ramses-fronten...
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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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@gmail.com> wrote:
This was last touched back in December:
https://bitbucket.org/yt_analysis/yt/pull-request/1335/ramses-unit-conversio...
https://bitbucket.org/yt_analysis/yt/issue/939/units-error-in-ramses-fronten...
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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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@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@gmail.com <mailto:nathan12343@gmail.com>> wrote: This was last touched back in December:
https://bitbucket.org/yt_analysis/yt/pull-request/1335/ramses-unit-conversio... <https://bitbucket.org/yt_analysis/yt/pull-request/1335/ramses-unit-conversio...> https://bitbucket.org/yt_analysis/yt/issue/939/units-error-in-ramses-fronten... <https://bitbucket.org/yt_analysis/yt/issue/939/units-error-in-ramses-fronten...>
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@haverford.edu <mailto:dnarayan@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@lists.spacepope.org <mailto:yt-dev@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@lists.spacepope.org <mailto:yt-dev@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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 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@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@haverford.edu <mailto:dnarayan@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@gmail.com <mailto:nathan12343@gmail.com>> wrote: This was last touched back in December:
https://bitbucket.org/yt_analysis/yt/pull-request/1335/ramses-unit-conversio... <https://bitbucket.org/yt_analysis/yt/pull-request/1335/ramses-unit-conversio...> https://bitbucket.org/yt_analysis/yt/issue/939/units-error-in-ramses-fronten... <https://bitbucket.org/yt_analysis/yt/issue/939/units-error-in-ramses-fronten...>
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@haverford.edu <mailto:dnarayan@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@lists.spacepope.org <mailto:yt-dev@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@lists.spacepope.org <mailto:yt-dev@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@lists.spacepope.org <mailto:yt-dev@lists.spacepope.org> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi Ricarda, Thanks so much! -d On Fri, Jun 5, 2015 at 7:25 AM, Ricarda Beckmann < ricarda.beckmann@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
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@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@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@gmail.com> wrote:
This was last touched back in December:
https://bitbucket.org/yt_analysis/yt/pull-request/1335/ramses-unit-conversio...
https://bitbucket.org/yt_analysis/yt/issue/939/units-error-in-ramses-fronten...
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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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@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
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@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@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@gmail.com> wrote:
This was last touched back in December:
https://bitbucket.org/yt_analysis/yt/pull-request/1335/ramses-unit-conversio...
https://bitbucket.org/yt_analysis/yt/issue/939/units-error-in-ramses-fronten...
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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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@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@astro.ox.ac.uk <mailto:ricarda.beckmann@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@astro.ox.ac.uk <mailto:Ricarda.Beckmann@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@haverford.edu <mailto:dnarayan@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@gmail.com <mailto:nathan12343@gmail.com>> wrote: This was last touched back in December:
https://bitbucket.org/yt_analysis/yt/pull-request/1335/ramses-unit-conversio... <https://bitbucket.org/yt_analysis/yt/pull-request/1335/ramses-unit-conversio...> https://bitbucket.org/yt_analysis/yt/issue/939/units-error-in-ramses-fronten... <https://bitbucket.org/yt_analysis/yt/issue/939/units-error-in-ramses-fronten...>
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@haverford.edu <mailto:dnarayan@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@lists.spacepope.org <mailto:yt-dev@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@lists.spacepope.org <mailto:yt-dev@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@lists.spacepope.org <mailto:yt-dev@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@lists.spacepope.org <mailto:yt-dev@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@lists.spacepope.org <mailto:yt-dev@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (4)
-
Ben Thompson -
Desika Narayanan -
Nathan Goldbaum -
Ricarda Beckmann