Hi,
for all those people that enforced "From: Cameron -> /dev/null" due to
recent spambomb, I'm forwarding the email shedding some light on what
happened. I'm partial responsible for it too, since it was I who
suggested to use "Milestone" keyword on bb's issue tracker.
Sorry for that!
Cheers,
Kacper
es on BB Issues
To: yt-dev(a)lists.spacepope.org
Everyone:
Several of the developers at the yt workshop are reclassifying the
bitbucket issues to better "tag" them for future handling. We decided to
use the "Milestone" field as a way of triaging these into several
categories: easy, moderate, difficult, longterm, and waiting for future
development. As part of this, we (I) made the dubious decision to remove
the previous numbered milestones because they were redundant with version
as we had been using them. This has resulted in a HUGE number of emails to
the list for all of the milestone modifications, which you have undoubtedly
received. For that I want to personally apologize, since we were unaware
this would be the behavior even on closed tickets.
I hope these new milestones will be useful in the future, and again I'm
sorry for all of the spam.
Cameron
--
Cameron Hummels
Postdoctoral Researcher
Steward Observatory
University of Arizona
http://chummels.org
--
Cameron Hummels
Postdoctoral Researcher
Steward Observatory
University of Arizona
http://chummels.org
New issue 922: Add particle support to volume renderer
https://bitbucket.org/yt_analysis/yt/issue/922/add-particle-support-to-volu…
Cameron Hummels:
An old version of the volume rendering software (using homogenized volume) could handle laying down particles as splotches in the render. This is super useful, and I think we should work to eventually get this into the VR.
Everyone:
Several of the developers at the yt workshop are reclassifying the
bitbucket issues to better "tag" them for future handling. We decided to
use the "Milestone" field as a way of triaging these into several
categories: easy, moderate, difficult, longterm, and waiting for future
development. As part of this, we (I) made the dubious decision to remove
the previous numbered milestones because they were redundant with version
as we had been using them. This has resulted in a HUGE number of emails to
the list for all of the milestone modifications, which you have undoubtedly
received. For that I want to personally apologize, since we were unaware
this would be the behavior even on closed tickets.
I hope these new milestones will be useful in the future, and again I'm
sorry for all of the spam.
Cameron
--
Cameron Hummels
Postdoctoral Researcher
Steward Observatory
University of Arizona
http://chummels.org
New issue 921: Querying non-periodic datasets outside of domain fails and needs more descriptive error
https://bitbucket.org/yt_analysis/yt/issue/921/querying-non-periodic-datase…
Cameron Hummels:
Right now when one attempts to index a region outside of the domain of a non-periodic dataset, one gets a somewhat opaque error.
Example:
```
#!python
$ yt load GasSloshingLowRes/sloshing_low_res_hdf5_plt_cnt_0690
box = ds.box(ds.domain_right_edge, 2*ds.domain_right_edge)
box.quantities.total_mass()
RuntimeError: Error: bad Region in non-periodic domain along dimension 0. Region left edge = 3.0856e+24 code_length, R
egion right edge = 6.1712e+24 code_lengthDataset left edge = -3.0856e+24 code_length, Dataset right edge = 3.0856e+24
code_length
```
It would be better to have a more descriptive error that you're trying to index a region outside of the valid domain.
Hi all,
The Software Sustainability Institute (http://www.software.ac.uk/) in
the UK is running a petition:
http://bit.ly/SoftwareIsFundamental
I wanted to pass it along, and to encourage you to read it and if it
speaks to you, to both consider signing and to pass it on to others.
-Matt
PS If you're going to SC14, be sure to come to the WSSSPE workshop,
where this topic and others will be the subject of productive
discussion!
New issue 919: Reading ORION2 sink particle files
https://bitbucket.org/yt_analysis/yt/issue/919/reading-orion2-sink-particle…
Anonymous:
yt is having problems reading empty ORION2 sink particle files (on the Chombo frontend).
When I try to make a plot (e.g., a sliceplot) it also reads in the corresponding sink particle file but if no sink particles have been created yet the file will only contain "0 0" and this causes an IO error.
Here's the traceback:
<ipython-input-29-2969b1e8c4ac> in <module>()
----> 1 slcx =SlicePlot(pf, 'x', 'tracer1')
/home/rosen/yt-x86_64/src/yt-hg/yt/visualization/plot_window.pyc in SlicePlot(ds, normal, fields, axis, *args, **kwargs)
1841 del kwargs['north_vector']
1842
-> 1843 return AxisAlignedSlicePlot(ds, normal, fields, *args, **kwargs)
/home/rosen/yt-x86_64/src/yt-hg/yt/visualization/plot_window.pyc in __init__(self, ds, axis, fields, center, width, axes_unit, origin, fontsize, field_parameters, window_size, aspect)
1013 slc = ds.slice(axis, center[axis],
1014 field_parameters = field_parameters, center=center)
-> 1015 slc.get_data(fields)
1016 PWViewerMPL.__init__(self, slc, bounds, origin=origin,
1017 fontsize=fontsize, fields=fields,
/home/rosen/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.pyc in get_data(self, fields)
600 def get_data(self, fields=None):
601 if self._current_chunk is None:
--> 602 self.index._identify_base_chunk(self)
603 if fields is None: return
604 nfields = []
/home/rosen/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.pyc in index(self)
127 if self._index is not None:
128 return self._index
--> 129 self._index = self.ds.index
130 return self._index
131
/home/rosen/yt-x86_64/src/yt-hg/yt/data_objects/static_output.pyc in index(self)
272 raise RuntimeError("You should not instantiate Dataset.")
273 self._instantiated_index = self._index_class(
--> 274 self, dataset_type=self.dataset_type)
275 # Now we do things that we need an instantiated index for
276 # ...first off, we create our field_info now.
/home/rosen/yt-x86_64/src/yt-hg/yt/frontends/chombo/data_structures.pyc in __init__(self, ds, dataset_type)
522
523 def __init__(self, ds, dataset_type="orion_chombo_native"):
--> 524 ChomboHierarchy.__init__(self, ds, dataset_type)
525
526 def _detect_output_fields(self):
/home/rosen/yt-x86_64/src/yt-hg/yt/frontends/chombo/data_structures.pyc in __init__(self, ds, dataset_type)
116 self.float_type = self._handle['Chombo_global'].attrs['testReal'].dtype.name
117 self._levels = [key for key in self._handle.keys() if key.startswith('level')]
--> 118 GridIndex.__init__(self, ds, dataset_type)
119
120 self._read_particles()
/home/rosen/yt-x86_64/src/yt-hg/yt/geometry/geometry_handler.pyc in __init__(self, ds, dataset_type)
63 # potentially quite expensive, and should be done with the indexing.
64 mylog.debug("Detecting fields.")
---> 65 self._detect_output_fields()
66
67 def __del__(self):
/home/rosen/yt-x86_64/src/yt-hg/yt/frontends/chombo/data_structures.pyc in _detect_output_fields(self)
536 self.particle_filename = self.index_filename[:-4] + 'sink'
537 if not os.path.exists(self.particle_filename): return
--> 538 pfield_list = [("io", c) for c in self.io.particle_field_index.keys()]
539 self.field_list.extend(pfield_list)
540
/home/rosen/yt-x86_64/src/yt-hg/yt/frontends/chombo/io.pyc in particle_field_index(self)
279 fn = self.ds.fullplotdir[:-4] + "sink"
280
--> 281 index = parse_orion_sinks(fn)
282
283 self._particle_field_index = index
/home/rosen/yt-x86_64/src/yt-hg/yt/frontends/chombo/io.pyc in parse_orion_sinks(fn)
224 with open(fn, 'r') as f:
225 lines = f.readlines()
--> 226 line = lines[1]
227
228 # The basic fields that all sink particles have
IndexError: list index out of range
Responsible: atmyers
Hi everyone,
The astro group at NCSA is in the process of hiring postdocs:
http://www.ncsa.illinois.edu/about/jobs/postdoc_astro
Postdocs in this group will have the opportunity to work on
computational tools, especially yt, and to apply those tools both to
astrophysics as well as other domains of science.
I've attached a PDF copy of the ad, and I would encourage you to
forward this on to any colleagues or groups that may be interested.
Please email me at mturk(a)ncsa.illinois.edu if you have any questions!
Best,
Matt
Hi all,
I was just looking through yt/data_object/selection_data_containers.py and
noticed that there are two nearly identical YTCuttingPlaneBase.to_frb
functions. They are almost the same with just a different kwarg and one
other line. This may have been a bad merge. Can someone who is familiar
with this area take a quick look and either get rid of one or tell me which
one should be removed?
Thanks,
Britton
Hello yt developers!
In thinking about adding communications plumbing to yt, so that it could listen & respond to requests made over the network somehow (e.g. "using currently loaded dataset, render an image from the following viewpoint").
We could roll our own using low-level socket stuff, and a select() or something in the main loop - that wouldn't be too bad. But I see that the zeromq messaging library is already among the dependencies of yt. At least, ipython depends on zeromq.
So the question(s) are,
does yt itself already use zeromq? (if so, then it sounds as though new communications stuff should use it too)
If yt doesn't, then any advice on choosing which path to take?
If we roll our own with a poll-for-message in yt's main loop somewhere,
then where in the yt source tree is that main loop's code?