Tubegen/bugs and feature requests: Difference between revisions

From VrlWiki
Jump to navigation Jump to search
Jadrian Miles (talk | contribs)
New page: == 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 p...
 
Jadrian Miles (talk | contribs)
No edit summary
Line 1: Line 1:
== Slowdown ==
== 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!
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!


Line 19: Line 20:
* <code>void jot_tube_mesh_generator::generate()</code>
* <code>void jot_tube_mesh_generator::generate()</code>
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.
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 <tt>-ODE 1</tt> to specify fourth-order Runge-Kutta seems to break some intrinsic culling metric; all tubes get preemptively culled. --- [[User:Jadrian Miles|Jadrian Miles]] 17:08, 24 March 2009 (UTC)
== 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.


[[Category:Diffusion MRI]][[Category:Bug Tracking Pages]]
[[Category:Diffusion MRI]][[Category:Bug Tracking Pages]]

Revision as of 17:08, 24 March 2009

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(n2).

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)

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.