Mailman 3 December 2016 - yt-dev

Soliciting opinions about how to handle data tables for spectral integrator port
by John Zuhone Dec. 8, 2016

Dec. 8, 2016

Hi everyone, I just issued PR 2465 (https://bitbucket.org/yt_analysis/yt/pull-requests/2465/wip-port-the-spectr…) to port the spectral integrator analysis module (originally written by Britton) under yt.fields. spectral_integrator is an analysis module that creates X-ray emission fields in user-specified energy bands. The hitch is that spectral_integrator uses HDF5 tables to compute the emissivity, since they are not analytical functions. We currently host those tables on yt-project.org/data. spectral_integrator downloads them automatically if the analysis module is used and they are not present. There was some discussion on Slack as to whether or not this is the correct approach, since it’s not ideal for certain computing environments (e.g., HPC). The files are a total of about 2.4 MB in size, so there is some reticence to bundling them with yt. There is also the issue that uploading new versions of the tables breaks backward-compatibility. I have sacrificed backwards-compatiblity for considerable simplification of code. Does anyone have any ideas about the best way to handle this issue? Best, John Z

4 3

Fwd: [Matplotlib-devel] [REL] matplotlib v2.0.0rc1
by Nathan Goldbaum Dec. 6, 2016

Dec. 6, 2016

---------- Forwarded message --------- From: Thomas Caswell <tcaswell(a)gmail.com> Date: Mon, Dec 5, 2016 at 11:38 PM Subject: [Matplotlib-devel] [REL] matplotlib v2.0.0rc1 To: matplotlib development list <matplotlib-devel(a)python.org>, matplotlib-users <matplotlib-users(a)python.org>, matplotlib-announce(a)python.org <matplotlib-announce(a)python.org> Folks, We are happy to announce matplotlib v2.0.0rc1 ! This is the first release candidate for the long awaited v2.0 release. For the full details of what is new please see http://matplotlib.org/2.0.0rc1/users/whats_new.html . Some of the highlights: - new default styles ( http://matplotlib.org/2.0.0rc1/users/dflt_style_changes.html ) - default font include most western alphabets - performance improvements in text and image rendering - vastly improved log scale ticks - many bug fixes and documentation improvements Please help us by testing the release candidate. To make this easy we have provided both wheels and conda packages for mac, linux and windows. You can install pre-releases via pip: pip install --pre matplotlib or via conda: conda install -c conda-forge/label/rc -c conda-forge matplotlib For more details see http://matplotlib.org/style_changes.html . Please report any issues to https://github.com/matplotlib/matplotlib/issues or matplotlib-users(a)python.org . The target for v2.0 final is around late Dec 2016/early Jan 2017. We anticipate there being at least 1 more release candidate. This release is the work of over 200 individual code contributors and many more who took part in the discussions, tested the beta releases, and reported bug reports. Thank you to everyone who contributed! Tom ps As of sending this email we are still waiting on the mac conda packages to finish building, (see https://travis-ci.org/conda-forge/matplotlib-feedstock/builds/181541792) Should be done in the next few hours, but I want to go to bed ;) _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel(a)python.org https://mail.python.org/mailman/listinfo/matplotlib-devel

1 0

Issue #1301: Dimensions for energy fields are confusing (yt_analysis/yt)
by John ZuHone Dec. 5, 2016

Dec. 5, 2016

New issue 1301: Dimensions for energy fields are confusing https://bitbucket.org/yt_analysis/yt/issues/1301/dimensions-for-energy-fiel… John ZuHone: The dimensions for `("gas", "thermal_energy")` are of specific energy, energy per unit mass. The dimensions for `("gas", "kinetic_energy")` are of energy per unit volume. Different hydro codes adopt different dimension conventions for total energy and thermal energy. It seems that we need a consistent naming scheme for these that is unambiguous, e.g. perhaps `("gas", "kinetic_energy_density")`? Responsible: jzuhone

1 0

the future of analysis_modules
by Britton Smith Dec. 5, 2016

Dec. 5, 2016

Greetings, I would like to open a discussion on the idea of moving most of yt’s analysis modules into an external yt extensions package. For ease of reading, I will separate this email into what this would mean for the code, what I see are the pros, cons, logistics, and open questions. I would very much appreciate comment on this. What this means If we did this, most of the contents of yt/analysis_modules would be moved into a repository named something like yt_astro_analysis. Installing this would be an option in the install script and would likely also be pip installable. Imports would change from from yt.analysis_modules.halo_analysis.api import HaloCatalog to from yt.extensions.astro_analysis.halo_analysis.api import HaloCatalog After creating yt_astro_analysis, there would be a period where the old analysis_modules would still exist but be deprecated before being removed at some point down the road. Pros - Almost all of the current analysis modules are specific to astrophysics. As we continue to make the core functionality of yt less astro specific, it’s not clear how to make room for non-astro analysis modules. Putting everything together under analysis_modules will make navigation and documentation messy and confusing. This would also significantly slim down the yt codebase. - Many of the tools in analysis_modules are very old and are in need of API-breaking refactor. Some of these, like two_point_functions, did not make the jump from yt-2 to yt-3 and are no longer usable. Many tools no longer have a champion, someone interested in using, maintaining, and updating them as yt’s core functionality develops and changes. Moving analysis_modules from yt decouples them from yt’s release cycle, allowing interested parties to make updates and releases on a separate, likely shorter timescale. Some analysis_modules may even be better suited to be moved into other extensions that are actively developed, such as the case of the AbsorptionSpectrum with the Trident project. - Similar to the point above, yt releases would not be slowed by the need to update all of the championless modules. Individual analysis modules can be tied to specific stable releases of yt and so assured to work there. Cons - This will take a non-zero amount of work. See below for a summary of the primary tasks. - There are some outstanding logistical questions. See below. - Not having yt and analysis modules explicitly tied to the same codebase/releases could result in analysis tools falling behind and out of date. - The disruption and need to alter scripts could irritate and alienate users. Proposed progression This is roughly how this would happen. Here is a table with all existing analysis modules, their status, and potential future: https://goo.gl/HZykQA 1. Create yt_astro_analysis repo with all analysis modules that are to be moved. Add an entry to the extensions page on yt-project.org. Make it installed by default in the install script, at least at first. 2. Deprecate all moved modules in yt. 3. After some time, remove deprecated modules from yt. Open issues Here are some logistics and questions that still need to be worked out. - Can we set up separate testing for yt_astro_analysis? Would maintaining this be a pain? - How/where would the documentation be hosted? - How would we move the analysis modules source code and maintain its revision history? Questions to yt-dev - Are you +/-1 on this? Any other comments? - Changes to the analysis_modules spreadsheet (https://goo.gl/HZykQA)? - Interested in helping out with this? If this happens, I propose anyone interested meets for a hangout to discuss how to proceed. Thanks for reading! Britton

6 9