Hi all,
we had a hdd failure on a machine hosting yt's jenkins and blog
instances. PRs are not being tested at the moment. I don't have an ETA
for a replacement yet. I will keep you posted.
Cheers,
Kacper
Hi all,
I am wondering why ProjectionPlot (and others) do not take all the keyword
arguments and pass them to PWViewerMPL and PlotWindow. For example,
currently there is no way to set buff_size at the creation of a plot. One
has to call .set_buff_size after the plot was created.
I am thinking about leaving only the arguments specific to ProjectionPlot
explicitly, and use **kwargs to pass all other arguments to PlotWindow. But
if there are reasons not to do this, please let me know.
Thanks!
Yi-Hao
Hi folks,
I'm currently working on implementing a couple of plots to help investigate
differences between two similar datasets.
I've implemented DifferenceProjectionPlot,
RelativeDifferenceProjectionPlot, and AsymmetryProjectionPlot.
These are available at my fork of yt https://bitbucket.org/krafczyk/yt under
the bookmark 'features/difference_plot'.
Essentially, Each of these Plots is a subclass of PWViewerMPL like
ProjectionPlot, but create's it's FRB by first creating FRBs for the two
data sets then applying an operation to each pixel value to get a new
derived value which is a part of the new FRB.
For DifferenceProjectionPlot this is simply A-B
For RelativeDifferenceProjectionPlot this is (A-B)/A
For AsymmetryProjectionPlot this is (A-B)/(A+B)
It's already been suggested to me that I can avoid creating three new
classes by moving the choice of combination algorithm to a keyword
argument, but I'd like to hear more suggestions.
Thanks,
Matthew Krafczyk
New issue 1304: Boolean objects only inherit the fields present in both of their parent objects
https://bitbucket.org/yt_analysis/yt/issues/1304/boolean-objects-only-inh...
chummels:
Boolean objects are meant to combine the fields present in two data objects from the same dataset. Normally, this means that they will have the same fields present.
However, the `ray` object creates a special field `"t"` as a parametric variable to tell you how far along the ray you are (goes from 0 to 1). When I take an intersection of this `ray` object with a `region` object, the result lacks this `"t"` field because `"t"` is only present in a single parent in the boolean intersection.
Here is an example of this in action with a sample dataset:
import yt
import numpy as np
ds = yt.load("gizmo_cosmology_plus/snap_N128L16_151.hdf5")
ad = ds.all_data()
ad[('gas', 'temperature')]
ray_start = ds.arr(np.random.random(3), 'unitary')
ray_end = ds.arr(np.random.random(3), 'unitary')
ray1 = ds.ray(ray_start, ray_end)
ray2 = ray1 & ad
# ray1 object *has* a t field because it was created from scratch
print ray1['t']
# ray2 object *lacks* a t field because only one of its parents contains it
print ray2['t']
New issue 1303: Boolean Containers only work for 3D objects
https://bitbucket.org/yt_analysis/yt/issues/1303/boolean-containers-only-...
chummels:
In trying to create the intersection of a `Ray` and a `Region` object, yt fails because Boolean operations only exist for 3D selection data containers. It seems like it should work for 1D or 2D data containers with 3D datasets too, but maybe this is harder than I am imagining.
Hi Everyone,
I’m bugging the mailing list to gather opinions from anyone interested the PR <https://bitbucket.org/yt_analysis/yt/pull-requests/2474/wip-refactor-part...> I’m working.
The purpose of the PR <https://bitbucket.org/yt_analysis/yt/pull-requests/2474/wip-refactor-part...> is to refactor the `ParticleDataset` class in yt. Currently the `ParticleDataset` is not much different from `Dataset`, but there sure are common attributes and methods specific to particle datasets that should be put in the `ParticleDataset` class. To make particle dataset better supported in yt, I plan to do the following things:
- Move particle specific operations from `Dataset` to `ParticleDataset`.
- Add some particle dataset specific properties.
- Gather common operations from `ParticleDataset`’s direct inheritance to `ParticleDataset` itself. Currently there are common parts in `TipsyDataset` and `GadgetDataset`’s constructor that I have figured out. There might be more.
- As Nathan suggested, it might be good to have an `SPHParticleDataset` for SPH codes but `ParticleDataset` for pure N-body codes.
If you’re interested in any of these, or have any idea to add, please feel free to leave your comments here or in the PR <https://bitbucket.org/yt_analysis/yt/pull-requests/2474/wip-refactor-part...>.
Thanks,
Bili
Hey everyone,
I've put together a PR of backported bugfixes for an upcoming yt 3.3.3
release. Feel free to glance it over and give comments. The PR includes a
couple dozen bugfixes merged over the last 1.5 months since our last bugfix
release. It passes all the unit tests in py2 and py3, but fails several
answer tests simply because of misalignment between the stable and dev api.
I was hoping to get this merged rather quickly so we can put out the
release in the next day or so. This will be the stable version of yt that
trident builds off of, and we're putting out the trident method paper on
the arxiv this week with our first 1.0 release of the code.
Let me know if you have any questions or comments.
https://bitbucket.org/yt_analysis/yt/pull-requests/2470/backport-bugfixes...
Cameron
--
Cameron Hummels
NSF Postdoctoral Fellow
Department of Astronomy
California Institute of Technology
http://chummels.org
New issue 1302: `take_log` works on generic field name, but not front end name
https://bitbucket.org/yt_analysis/yt/issues/1302/take_log-works-on-generi...
Michael Zingale:
This script reads in a Castro (boxlib) file and makes two plots. The goal is to not take the log. For the first attempt, we disable log using the field `('boxlib', 'density')`. For the next, we use `('gas', 'density').
Note these are ailased to one another as the print shows:
```
On-Disk Field (boxlib, density): (units: g/cm**3, display_name: '\rho')
Alias Field for "('boxlib', 'density')" (gas, density): (units: g/cm**3, display_name: '\rho')
```
but only the one with `gas` successfully disables the log.
```
import yt
ds = yt.load("plt00000")
print(ds.fields.boxlib.density)
print(ds.fields.gas.density)
ds.index
ds.field_info['boxlib','density'].take_log = False
p = yt.SlicePlot(ds,"theta",'density')
p.save("densBoxLib.png")
ds = yt.load("plt00000")
ds.index
ds.field_info['gas','density'].take_log = False
p = yt.SlicePlot(ds,"theta", 'density')
p.save("densGas.png")
```
The test dataset is here:
http://bender.astro.sunysb.edu/random/plt00000.tgz
(for some reason, I can no longer open the datasets on the yt page, so something changed in the front end that I need to investigate separately, and/or, update the sample datasets)
Hi,
I'm okay with this, but let's try to make it obvious where things go.
(which you have all suggested.)
I think astropy does this and has helper functions for it.
Matt
On Dec 8, 2016 9:28 AM, "Britton Smith" <brittonsmith(a)gmail.com> wrote:
HI all,
I agree that it would be best to keep the data files out of the repo. What
about adding some config variables to control where the data gets stored?
We could even have it default to storing things in .config/yt. Perhaps, on
the first import when the data is not there, you just get a notice with
links to wget/curl them.
Britton
On Wed, Dec 7, 2016 at 12:12 PM, Nathan Goldbaum <nathan12343(a)gmail.com>
wrote:
>
>
> On Wed, Dec 7, 2016 at 1:30 PM, John Zuhone <jzuhone(a)gmail.com> wrote:
>
>> Hi everyone,
>>
>> I just issued PR 2465 (https://bitbucket.org/yt_anal
>> ysis/yt/pull-requests/2465/wip-port-the-spectral_integrator-analysis/)
>> to port the spectral integrator analysis module (originally written by
>> Britton) under yt.fields. spectral_integrator is an analysis module that
>> creates X-ray emission fields in user-specified energy bands.
>>
>> The hitch is that spectral_integrator uses HDF5 tables to compute the
>> emissivity, since they are not analytical functions. We currently host
>> those tables on yt-project.org/data. spectral_integrator downloads them
>> automatically if the analysis module is used and they are not present.
>>
>> There was some discussion on Slack as to whether or not this is the
>> correct approach, since it’s not ideal for certain computing environments
>> (e.g., HPC).
>>
>
> Also a problem for e.g. packaging yt on linux distros.
>
>
>> The files are a total of about 2.4 MB in size, so there is some reticence
>> to bundling them with yt.
>>
>
> So my main concern here is adding them to the repo. If you could figure
> out a way to add them to the source distribution without including them in
> the repo (and then issue an error with a URL for non-sdist builds of yt
> [e.g. from the repo]), it wouldn't be a problem.
>
> This isn't really a generic solution for all binary files we might want to
> send to users, but 2.4 MB isn't all that big to be part of an sdist or
> wheel.
>
>
>> There is also the issue that uploading new versions of the tables breaks
>> backward-compatibility. I have sacrificed backwards-compatiblity for
>> considerable simplification of code.
>>
>
> I think the solution is just to use different names for the files or the
> hdf5 datasets or groups here so the code can tell the difference.
>
>
>>
>> Does anyone have any ideas about the best way to handle this issue?
>>
>> Best,
>>
>> John Z
>>
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev(a)lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev(a)lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
_______________________________________________
yt-dev mailing list
yt-dev(a)lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
