I'm trying to understand how the particle deposition fields work for
grid-based codes. Specifically, how does yt handle particles that are close
to the grid boundaries, so that the CIC interpolation stencil involves
cells on grid(s) other than the one that contains the particle position?.
Like, say I did:
ds = yt.load(fn)
g = ds.index.grids
print g['deposit', 'all_cic']
How does yt handle the fact that particles other than those living on "g"
can contribute to the total CIC density? Does it grab a layer of "ghost
particles" somehow? I can't seem to find where that happens.
Sorry if I'm just missing something obvious here...
Are there any requirements/restrictions on what types of codes should be
added as new frontends in the yt repository?
I ask because yesterday I wrote a frontend for a collaborator working with
the Dumses code. As best I can tell, Dumses is a stripped-down version of
Ramses, but without the AMR and with a completely different file format.
Also, as best I can tell, only a handful of people (mainly at the CEA?)
work on this code, and it is nigh-impossible to find any information on the
interwebs about it.
Should I fold this new frontend into the main yt repo, or just give the
users of Dumses the frontend code and let them do what they will? The
former might pull in a couple more users/developers, but the latter would
keep us from cluttering yt/frontends.
At Britton's great suggestion, let's move the discussion of what to do with
species fields from BitBucket comments to here. For reference, see the
discussion in the comments here . Note that the current situation is
outlined in YTEP-003, specifically the section on species names .
The main issue is that yt supports a wide range of codes, which are
applicable in various domains of science and sometimes the nomenclature
clashes. What is meant by 'species' is a prime example. 'Species' can
mean atomic elements, ions, or nuclei (perhaps others?), and the definition
of each of these should - if it is possible - be made explicit.
Agreeing on the yt-internal nomenclature for this explicitness requires
There seems to be an issue accessing the nuclei density fields. These are
derived fields that give the total number density of an element with names
like "H_nuclei_density." At some point, these have stopped working and I
am trying to debug this. To reproduce this, one can do the following:
ds = yt.load("enzo_cosmology_plus/DD0046/DD0046")
ad = ds.all_data()
I have traced this as far as the following. In the call to
create_field_info, a YTFieldNotFound exception is raised on line 137 of
yt/fields/species_fields.py. Here, the nuclei density field function is
trying to access a number density field that should exist, but doesn't seem
to at the moment. Later on it does, but not at this moment. Does anyone
have any advice for where to look next?
New issue 916: Geometric fields cannot be used in the definition of a fluid field
This causes an error in the way the FITS frontend is currently setup, minimally reproducible script is here:
import numpy as np
ds = yt.load("xray_fits/A2052_merged_0.3-2_match-core_tmap_bgecorr.fits",
def _counts(field, data):
exposure_time = data.get_field_parameter("exposure_time")
ds.add_field(name="counts", function=_counts, units="counts", take_log=False)
The problem is that the `('fits', 'pixel')` field depends on the `('index', 'ones')` field, which doesn't get generated until after the `pixel` field is created.
Recently the python packaging ecosystem has come up with a new way of
sharing binary builds of python packages to end users. This takes the form
of so-called "binary wheels" (everything in python packaging is a joke
about cheese...). The main advantage of wheels is that users installing
via pip on Windows and OSX will no longer need compilers to build yt and
installation will also proceed significantly faster. As far as I can tell,
wheels are discouraged on Linux since it's assumed that users will use
their OS package manager to install binary builds. You may even be using
wheels right now - matplotlib, numpy, and many other projects with c
extensions are now distributing wheels on OS X and windows. More
information about wheels is available here:
The main downside of wheels is that it's another piece of tooling to
I just tested and with a newish version of setuptools and the "wheel"
package installed, our setup script can produce wheels! You just need to
do "python setup.py bdist_wheel".
I'm curious whether people would be agreeable in principle to uploading
wheels to PyPI as a (semi-)automated part of our release process. Please
let me know what you think.
I'm seeing some behavior with units of axes that seems
counter-intuitive, but maybe I need to change my intuition.
In particular, if one makes a slice plot, but specifies the width of the
plot in units of 'code_length' - for example, from using domain_right_edge
- the units aren't properly converted to whatever was set as
`ds.length_unit`. Is this working as intended? Are users expected to
manually apply `.in_cgs()` to such items that have code_length? Naively, I
would expect that when units are displayed, if they are code_* units, they
should be converted to whatever is declared in