Mailman 3 November 2013 - yt-dev

RAMSES Todo List
by Sam Geen Dec. 2, 2013

Dec. 2, 2013

Hi, I intend to try to fiddle with the RAMSES frontend when I have time/need, and thought it would be good to collate a list of tasks that need to be completed so we have a consensus on what needs to be fixed. Feel free to suggest things or tell me that they're already implemented if I missed them: 1) Add support for RT and ATON files, which are now part of the default RAMSES (I assume from the code that the cooling and grav files are already read) 2) Via 1), it might be nice to refactor the RAMSESDomainFile class a bit to provide a more generic Ramses file reading routine/class, since the formats of the files are fairly similar and in doing 1) we might get some copy-paste bloat. 3) Allow for RAMSES runs that only contain AMR & particles (i.e. pure N-body runs with no hydro) 4) Refactor the inputs to fit YT default field names (for MHD, RT and ATON). 5) Allow YT to interpret non-cosmological simulations in RAMSES, or if it already does, remove the warning that says this. 6) Romain Teyssier suggested allowing users to specify their own default field names for user-modified versions of RAMSES. I don't know if YT caches data that would allow this, but I thought I'd punt the suggestion along. Another option could be to allow users to expose the RAMSES namelist files to YT (i.e. the parameter files for starting up a run) - these contain a lot more information on the physics included, etc. I'd put this on a low priority unless someone thinks of something clever that solves this cleanly. 7) It could be worthwhile to implement read-on-demand if it's not already - sometimes the users won't query the ATON/RT/hydro/particle file or certain fluid fields in each file and so we wouldn't need to read those files in that case. This could be folded into 2). Cheers, Sam

4 15

yt-3.0 now a part of yt repository
by Britton Smith Dec. 2, 2013

Dec. 2, 2013

Hi all, After some discussion on the dev mailing list, we've decided to unify the repositories for yt-3.0 and yt. It will still be located in a branch called yt-3.0 in that repository. At some point in the near future the separate yt-3.0 repository will become read-only. This simply means that if you are using yt normally, from the repository here: http://bitbucket.org/yt_analysis/yt you will be able to switch to the yt-3.0 branch more easily. And, if you currently have a fork of the repository yt-3.0, you'll need to switch to using a fork of the main yt repository. This is easy, just fork the main yt repo (unless you already have!) and push your yt-3.0 changes there. Just as it has always been, installing the "stable" and "development" versions from the install script will still only put you on the latest stable and development versions of yt-2.x. Additionally, doing "yt update" will not accidentally switch you from one version to the other. Happy Thanksgiving! Britton and the yt development team

2 5

Issue #737: Windows (yt_analysis/yt)
by Matthew Turk Nov. 27, 2013

Nov. 27, 2013

New issue 737: Windows https://bitbucket.org/yt_analysis/yt/issue/737/windows Matthew Turk: We should make at least a first pass at supporting Windows. I don't think there are a *lot* of things we would need to do, and there *are* people using Windows who want to use yt. Responsible: MatthewTurk

1 0

Issue #736: The website should mention Conda support (yt_analysis/yt)
by Matthew Turk Nov. 27, 2013

Nov. 27, 2013

New issue 736: The website should mention Conda support https://bitbucket.org/yt_analysis/yt/issue/736/the-website-should-mention-c… Matthew Turk: The website ought to say, "just conda install yt" since we're now in Anaconda.

1 0

Issue #735: PlotWindow plots need to deal with non unitary aspect ratios better (yt_analysis/yt)
by Nathan Goldbaum Nov. 27, 2013

Nov. 27, 2013

New issue 735: PlotWindow plots need to deal with non unitary aspect ratios better https://bitbucket.org/yt_analysis/yt/issue/735/plotwindow-plots-need-to-dea… Nathan Goldbaum: See e.g. http://lists.spacepope.org/pipermail/yt-users-spacepope.org/2013-November/0… Responsible: ngoldbaum

1 0

proposal to merge yt-3.0 development into main repo
by Britton Smith Nov. 27, 2013

Nov. 27, 2013

Hi all, Now that we have pushed out the last (or nearly the last) major release of yt-2.x, many are now joining the effort to work on yt-3.0. As you may have noticed, there is a yt-3.0 branch in the main yt repo hosted at https://bitbucket.org/yt_analysis/yt. However, most of the actual development has been happening in a separate yt-3.0 repo ( https://bitbucket.org/yt_analysis/yt-3.0). I think it may now be time to consider moving yt-3.0 development over to the main repository. I think this will lower the barrier of entry for a number of people and should not be a big problem to users of 2.x now that that version has mostly stabilized. As for logistics, a number of people have done work in forks of the yt-3.0, so we should not remove it entirely. Instead, I propose making it read-only, and having people push their changes to a fork of the main yt repo and working off of that from now on. The magic of mercurial should make this relatively painless. Thoughts? +/-1? Britton

11 21

Best way to share BCs for the kD-tree?
by Matthew Turk Nov. 26, 2013

Nov. 26, 2013

Hi all, especially Sam, Is there a good way to share boundary conditions between nodes of the kD-tree? I'm particularly interested in either speeding up vertex value generation or storing an additional layer of values that correspond to (expensive to compute) values on other processors, for the purposes of the contour finder. Basically, I think we can parallelize the contour finder in yt-3.0 PR 120 if we can share boundary conditions between processors. But, I'm not sure how to do that. Alternately, if we could double-count boundary nodes between processors, that would work as well. For instance, if processors 1 has a tile that borders a tile from processor 4, that tile would be "owned" by 4 but would be replicated on 1. Any ideas? -Matt

2 2

Issue #734: _recreate_frb for OffAxisProjectionPlot triggers a NotImplementedError (yt_analysis/yt)
by Nathan Goldbaum Nov. 26, 2013

Nov. 26, 2013

New issue 734: _recreate_frb for OffAxisProjectionPlot triggers a NotImplementedError https://bitbucket.org/yt_analysis/yt/issue/734/_recreate_frb-for-offaxispro… Nathan Goldbaum: See [PR 653](https://bitbucket.org/yt_analysis/yt/pull-request/653/disable-recreati…. The FRB should be recreated by generating a new volume rendering instead.

1 0

HDR volume renderings
by Matthew Turk Nov. 25, 2013

Nov. 25, 2013

Hi all, Amit Chourasia from SDSC shared with me this paper about transfer functions: http://users.sdsc.edu/~amit/web/files/pub/07-Data_centric_transfer_function… I thought it was absolutely fascinating, and might be useful in yt! -Matt

1 0

Issue #732: Progressbar is not installed properly (yt_analysis/yt)
by Kacper Kowalik Nov. 25, 2013

Nov. 25, 2013

New issue 732: Progressbar is not installed properly https://bitbucket.org/yt_analysis/yt/issue/732/progressbar-is-not-installed… Kacper Kowalik: As reported by Sam Geen on the mailing [list](http://lists.spacepope.org/pipermail/yt-users-spacepope.org/2013-Nove… `yt/extern/progressbar` directory is not packed, which results in runtime failure during basic operations ``` #!python >>> import yt.mods Traceback (most recent call last): File "<stdin>", line 1, in <module> File "yt/mods.py", line 35, in <module> import yt.startup_tasks as __startup_tasks File "yt/startup_tasks.py", line 22, in <module> from yt.funcs import * File "yt/funcs.py", line 27, in <module> import yt.extern.progressbar as pb ImportError: No module named progressbar ``` Responsible: xarthisius

1 0