Mailman 3 May 2013 - yt-dev

Issue #564: Projections not passing field parameters (yt_analysis/yt)
by dcollins4096 10 May '13

10 May '13

New issue 564: Projections not passing field parameters https://bitbucket.org/yt_analysis/yt/issue/564/projections-not-passing-fiel… dcollins4096: If I have a field defined as such: add_field('linewidth',function=linewidth, validators=[ValidateParameter('avg_vx')]) and some region region = pf.h.region(Center,Left,Right) region.set_field_parameter('avg_vx',15) plotting a projection of that region fails to find the field_parameter: proj = oober.pf.h.proj(2,'linewidth',source=region) >>> proj = oober.pf.h.proj(2,'linewidth',source=region) Initializing tree 0 / 4100% |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| Time: 00:00:00 Traceback (most recent call last): | ETA: --:--:-- File "<stdin>", line 1, in <module> File "/nics/b/home/collins/local_2013_03_12/src/yt-hg/yt/data_objects/data_containers.py", line 1758, in __init__ self._refresh_data() File "/nics/b/home/collins/local_2013_03_12/src/yt-hg/yt/data_objects/data_containers.py", line 318, in _refresh_data self.get_data() File "/nics/b/home/collins/local_2013_03_12/src/yt-hg/yt/data_objects/data_containers.py", line 1859, in get_data self._add_level_to_tree(tree, level, fields) File "/nics/b/home/collins/local_2013_03_12/src/yt-hg/yt/data_objects/data_containers.py", line 1981, in _add_level_to_tree self._add_grid_to_tree(tree, grid, fields, zero_out, dls) File "/nics/b/home/collins/local_2013_03_12/src/yt-hg/yt/data_objects/data_containers.py", line 1925, in _add_grid_to_tree for fd in self._get_data_from_grid(grid, fields)] File "/nics/b/home/collins/local_2013_03_12/src/yt-hg/yt/data_objects/data_containers.py", line 93, in save_state tr = func(self, grid, field, *args, **kwargs) File "/nics/b/home/collins/local_2013_03_12/src/yt-hg/yt/data_objects/data_containers.py", line 2003, in _get_data_from_grid return [grid[field] * bad_points for field in fields] File "/nics/b/home/collins/local_2013_03_12/src/yt-hg/yt/data_objects/grid_patch.py", line 157, in __getitem__ self.get_data(key) File "/nics/b/home/collins/local_2013_03_12/src/yt-hg/yt/data_objects/grid_patch.py", line 200, in get_data self._generate_field(field) File "/nics/b/home/collins/local_2013_03_12/src/yt-hg/yt/data_objects/grid_patch.py", line 132, in _generate_field self.pf.field_info[field].check_available(self) File "/nics/b/home/collins/local_2013_03_12/src/yt-hg/yt/data_objects/field_info_container.py", line 364, in check_available validator(data) File "/nics/b/home/collins/local_2013_03_12/src/yt-hg/yt/data_objects/field_info_container.py", line 440, in __call__ raise NeedsParameter(doesnt_have) yt.data_objects.field_info_container.NeedsParameter: (['avg_vx']) Responsible: MatthewTurk

1 0

3.0 alpha 2 is coming
by Matthew Turk 10 May '13

10 May '13

