Tubegen/bugs and feature requests

Bugs

Slowdown

Streamtube generation gets slower and slower as the program runs. What's going on? Is it running out of memory, reading inefficiently through a big file, doing something probabilistic that gets less likely the more tubes there are? We need a speedup!

In streamtube.cpp, function tube_collection_generator::generateSpacing(), unless getCullingDistance() == 0.0 (set this by passing -cd 0.0 to tubegen), a pairwise inter-tube distance-based culling check happens after each streamtube is generated, for a total complexity of O(n²).

It would be a good idea to separate out seeding, streamline/tube generation, and culling, since each of these can be modified or optimized separately. There's a lot of code repetition in streamtube.cpp --- . Also want to figure out the function of tube_collection_generator::getDistThreshold() (-dth argument to tubegen) in streamtube::avgdistance().

Just in streamtube.cpp, there's:

• void brown_streamtube::generate(double seed_point[3])
• void MC_streamtube::generate(double seed_point[3])
• void cross_fiber::generate(double seed_point[3])
• void tube_collection_generator::generate2()
• void tube_collection_generator::generatecross()
• void tube_collection_generator::generatecrossradii()
• void tube_collection_generator::generatehalfcircle()
• streamtube* tube_collection_generator::generateOneTube(double p[3])
• void tube_collection_generator::generate(int MC)
• void tube_collection_generator::generateSpacing(double sspace[3], int MC)
• void jot_tube_mesh_generator::generate()

These obviously do different things but there seems to be a lot of repeated code among them that should be factored out. Some of them are truly enormous functions, too, and should be broken apart for clarity.

RK4

Using -ODE 1 to specify fourth-order Runge-Kutta seems to break some intrinsic culling metric; all tubes get preemptively culled. --- Jadrian Miles 17:08, 24 March 2009 (UTC)

Length filtering

The Zhang paper says we filter by streamline length. The command-line argument description (and, consequently, the wiki documentation) seemingly agree, saying that the -cs argument is "Min tube length in mm." But Tubegen begs to differ: that argument is actually the minimum size of a streamline, size being the number of vertices. That's why, you'll notice, that argument has to be an integer, not a double. So it's either broken or misused, depending on how you look at it. --- Nathan Malkin 12:39, 16 August 2010 (EDT)

Distance method

Not necessarily a bug: the Zhang paper talks about the distance from the "shorter trajectory to the longer trajectory." Tubegen actually looks at the number of vertices in each streamline and makes the comparison based on that. This is only fine as long as the distance between each pair of points is the same. --- Nathan Malkin 12:39, 16 August 2010 (EDT)

Culling with seeds given

Anecdotal evidence: I ran Tubegen using the -OUTSF argument to output the seeds file it generated. Then I ran it (twice) using -USESF 1 and -SF to integrate streamlines based on the (previously generated) seed points (and then cull them). While the output from the second set of calls was the same, it was different from the output of the original run. Not sure why this is happening, but it probably shouldn't be. --- Nathan Malkin 12:39, 16 August 2010 (EDT)

Feature Requests

Adaptive Step Size

dhl thinks it would be a good idea to change the advection algorithm to use an adaptive, rather than fixed, step size.