Using Externally-Generated Centerlines in the 0D Simulator

[riro3277]

I have been working with Dr. Pfaller on developing an additional ability in SimVascular to utilize externally-generated centerlines within the 0D simulator. This Issue will act as a thread for continued conversation and updates on where I am at. I have also created a fork where I will be updating my progress

[mrp089]

Thanks, @riro3277!

Can you post some pictures of the centerlines you have generated externally and briefly explain how you generated them? @ktbolt, I think this could be interesting for us as well.

[riro3277]

HeartToBrainCenterline.pptx

I made this short powerpoint recently that goes over the idea pretty quickly. I attached it to this message. Basically, I used the VMTK module in 3D slicer to generate the network model that is able to capture the loops within the cerebral vessels with pretty reasonable resolution. I was then able to export it as a vtp and now am trying to integrate it into the SimVascular 0D model. I am currently working trying to find a way to quickly compile the SV source code to test any changes that I make. I am mainly focusing on this file:

[https://github.com/SimVascular/SimVascular/blob/edd1fc7c26cf9550594a7362d66bb5d0fadda4d9/Code/Source/sv4gui/Modules/Model/Common/sv4gui_ModelUtils.cxx#L1184-L1232]

in which I will be making the majority of changes. If you have an idea on how to compile the source to allow me to quickly check this centerlines portion, it would be greatly appreciated.

Thank You,

Ricardo

[mrp089]

@riro3277, were you able to compile the code and make modifications to sv4gui_ModelUtils.cxx?

[riro3277]

I have been getting this error that I am unsure how to fix when compiling:

I completed the build externals and everything ran properly on my Ubuntu 20.04.6 system so I would think I have all the dependencies. If you have any idea what this is for, that would be greatly appreciated

[mrp089]

That's a common problem with an easy fix! One of the external libraries requires gcc-8. Have a look at the Ubuntu build instructions:

SimVascular/.github/workflows/build.yml

Lines 53 to 69 in edd1fc7

	build-ubuntu-20:
	runs-on: ubuntu-20.04
	steps:
	- name: Checkout
	uses: actions/checkout@v2
	- name: Install dependencies
	shell: bash
	run: sudo apt-get install libglu1-mesa-dev libxt-dev libxi-dev libglew-dev libxmu-dev gcc-8 g++-8 qt5-default zip
	- name: Build
	shell: bash
	run: |
	export CC=/usr/bin/gcc-8
	export CXX=/usr/bin/g++-8
	mkdir Build
	cd Build
	cmake .. -DSV_ENABLE_DISTRIBUTION=ON
	make -j2

The export ... statements set the gcc version to 8.

[riro3277]

I tried using gcc-8 and gcc-7 and got the same error for both versions:

Are there any other reasons for this?

Thanks,

Ricardo

[mrp089]

You're probably using a different gcc when typing sudo make. You shouldn't have to use sudo before make.

What's the output of this:

echo $CXX
echo $CC

[riro3277]

It gives a blank line for both entries. Sudo has been the only way I can get the make to run but I will mess around with some permissions

[riro3277]

Is this the best method for building on Ubuntu 20? https://github.com/SimVascular/SimVascular/blob/master/BuildWithMake/README-build-linux.txt

[mrp089]

The most up-to-date is this, which we execute on all our test machines:

SimVascular/.github/workflows/build.yml

Lines 53 to 69 in edd1fc7

	build-ubuntu-20:
	runs-on: ubuntu-20.04
	steps:
	- name: Checkout
	uses: actions/checkout@v2
	- name: Install dependencies
	shell: bash
	run: sudo apt-get install libglu1-mesa-dev libxt-dev libxi-dev libglew-dev libxmu-dev gcc-8 g++-8 qt5-default zip
	- name: Build
	shell: bash
	run: |
	export CC=/usr/bin/gcc-8
	export CXX=/usr/bin/g++-8
	mkdir Build
	cd Build
	cmake .. -DSV_ENABLE_DISTRIBUTION=ON
	make -j2

If you follow these steps, it should build. If your CXX and CC are empty, you have not set them to point to gcc-8.

[riro3277]

I was able to figure out the permissions and set the right compiler.

The build makes it to here and has been buffering here for around an hour and a half. Is this regular or is there a problem going on here?

[ktbolt]

@riro3277 SV typically takes a few minutes to build. You seem to be stuck downloading externals?

[riro3277]

Yes, it is getting stuck downloading externals but I am unsure where the problem is arising from. I am using gcc-8 and g++-8. I made sure all the libs are installed correctly also which they are.

[ktbolt]

If you are seeing

-- PKG MMG found!
-- PKG VTK found!
-- PKG GDCM found!
-- PKG ITK found!
-- PKG OpenCASCADE found!

then the externals have already been downloaded, you should then see

- Found MITK: /SimVascular/build/Externals-build/svExternals/bin/mitk-2018.04.2/include (Required is at least version "2018.04.2") 
-- PKG MITK found!
...
- Libraries:
-- 	Source/PythonAPI
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success
-- 	Source/sv2/Globals
-- 	Source/sv/Utils
-- 	Source/sv/Repository
-- 	Source/sv3/Path
-- 	Source/sv3/Common
-- 	Source/vtkSV/Common
-- 	Source/vtkSV/IO
-- 	Source/sv4gui/Plugins/org.sv.pythondatanodes
-- 	Source/sv4gui/Plugins/org.sv.gui.qt.mitksegmentation
-- Executables
-- 	Source/Application
-- Found Git: /usr/bin/git (found version "2.25.1") 
-- Checking if git repository: /home/davep/software/ktbolt/SimVascular/Code/../.git
-- Submodule update
-- Generating simvascular scripts. Dev name: sv, install name:  simvascular
-- Configuring done (42.7s)
-- Generating done (9.2s)
-- Build files have been written to: /SimVascular/build/SimVascular-build
[ 87%] Performing build step for 'SimVascular'
Copying Tcl Directory...
[  0%] Built target copy-tcl
[  0%] Copying dicom2 to /SimVascular/build/SimVascular-build/bin/dicom2
[  0%] Built target dicom2-copy
[  0%] Built target dcmdump-copy

Maybe remove the build directory and start again.

The build/Externals-build/svExternals/bin directory should look like

freetype-2.6.3  hdf5-1.10.1  mitk-2018.04.2  opencascade-7.3.0  qt-5.11.3    tinyxml2-6.2.0
gdcm-2.6.3      itk-4.13.2   mmg-5.3.9       python-3.5.5       tcltk-8.6.4  vtk-8.1.1

[riro3277]

Okay, thanks. I was able to successfully build and install the source. Now, what do you think the best way would be to re-compile and test changes to the sv4gui_ModelUtils.cxx?

[ktbolt]

To re-compile after changing the source code

$ cd SimVascular/build/SimVascular-build
$ make

What code did you make changes to, was it the CreateCenterlineSections() function ?

You will need to test by running SV with a project that calls this code, ROM simulation I guess.

Or you could add a method to the SV Python API and test using a Python script. Some of the Modeling.PolyData methods call sv4guiModelUtils methods, for example

SimVascular/Code/Source/PythonAPI/ModelingPolyData_PyClass.cxx

Line 564 in edd1fc7

PyDoc_STRVAR(ModelingPolyData_compute_centerlines_doc,

.

That would make testing faster but would require a bit more coding in the unknown.

[riro3277]

It would be the CreateCenterlinesSections() function. So to do this without the Python API, I would need to make the source, run the gui, load a project, and then run the ROM simulation within the GUI?

[ktbolt]

Correct, create an SV project with a model and then create a ROM Simulation Tool and create centerlines from there.

You can run the new build using SimVascular/build/SimVascular-build/sv.

[riro3277]

I am thinking that instead of having to change SimVascular source code directly, I edit this directory Code/ThirdParty/vmtk/simvascular_vmtk/ to take in my raw centerline and output one with the needed arrays that I can then move into the project directory of the SimVascular project for the ROM simulations. Would this work instead? Also, I tried doing an isolated build of this directory but was getting errors if anyone has tried to do so before.

[ktbolt]

Code/ThirdParty/vmtk/simvascular_vmtk builds along with the SimVascular source and can be thought of as part of the source. You can modify this code and merge it with the SimVascular source.

[riro3277]

Hi all,

I had a quick question I am struggling with. What are the parameters being passed to the sys_geom_centerlinesections function? I can't tell what needs to be passed and what their format is.

[ktbolt]

Have a look at the sys_geom_centerlinesections code, the parameters are described a bit there.

[riro3277]

Hi All,

I am encountering a problem that I am not sure what is happening. I am passing the externally generated centerline to SV where I assigned the MaximumInscribedSphereRadius using our signed distance field algorithm which seems to be working pretty accurately. This fully works for simple test cases I have tried but there is some errors for the entire heart-to-brain centerline. These errors can be found in the pictures below with a complete hole and a jagged line in the loop section (AcoA_Hole.jpg) and random jagged lines found throughout spots in the centerlines (Jagged_Non-Loop_Vessels.jpg). The solid line is the centerline after it is passed to SimVascular and the dotted line is the centerline is the raw centerline (Only has the MaximumInscribedSphereRadius array) before it is passed to SimVascular. Do you think this is a resolution error for the jagged lines and the hole in the loop is due to how the branchID algorithm is walking through the points? If you have any advice, it would be greatly appreciated!

Ricardo

[riro3277]

I had one more question to continue this. Due to this error, I am thinking of generating the needed arrays in an external python script. Which of these arrays are needed for the 0D simulator and which can be left out?

[riro3277]

Hi all,

Happy New Year! I wanted to give a quick update to where I currently am with this project. I made some substantial progress and am able to read an external centerlines with loops and produce an 0D-input centerline that contains all the needed arrays. Although this process is not streamlined and uses multiple different pre-processing scripts, I can complete it. The problem now lies in that when creating the solver_0d.json file, the branches of the centerline are not matching with the assignments of resistance/inflow values. As in centerline branches are not corresponded to the correct cap of the surface model. I am having trouble finding the right file that matches the outlet caps to branches of the centerline in order to try and make corrections. Any help would be appreciated!

Thanks,

Ricardo

[riro3277]

Hi All,

I wanted to give a quick update regarding the last question. I am able to produce the .json input file but when I try to run the solver, I am getting a segmentation fault. I can't find any distinguishable difference between this solver file and a working file. Here is a link to the ROM simulation folder that contains the centerline and the input file https://drive.google.com/file/d/1fPTmSxXjwVbtbVG2RpT74pOID8AZ9trU/view?usp=drive_link. If there are any suggestions or reasoning to why this happening, it would be greatly appreciated!

Thanks,

Ricardo