Hi all, Just a reminder, if you want stuff to go into the 3.0 alpha 2 release, please start wrapping up your work so it can be reviewed in a PR by the 15th. (I'm trying to have the new octree stuff done by the end of the week so that it can get at least tested by a few people before going in.) -Matt

1 1

Issue #563: mkdir_rec does not work with absolute paths (yt_analysis/yt)
by Britton Smith 09 May '13

09 May '13

New issue 563: mkdir_rec does not work with absolute paths https://bitbucket.org/yt_analysis/yt/issue/563/mkdir_rec-does-not-work-with… Britton Smith: The mkdir_rec (recursive mkdir) starts with "." as the base, so absolute paths don't get made properly. Responsible: brittonsmith

1 0

Issue #562: Reason Slices/Projections Broken (yt_analysis/yt)
by Sam Skillman 09 May '13

09 May '13

New issue 562: Reason Slices/Projections Broken https://bitbucket.org/yt_analysis/yt/issue/562/reason-slices-projections-br… Sam Skillman: Currently reason slices/projections are broken, with the following traceback: ``` #!text Traceback (most recent call last): File "/home/skillman/local/src/yt-hg/yt/gui/reason/basic_repl.py", line 91, in execute exec code in self.locals File "", line 1, in File "/home/skillman/local/src/yt-hg/yt/gui/reason/widget_store.py", line 79, in create_slice pw = PWViewerExtJS(sl, (DLE[xax], DRE[xax], DLE[yax], DRE[yax]), setup = False) File "/home/skillman/local/src/yt-hg/yt/visualization/plot_window.py", line 561, in __init__ self.setup_callbacks() File "/home/skillman/local/src/yt-hg/yt/visualization/plot_window.py", line 670, in setup_callbacks if self._plot_type.startswith('OffAxis'): AttributeError: 'PWViewerExtJS' object has no attribute '_plot_type' ``` Responsible: samskillman

1 0

Issue #561: SlicePlot set_width() does not work with unitful arguments (yt_analysis/yt)
by J.S. Oishi 09 May '13

09 May '13

New issue 561: SlicePlot set_width() does not work with unitful arguments https://bitbucket.org/yt_analysis/yt/issue/561/sliceplot-set_width-does-not… J.S. Oishi: The documentation for set_width() says that it can take an argument using a tuple (10, 'cm') for each x component of the x-y plot, for example: sp = SlicePlot(pf, "z", "MagneticPressure") sp.set_width((25.6, 'cm'), (10, 'cm')) However, this returns a slice with the width unchanged. Using code units, e.g.: sp = SlicePlot(pf, "z", "MagneticPressure") sp.set_width(1, 0.4) works fine.

1 0

field interpolater question
by Britton Smith 08 May '13

08 May '13

Hi all, I'm working on some analysis that requires interpolating from some data tables. Normally, I would use the Unilinear, Bilinear, and TrilinearFieldInterpolators in yt, but they only accept evenly spaced bins, which I don't have. It actually looks like the cython function which does the calculation accepts the bins as arrays, which the python function creates from the given bounds. I'd like to change this behavior to allow me to give the bins to the python function. Currently, the call to create the interpolator looks like this: BilinearInterpolator(table, boundaries, field_names) where boundaries is (x_0, x_n, y_0, y_n) or the min/max of the x and y bins. Would it be ok if I changed this so that boundaries can also be a pair of arrays? I would just have the function check and still maintain the old way as well. By doing it this way, it shouldn't break backward compatibility either. Would this be an ok solution? Britton

2 2

Bitbucket notifications upgrades
by Nathan Goldbaum 08 May '13

08 May '13

Hi all, Bitbucket just released a significant upgrade to their e-mail notification system: http://blog.bitbucket.org/2013/05/07/beautiful-and-relevant-notifications/ You can now sign up to receive notifications about new pull requests, issues, and commits on a repository by repository basis and will by default receive e-mail when someone @mentions your bitbucket nick. If you've ever been annoyed about getting too many or not enough e-mails from bitbucket, now is the time to adjust your settings to your liking. Cheers, Nathan

1 0

Native field discussion
by Casey W. Stark 08 May '13

08 May '13

Hey yt. Nathan and I had a cool idea as an extension of the units work, but I am hitting a yt internals knowledge wall writing a YTEP. I would like some input on technical details or general feelings before I move ahead with the write-up. One of the things mentioned in the units YTEP is handling code units. Basically each frontend static output should register the code units. In Nyx for instance, we would do something like registering "code_length" as Mpccm, "code_mass" as Msun, etc. Then any field from the dataset can be loaded in code units with something like dd["density"].in_units("code_density"). This got us thinking -- why load native fields in CGS now? Instead, we can define native fields exactly as they are on disk and users who want code units will never have to convert by hand again. If frontend developers define the fields and units on disk, and some mapping to the universal fields, we shouldn't have to define or convert units anywhere else. I made a quick and dirty example of what we're thinking here: http://paste.yt-project.org/show/3441/ So, is something like this a good idea? Is it realistic? Would this make for a simpler field info container? Nathan, is there anything I missed? - Casey

7 14

[yt_analysis/yt] Flash answer tests needs to be regenerated (issue #560)
by Kacper Kowalik 08 May '13

08 May '13

New issue 560: Flash answer tests needs to be regenerated https://bitbucket.org/yt_analysis/yt/issue/560/flash-answer-tests-needs-to-… Kacper Kowalik: Due to recent [commit](https://bitbucket.org/yt_analysis/yt/commits/532858bcf68d/) several tests for flash frontend fail with ``` #!bash File "/usr/lib64/python2.7/unittest/case.py", line 327, in run testMethod() File "/usr/lib64/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/tmp/jenkins/workspace/py2.7-yt-2.x_testing/yt/utilities/answer_testing/framework.py", line 305, in __call__ nv = self.run() File "/tmp/jenkins/workspace/py2.7-yt-2.x_testing/yt/utilities/answer_testing/framework.py", line 449, in run data_source = obj) File "/tmp/jenkins/workspace/py2.7-yt-2.x_testing/yt/data_objects/data_containers.py", line 1760, in __init__ self._refresh_data() File "/tmp/jenkins/workspace/py2.7-yt-2.x_testing/yt/data_objects/data_containers.py", line 320, in _refresh_data self.get_data() File "/tmp/jenkins/workspace/py2.7-yt-2.x_testing/yt/data_objects/data_containers.py", line 1861, in get_data self._add_level_to_tree(tree, level, fields) File "/tmp/jenkins/workspace/py2.7-yt-2.x_testing/yt/data_objects/data_containers.py", line 1983, in _add_level_to_tree self._add_grid_to_tree(tree, grid, fields, zero_out, dls) File "/tmp/jenkins/workspace/py2.7-yt-2.x_testing/yt/data_objects/data_containers.py", line 1927, in _add_grid_to_tree for fd in self._get_data_from_grid(grid, fields)] File "/tmp/jenkins/workspace/py2.7-yt-2.x_testing/yt/data_objects/data_containers.py", line 95, in save_state tr = func(self, grid, field, *args, **kwargs) File "/tmp/jenkins/workspace/py2.7-yt-2.x_testing/yt/data_objects/data_containers.py", line 2005, in _get_data_from_grid return [grid[field] * bad_points for field in fields] File "/tmp/jenkins/workspace/py2.7-yt-2.x_testing/yt/data_objects/grid_patch.py", line 157, in __getitem__ self.get_data(key) File "/tmp/jenkins/workspace/py2.7-yt-2.x_testing/yt/data_objects/grid_patch.py", line 200, in get_data self._generate_field(field) File "/tmp/jenkins/workspace/py2.7-yt-2.x_testing/yt/data_objects/grid_patch.py", line 145, in _generate_field self[field] = self.pf.field_info[field](self) File "/tmp/jenkins/workspace/py2.7-yt-2.x_testing/yt/data_objects/field_info_container.py", line 393, in __call__ dd = self._function(self, data) File "/tmp/jenkins/workspace/py2.7-yt-2.x_testing/yt/data_objects/field_info_container.py", line 151, in _TranslationFunc return data[field_name] File "/tmp/jenkins/workspace/py2.7-yt-2.x_testing/yt/data_objects/grid_patch.py", line 157, in __getitem__ self.get_data(key) File "/tmp/jenkins/workspace/py2.7-yt-2.x_testing/yt/data_objects/grid_patch.py", line 200, in get_data self._generate_field(field) File "/tmp/jenkins/workspace/py2.7-yt-2.x_testing/yt/data_objects/grid_patch.py", line 147, in _generate_field raise exceptions.KeyError(field) 'velo' ```

1 0

[yt_analysis/yt] The TotalMass derived quantity fails when no particles are present (issue #559)
by Nathan Goldbaum 07 May '13

07 May '13

New issue 559: The TotalMass derived quantity fails when no particles are present https://bitbucket.org/yt_analysis/yt/issue/559/the-totalmass-derived-quanti… Nathan Goldbaum: As brought up by Mark Krumholz on the mailing list: http://paste.yt-project.org/show/3445/ We should check to make sure particles are in the dataset before including them instead of assuming they're there. Responsible: ngoldbaum

1 0