yt-dev July 2014

yt-dev@python.org

16 participants
70 discussions

Status of sunrise exporter, radmc, and two point functions for 3.0 release?

by Nathan Goldbaum

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

5 years, 10 months

Branches post 3.0

by Matthew Turk

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

5 years, 10 months

halo merger tree in yt-3.0

by Britton Smith

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

5 years, 10 months

New push access

by Matthew Turk

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

5 years, 10 months

Issue #867: Clump finder gives incorrect results. (yt_analysis/yt)

by Britton Smith

New issue 867: Clump finder gives incorrect results. https://bitbucket.org/yt_analysis/yt/issue/867/clump-finder-gives-incorrect… Britton Smith: The find_clumps.py recipe gives inconsistent results between yt-2.x and yt-3.0.

5 years, 10 months

Issue #866: Contour annotation doesn't appear to work with hexahedral meshes, spherical geometry (yt_analysis/yt)

by kylepp

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-ap… 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

5 years, 10 months

Issue #865: Slices of hexahedral meshes have incorrect axis labels in spherical coordinates (yt_analysis/yt)

by kylepp

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-meshes-… 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

5 years, 10 months

release notes

by Matthew Turk

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_cmTRXGd3DmMNh839YGIj… 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

5 years, 10 months

Documentation Sprint Tomorrow

by Cameron Hummels

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

5 years, 10 months

Issue #864: Enzo particle filter failure with changset: d4bf4fed7f06 (yt_analysis/yt)

by Cameron Hummels

New issue 864: Enzo particle filter failure with changset: d4bf4fed7f06 https://bitbucket.org/yt_analysis/yt/issue/864/enzo-particle-filter-failure… 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/

5 years, 10 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

yt-dev July 2014