I'd like to propose adding a new particle union that should be defined for
all datasets that include particles. This came up in the context of the
demeshening work (see
https://bitbucket.org/yt_analysis/ytep/pull-requests/67 for more details).
Right now many of the derived quantities make a distinction between
calculating results using just the gas or just the particles or both. Up
until now they have calculated the results for particles using particle
fields from the 'all' particle union. This makes perfect sense for AMR data
but doesn't really make sense for SPH data, since it will double-count SPH
particles. In fact, I think this is an issue even without the demeshening,
but the demeshening makes it more starkly apparent.
I'd like to propose defining a new "n-body" particle union (suggestions for
alternate names are very welcome) that will be defined for all yt datasets.
This union will be identical to the 'all' particle union for AMR data and
N-body particle data, but for SPH data will only include the particle types
that aren't SPH particles (if any). That means the "n-body" particle type
represents infinitesimal particles but not particles that have finite
extents (e.g. an SPH particle's smoothing region).
I think this new particle type would probably be generically useful beyond
just the derived quantities, maybe even more useful than "all". I also kind
of prefer the name "n-body" to "all" since it more prominently indicates
that it's associated with particle data.
Please let me know if you have thoughts or suggestions about this proposal.
I'm happy to draft a YTEP or update YTEP-0031 with more details if people
want to see that.
We are long overdue for a yt team meeting and I think there is a lot to
talk about. I would like to schedule this meeting as a hangout sometime
within the next couple weeks.
We usually schedule these with a doodle poll. By default, all steering
committee members are invited to the poll, but anyone is welcome to
attend. If you'd like to join in on the meeting, please respond to me by
this Friday and I'll make sure you're invited to the poll.
After Friday, I will make the poll, schedule the meeting, and announce the
Ok, back to work!
New issue 1339: rho-temperature phase diagram for gizmo
Excuse me ,I have a small problem, probably a trivial problem.
I want to create a Density-Temperature phase diagram for gizmo date. I guess yt can help me to achieve this goal . I have read the cookbook but I haven't found any helpful information.
Hello! I've modified the Cosmology class is cosmology.py to take a couple
of parameters for working with the Linder 2002 parameterization of w(a) =
w_0 + w_a (1 - a) in dynamical dark energy, but leaving the cosmological
constant as the default choice. However, because the cosmology class is
used internally in yt in several places (where it takes its parameters from
the dataset object itself), I was thinking it would make the most sense to
add these parameters to the dataset object itself so that they could be set
when loading data (as they're not actually stored in the simulation output
itself). These parameters are a value for w_0, a value for w_a, and a flag
saying whether or not to use dynamical dark energy or the cosmological
constant. I tried looking at the yt source code to find where the best
place to do this would be, but I just thought I would ask, just to be safe
and sure about it.
So, my question is: what do I need to modify in order to add those three
parameters to a generic dataset object (I'm using gadget, but it would be
nice if they were independent of simulation code) so that they can then be
passed to the cosmology class in yt? Thanks!
New issue 1338: _localize_check trying to join strings with None
In yt version 3.3.5 (installed by pip) run in python 2.7.13, when loading a BoxLib format folder I get the following message:
Traceback (most recent call last):
File "get_plot.py", line 20, in <module>
File "xxx/python2.7/site-packages/yt/convenience.py", line 86, in load
return candidates(*args, **kwargs)
File "xxx/python2.7/site-packages/yt/frontends/boxlib/data_structures.py", line 392, in __init__
self.cparam_filename = self._localize_check(cparam_filename)
File "xxx/python2.7/site-packages/yt/frontends/boxlib/data_structures.py", line 415, in _localize_check
File "xxx/python2.7/genericpath.py", line 26, in exists
TypeError: coercing to Unicode: need string or buffer, NoneType found
The problem is occurring in the BoxLibDataset class of data_structures.py
In the __init__ of this class, the parameters, cparam_filename, and fparam_filename are set to None. The function _localize_check will then try to see if if the files exist or not, however, it tries to join the root_dir with the variable cparam_filename which is set to none in the __init__ function. The code crashes because join cannot handle anything but strings and buffers, and it is getting None.
The version of yt in Anaconda (version 3.3.2) has the __init__ function of the BoxLibDataset class define cparam_filename and fparam_filename as string file names ('inputs' and something else I can't remember) that coincide with the BoxLib standards.
New issue 1337: annotate_scale does not work for non-unity aspect ratio
The annotate_scale() function does not work when the aspect ratio is not unity.
from yt.units import kpc
ds = yt.load("IsolatedGalaxy/galaxy0030/galaxy0030")
slc = yt.SlicePlot(ds, 'z', 'density', center=[0.5, 0.5, 0.5],
slc.annotate_scale(coeff=2.0, unit='kpc', pos=(0.1,0.1))
The code works fine when changing the width to (20\*kpc,20\*kpc).