Hi yt-users,
Let’s try this again. The file I sent the first time was too large.
I’m using yt version 3.3.1, and I’ve recently encountered an issue loading data correctly. I’m running SPH simulations of white dwarf mergers and want to know what the mass fractions of different elements are at different times. I have two files that contain the data: 1) a tipsy file, 2) and a text file that contains the mass fraction values of helium-4. The tipsy file loads just fine and I’m able to access the information from the helium file once the tipsy file is loaded. For some reason though, when I have more than 262144 particles in my simulation, yt does not load the helium mass fraction values correctly anymore. I’ve initialized all particles to have a 4% helium mass fraction, and all of the particles up to and including the particle indexed by 262143 have this value, but after that the particles all have 0% according to yt. I’ve checked the helium files directly and all values are at 4%. I’m confused as to why yt would stop loading values correctly after a certain point.
I’ve included two tipsy files as well as their corresponding helium mass fraction files. I have also written a script called visualization_test_script.py that makes scatter plots of the white dwarfs showing particles that have correct and incorrect values of helium. I can send more tipsy files if necessary, but they are too large to send any more here.
Thanks,
Matt
Hi ht-users,
Let’s try this again. The file I sent the first time was too large.
I’m using yt version 3.3.1, and I’ve recently encountered an issue loading data correctly. I’m running SPH simulations of white dwarf mergers and want to know what the mass fractions of different elements are at different times. I have two files that contain the data: 1) a tipsy file, 2) and a text file that contains the mass fraction values of helium-4. The tipsy file loads just fine and I’m able to access the information from the helium file once the tipsy file is loaded. For some reason though, when I have more than 262144 particles in my simulation, yt does not load the helium mass fraction values correctly anymore. I’ve initialized all particles to have a 4% helium mass fraction, and all of the particles up to and including the particle indexed by 262143 have this value, but after that the particles all have 0% according to yt. I’ve checked the helium files directly and all values are at 4%. I’m confused as to why yt would stop loading values correctly after a certain point.
I’ve included two tipsy files as well as their corresponding helium mass fraction files. I have also written a script called visualization_test_script.py that makes scatter plots of the white dwarfs showing particles that have correct and incorrect values of helium. I can send more tipsy files if necessary, but they are too large to send any more here.
Thanks,
Matt
The yt community is proud to announce the release of yt 3.3.2!
yt (http://yt-project.org) is an open source, community developed toolkit
for the analysis and visualization of volumetric data of all types, with a
particular emphasis on astrophysical and nuclear engineering simulations.
yt 3.3.2 is a bugfix release that includes a number of fixes and
enhancements for issues discovered after the release of yt 3.3.1. We urge
all yt users to update to the latest version.
If your python installation is managed via conda, update following:
$ conda update -c conda-forge yt
If your python installation is managed via pip, update following:
$ pip install -U yt
Finally, if you manage your yt installation by running out of a clone of
the yt mercurial repository, update following:
$ yt update
We would like to thank the following people for their contributions to this
release:
Corentin Cadiou
Nathan Goldbaum
Cameron Hummels
Suoqing Ji
Ben Keller
Chang-Goo Kim
Kacper Kowalik
Alex Lindsay
Andrew Myers
John Regan
Mark Richardson
Rafael Ruggiero
Hsi-Yu Schive
Britton Smith
Matthew Turk
John Wise
Michael Zingale
John ZuHone
A summary of changes in this release, along with the number of the pull
request implementing the change follows below:
* Ensure package data files are installed to the correct location (PR 2425)
* Ensure particle profile date are interpreted in the correct units for
Enzo data (PR 2423)
* Work around an issue with reading FLASH 2.5 data using the latest release
of h5py. (PR 2421)
* Update docstrings for RockstarHaloFinder (PR 2416)
* Convert the axis argument of the argmax function to a list if it is not
one already (PR 2414)
* Make the annotate_clear callback return an instance of the plot for
improved user experience in the Jupyter notebook (PR 2413)
* Explicitly use integer divion to avoid reading in incorrect grid data in
python3 (PR 2412)
* Suppress logging when searching for datasets in a simulation time series
(PR 2409)
* Update instructions on how to set the log level for the yt logger in the
documentation (PR 2400)
* Various bugfixes for the light ray functionality. These fixes will impact
answers generated by the Trident code. (PR 2321, PR 2323, PR 2342, PR 2344,
PR 2345, PR 2399)
* Don't use /apjs macro in suggested citation (PR 2398)
* Add new fields to the list of known fields in the Enzo frontend (PR 2397)
* Update configuration for nose so that absolute paths to tests work
correctly (PR 2395)
* Add mention of ytree to the merger tree documentation (PR 2393)
* Install netcdf by default in the install script (PR 2389)
* Fix a units issue in the implementation of ds.box (PR 2387)
* Disable a randomly failing test (PR 2384)
* Fix zoom for the perspective lens (PR 2381)
* Fix test failures in a 32 bit build of yt (PR 2380)
* Avoid a zero division error in the volume renderer (PR 2379, PR 2388)
* Don't take the absolute value of the redshift for the timestamp
PlotWindow callback (PR 2373)
* Don't try to read non-existent tipsy auxiliary files (PR 2370)
* Fix a type issue that causes load_octree to crash (PR 2362)
* Performance improvements for the get_vertex_centered_data function (PR
2341)
* Performance improvements for the particle_trajectories analysis module
(PR 2337)
*The LaTeX representation of yt units with numeric multiplicative factors
has been improved (PR 2310)
* The annotate_cell_edges PlotWindow callback now produces output that is
more uniform as a function of image resolution (PR 2307)
* Fix a number of issues in the example skeleton frontend (PR 2357)
* Mention the availability of demo.use.yt in the quickstart guide (PR 2358)
* A realoaded ytdata dataset generated from a profile object can now be
plotted with ProfilePlot or PhasePlot (PR 2357)
* Make smoothed_covering_grid work correctly with 1D and 2D data. (PR 2354)
* Fail more gracefully if yt loads a FLASH dataset with accompanying
particle file and the particle file is not from the same simulation time as
the plot file. (PR 2353)
* Fix an issue with locally defined derived fields not generating correct
colorbar labels (PR 2351)
* Avoid mutating a YTArray passed into the YTArray initializer (PR 2347)
* RAMSES fields and parameters with units of time are now read in correctly
for cosmological simulations (PR 2346, PR 2374)
* Print a nicer error message when trying to create a profile object that
mixes particle and mesh fields (PR 2338)
* Ensure the FixedResolutionBuffer object associated with PlotWindow plots
is regenerated before it is used again if it is invalidated. (PR 2335)
* Fix an issue that would cause incorrect units to be used if units are
passed in at dataset load time with units_override (PR 2334, PR 2407)
* Add gravitational_potential as a known field in the Athena frontend (PR
2333)
* Make 'metallicity' a known field in the stream frontend (PR 2331)
* Prevent a segmentation fault in the volume renderer by accounting for
round-off error. (PR 2328)
* Minor fix for the documentation of the Streamline functionality (PR 2317)
* Spelling fixes in the PlotWindow documentation (PR 2313)
* Add metadata for a number of new castro fields (PR 2312)
* Fix an issue with converting units from the latest version of the Pint
package to yt units (PR 2309)
* Halo properties written out by rockstar-galaxies can now be read in by
the rockstar frontend (PR 2306)
* The git hash of the version of castro used to produce a castro dataset
can now be queried (PR 2305)
* Fix a bug in scene.show() that might cause volume rendering images to now
show up inline in the notebook (PR 2304)
* Various fixes for the install script (PR 2308, PR 2316, PR2311, PR 2327)
Hi all,
I'm still struggling in porting the my ZEUS data in spherical
coordinates in yt. After many tests, I decided that it would by a good
idea to interpolate all my arrays from the spherical (non uniform)
grid to an AMR grid in cartesian (it will help me also with other
software that accepts only cartesian coordinates).
I wrote a python program to create an octree, but it is quite
unefficient. Than, I read that it is possible to create an octree with
yt. What I REALLY would like to do is to compute the octree, save all
grids, all the levels in the GDF format, than with a script open the
GDF format and insert in every grid the interpolated density, energy
etc...
I'm able to create the octree (or at least I think!) using the
attached script, but I don't know how to save it in the GDF format.
Could you help me?
Many thanks,
Andrea
Hi people,
I wish to see the sliceplots of "divergence of velocity" fields in yt. I
see yt has an example of how to derive gradient of a scalar field , is
there any example to show how to derive new field for divergence too ?
Best
Turhan
Hi,
I am getting an issue with a very basic YT code:
I am using the 3.3.1 version and I can not access the cells contained in a sphere (it returns all the cells of the ENZO simulation):
The YT cookbook explains that to access the different fields (for example the x position) of the cells contained in a sphere one must code : ds.sphere[(0.5,0.5,0.5),0.1)][‘x’] …
But it gives me exactly the same results of ds.all_data().[‘x’] which is a 100M cells’ list.
Do you have an idea about selecting only the sphere region easily?
Thanks
Vincent
Dear all,
I would like to get few clarification on
yt.analysis_modules.halo_merger_tree.merger_tree.MergerTree()
1) MergerTree() has a parameter halo_finder_threshold. Does this something
synonym to virial overdensity(like M200 or R200 ) ?
2) FOF_link_length parameter for halo_finder_function = FOFHaloFinder.
The default value is 0.2.
My doubt is, 0.2 is in which unit ? Is it in code unit or Mpc ?
And also halo_finder_function = HaloFinder and halo_finder_function =
FOFHaloFinder are giving entirely different value for the Group Mass in
the MergerHalo.out (a difference of more than one order of magnitude)
thank you.
--
Reju Sam John
Hi all,
I am trying to run Rockstar Halo Finding with the following code.
from yt.mods import *
from yt.analysis_modules.halo_finding.rockstar.api import RockstarHaloFinder
#find all of our simulation files
files = glob.glob("RD*/*hierarchy")
#hopefully the file name order is chronological
files.sort()
print files
ts = TimeSeriesData.from_filenames(files[:])
rh = RockstarHaloFinder(ts)
rh.run()
but I am getting the following error.
File "rockstar_halo_finding.py", line 14, in <module>
rh = RockstarHaloFinder(ts)
File
"/home/john/yt_new/yt-x86_64/src/yt-hg/yt/analysis_modules/halo_finding/rockstar/rockstar.py",
line 220, in __init__
self.pool, self.workgroup = self.runner.setup_pool()
File
"/home/john/yt_new/yt-x86_64/src/yt-hg/yt/analysis_modules/halo_finding/rockstar/rockstar.py",
line 102, in setup_pool
(self.num_writers, "writers") ]
File
"/home/john/yt_new/yt-x86_64/src/yt-hg/yt/utilities/parallel_tools/parallel_analysis_interface.py",
line 325, in from_sizes
pool.add_workgroup(size, name = name)
File
"/home/john/yt_new/yt-x86_64/src/yt-hg/yt/utilities/parallel_tools/parallel_analysis_interface.py",
line 293, in add_workgroup
group = self.comm.comm.Get_group().Incl(ranks)
AttributeError: 'NoneType' object has no attribute 'Get_group'
could you please explain what is going wrong here ?
Thank you.
--
Reju Sam John
Hi people from the yt mailing list,
I'm trying to import to python the rockstar halo finder and it says that an
import error occurred.
I installed yt via the installation script with INST_CONDA=0,
INST_YT_SOURCE=1, ROCKSTAR = 1
ImportError:
dlopen(/Users/Oleg/yt-x86_64/src/yt-hg/yt/analysis_modules/halo_finding/rockstar/rockstar_interface.so,
2): Library not loaded: librockstar.so
Referenced from:
/Users/Oleg/yt-x86_64/src/yt-hg/yt/analysis_modules/halo_finding/rockstar/rockstar_interface.so
Reason: image not found
I'll appreciate any help
Oleg
Hi All,
I'm getting some strange results when I try to profile the particle
distribution.
I'm using the Enzo64 dataset pulled from the YTHub.
I use the following very simple script but get values which are different
by 50 orders of magnitude. I must be doing something very wrong with the
create_profile routine but its not obvious
prof = create_profile(sp, [("all", "particle_radius")], [("all",
"particle_mass")], weight_field=None)
Any ideas what's going wrong here? Looks at a minimum that the units are
getting messed up?
Cheers,
John
