resetting Streamlines properties?

[chrishavlin]

I recently found myself in a position where I calculated some Streamlines but then realized I wanted a different streamline length and had to re-calculate. Currently the only way to do this is to instantiate a new Streamlines object, which is pretty slow if you don't know to supply a volume argument (which I didn't at first). To avoid waiting for the AMRKDTree to re-build between instances, you can do:

from yt.utilities.amr_kdtree.api import AMRKDTree
from yt.visualization.api import Streamlines

x_field = ("gas", "velocity_x")
y_field = ("gas", "velocity_y")
z_field = ("gas", "velocity_z")

volume = AMRKDTree(ds)
volume.set_fields(
    [x_field, y_field, z_field], [False, False, False], False
)
volume.join_parallel_trees()

streamlines = Streamlines(
    ds,
    pos,
    x_field, y_field, z_field,
    length=1.0 * Mpc,
    get_magnitude=True,
    volume=volume
)
streamlines.integrate_through_volume()

# do something... decide you want longer streamlines 

streamlines = Streamlines(
    ds,
    pos,
    x_field, y_field, z_field,
    length=2.0 * Mpc,
    get_magnitude=True,
    volume=volume
)
streamlines.integrate_through_volume()

But I think it'd be nice to be able reset some of the Streamlines attributes so that you can re-use the default volume. So the above code might condense to something like:

streamlines = Streamlines(
    ds,
    pos,
    x_field, y_field, z_field,
    length=1.0 * Mpc,
    get_magnitude=True,
)
streamlines.integrate_through_volume()

# do something... decide you want longer streamlines 

streamlines.length = 2.0 * Mpc
streamlines.integrate_through_volume()

I think it'd make sense to implement for the following attributes: starting_positions, length, get_magnitude, direction, dx. And while you could directly set these attributes now, there's a bit of sanitizing that happens in Streamlines.__init__ so it'd be safer to have these as getter/setter attributes.

Good idea? Bad idea?

Link to streamlines.py

[neutrinoceros]

Sounds reasonable to me. yt shines within iterative workflows so I believe supporting this makes sense.