11:20 p.m.
Hi, I am generating Halos using HOP (via yt). I see that the default overdensity is 160. I
guess it means 160 particles per cell. But isn't cell size a function of the
simulation box volume and the grid ?
For example, if Box=200Mpc and Ngrid=512^3, then cell=(0.390625 Mpc)^3
Isn't 0.390625 Mpc too big for a galaxy ?
What is the calculation behind 160 ?
shankar
KU Cosmology
11:31 p.m.
Shankar,
Hi, I am generating Halos using HOP (via yt). I see that the default
overdensity
is 160. I guess it means 160 particles per cell.
No, it is not 160 particles per cell. See below.
But isn't cell size a function
of the simulation box volume and the grid ?
For example, if Box=200Mpc and Ngrid=512^3, then cell=(0.390625 Mpc)^3
Isn't 0.390625 Mpc too big for a galaxy ?
Yes, but, and no, this is not actually what matters. Yes, galaxies are not 390 Kpc on a
side, typically, but you're not looking for galaxies with HOP. You're looking for
dark matter haloes (which is where galaxies live), which are much larger than galaxies.
They may not be as large as 390 Kpc across, but luckily, HOP doesn't actually care
about the cell size, so having a dark matter halo smaller than the cell is not a problem.
What is the calculation behind 160 ?
The over-density threshold in HOP refers to the cutoff density for the least-dense members
of any halo. That number is the multiple of the overall average density *in the
simulational box*, not the universe, which is an important point to remember. All HOP
cares about is the positions and masses of dark matter particles, it knows nothing about
the gridding, cosmology, or day of the week. I suggest you read the HOP method paper,
especially section 2.2, which explains what the over-density threshold parameter means.
http://adsabs.harvard.edu/abs/1998ApJ...498..137E
Good luck!
_______________________________________________________
sskory(a)physics.ucsd.edu o__ Stephen Skory
http://physics.ucsd.edu/~sskory/ _.>/ _Graduate Student
________________________________(_)_\(_)_______________
12:28 a.m.
New subject: Comoving units
Hello everyone:
I upgraded to the new version of yt, and I noticed there was a
change in unit designation. I used to be able to specify units in
comoving units of kpc as: "kpccm", but that functionality now appears to
be broken. Does anyone know what the new syntax is for using comoving
units?
Here is a code example that used to work, but it no longer does in the
new version:
pf = EnzoStaticOutput(filename)
thick_faceon = 10.0/pf['kpccm']
Thanks!
Cameron
--
Cameron Hummels
PhD Candidate, Astronomy Department of Columbia University
Public Outreach Director, Astronomy Department of Columbia University
NASA IYA New York State Student Ambassador
http://outreach.astro.columbia.edu
12:35 a.m.
New subject: Comoving units
Hi Cameron,
Over here it's working for me with 1.5 and trunk:
In [2]: pf = load("RD0005-mine/RedshiftOutput0005")
In [3]: pf["kpccm"]
Out[3]: 7692.3076923076915
Looking at the source, which I am now officially putting on my "clean
this up" list, it looks like the comoving units only get set up if the
parameter "ComovingCoordinates" is set in the enzo parameter file:
http://yt.enzotools.org/browser/trunk/yt/lagos/OutputTypes.py#L323
and then if it is, this routine gets called:
http://yt.enzotools.org/browser/trunk/yt/lagos/OutputTypes.py#L340
which sets up all the /h and comoving stuff. I guess the question now
is, is yt skipping over the line where it sets those units up, or is
it misunderstanding the ComovingCoordinates line in the parameter
file? Could you let me know what the value of "
pf['ComovingCoordinates'] " is, and what the line in the Enzo
parameter file is as well? For me, it looks like:
In [5]: pf["ComovingCoordinates"]
Out[5]: 1
and the line in the file is:
ComovingCoordinates = 1
Thanks, Cameron!
-Matt
On Mon, Nov 23, 2009 at 10:58 AM, Cameron Hummels
<chummels(a)astro.columbia.edu> wrote:
Hello everyone:
I upgraded to the new version of yt, and I noticed there was a change in
unit designation. I used to be able to specify units in comoving units of
kpc as: "kpccm", but that functionality now appears to be broken. Does
anyone know what the new syntax is for using comoving units?
Here is a code example that used to work, but it no longer does in the new
version:
pf = EnzoStaticOutput(filename)
thick_faceon = 10.0/pf['kpccm']
Thanks!
Cameron
--
Cameron Hummels
PhD Candidate, Astronomy Department of Columbia University
Public Outreach Director, Astronomy Department of Columbia University
NASA IYA New York State Student Ambassador
http://outreach.astro.columbia.edu
_______________________________________________
yt-users mailing list
yt-users(a)lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
1:37 a.m.
New subject: Comoving units
Hi Matt:
Here are my outputs in 1.5 and trunk iyt:
-----------------------------------------------------------
In [1]: pf = load("L20S2D9H26S_0050")
In [2]: pf["kpccm"]
---------------------------------------------------------------------------
KeyError Traceback (most recent call last)
/u/ac/chummels/source/yt-x86_64/src/yt-1.5/scripts/iyt in <module>()
----> 1
2
3
4
5
/u/ac/chummels/source/yt-x86_64/src/yt-1.5/yt/lagos/OutputTypes.pyc in
__getitem__(self, key)
104 self.conversion_factors]:
105 if key in d: return d[key]
--> 106 raise KeyError(key)
107
108 def keys(self):
KeyError: 'kpccm'
In [3]: pf["ComovingCoordinates"]
Out[3]: 1
----------------------------------------------------------------------
My enzo parameter file also has the comoving coordinates flag set as
yours does. Weird...
ComovingCoordinates = 1
Cameron
Matthew Turk wrote:
Hi Cameron,
Over here it's working for me with 1.5 and trunk:
In [2]: pf = load("RD0005-mine/RedshiftOutput0005")
In [3]: pf["kpccm"]
Out[3]: 7692.3076923076915
Looking at the source, which I am now officially putting on my "clean
this up" list, it looks like the comoving units only get set up if the
parameter "ComovingCoordinates" is set in the enzo parameter file:
http://yt.enzotools.org/browser/trunk/yt/lagos/OutputTypes.py#L323
and then if it is, this routine gets called:
http://yt.enzotools.org/browser/trunk/yt/lagos/OutputTypes.py#L340
which sets up all the /h and comoving stuff. I guess the question now
is, is yt skipping over the line where it sets those units up, or is
it misunderstanding the ComovingCoordinates line in the parameter
file? Could you let me know what the value of "
pf['ComovingCoordinates'] " is, and what the line in the Enzo
parameter file is as well? For me, it looks like:
In [5]: pf["ComovingCoordinates"]
Out[5]: 1
and the line in the file is:
ComovingCoordinates = 1
Thanks, Cameron!
-Matt
On Mon, Nov 23, 2009 at 10:58 AM, Cameron Hummels
<chummels(a)astro.columbia.edu> wrote:
> Hello everyone:
>
> I upgraded to the new version of yt, and I noticed there was a change in
> unit designation. I used to be able to specify units in comoving units of
> kpc as: "kpccm", but that functionality now appears to be broken. Does
> anyone know what the new syntax is for using comoving units?
> Here is a code example that used to work, but it no longer does in the new
> version:
>
> pf = EnzoStaticOutput(filename)
> thick_faceon = 10.0/pf['kpccm']
>
> Thanks!
> Cameron
>
>
> --
> Cameron Hummels
> PhD Candidate, Astronomy Department of Columbia University
> Public Outreach Director, Astronomy Department of Columbia University
> NASA IYA New York State Student Ambassador
> http://outreach.astro.columbia.edu
>
> _______________________________________________
> yt-users mailing list
> yt-users(a)lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>
>
_______________________________________________
yt-users mailing list
yt-users(a)lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
--
Cameron Hummels
PhD Candidate, Astronomy Department of Columbia University
Public Outreach Director, Astronomy Department of Columbia University
NASA IYA New York State Student Ambassador
http://outreach.astro.columbia.edu
1:44 a.m.
New subject: Comoving units
Hi Camera,
This is definitely a bug. Would you be able to send me *just* the
parameter file, L20S2D9H26S_0050, off-list, so that I can identify the
problem and fix it in both 1.5 and trunk?
Thanks,
Matt
On Mon, Nov 23, 2009 at 12:07 PM, Cameron Hummels
<chummels(a)astro.columbia.edu> wrote:
Hi Matt:
Here are my outputs in 1.5 and trunk iyt:
-----------------------------------------------------------
In [1]: pf = load("L20S2D9H26S_0050")
In [2]: pf["kpccm"]
---------------------------------------------------------------------------
KeyError Traceback (most recent call last)
/u/ac/chummels/source/yt-x86_64/src/yt-1.5/scripts/iyt in <module>()
----> 1
2
3
4
5
/u/ac/chummels/source/yt-x86_64/src/yt-1.5/yt/lagos/OutputTypes.pyc in
__getitem__(self, key)
104 self.conversion_factors]:
105 if key in d: return d[key]
--> 106 raise KeyError(key)
107
108 def keys(self):
KeyError: 'kpccm'
In [3]: pf["ComovingCoordinates"]
Out[3]: 1
----------------------------------------------------------------------
My enzo parameter file also has the comoving coordinates flag set as yours
does. Weird...
ComovingCoordinates = 1
Cameron
Matthew Turk wrote:
Hi Cameron,
Over here it's working for me with 1.5 and trunk:
In [2]: pf = load("RD0005-mine/RedshiftOutput0005")
In [3]: pf["kpccm"]
Out[3]: 7692.3076923076915
Looking at the source, which I am now officially putting on my "clean
this up" list, it looks like the comoving units only get set up if the
parameter "ComovingCoordinates" is set in the enzo parameter file:
http://yt.enzotools.org/browser/trunk/yt/lagos/OutputTypes.py#L323
and then if it is, this routine gets called:
http://yt.enzotools.org/browser/trunk/yt/lagos/OutputTypes.py#L340
which sets up all the /h and comoving stuff. I guess the question now
is, is yt skipping over the line where it sets those units up, or is
it misunderstanding the ComovingCoordinates line in the parameter
file? Could you let me know what the value of "
pf['ComovingCoordinates'] " is, and what the line in the Enzo
parameter file is as well? For me, it looks like:
In [5]: pf["ComovingCoordinates"]
Out[5]: 1
and the line in the file is:
ComovingCoordinates = 1
Thanks, Cameron!
-Matt
On Mon, Nov 23, 2009 at 10:58 AM, Cameron Hummels
<chummels(a)astro.columbia.edu> wrote:
Hello everyone:
I upgraded to the new version of yt, and I noticed there was a change in
unit designation. I used to be able to specify units in comoving units of
kpc as: "kpccm", but that functionality now appears to be broken. Does
anyone know what the new syntax is for using comoving units?
Here is a code example that used to work, but it no longer does in the new
version:
pf = EnzoStaticOutput(filename)
thick_faceon = 10.0/pf['kpccm']
Thanks!
Cameron
--
Cameron Hummels
PhD Candidate, Astronomy Department of Columbia University
Public Outreach Director, Astronomy Department of Columbia University
NASA IYA New York State Student Ambassador
http://outreach.astro.columbia.edu
_______________________________________________
yt-users mailing list
yt-users(a)lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________
yt-users mailing list
yt-users(a)lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
--
Cameron Hummels
PhD Candidate, Astronomy Department of Columbia University
Public Outreach Director, Astronomy Department of Columbia University
NASA IYA New York State Student Ambassador
http://outreach.astro.columbia.edu
_______________________________________________
yt-users mailing list
yt-users(a)lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
2:42 a.m.
New subject: Comoving units
Hi Cameron (not Camera) and everyone else,
This was a bug in yt-1.5, not trunk, and I've fixed it in r1541. When
I tested it initially, I thought I was running on both 1.5 and trunk,
but that was mistaken, and I only tested in trunk. It's now fixed!
-Matt
On Mon, Nov 23, 2009 at 12:14 PM, Matthew Turk <matthewturk(a)gmail.com> wrote:
Hi Camera,
This is definitely a bug. Would you be able to send me *just* the
parameter file, L20S2D9H26S_0050, off-list, so that I can identify the
problem and fix it in both 1.5 and trunk?
Thanks,
Matt
On Mon, Nov 23, 2009 at 12:07 PM, Cameron Hummels
<chummels(a)astro.columbia.edu> wrote:
> Hi Matt:
>
> Here are my outputs in 1.5 and trunk iyt:
>
>
> -----------------------------------------------------------
>
> In [1]: pf = load("L20S2D9H26S_0050")
>
> In [2]: pf["kpccm"]
> ---------------------------------------------------------------------------
> KeyError Traceback (most recent call last)
>
> /u/ac/chummels/source/yt-x86_64/src/yt-1.5/scripts/iyt in <module>()
> ----> 1
> 2
> 3
> 4
> 5
>
> /u/ac/chummels/source/yt-x86_64/src/yt-1.5/yt/lagos/OutputTypes.pyc in
> __getitem__(self, key)
> 104 self.conversion_factors]:
> 105 if key in d: return d[key]
> --> 106 raise KeyError(key)
> 107
> 108 def keys(self):
>
> KeyError: 'kpccm'
>
> In [3]: pf["ComovingCoordinates"]
> Out[3]: 1
>
> ----------------------------------------------------------------------
>
>
> My enzo parameter file also has the comoving coordinates flag set as yours
> does. Weird...
>
> ComovingCoordinates = 1
>
> Cameron
>
>
> Matthew Turk wrote:
>
> Hi Cameron,
>
> Over here it's working for me with 1.5 and trunk:
>
> In [2]: pf = load("RD0005-mine/RedshiftOutput0005")
>
> In [3]: pf["kpccm"]
> Out[3]: 7692.3076923076915
>
> Looking at the source, which I am now officially putting on my "clean
> this up" list, it looks like the comoving units only get set up if the
> parameter "ComovingCoordinates" is set in the enzo parameter file:
>
> http://yt.enzotools.org/browser/trunk/yt/lagos/OutputTypes.py#L323
>
> and then if it is, this routine gets called:
>
> http://yt.enzotools.org/browser/trunk/yt/lagos/OutputTypes.py#L340
>
> which sets up all the /h and comoving stuff. I guess the question now
> is, is yt skipping over the line where it sets those units up, or is
> it misunderstanding the ComovingCoordinates line in the parameter
> file? Could you let me know what the value of "
> pf['ComovingCoordinates'] " is, and what the line in the Enzo
> parameter file is as well? For me, it looks like:
>
> In [5]: pf["ComovingCoordinates"]
> Out[5]: 1
>
> and the line in the file is:
>
> ComovingCoordinates = 1
>
> Thanks, Cameron!
>
> -Matt
>
> On Mon, Nov 23, 2009 at 10:58 AM, Cameron Hummels
> <chummels(a)astro.columbia.edu> wrote:
>
>
> Hello everyone:
>
> I upgraded to the new version of yt, and I noticed there was a change in
> unit designation. I used to be able to specify units in comoving units of
> kpc as: "kpccm", but that functionality now appears to be broken. Does
> anyone know what the new syntax is for using comoving units?
> Here is a code example that used to work, but it no longer does in the new
> version:
>
> pf = EnzoStaticOutput(filename)
> thick_faceon = 10.0/pf['kpccm']
>
> Thanks!
> Cameron
>
>
> --
> Cameron Hummels
> PhD Candidate, Astronomy Department of Columbia University
> Public Outreach Director, Astronomy Department of Columbia University
> NASA IYA New York State Student Ambassador
> http://outreach.astro.columbia.edu
>
> _______________________________________________
> yt-users mailing list
> yt-users(a)lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>
>
>
> _______________________________________________
> yt-users mailing list
> yt-users(a)lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>
>
>
> --
> Cameron Hummels
> PhD Candidate, Astronomy Department of Columbia University
> Public Outreach Director, Astronomy Department of Columbia University
> NASA IYA New York State Student Ambassador
> http://outreach.astro.columbia.edu
>
> _______________________________________________
> yt-users mailing list
> yt-users(a)lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>
>
3284
days inactive
3284
days old
6 comments
4 participants
participants (4)
-
Agarwal, Shankar -
Cameron Hummels -
Matthew Turk -
Stephen Skory