RAMSES Todo List
by Sam Geen
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
5 years
yt-3.0 now a part of yt repository
by Britton Smith
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
5 years
proposal to merge yt-3.0 development into main repo
by Britton Smith
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
5 years
Best way to share BCs for the kD-tree?
by Matthew Turk
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
5 years
