Performance Enhancement

[richterjakob]

The 0D solver is already very fast compared to other solvers. However, there are few improvements that can be made to increase the performance even further. The proposed changes are:

• Switch back to dense matrices and solvers. The 0D systems are not big enough to get better performance from a sparse solving strategy. In addition, the current implementation does not exploit the advantages of sparse systems. It jumps back and forth between sparse and dense matrices which is not very efficient (profiling showed that a lot of time is lost in instantiations of CSR matrices).
• Set all entries at once during assembly for each block: Iterating over each entry is very time-consuming. Numpy offers better alternatives with its advanced indexing strategies.
• Avoid reassembling of unchanged element contributions. The assembly procedure used in the 0D solver allows to just keep element contributions for the next iterations if they are not changed.
• Avoid divisions as much as possible. Divisions are appr. 10x slower than multiplications. When e.g. the inverse of a variable is used multiple times (like the inverse of timestep dt), it should be calculated once and then used as a multiplier.

The above suggestions have been implemented in https://github.com/SimVascular/svZeroDSolver/pull/61 and increased the speed of the 0D solver by approximately 500%.

Interested parties

@mrp089

[ktbolt]

@richterjakob I am wondering if the performance of the 0D solver is really a priority. Note that it will be re-implemented in C++ in the future.

@mrp089 @JonathanPham What do you think?

[richterjakob]

@ktbolt Thanks for your comment. I am aware of the reimplementation in C++ in the future. However, I was not sure about the schedule for the reimplementation and needed a higher performance for my current work as I am evaluating many 0D problems at the same time. The above suggestions are just small optimizations I used in my previous works with 0D solvers and numpy/scipy. I thought, I just implement them quickly.

Let me know what you think!

[JonathanPham]

@ktbolt @richterjakob Performance optimizations in the Python version of the 0D solver sound great! I don't think a C++ will be happening anytime soon. That conversion has been put on the back-burner.

@richterjakob Thanks for optimizing the 0D solver!

[ktbolt]

@richterjakob Sounds good, have at it!

[mrp089]

@ktbolt I think this is a great idea! We never fully optimized the Python version for "peak performance." I think there should be a couple of low-hanging fruits for speedups. I'm currently running the solver through all N=72 models we use in the 3D-1D-0D paper to see 1) if the results are the same and 2) how much faster the new version is.

@richterjakob Can you have a look at some pulmonary models? It looks like 0080_00011 and 0081_0001 are a bit faster but 0082_0001 is much slower.

[mrp089]

@richterjakob Fixed the performance decrease in large models by switching between two strategies:

• n_dof > size solve sparse system (usually pulmonary models)
• n_dof <= size solve dense system (everything else)

We currently use size=800, which works well (but of course could be fine-tuned).

I reran the faster svZeroDSolver for all N=72 VMR models: 1) results are the same! 2) we get a mean speedup of 2

I'm merging #61