Dear all,
For my master's research, I installed yt and I want to load my research data converted to gadget2 format with yt.
The function I want to use is the clump function, and I want to create a similar figure by performing the same processing as the Clump Finding below.
https://yt-project.org/doc/cookbook/constructing_data_objects.html#cookbook…
First of all, I tried to test with the gadget data placed in the data index, but neither the default nor the hdf5 format works.
Is it possible to do Clump Finding in Gadget2 format?
Hi all,
Thanks for all your help over the last couple of days. One more question:
- Can I plot particles on a volume rendered image?
I have stars and I want to show where they are!
Thanks,
Libby
--
Elizabeth Harper-Clark MA MSci
PhD Candidate, Canadian Institute for Theoretical Astrophysics, UofT
Sciences and Engineering Coordinator, Teaching Assistants' Training Program,
UofT
www.astro.utoronto.ca/~h-clark <http://www.astro.utoronto.ca/%7Eh-clark>
h-clark(a)cita.utoronto.ca
Astronomy office phone: +1-416-978-5759
It appears that Yt does not run Rockstar correctly. Here are 2 issues we
discovered so far:
1. DM particle mass and hence halo masses are incorrect in a simulation
with baryons. Here are lines from one of out_*.list for a simulation
with 1024^3 particles in a 40 cMpc/h box:
#Om = 0.303600; Ol = 0.696400; h = 0.681400
#Particle mass: 4.22991e+06 Msun/h
The particle mass should be 2.77536623e11*0.3036/0.6814*40**3/1024**3 =
7370552 Msun
Instead, the reported value is 4.22991e+06 Msun/h = 6207675 Msun, which
is exactly 2.77536623e11*0.2557/0.6814*40**3/1024**3 and 0.2557 =
Omega_{DM}, not Omega_M.
The same incorrect value is reported independently of what I set for the
dm_only argument to RockstarHaloFinder.
In a DMO simulation with identical initial conditions the particle mass
is reported correctly:
#Particle mass: 5.02229e+06 Msun/h
This is for the snapshot read by the artio frontend.
2. I tried to circumvent the previous bug by setting
particle_mass=5.02229e+06 in the call to RockstarHaloFinder, but that
dies with the following error:
p['particle_mass'].convert_to_units("Msun / h")
P002 yt : [ERROR ] 2021-06-01 19:17:19,937 AttributeError: 'float'
object has no attribute 'convert_to_units'
It appears that the argument of particle_mass keyword must be some class
rather than a number as listed in the documentation.
3. When running on a simulation with a non-zero DC mode Yt sets the box
size incorrectly:
> fgrep '#Box size' out_*
out_0.list:#Box size: 40.216236 Mpc/h
out_1.list:#Box size: 40.216236 Mpc/h
...
out_14.list:#Box size: 40.216236 Mpc/h
It appears that Yt uses the value Lbox*abox/auni for the first snapshot,
and never recomputes it for the following snapshots. That corrupts halo
positions, and, what is even worse, applies periodic wrapping
incorrectly, so halos near the box boundaries are messed up.
Nick Gnedin
--
This email has been checked for viruses by AVG.
https://www.avg.com
Dear yt and rockstar users,
I recently installed the newest version of rockstar-galaxies as I had been
using a much older version. Although the output reports a particle mass of
1.31418e+05 Msun/h, I don't see any halos smaller than 1e+08 Msun/h. I was
expecting to get the minimum masses an order of magnitude lower.
I see in the config includes MIN_HALO_OUTPUT_SIZE = 25, set as a default. I
tried to change this parameter to 10 and restart from the beginning, but I
run rockstar within yt with RockstarHaloFinder (
yt.extensions.astro_analysis.halo_finding.rockstar.api), but my config file
was overwritten by the defaults. Is this even the right approach? If so,
how do I restart rockstar (more detailed than just rh.run(restart=True),
please) with customized parameters within yt's RockstarHaloFinder?
Thanks in advance,
--
Carla Bernhardt
PhD Student
Universität Heidelberg
ZAH Institut für Theoretische Astrophysik
Hello All!
I am having some trouble understanding the interplay between a few gas fields, namely ('gas', 'density'), ('gas', 'cell_mass'), and ('gas', 'cell_volume'). Looking at the O/H ratios at various radii for some galaxies has lead me to some confusion in how to properly convert between these .
I am using a script like this to construct a sphere of a given radius (here 10% of the virial radius) and find the mass of the gas within it:
###BEGIN SCRIPT
import yt
ds = yt.load('/Volumes/My Passport for Mac/VELAhalos_4_1_2021/GEN6/VELA07_snap/10MpcBox_csf512_a0.500.d')
x = ds.quan(19.97536, 'Mpccm/h')
y = ds.quan(19.58991, 'Mpccm/h')
z = ds.quan(20.38296, 'Mpccm/h')
center = [x,y,z]
radius = yt.YTQuantity(185.12684881603383 , 'kpc')
sp_10percent = ds.sphere(center, radius * 0.1)
gas_density, gas_volume, gas_mass = sp_10percent.quantities.total_quantity([('gas', 'density'), ('gas', 'cell_volume'), ('gas', 'cell_mass')])
##END SCRIPT
This script returns these values:
gas_density = 11770623025851.596 Msun/kpc**3
gas_volume = 26575.843162683213 kpc**3
gas_mass = 15826330839.340445 Msun
Now, from what I understood, the gas_mass field is derived from the gas_density * gas_volume (from this page https://yt-project.org/doc/reference/field_list.html). However, doing that calculation returns a value around 10^16 Msun, not anywhere close to the 10^9 value returned by the cell_mass field. I am wondering the proper way to manually convert from the gas_density to the cell_mass field, and I am clearly missing something in my understanding. I would like to be able to do this outside of yt for convenience as the 'art', 'Metal_Density_SNII' field only returns a density, and not a mass, which I would like to study, so where do I look to find the proper conversion? Or is my understanding of one of the above fields lacking in some way?
Thank you for your time and convience!
Dear all,
I apologize, but after my email yesterday the steering committee discussed
and decided that right now we are *this close* to the yt-4.0 release, and
rather than give a Managing Mischief week half our attention and enthusiasm
we should postpone. Therefore, *Managing Mischief week is NOT happening
next week*.
We really want this virtual yt MM week to be a success, and hopefully give
us something to work off of for future yt-hack weeks, so it *will* happen
this summer, just not in June. Please hang on to your excitement about
this, and we will let you know well in advance of the rescheduled dates.
And...get excited for the yt-4.0 release, coming soon!
Thank you all for your understanding and patience,
Stephanie
(for the yt steering committee)
--
Dr. Stephanie Tonnesen
Associate Research Scientist
CCA, Flatiron Institute
New York, NY
stonnes(a)gmail.com
Hello,
I wanted to ask if yt supports the registration of external data as a field
of an existing dataset.
In case it helps clarify my question, I just wanted to briefly elaborate on
what I'm looking to do. I'm trying to characterize the turbulent velocities
in some high resolution unigrid simulations. Because this involves
convolution, I need to compute the turbulent velocity outside of the yt
infrastructure (this seems beyond the scope of what a user-defined derived
field can support). It would be convenient to be able to load the results
back into yt to use the existing analysis machinery (e.g. for phase plots
and slices). I have thought about using the "Generic Unigrid Data"
frontend, but the simulation's size unfortunately makes that approach
somewhat intractable.
I'm pretty confident that the answer to my question is "no," but I wanted
to be sure before I rolled my own solution. Thank you for your help.
Best,
Matthew Abruzzo
Dear yt-ers!
Next week is our first attempt at a completely virtual yt hack week, so we
hope you can join in to make it a success!
*The goal of this week is "Managing Mischief"--This is when we want dead
code, code styling, and other PRs both submitted and merged. We can take a
look at YTEPs that have been waiting for our attention as well!*
This is a pretty open-ended week, with the goal being to push through these
refactoring-type PRs. If you want to be involved, but aren't sure where to
start, some of the steering committee will be "on-call" throughout the week
on slack so you can ask them what people are working on, or who to ask to
take a look at the PR you are working on.
We are letting this be self-driven, so if you and someone else are hashing
out something and want to zoom, go for it! If slack and github messaging
are getting the job done, stick with that! If you want a third mind on a
call/github discussion to help out, ask!
*Let's try using the #development channel for most of this discussion on
slack. *Post here the PRs you are working on so others can join in! Post
here your questions about code style! Post here your frustration that you
can't pass that last fido test!
*So you know you are not alone, here is when we will definitely be online
thinking yt thoughts. *These are NOT comprehensive (you may get a response
very quickly outside of these times!), but you can expect a quick response
during these days and times:
Monday (June 7):
12 pm - 2pm UTC: Matt Turk and Britton Smith
6 pm - 8 pm UTC: John ZuHone and Cameron Hummels
Tuesday (June 8):
1 pm - 3 pm UTC: Matt Turk and Britton Smith
6 pm - 8 pm UTC: Matt Turk and John ZuHone
Wednesday (June 9):
2 pm - 4 pm UTC: Britton Smith and John ZuHone
Thursday (June 10):
3 pm - 4 pm UTC: Matt Turk and Britton Smith
4 pm - 5pm UTC: Matt Turk and John ZuHone
Friday (June 11):
2 pm - 3 pm UTC: Matt Turk and John ZuHone
7 pm - 8 pm UTC: Matt Turk and John ZuHone
Can't wait to hack away next week!
--Your friendly neighborhood yt steering committee
--
Dr. Stephanie Tonnesen
Associate Research Scientist
CCA, Flatiron Institute
New York, NY
stonnes(a)gmail.com
