We need to test and demonstrate the speed of the package. One nice tool designed for development is the BenchmarTools. I hesitate to do this because performance really depends on the hardware of the platform you are testing on, the compiler options and the test parameters, so it is trivial and reliable.

Besides, we need to consider parallelization. The internal of trace method is designed such that no parallelization is involved: I want parallelization to happen per fieldline, i.e. at the trace call level, like

@threads for i = 1:10
   trace(...)
end

For each line being traced, there is less space for parallelization unless you want to build the connectivity for all the cells. This needs to be described in the doc.

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Currently most tracing functions in the package assume regular grid, meaning that the size of each cell is not changing. However, the whole grid information is passed all the way down to the kernel functions, which may be a waste of memory.

In the future we may want to extend the functions to support more grid types, so be careful about changing the kernel functions. We need to find a balance between generalization and efficiency.

Once the new PrecompileTools is registered, let's use it for speeding up TTFX

• Dobreak: use lower case.
• check allocations
• loopvectorization

The original tracing scheme is implemented in C from LANL. The algorithm has been reimplemented in Julia.
Calling the native functions in Julia is about 5 times faster than calling the dynmic C library.
Some of the tests originates from SpacePy.

A bug has been fixed in the field normalization function for the nonuniform dx, dy and dz grid, as in the original code dx=dy=dz is always assumed.

The current seeding function needs improvement: if the number of seeds is small it may not be uniformly sampled visually. One way to do this is first divide the whole domain into multiple chunks of the same size, and then select random seeds from them.

There is an add_arrow method which I used to add one single arrow for each field line:

This is rarely needed now since

• each plotting library has their streamplot implementation based on more efficient algorithms, and
• the position of the arrow generated from add_arrow always lies at the center of the line, which is not ideal.

We can remove this method and thus remove all python dependencies. As an alternative representation of directions, we can simply denote the start and end points of the traced lines with different colors.

As of now, the plotting functionalities such as arrows rely on Matplotlib. Matplotlib only has fake 3D plots, and there are many difficulties such as creating arrows in 3D. We do not necessarily require PyPlot for plotting; instead, it would be better to have specific plotting utilities for certain packages, similar to the concept of recipe.

I really want to find a better 3D visualization tool as a replacement. Maybe it is also possible to export the field line data to real 3D engines such as ParaView, VisIt, Blender, etc.

Meshes 0.25 introduces a bug for computing line segment intersections. This affects the unstructured mesh tracing

We should skip that version and upgrade to 0.26+.

Originally, the 2D field tracing in an unstructured grid relied on UnstructuredGrids.jl. I quickly built a 2D stream tracer on unstructured 2D grid based on the brute force algorithm.

Unfortunately this package is no longer maintained. I then substituted it with Meshes.jl, which is registered under the Julia Geometry group account, provides a cleaner interface and seems to be carefully designed. The main developer is very helpful and responsive, so I decide to completely shifted to this package. It already support hexahedron in 3D, so I guess it won't be difficult to extend the tracing to 3D unstructured grid.

• Extend to generalized 2D Cartesian grid
• Extend to 3D unstructured grid

Adaptive step control integration schemes like rk45 is something we can look into . From DifferentialEquations.jl, there are hundreds of schemes we can choose from, which are much better than implementing our own fragile ODE solver.

However, the question remains about how much do we gain from switching to more complicated schemes. the accuracy of tracing depends essentially on the grid resolution and how field data are stored. Actually, the brute force algorithm may not be as bad as you think in terms of accuracy. Finite volume method uses one value per cell to represent the solution space, therefore it is just cheating to use higher order method for stream tracing.