annotate velocity in non-cubic datasets

[yt-fido]

Originally reported by: Anonymous

---

It looks like the annotate_velocity method on SlicePlots selects a number of points uniformly distributed in the x and y coordinates but this does not work well for slices where one of the dimensions is much larger than the other. Is it possible to scale the number of displayed arrows with the size of each axis of the domain?

---

• Bitbucket: https://bitbucket.org/yt_analysis/yt/issue/1014

[yt-fido]

Original comment by Nathan Goldbaum (Bitbucket: ngoldbaum, GitHub: ngoldbaum):

---

Can you create a short example that illustrates this issue? It helps if you use one of the test datasets on yt-project.org/data, since it then makes it easy for someone else to reproduce and debug the issue locally.

Also if you want to take a hand at fixing this yourself, the velocity callback is defined in yt/visualization/plot_modications.py.

[yt-fido]

Original comment by Miguel de Val-Borro (Bitbucket: migueldvb, GitHub: migueldvb):

---

I have a dataset which is elongated in one of the spatial dimensions. The number of blocks is chosen so that the cells are roughly cubic so that it has about five times more blocks in the x direction than in z direction. However I think that annotate_velocity distributes the arrows uniformly as if the x and z dimensions were equal which looks like this figure.

I wonder if one can scale the displayed arrows by the number of blocks in each dimension which should be related with the real dimensions of the domain.

[yt-fido]

Original comment by Nathan Goldbaum (Bitbucket: ngoldbaum, GitHub: ngoldbaum):

---

Right now the number of arrows is fixed along each direction. If you want to change this, you will need to alter the QuiverCallback to (optionally) allow for a different number of arrows along the x and y directions. One way to do this would be to allow the factor keyword argument to be a tuple, and then handle that tuple appropriately. This will require code changes in VelocityCallback, MagneticFieldCallback, QuiverCallback, and CuttingQuiverCallback.

I don't have time to do this right now, but please feel free to go ahead and try for yourself. The callback code is relatively straightforward and self-contained. Please also feel free to raise this issue on the mailing list if you run into trouble.

[yt-fido]

Original comment by Miguel de Val-Borro (Bitbucket: migueldvb, GitHub: migueldvb):

---

Thank you for the explanation. I can try to make those changes.

[yt-fido]

Original comment by chummels (Bitbucket: chummels, GitHub: chummels):

---

@migueldvb : Have you made any progress on this?

[yt-fido]

Original comment by Miguel de Val-Borro (Bitbucket: migueldvb, GitHub: migueldvb):

---

@chummels let me see if I did something to fix this problem.

[yt-fido]

Original comment by Miguel de Val-Borro (Bitbucket: migueldvb, GitHub: migueldvb):

---

@chummels I did not fix this issue but I can do it for 3.4. Sorry that I completely forgot about this.

[yt-fido]

Original comment by chummels (Bitbucket: chummels, GitHub: chummels):

---

It's OK. I just wanted to see what the current situation was.

[yt-fido]

Original comment by Miguel de Val-Borro (Bitbucket: migueldvb, GitHub: migueldvb):

---

@ngoldbaum When I replace the factor keyword by a tuple to get different number of arrows in the x and y directions I get strange behavior like in the figure below.

The velocities should have roughly spherical symmetry about the origin. Perhaps the right way to do it is to use the physical dimensions of the image to select the number of points in each dimension?