yt-dev October 2014

yt-dev@python.org

16 participants
42 discussions

Fwd: ALERT/APOLOGY: Milestone changes on BB Issues

by Kacper Kowalik

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

7 years

Issue #922: Add particle support to volume renderer (yt_analysis/yt)

by Cameron Hummels

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.

7 years

ALERT/APOLOGY: Milestone changes on BB Issues

by Cameron Hummels

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

7 years

Issue #921: Querying non-periodic datasets outside of domain fails and needs more descriptive error (yt_analysis/yt)

by Cameron Hummels

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.

7 years

Software is fundamental petition

by Matthew Turk

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!

7 years

Issue #920: Can't load VLA fits dataset (yt_analysis/yt)

by Anonymous

New issue 920: Can't load VLA fits dataset https://bitbucket.org/yt_analysis/yt/issue/920/cant-load-vla-fits-dataset Anonymous: Greetings, This dataset crashed yt. It is a VLA datacube. Here it is: https://dl.dropboxusercontent.com/u/6285549/TMP/NGC_2403_NA_CUBE_THINGS.FIT… Is probably due to NAXIS=4 yet the 4th dimension is 'dummy'. Cheers, X

7 years

Issue #919: Reading ORION2 sink particle files (yt_analysis/yt)

by Anonymous

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

7 years

Postdoc positions at NCSA

by Matthew Turk

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

7 years

near duplicate to_frb functions in YTCuttingPlaneBase

by Britton Smith

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

7 years

Adding communications plumbing to yt - is zeromq already used by yt?

by Levy, Stuart A

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?

7 years

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

yt-dev October 2014