Hi yt developers,
I'm trying to produce 3D streamlines using the AMR data from FLASH following the yt-project tutorial http://yt-project.org/doc/visualizing/streamlines.html. However, the execution was very slow (in particular, at the 'Streamlines' call). The code didn't complete one single streamline after an hour.
Here's the excerpt of my code:
c = ds.domain_center
streamlines = Streamlines(ds, c, 'velx', 'vely', 'velz', length=1.0*pc, get_magnitude=False)
ax = Axes3D(fig)
for stream in streamlines.streamlines:
stream = stream[np.all(stream != 0.0, axis=1)]
ax.plot3D(stream[:,0], stream[:,1], stream[:,2], alpha=0.1)
I have two thoughts:
1. My FLASH file is quite large (~10GB). It may just be slow because of the large AMR grid size. Are there any ways to read only the velocities off the grid or only a subsection of the grid?
2. FLASH's octree data structure may be incompatible with the AMRKDTree construction (first step in streamlines creation). In the doc string of AMRKDTree, it says "Not applicable to particle or octree-based datasets.". If it's the case, I may have to find another way out.
Thank you very much for your time! Have a great weekend!
Nathan and I have been doing some work on spatial line plotting and are
looking for some review. You can find the work we've done at:
I encourage you to try out the API on some of your own test datasets and
then give feedback on any issues.
Meagan and I are going to be giving a talk about yt at the scipy conference
in a few weeks. While Meagan's contributions to the demeshening project
have not yet been merged in to mainline yt, I believe we are all working
under the assumption that the demeshening work will be merged in sometime
after the release of yt 3.4. This work would not be possible without
Meagan's contributions. In addition, Meagan has already contributed fixes
for the Gadget frontend to mainline yt.
Given that Meagan will be officially representing the project during our
talk, I think now is an appropriate time to recognize her contributions by
making her a project member.
According to YTEP-1776, we need supporting votes from five additional
project members to officially include Meagan. Please reply with a +1 if
you'd like to second the nomination.
I'm mailing both yt-users and yt-dev since I don't think there are many
ramses users on yt-dev.
I'd like some feedback from users of the RAMSES frontend about a pull
request I just proposed:
See the pull request for details, but briefly, I've made it possible to
access the 'particle_age' field values for cosmology simulations as they
are stored in the ramses outputs. Currently we apply an in-place conversion
from conformal time to proper time when we read these data in, and it turns
out this conversion makes it difficult to write a particle filter for DM
particles that will work for all RAMSES data.
The trouble is that if we change the meaning of the particle_age field,
this may break the scripts of people who are currently using yt with RAMSES
data. Then again, we already made such a change when we added the in-place
conversion a year ago.
If you have thoughts and opinions about this I'd very much appreciate to
hear your comments on github.
If anyone followed the e-mail thread on yt-users between me and Carla
Bernhardt, they'd see that we had a lot of difficultly dealing with the
INST_CONDA=0 option in the install script.
This option reverts the install script to "legacy" mode, installing yt and
all of yt's dependencies from source rather than using miniconda and conda
packages to bootstrap a python environment.
The problem is that the packages that get installed must be manually and
laboriously updated. In practice this means packages are basically never
updated. This also means the script installs relatively old versions of
libraries (currently, matplotlib 1.5.1, numpy 1.11) simply because no one
has taken the time to go through the list of libraries installed and update
them. This means anyone who uses this option isn't benefiting from upstream
bugfixes. It also means we risk bitrot.
In practice, I don't think I've recently heard of a situation where
INST_CONDA=1 failed but INST_CONDA=0 did not.
The other option of course is for someone to step up and take
responsibility for updating the INST_CONDA=0 section of the install script.
I'd be happy to help out with that if anyone wants to volunteer.
However, without a maintainer, I think we are doing our users a disservice
by leaving this option available.
If we *do* eliminate this option, we immediately reap the following
* The install script can be trimmed down by several hundred lines
* We can simplify the install-script based install instructions in the docs
* It becomes easier to test modifications to the install script because
there are fewer permutations to test.
Please let me know what you think. I'd especially like to hear from people
who are fans of INST_CONDA=0 or who recently used it with no issues.