Hi all,
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.
-Nathan
Hi everyone,
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.
-Matt
Hi all,
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.
Britton
Hi all,
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
long overdue!
* Hilary Egan
* Mike Zingale
Welcome aboard, and sorry it didn't happen sooner!
-Matt
New issue 866: Contour annotation doesn't appear to work with hexahedral meshes, spherical geometry
https://bitbucket.org/yt_analysis/yt/issue/866/contour-annotation-doesnt-...
kylepp:
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?
Responsible: MatthewTurk
New issue 865: Slices of hexahedral meshes have incorrect axis labels in spherical coordinates
https://bitbucket.org/yt_analysis/yt/issue/865/slices-of-hexahedral-meshe...
kylepp:
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').
Responsible: MatthewTurk
Hey all,
I've drafted up a preliminary set of release notes for whenever 3.0
goes out the door:
https://docs.google.com/document/d/12oiEFhgeCrKMWMlJbO_cmTRXGd3DmMNh839YG...
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.
Thanks,
Matt
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:
https://trello.com/b/Y5XV4Hod/yt-3-0
Cameron
--
Cameron Hummels
Postdoctoral Researcher
Steward Observatory
University of Arizona
http://chummels.org
New issue 864: Enzo particle filter failure with changset: d4bf4fed7f06
https://bitbucket.org/yt_analysis/yt/issue/864/enzo-particle-filter-failu...
Cameron Hummels:
I attempted to use a script that used to work to generate a simple star particle filter and then access the resulting `cic` field, and now it fails. I used `hg bisect` to track down the offending changeset which breaks this functionality, and it is d4bf4fed7f06, which was committed by @MatthewTurk two months ago. Not sure how to correct the problem. It involves chunking while making particle deposit fields from particle unions.
Sample script with sample enzo dataset:
http://paste.yt-project.org/show/4941/
Error which occurs for changeset d4bf4fed7f06 and beyond:
http://paste.yt-project.org/show/6CqhjvujtDqsgnLaaVka/
