Mailman 3 March 2013 - yt-dev

Problems with periodicity in 2.x and 3.0
by Matthew Turk March 19, 2013

March 19, 2013

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, … [View More]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 [View Less]

1 0

fcoords / fwidth in yt-3.0
by Matthew Turk March 19, 2013

March 19, 2013

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 … [View More]

1 0

[yt_analysis/yt] yt plot is broken in 3.0 (issue #530)
by Nathan Goldbaum March 18, 2013

March 18, 2013

--- 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 … [View More]

1 0

[yt_analysis/yt] SlicePlot plots unrequested fields when plotting derived fields (issue #529)
by John ZuHone March 15, 2013

March 15, 2013

--- 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 … [View More]

1 0

[yt_analysis/yt] Cartesian coordinates broken for FLASH datasets in 3.0 (issue #528)
by John ZuHone March 15, 2013

March 15, 2013

--- 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 … [View More]

1 0

[yt_analysis/yt] Adding support for Python3 (issue #527)
by Kacper Kowalik March 15, 2013

March 15, 2013

--- 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.

4 3

Announcing yt 3.0 alpha 1
by Matthew Turk March 15, 2013

March 15, 2013

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 … [View More]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! [View Less]

1 0

[yt_analysis/yt] Derived fields depending on user defined field parameter cannot be stored in GDF sidecar (issue #526)
by Kacper Kowalik March 15, 2013

March 15, 2013

--- 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 … [View More]

1 0

[yt_analysis/yt] Plotting 'TotalEnergy' with Enzo frontend results in error (issue #525)
by Kacper Kowalik March 15, 2013

March 15, 2013

--- 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 <… [View More]

1 0

Releasing 3.0a1
by Matthew Turk March 14, 2013

March 14, 2013

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:… [View More]

4 5