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-periodic...
-Matt
Hi all,
Just as a quick word of warning, John ZuHone found this bug:
https://bitbucket.org/yt_analysis/yt/issue/528/cartesian-coordinates-brok...
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-cartes...
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.
--- 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.
--- 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-unrequeste...
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.
--- 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-brok...
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.
--- 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.
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!
--- 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-...
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.
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
