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
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@physics.ucsd.edu o__ Stephen Skory http://physics.ucsd.edu/~sskory/ _.>/ _Graduate Student ________________________________(_)_\(_)_______________
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
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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
yt-users mailing list yt-users@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
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@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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
yt-users mailing list yt-users@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
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@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@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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
yt-users mailing list yt-users@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
-
Agarwal, Shankar -
Cameron Hummels -
Matthew Turk -
Stephen Skory