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
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).
Can someone point me to an example (docs, notebooks, emails, whatever) of
defining a custom particle filter for yt-3.0? I'm trying to do this and I
know I've seen discussion of this before, but I can't find where.
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
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
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
Just as it has always been, installing the "stable" and "development"
from the install script will still only put you on the latest stable and
versions of yt-2.x. Additionally, doing "yt update" will not accidentally
you from one version to the other.
Britton and the yt development team
New issue 739: Build problem
$ uname -a
Linux sys-debian 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux
Full log attached
Last lines of log are as follows:
Edit setup.cfg to change the build options
matplotlib: yes [1.3.0]
python: yes [2.7.6 (default, Dec 2 2013, 18:10:09) [GCC
platform: yes [linux2]
REQUIRED DEPENDENCIES AND EXTENSIONS
Requires numpy 1.5 or later to build. (Numpy not found)