Why do StellarHsml not always enclose the closest 32 star particles?
Haowen Zhang
22 Apr '22
Hi,
I was wondering why the radius StellarHsml does not always enclose the closest 32 star particles, but sometimes 31 or 33. For the case of 31 particles, what I found is that there's a particle around with very high relative velocity, which might be accelerated by, e.g., feedback or other mechanisms. Is there any other reason why you chose to exclude particles in the neighborhood? Also, what are the reasons to include 33 rather than only 32 particles?
These questions are relevant since I wanna efficiently estimate the 3D velocity field around each star particle using parallel queries of k-d trees. If I can keep the number of neighbor star particles the same (e.g., 32) for every particle, and mask the unwanted (e.g., high velocity) particles using any data field you've provided (like ParticleIDs), that would speed up the calculation process dramatically. Thanks!
Dylan Nelson
22 Apr '22
As the documentation suggests, the StellarHsml enclosed the 32 +/- 1 nearest neighbors. This was just a choice during calculation, but there isn't anyway to change it now. If you want exactly 32 neighbors, you would have to calculate such a distance yourself.
Haowen Zhang
22 Apr '22
Hi Dylan,
Thanks for your response! I totally understand that I need to calculate the radii myself if I want exactly 32 neighbors. But I was just curious how the exact number of neighbors (31,32, or 33) was chosen during the calculation, since at least for the case of 31 particles, you seem to be very successful removing the neighbor particle with high relative velocities, which is a problem I'm having when fixing the neighbor count at 32. Is it possible for you to make the StellarHsml calculation process available to TNG data users?
Dylan Nelson
22 Apr '22
Hi Haowen,
I would suggest to use the scipy.kdtree - the StellarHsml values were essentially computed with a similar code. (It must proceed iteratively, increasing or decreasing the size of the spatial search until the number of enclosed neighbors equals 32 +/- 1).
Haowen Zhang
22 Apr '22
Hi Dylan,
That's exactly what I'm using. The only problem with a variable neighbor count is that I cannot vectorize the calculation and thus it runs much more slowly. With a fixed neighbor count of 32, the code runs ~30x faster, but tend to enclose particles with very high relative velocities that seem to be excluded when your StellarHsml includes only 31 particles. That's why I was wondering if you applied any additional criteria (especially with regards to velocity) when deciding if StellarHsml should include 31, 32, or 33 particles.
Thanks!
Dylan Nelson
22 Apr '22
Hi Haowen,
No, it's just the 32 +/- 1 closest stars, starting from some initial guess, and iterating until that condition is true. No properties other than Coordinates were used.
Hi,
I was wondering why the radius StellarHsml does not always enclose the closest 32 star particles, but sometimes 31 or 33. For the case of 31 particles, what I found is that there's a particle around with very high relative velocity, which might be accelerated by, e.g., feedback or other mechanisms. Is there any other reason why you chose to exclude particles in the neighborhood? Also, what are the reasons to include 33 rather than only 32 particles?
These questions are relevant since I wanna efficiently estimate the 3D velocity field around each star particle using parallel queries of k-d trees. If I can keep the number of neighbor star particles the same (e.g., 32) for every particle, and mask the unwanted (e.g., high velocity) particles using any data field you've provided (like ParticleIDs), that would speed up the calculation process dramatically. Thanks!
As the documentation suggests, the StellarHsml enclosed the
32 +/- 1nearest neighbors. This was just a choice during calculation, but there isn't anyway to change it now. If you want exactly32neighbors, you would have to calculate such a distance yourself.Hi Dylan,
Thanks for your response! I totally understand that I need to calculate the radii myself if I want exactly 32 neighbors. But I was just curious how the exact number of neighbors (31,32, or 33) was chosen during the calculation, since at least for the case of 31 particles, you seem to be very successful removing the neighbor particle with high relative velocities, which is a problem I'm having when fixing the neighbor count at 32. Is it possible for you to make the StellarHsml calculation process available to TNG data users?
Hi Haowen,
I would suggest to use the scipy.kdtree - the StellarHsml values were essentially computed with a similar code. (It must proceed iteratively, increasing or decreasing the size of the spatial search until the number of enclosed neighbors equals 32 +/- 1).
Hi Dylan,
That's exactly what I'm using. The only problem with a variable neighbor count is that I cannot vectorize the calculation and thus it runs much more slowly. With a fixed neighbor count of 32, the code runs ~30x faster, but tend to enclose particles with very high relative velocities that seem to be excluded when your StellarHsml includes only 31 particles. That's why I was wondering if you applied any additional criteria (especially with regards to velocity) when deciding if StellarHsml should include 31, 32, or 33 particles.
Thanks!
Hi Haowen,
No, it's just the 32 +/- 1 closest stars, starting from some initial guess, and iterating until that condition is true. No properties other than Coordinates were used.