Hi all,
Sometime in the next day or two, pull request #1000 in the yt_analysis/yt
repository will be created.
I want to congratulate everyone who has contributed to that goal.
If you are a yt user and have noticed something that you want to fix,
please feel free to send us patches. We love patches!
More information about contributing to yt here:
http://yt-project.org/docs/dev-3.0/developing/index.html
Here's to PR #10000!
-Nathan
Hi all,
I think this question is primarily for John ZuHone, but please feel free to
jump in.
I'm currently looking at the FITS frontend for my scipy talk.
I just made a projection of the M33 HI data cube we have on the data hub.
The image is here: http://i.imgur.com/kcw98g8.png
I know that we decided to not try to jam WCS axes into the PlotWindow code,
instead reserving that for PlotWindowWCS. I agree with that.
However, I'm confused about the units of the z-axis. Presumably, the units
of the actual observation are km/s. Did we ever investigate making the
units of the z-axis km/s? Is that not possible at the moment due to a
restriction that all three axes must have spatial units?
Thanks for your advice,
Nathan
Hey yt-devs,
I'm trying to debug some Cython routines and want to throw in some print
statements. However, when adding a simple python print statement I get the
following compile error:
Python print statement not allowed without gil
Is there other way to do this here? Any other Cython debugging tips people
have would also be very welcome.
Britton
Hello everyone,
As I'm updating some of the documentation in 3.0 to be current on field
generation, I thought of something that might make the particle fields a
bit more clean as we build on them in the future.
As I understand it, each particle type from a given code will generate its
own namespace for those native particle quantities. So for example a
Gadget binary dataset will read in its star, gas, and DM particles as:
('star', 'particle_mass')
('gas', 'particle_mass')
('DM', 'particle_mass')
but when these different particles are deposited and smoothed on to the
grid, they all get put into the same 'deposit' namespace:
('deposit', 'star_density')
('deposit', 'gas_density')
('deposit', 'DM_density')
It seems to me that perhaps we should create a separate deposit namespace
for each of the native particle types, so that we'll have a clean 1-to-1
conversion between native particle types and smoothed particle types in
namespaces. Now the above fields would map to:
('deposit_star', 'density')
('deposit_gas', 'density')
('deposit_DM', 'density')
This doesn't seem like it would be hard to change in the field-generation
infrastructure, but it might break things later on, which I've just not yet
considered. Anyway, I just wanted to bounce this off of people. It may
not be better in the long run, but it seemed like if we're breaking API, it
should be done now instead of later on. I may be missing something big
here, but I wanted to see what others thought.
Cameron
--
Cameron Hummels
Postdoctoral Researcher
Steward Observatory
University of Arizona
http://chummels.org
What is the source for the default values of the cosmological parameters in yt.utilities.Cosmology? It looks like WMAP7, but we haven't exactly said where.
Hi all,
There's a minor issue with the PhasePlot class that I'd like to fix -
unfortunately fixing it implies an API change. Before I issue a pull
request I'd like to ask the group what they think.
Right now a PhasePlot can be created in two ways. Both are via the
PhasePlot constructor. The first uses what we have in the docs:
ph = PhasePlot(dd, 'density', 'temperature', ['cell_mass', 'cell_volume'])
The second is via the profile keyword argument:
profile = create_profile(dd, ['density', 'temperature'], ['cell_mass',
'cell_volume'])
ph = PhasePlot(source, None, None, None, profile=profile)
As you can see, the second approach is not so nice right now due to the
positional arguments in the PhasePlot initializer (I'm passing None where I
can pass dummy arguments -- I could pass anything in these slots, they are
ignored by the PhasePlot initializer).
This would make a lot more sense if PhasePlot didn't have positional
arguments and you could just do PhasePlot(profile=profile). Then again,
I'd prefer not to change the API so drastically and add possible headaches
for dealing with the two ways the PhasePlot initializer can be used.
For ProfilePlot, we don't have a profile keyword argument. Instead there
is a classmethod named from_profiles that creates a ProfilePlot without
explicitly invoking the class initializer.
I'd like to add a from_profiles method to PhasePlot to help make this
nicer. I'd also like to remove the profile keyword argument, but wanted to
check with the list first before opening a PR that breaks the PhasePlot
API. I could also leave the profile keyword argument, but for the sake of
simplicity I'd prefer if from_profiles were the only way to create a
PhasePlot from a profile object.
Thanks for your advice!
-Nathan
Hi all,
I'd like to update my open plotting docs PR (
https://bitbucket.org/yt_analysis/yt/pull-request/985/updates-for-the-nar...)
with examples for a few of the new plot callbacks in yt-3. I have examples
for everything except for annotate_triangle_facets.
Does anyone have an example usage for the triangle_facets callback? I
believe this was added for the work to support MOAB/PYNE.
-Nathan
Hi all,
Does anybody have an Occulus Rift dev kit? If so, are you by any
chance going to SciPy this year, and/or able and willing to transmit
the kit to someone who is going?
Alternately, anybody happen to have a Google Cardboard?
-Matt
