Hello,
I am making profile plots as a function of height from the galactic disk with several variables for a FLASH simulation of a galaxy. For the low values of the height, the profile plot gives me nonsense for several variables. After loading in the data and setting some units, these are the few lines I am using:
dd = ds.all_data()
d = yt.ProfilePlot(dd, "z", ["magnetic_field_magnitude"], weight_field='ones')
d.set_log("magnetic_field_magnitude", False)
I then change some labels and save the plot, but these two lines are what's most important. For the first ~1 kpc on the height scale, the plot just has a "zig-zag" pattern for the y-axis, magnetic field magnitude from this code, running from the lower to upper bounds, which is complete nonsense for my data. It then follows a nice curve for the remainder of the plot.
Does anyone have any suggestions on how to fix the "zig-zag" at the lower height values?
Thanks,
Jordan Gardipee
Hi all,
I'm using the particle filters to easily sub-select particular types of
particles in an Enzo simulation.
I know that when yt reads a particle field from file or generates a derived
field then this is effectively cached in memory so it doesn't have to be
re-constructed (e.g doing data[('all', 'example_field')] may take a while
initially, but is effectively instantaneous in subsequent calls).
However, I've noticed that when making new particle filters they don't seem
to be taking advantage of this. For example if I have a new particle filter
"all_stars" which is intended to be a subset of "all", filtering by
"particle_type":
@yt.particle_filter(requires=["particle_type"],
filtered_type='all')def all_stars(pfilter, data):
filter = data[(pfilter.filtered_type, "particle_type")] == 2
return filter
I've noticed even when having already "loaded" the particle_type field and
example field for all particles doing something like:
all_pt = data[('all','particle_type')]
all_ef = data[('all,'example_field')]
the calls to get the above for the new particle type (
data[('all_stars','example_field')] ) still takes a while, as though it is
completely re-loading the data. This is wouldn't be too much of a problem
but for the fact that I have ~ a dozen different particle types and would
like to loop over them, and re-loading takes quite a while.
Is there a way I can construct the particle filters to take advantage of
cached data a bit better? Or is this not currently set up this way? (if not
I can just construct the filters myself outside the particle_filter
framework).
Best,
Andew
---
Pasadena Fellow in Theoretical Astrophysics
Carnegie Observatories
California Institute of Technology
Hi all,
I'm using the particle filters to easily sub-select particular types of
particles in an Enzo simulation.
I know that when yt reads a particle field from file or generates a derived
field then this is effectively cached in memory so it doesn't have to be
re-constructed (e.g doing data[('all', 'example_field')] may take a while
initially, but is effectively instantaneous in subsequent calls).
However, I've noticed that when making new particle filters they don't seem
to be taking advantage of this. For example if I have a new particle filter
"all_stars" which is intended to be a subset of "all", filtering by
"particle_type":
@yt.particle_filter(requires=["particle_type"],
filtered_type='all')def all_stars(pfilter, data):
filter = data[(pfilter.filtered_type, "particle_type")] == 2
return filter
I've noticed even when having already "loaded" the particle_type field and
example field for all particles doing something like:
all_pt = data[('all','particle_type')]
all_ef = data[('all,'example_field')]
the calls to get the above for the new particle type (
data[('all_stars','example_field')] ) still takes a while, as though it is
completely re-loading the data. This is wouldn't be too much of a problem
but for the fact that I have ~ a dozen different particle types and would
like to loop over them, and re-loading takes quite a while.
Is there a way I can construct the particle filters to take advantage of
cached data a bit better? Or is this not currently set up this way? (if not
I can just construct the filters myself outside the particle_filter
framework).
Best,
Andew
---
Pasadena Fellow in Theoretical Astrophysics
Carnegie Observatories
California Institute of Technology
Hi,
I'm trying to run the OneZoneFreefallTest in Enzo: /run/Cooling/OneZoneFreefallTest and I get the following error:
Traceback (most recent call last):
File "plot.py", line 6, in <module>
import yt.extensions.EnzoSimulation as ES
ImportError: No module named yt.extensions.EnzoSimulation
I would have guessed that the plotting script has become a bit outdated and lagged behind yt updates, as from what I can see from github is that the last time it has been altered was 7 years ago. Is there instead a different module I should be using, or an alteration I can make to the plot.py script?
Thank you,
Chris Jessop
Hi,
I'm a new user of yt and have inherited some old code and data that was written in 2016 (original script and data: http://paste.yt-project.org/show/234/,
http://use.yt/upload/6961a33c, http://use.yt/upload/b08c0345). The goal of the code was to produce projection plots of the density of tracer particles (notated by negative mass) which follow the ISM of simulated galaxies in groups. I believe it used to work, and produced a projection plot of the density of the tracer particles, called passivecic_field (https://i.imgur.com/woxJfm5.png). When I try to run the code now (using yt 3.60), I get the error KeyError: "No field named ('passive_part', 'passive_mass')".
I attempted to fix the issue by changing 'passive_mass' to 'particle_mass' in the definition of passivecic_field, and changing the filter so it accepts positive rather than negative mass particles, since passive_mass was just a negative scalar multiple of particle mass (new script: http://paste.yt-project.org/show/235/). This allows the code to run, but outputs the plot shown in http://use.yt/upload/0ecc9669, which shows few of the details of the original plot (especially the galaxy tails, which are what I am interested in). Do you know what might be causing the KeyError when passive_mass is used, and why the plot for particle_mass would have so much less detail?
Thanks,
Camryn P.
Hi folks,
As a heads up, we're in the final stages of merging yt-4.0 into the
branch that is presently called "master" on github. So if you are
running off the mainline development, you will soon see this rather
extensive change. You may need to install additional dependencies
(notably unyt) but this should be handled by running "pip install -e
." in your yt directory.
Once this is in, we'll work to update and edit PRs to retarget them.
Most should not need much in the way of changes.
Thanks to everybody who worked so hard to make this happen!
-Matt
Hello,
I've recently recompiled several Enzo data sets with the -g flag to
obtain the gravitational potential field. Several are now producing the
following error when trying to perform any analysis with yt:
File
"/opt/apps/pkgs/cpython/3.7.1/intel64/intel_2019.2/lib/python3.7/site-packages/h5py/_hl/files.py",
line 170, in make_fid
fid = h5f.open(name, flags, fapl=fapl)
File "h5py/_objects.pyx", line 54, in h5py._objects.with_phil.wrapper
File "h5py/_objects.pyx", line 55, in h5py._objects.with_phil.wrapper
File "h5py/h5f.pyx", line 85, in h5py.h5f.open
OSError: Unable to open file (file signature not found)
I was wondering if anyone else has had the same issue and knows of any
workaround? Both Enzo and cpython have been built with version 1.8.17 of
hdf5. I'm using version 3.5.1 of yt and version 3.7.1 of cpython.
Many thanks,
Sam Patrick
Hello again,
I am using yt slices and projections with scale annotation. I have my plots in comoving units ("Mpccm/h") but whenever I want to use the same units for annotation:
slc.annotate_scale(corner='lower_right', coeff=10, units='Mpccm/h'),
yt does not recognize these units. Am I missing something or only the physical scale annotation is possible ?
Thanks,
Salome
Hi yt-users and yt-devs,
As we are getting closer to the yt-4.0 release, we could really use your
help! Do you have an issue with yt that has been bugging you? *In
particular we are looking for API issues:* are there ways that using yt is
inconsistent? Does an argument that you use in one function differ in
another one (e.g. using `axes` in one and `ax` in another? or ds working
for some plotting functions but ad required for others?)? Or would you
expect to be able to use a function on a yt object and it doesn't work the
way you're expecting?
*Please add any issues you have to github! *
https://github.com/yt-project/yt/issues/new
Be as detailed as you can, but don't worry--if someone is confused about
the problem, they will ask you!
*It is important to do this now, so big API changes are added before the
yt-4.0 release! *This will allow them to be better tested for a better yt!!
*(fine print: remember, we all want yt to be perfect, but with limited
person-hours, the yt-4.0 developers will do the best they can. Please
don't be discouraged if your issue isn't solved right away! Also, if you
don't know if your issue falls under "API" you can always add it so
everyone knows about it, even if it doesn't get pushed in the yt-4.0
release!)*
Thanks!
Stephanie
--
Dr. Stephanie Tonnesen
Associate Research Scientist
CCA, Flatiron Institute
New York, NY
stonnes(a)gmail.com
