yt-dev March 2013

yt-dev@python.org

15 participants
37 discussions

Problems with periodicity in 2.x and 3.0

by Matthew Turk

Hi all, (This message is particularly relevant for Doug, Stephen and Nathan.) I've been tracking down some failing tests. The script I have used is here: http://paste.yt-project.org/show/3266/ Here are the four images: v2 Density: http://i.imgur.com/mdmJqw6.png v2 invrad: http://i.imgur.com/XmBmHZw.png v3 Density: http://i.imgur.com/INlyBdr.png v3 invrad: http://i.imgur.com/qu3tFpc.png They're both wrong. But, in related ways. Note that there's only *one* grid in the fake_random_pf, so the grids may also be getting selected wrong, but that's being masked here by the other problem. v2 => The wrong cells are being selected. This is related to the v3 problem, as v2 uses the RadiusCode field to select cells that are within the data object. v3 => The correct cells are being selected, but the problem with RadiusCode persists. Fortunately, we have a different cell-selection method. (I also think we may have too loose a restriction on cell selection in v3, but that's another topic; once we can sort out this script we can bring that up.) So I think the ultimate problem here is RadiusCode, and underneath that, get_radius. I know I provided comments on this, but I am now having a hard time figuring out how to fix it. Here's the source: def get_radius(data, field_prefix): center = data.get_field_parameter("center") DW = data.pf.domain_right_edge - data.pf.domain_left_edge radius = np.zeros(data[field_prefix+"x"].shape, dtype='float64') r = radius.copy() if any(data.pf.periodicity): rdw = radius.copy() for i, ax in enumerate('xyz'): np.subtract(data["%s%s" % (field_prefix, ax)], center[i], r) if data.pf.periodicity[i] == True: np.subtract(DW[i], r, rdw) np.abs(r, r) np.minimum(r, rdw, r) np.power(r, 2.0, r) np.add(radius, r, radius) np.sqrt(radius, radius) return radius The periodicity seems to be the issue here. As a note, this actually does work with center on 0, 0, 0, which led me to realize it's an asymmetric problem of wrapping-right, and not wrapping-left. I *believe* this can be fixed by changing inside the periodicity check to be: if data.pf.periodicity[i] == True: np.abs(r, r) np.subtract(r, DW[i], rdw) np.abs(rdw, rdw) np.minimum(r, rdw, r) I have issued a pull request for this, but I felt it appropriate to email the list because I would like to make sure this issue is raised for a somewhat larger audience than those who get the PR notifications. https://bitbucket.org/yt_analysis/yt/pull-request/465/get_radius-periodicit… -Matt

8 years, 7 months

fcoords / fwidth in yt-3.0

by Matthew Turk

Hi all, Just as a quick word of warning, John ZuHone found this bug: https://bitbucket.org/yt_analysis/yt/issue/528/cartesian-coordinates-broken… The issue in a nutshell is that fcoords is scaling between 0, 1 but not in a reliable way. I've looked into it and it seems to me that the correct solution is the one John identified: remove the scaling from yt/geometry/cartesian_fields.py . Looking over the code, I believe most of the frontends are in place to do exactly that. I'm going to issue a Pull Request for this bug to the yt_analysis/yt-3.0 repository shortly, where I remove the scaling and offsetting from the cartesian_fields.py file. I have verified (and fixed) that RAMSES & Gadget are correctly setting fcoords and fwidth, but I was hoping to get verification from NMSU-ART and ARTIO before proceeding. https://bitbucket.org/yt_analysis/yt-3.0/pull-request/21/resetting-cartesia… The coordinate setting inside grid_patch is correct, so I think once the octrees are verified, it's ready to go. I'll update the YTEP to explicitly note that fcoords, fwidth must be in the domain coordinates. -Matt PS Fixing the tests -- not sure what's up with them! -- is on my agenda for today.

8 years, 7 months

[yt_analysis/yt] yt plot is broken in 3.0 (issue #530)

by Nathan Goldbaum

--- you can reply above this line --- New issue 530: yt plot is broken in 3.0 https://bitbucket.org/yt_analysis/yt/issue/530/yt-plot-is-broken-in-30 Nathan Goldbaum: Right now specifying a field to plot via the command line like so: $ yt plot -f Temperature DD0000/DD0000 will fail due to the new field tuple syntax. Even the default behavior of -f (e.g. yt plot DD0000/DD0000) is broken since the default is still 'Density' instead of ('gas', 'Density'). I have a monkeypatch that sort of fixes this pasted here: http://paste.yt-project.org/show/3260/ The first section of that diff is pretty clearly correct since this recovers the old functionality. It's not at all clear to me how to handle the second diff since not all fields are 'gas' fields. -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

8 years, 7 months

[yt_analysis/yt] SlicePlot plots unrequested fields when plotting derived fields (issue #529)

by John ZuHone

--- you can reply above this line --- New issue 529: SlicePlot plots unrequested fields when plotting derived fields https://bitbucket.org/yt_analysis/yt/issue/529/sliceplot-plots-unrequested-… John ZuHone: Whenever a derived field is plotted, the fields it depends on are also plotted. For example, when plotting `"Temperature"` from FLASH data, `"temp"` is also plotted. Similarly, plotting `"VelocityMagnitude"` will end up plotting all of the velocity components as well. This did not show up in 2.x versions of `SlicePlot` because the `AMRSlice` object was given a list of fields, whereas now `SlicePlot` calls `slc.get_data(fields)`, and the field dependencies get passed to the FRB as well as the requested fields. Responsible: jzuhone -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

8 years, 7 months

[yt_analysis/yt] Cartesian coordinates broken for FLASH datasets in 3.0 (issue #528)

by John ZuHone

--- you can reply above this line --- New issue 528: Cartesian coordinates broken for FLASH datasets in 3.0 https://bitbucket.org/yt_analysis/yt/issue/528/cartesian-coordinates-broken… John ZuHone: The coordinate fields "x", "y", and "z" are incorrect in FLASH data in 3.0. The notebook at https://hub.yt-project.org/nb/dwg4ew shows an example of this. If you grab the coordinates from the fields themselves, they are shifted by pf.domain_left_edge, but if you look at the data object's fcoords property, these coordinates are correct. I suspect the reason for this is that the geometry handler, which defines the coordinate fields by, e.g. (in yt.geometry.cartesian_fields.py): ``` #!python def _coordX(field, data): return data.pf.domain_left_edge[0] + data.fcoords[...,0] add_cart_field('x', function=_coordX, display_field=False) ``` But for FLASH data the fcoords property already has the correct coordinate translation, I suspect because it is getting it from the grids. This presents a quandary, because changing either the way the field is defined will likely wind up with wrong coordinates for other frontends. Any ideas, @MatthewTurk? I haven't tried it on Enzo data, but I guess this doesn't show up in that case because (once again) domains are usually (0,1). Responsible: jzuhone -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

8 years, 7 months

[yt_analysis/yt] Adding support for Python3 (issue #527)

by Kacper Kowalik

--- you can reply above this line --- New issue 527: Adding support for Python3 https://bitbucket.org/yt_analysis/yt/issue/527/adding-support-for-python3 Kacper Kowalik: yt should work with python3 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

8 years, 7 months

Announcing yt 3.0 alpha 1

by Matthew Turk

Hi everyone, We're proud to announce the first release ALPHA release of yt 3.0. yt has recently transitioned to a time-based release plan ( https://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0008.html ) and this is the first scheduled alpha of 3.0. No date for a "final" release has yet been set. The yt 2.5 codebase, and further updates in the 2.x series, will be supported for a considerable amount of time and you do not need to upgrade. = yt 3.0?! = yt 3.0 represents a new direction forward for yt: getting rid of all the underlying assumptions that data needs to be sectioned off into nice little grid patches. This includes supporting Octree codes natively (NMSU-ART and RAMSES), eventual support for SPH codes, and even opaque data structures where the data is extremely large (ARTIO). We're even planning support for natively handling cylindrical and spherical coordinates. More: http://blog.yt-project.org/post/WhatsUpWith30.html However, this *is* an alpha release. Not all of the existing codes have been ported to 3.0. Below Additionally, this release benefits from the technical and non-technical contributions from many new people. yt is developed in the context of a community of contributors, and with the push toward a new architecture, we aim to expand that community considerably. In particular, this release has considerably benefited from contributions from Chris Moody, Sam Leitner, Doug Rudd, Anthony Scopatz and Kaylea Nelson. = Getting It! = To try out yt 3.0, you can now pull from the main yt repository, update to the yt-3.0 branch, and rebuild your extensions. Or, if you would like to create a new, safely sectioned off environment, simply re-run the normal "development" install script after changing the variable BRANCH to "yt-3.0". = What We Know Works = * RAMSES access to fluids (non-standard fluids require specification) particle access bug fixes coming in next few days * Enzo 2.x and new-style particle IO * FLASH (considerably faster for fluid access) * Stream frontend * NMSU-ART * ARTIO * Gadget: reading particles from disk in standard Gadget-IO, selecting and processing them. Because of the myriad gadget output formats, this may not work for your code yet. * OWLS: reading particles from disk, selecting and processing them. * Tipsy: partial support for reading, selecting and processing Other simulation platforms may work. Not all data objects have been ported, although most have. There may be corner cases (large or small) that have not been explored with these codes. = Reporting Problems = If you test out yt 3.0 we want to hear if it DID or DID NOT work! Feedback is crucial at this time. yt-users and yt-dev are both good forums for discussion, asking questions, and reporting problems. Lots of things have changed on the backend, but we have attempted to minimize the user-facing changes. To report a bug please go here: https://bitbucket.org/yt_analysis/yt/issues/new Note that you will not receive updates if you are not logged in when you create the bug. = What's Next? = The next alpha release (3.0a2) is scheduled to be released on May 15, 2013, but development can be monitored either at http://bitbucket.org/yt_analysis/yt-3.0 or in the main yt repository under the named branch "yt-3.0". We hope to have ready for inclusion additional improvements to Octree codes, a units implementation for arrays, a field naming scheme overhaul, and further robustness for particle codes. If you'd like to participate, please stop by #yt on irc.freenode.net ( http://yt-project.org/irc.html ) or yt-dev ( http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org ), or submit a pull request on BitBucket. = Thanks! = Thank you for reading to the end!

8 years, 7 months

[yt_analysis/yt] Derived fields depending on user defined field parameter cannot be stored in GDF sidecar (issue #526)

by Kacper Kowalik

--- you can reply above this line --- New issue 526: Derived fields depending on user defined field parameter cannot be stored in GDF sidecar https://bitbucket.org/yt_analysis/yt/issue/526/derived-fields-depending-on-… Kacper Kowalik: As reported by @mqk on [ml](http://lists.spacepope.org/pipermail/yt-users-spacepope.org/2013-March/… it's currently impossible to save derived field that relies on user defined field parameter. -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

8 years, 7 months

[yt_analysis/yt] Plotting 'TotalEnergy' with Enzo frontend results in error (issue #525)

by Kacper Kowalik

--- you can reply above this line --- New issue 525: Plotting 'TotalEnergy' with Enzo frontend results in error https://bitbucket.org/yt_analysis/yt/issue/525/plotting-totalenergy-with-en… Kacper Kowalik: As reported by @devinsilvia on #yt, following code: ``` #!python from yt.mods import * pf = load("IsolatedGalaxy/galaxy0030/galaxy0030") slc = SlicePlot(pf, 'z', 'TotalEnergy') slc.save() ``` yields ``` #!bash Traceback (most recent call last): File "simple_plot.py", line 6, in <module> slc = SlicePlot(pf, 'z', 'TotalEnergy') File "/home/xarth/codes/yt-my/yt/visualization/plot_window.py", line 1205, in __init__ PWViewerMPL.__init__(self, slc, bounds, origin=origin, fontsize=fontsize) File "/home/xarth/codes/yt-my/yt/visualization/plot_window.py", line 805, in __init__ PWViewer.__init__(self, *args, **kwargs) File "/home/xarth/codes/yt-my/yt/visualization/plot_window.py", line 579, in __init__ if setup: self._setup_plots() File "/home/xarth/codes/yt-my/yt/visualization/plot_window.py", line 939, in _setup_plots parser.parse(colorbar_label) File "/usr/lib64/python2.7/site-packages/matplotlib/mathtext.py", line 3010, in parse box = self._parser.parse(s, font_output, fontsize, dpi) File "/usr/lib64/python2.7/site-packages/matplotlib/mathtext.py", line 2344, in parse str(err)])) ValueError: m{Energy}$$\/\/(\rm{ergs}/\rm{g})$ ^ Expected end of text (at char 0), (line:1, col:1) ``` -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

8 years, 7 months

Releasing 3.0a1

by Matthew Turk

Hi all, Tomorrow is the fifteenth, which puts us on track for 3.0a1: https://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0008.html Releasing an alpha of 3.0 means: * Tagging in the repo * Sending out an email to yt-users with plenty of caveats * Providing installation instructions * Soliciting feedback I'd like to suggest that this also includes a code dump into yt_analysis/yt at the tag point. This means putting the branch yt-3.0 into the main yt repository. This provides a few things: 1) Anyone who manually pulls can switch much more easily (this will not affect "yt update" I believe) 2) We can consolidate a little bit of the differences between the two repositories 3) Installing 3.0 from the install script just means changing the branch name in install_script.sh. On the downside, a blind "hg update -C" could potentially switch branches. I don't think this is a big deal since this is not a common thing to do. [+-][01] on pushing yt-3.0 branch into yt_analysis/yt? I am neutral to killing off yt_analysis/yt-3.0 at this time and developing yt-3.0 in yt_analysis/yt, but would entertain those suggestions. (This would mean higher traffic on pull requests.) There are still a few outstanding things before the alpha. Doug, would you like me to pull in the artio changes? And Chris, do you think you'll have time to address the outstanding pull request comments? I also intend to fix RAMSES particles tomorrow, but if that doesn't happen it's no big deal. -Matt

8 years, 7 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

yt-dev March 2013