Exponential scaling of Analyser() computation time for large-scale vascular network models
Background / Context
I am using Circulatory Autogen to model the time-dependent haemodynamics of complex vascular networks. In this approach, each vessel segment within the vascular network is represented as an individual component within OpenCOR, where each vessel component is mapped to a separate module/model sourced from an external CellML modules file.
To sufficiently capture the haemodynamics of dense vascular anatomies, the resulting CellML models require a significant number of these interconnected vessel segments (scaling into the hundreds or more).
The Issue
Currently, generating these CellML models places a significant computational load on Circulatory Autogen. As the size of the vascular network (and consequently, the number of vessel segments) increases, the computation time required to fully construct the CellML models scales exponentially.
While I can feasibly generate CellML models for smaller sub-volumes of the network, which is acceptable for early-stage prototyping, scaling this up to represent the entire anatomical volume (which is the ultimate goal of the project) is currently computationally infeasible.
Investigation & Root Cause
After profiling the performance within Circulatory Autogen, I identified that the primary bottleneck contributing to the vast majority of this computation time is the Analyser() function from libcellml. As shown in the benchmarking figure below, the execution time for Analyser() scales exponentially relative to the number of generated vessel segments:
Figure 1: A plot showcasing computation time as a function of the number of vessel segments for various helper functions within the Circulatory Autogen pipeline, demonstrating the significantly larger exponential scaling of computation time associated with the Analyser() function as the number of vessel segments increases. Sub-volumes between 5% to 20% were benchmarked.
Impact & Request
Because the Analyser() function currently bottlenecks the model generation pipeline, it strictly limits the complexity and scale of the models we can build.
To better facilitate the modeling of larger, denser, and more anatomically complete vascular networks, there is a critical need to improve the computational efficiency and scaling behavior of the Analyser() function. Any insights, optimizations, or workarounds to help mitigate this exponential scaling for highly modular/component-heavy models would be greatly appreciated.
If you have any questions please let myself or @FinbarArgus know - thanks ((:
Exponential scaling of
Analyser()computation time for large-scale vascular network modelsBackground / Context
I am using Circulatory Autogen to model the time-dependent haemodynamics of complex vascular networks. In this approach, each vessel segment within the vascular network is represented as an individual component within OpenCOR, where each vessel component is mapped to a separate module/model sourced from an external CellML modules file.
To sufficiently capture the haemodynamics of dense vascular anatomies, the resulting CellML models require a significant number of these interconnected vessel segments (scaling into the hundreds or more).
The Issue
Currently, generating these CellML models places a significant computational load on Circulatory Autogen. As the size of the vascular network (and consequently, the number of vessel segments) increases, the computation time required to fully construct the CellML models scales exponentially.
While I can feasibly generate CellML models for smaller sub-volumes of the network, which is acceptable for early-stage prototyping, scaling this up to represent the entire anatomical volume (which is the ultimate goal of the project) is currently computationally infeasible.
Investigation & Root Cause
After profiling the performance within Circulatory Autogen, I identified that the primary bottleneck contributing to the vast majority of this computation time is the
Analyser()function fromlibcellml. As shown in the benchmarking figure below, the execution time forAnalyser()scales exponentially relative to the number of generated vessel segments:Figure 1: A plot showcasing computation time as a function of the number of vessel segments for various helper functions within the Circulatory Autogen pipeline, demonstrating the significantly larger exponential scaling of computation time associated with the
Analyser()function as the number of vessel segments increases. Sub-volumes between 5% to 20% were benchmarked.Impact & Request
Because the
Analyser()function currently bottlenecks the model generation pipeline, it strictly limits the complexity and scale of the models we can build.To better facilitate the modeling of larger, denser, and more anatomically complete vascular networks, there is a critical need to improve the computational efficiency and scaling behavior of the
Analyser()function. Any insights, optimizations, or workarounds to help mitigate this exponential scaling for highly modular/component-heavy models would be greatly appreciated.If you have any questions please let myself or @FinbarArgus know - thanks ((: