I know that we want to port them, but since they will likely not be updated
before we release, should we remove the sections on these analysis modules
from the 3.0 docs?
No need to completely remove them from the code, I don't think, so long as
we don't advertise them as working in the docs.
Yesterday during the doc sprint, the question of what to do about
branches post-3.0 came up. Currently there are three branches, which
correspond to different names on the front page of the yt homepage.
* Stable => The branch into which bug fixes are merged, but not a lot
of active development occurs.
* yt => The 2.x development branch, which has slowed almost to a halt
* yt-3.0 => The 3.0 development branch
It seems there is broad consensus that after the release, the yt-3.0
branch would be merged into the yt branch. (I would like to hold off
on "closing" the yt-3.0 branch for a while, however.) But, what is
then to be done about the "stable" branch? My thought was:
* stable => will be on 2.x for at least one release, until 3.1
* yt => 3.0
* yt-3.0 => we try to migrate development onto the yt branch, which
is 3.0, but don't force yet
The alternate idea was:
* stable => 3.0
* yt => 3.0
* yt-3.0 => closed
I think we need a longer migration time for 2.x, though. I will
update YTEP-0008 with whatever we come up with, but is there a strong
opinion for either of these options? Option 1: stable stays 2.x for
now, Option 2, stable becomes 3.0.
I want to address the state of halo merger trees in yt-3.0. As it stands,
one cannot use yt-3.0 to create a merger tree. The two existing methods
have not been ported over from yt-2.x and now rely on functionality that
has seen significant changes. For example, the old HaloProfiler has been
removed, and the outputs of all yt halo finders have been redesigned to
work with the new halo_analysis framework discussed in YTEP-0012. Both of
these changes break one or both of the current merger trees. Thus, it will
take significant work to make them functional within yt-3.0. In addition,
the aim has been to design a new merger tree that would work with the
halo_analysis framework (discussed as HaloCatalogTimeSeries in the YTEP).
In summary, unless there is someone willing to champion them, I believe the
merger trees in yt-2.x have come to the end of their roads. I could be
convinced otherwise, but given the fact that they are broken at this time,
we need to make a decision by the release of yt-3.0. I see a few options:
1. Remove the existing merger trees from the yt-3.0 codebase now, but leave
the page in the documentation containing only a note that this
functionality does not yet exist in 3.0, but is still available in 2.x. I
think there are a few people (including me) who have building a new
3.0-compliant merger tree on their radar so I do not envision us going
without for too long.
2. Keep the existing code and throw NotImplementedYet exceptions when it is
imported. Additionally, remove all imports to non-existing machinery like
the HaloProfiler. Add a note to the documentation stating that this no
longer works but is waiting for help to be ported.
3. Fix one or both of them now to at least be functional (if not optimally)
by the yt-3.0 release. I personally cannot do this. If you vote for this
option, you should be willing to commit to do this.
I am mostly interested in hearing from people who have a stake in the halo
merger trees, but all input is welcome.
This morning, Nathan pointed out that we haven't updated the
membership of the "yt-dev" team on BitBucket recently. Adding people
to this team gives them the ability to hit the merge button on pull
requests (and create repos as yt_analysis), and since they've both
been incredibly enthusiastic and energetic contributors, I think it's
* Hilary Egan
* Mike Zingale
Welcome aboard, and sorry it didn't happen sooner!
New issue 866: Contour annotation doesn't appear to work with hexahedral meshes, spherical geometry
When I try to add contours to a slice plot from a hexahedral mesh in spherical geometry, the contours aren't right, and appear in the wrong place (see attached image). Probably the contour method hasn't been updated to work with these meshes yet?
New issue 865: Slices of hexahedral meshes have incorrect axis labels in spherical coordinates
When a slice is generated from a hexahedral mesh in spherical geometry, the axes are labelled with the names of the spherical coordinates, rather than the Cartesian or cylindrical coordinates. For example, taking a slice normal to 'phi' returns an image in the r-theta plane, but the axes should be labelled either as 'x' and 'z' or 'R' and 'z' (distinguishing spherical 'r' from cylindrical 'R').
I've drafted up a preliminary set of release notes for whenever 3.0
goes out the door:
I've opened it up for comments from everyone, so please go ahead and
right click to leave notes and suggestions. I'm sure I've forgotten
things. It might be a good idea to keep the bullet points short
(shorter even than I have done here) and instead link to a full list
of release notes and changes in the final doc build. Anyway, please
feel free to leave comments.
In case anyone wants to join, we are going to have another docs sprint
tomorrow at Noon PDT. If you are interesting in joining, we'll probably be
online for a couple of ours working on things. It's mostly independent
work, but it's nice to set time aside to work on it, and everyone is on a
google hangout so you can ask questions where necessary.
Let me know if you want me to invite you to join the google event.
You can see a list of some of the remaining tasks to be done before yt 3.0
is released here:
University of Arizona