Adding svSlicer

[chlookaburra]

Use Case

svSlicer (https://github.com/StanfordCBCL/svSlicer) is a repository that takes in 3D results (.vtu file), projects them onto the specified centerline (.vtp file), and averages the results along the points on the centerline to return a .vtp file. This .vtp file can then be postprocessed using vtk in your favorite python script. The whole repository only has one C++ file called main.cpp

I suggest that we add this C++ file to svMultiPhysics. This repository will be useful for comparing 3D model results projected on a centerline with 0D model results, as the lab transitions to more automated methods of BC tuning.

Problem

Currently, svSlicer has only been tested on svSolver's 3D results. I started testing the code using svMultiPhysics. I ran into several issues on my Macbook Pro with M2 Max.

Installation issues:

1. set(CMAKE_CXX_COMPILER "/usr/local/opt/llvm/bin/clang") does not work with Homebrew installation
2. cmake --install . gives a Permission denied error
3. Did not try this on HPC cluster yet, so there remain mysterious issues (or maybe not).

Code issue:

1. There are no arrays called 'velocity' and 'pressure', so svSlicer will automatically delete those arrays when creating the .vtp file.

Solution

I have solutions to some of these issues. Others remain to be tested by folks.

Installation issues:

1. Replace the path to “/opt/homebrew/opt/llvm/bin/clang” for those using the Homebrew installation
2. sudo make install . will allow permission to install
3. If issues arise, create a Docker (or does the preexisting one for svMultiPhysics work? someone should test this.)

Code issue:

1. These arrays are now called 'Velocity' and 'Pressure'. Also, 'WSS' is now part of svMultiPhysics. These should be fixed in the main.cpp file.

Alternatives considered

It would be great to discuss!
Also, would it be more useful for this feature to be part of the .xml file or as a standalone option (e.g., running it as "svslicer" alone)?

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct and Contributing Guidelines

[ktbolt]

@chlookaburra svSlicer should not be added to svMultiPhysics. This should be added to https://github.com/SimVascular/Tools and rename it to something descriptive without the sv prefix.

[msbazzi]

@ktbolt We had a nice discussion about this during the meeting today. I think it could be a good idea to have a post-processing folder inside the repository. This would contain svSlicer, as well as other general-purpose post-processing tools, for time-averaging results, for instance. We could also demonstrate how these are used in a demo case folder, with demo cases that are more realistic and larger than the test cases we currently have.

[ktbolt]

@msbazzi Please list the arguments for including general-purpose post-processing tools into a solver repository.

[msbazzi]

@ktbolt Here are some that came up during the discussion with @dcodoni and @aabrown100-git:

1- Most users want to post process the results -- further than the outputs we can obtain from the solver
2- Many svMultiPhysics user dont know about the existence of tool in Simvascular (me and @aabrown100-git included) . So i think it would be helpful to centralized the solver and post processing in one GitHub location.
3- Keeping in the same repository will help ensure the compatibility with software/solver updates.
4- Having a centralized folder will standardize the post-processing

Does it make sense?

[lpapamanolis]

@ktbolt @msbazzi Adding my two cents in favor of this:

General-purpose post-processing tools would perform routine calculations that are essential for interpreting simulation results (most lab members are separately implementing the same post-processing scripts again and again). Multiple users have asked for post-processing functionalities on the forums. Internally, svSlicer's functionality had previously been reimplemented separately at least by 3 different people.

If we consolidate post-processing tools under svMultiPhysics, we would increase visibility internally and to the wider community (along with all the other benefits that @msbazzi mentioned), and this would save all of us a lot of time in the future. We could potentially add this in a separate folder outside the solver path to keep things tidy, for example here:
https://github.com/SimVascular/svMultiPhysics/tree/main/Code/Source/post_processing

[alisonmarsden]

Perhaps these should formally be part of the SimVascular project on GitHub, but sit outside of the svMultiPhysics solver repository since they are not directly part of the solver codebase. From: Lazaros Papamanolis ***@***.***> Date: Tuesday, February 4, 2025 at 2:48 PM To: SimVascular/svMultiPhysics ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [SimVascular/svMultiPhysics] Adding svSlicer (Issue SimVascular/Tools#9) @ktbolt<https://github.com/ktbolt> @msbazzi<https://github.com/msbazzi> Adding my two cents in favor of this: General-purpose post-processing tools would perform routine calculations that are essential for interpreting simulation results (most lab members are separately implementing the same post-processing scripts again and again). Multiple users have asked for post-processing functionalities on the forums. Internally, svSlicer's functionality had previously been reimplemented separately at least by 3 different people. If we consolidate post-processing tools under svMultiPhysics, we would increase visibility internally and to the wider community (along with all the other benefits that @msbazzi<https://github.com/msbazzi> mentioned), and this would save all of us a lot of time in the future. We could potentially add this in a separate folder outside the solver path to keep things tidy, for example here: https://github.com/SimVascular/svMultiPhysics/tree/main/Code/Source/post_processing — Reply to this email directly, view it on GitHub<#9>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADJGJZ2FFP7SCPY7J4PPMSL2OE7RZAVCNFSM6AAAAABVY6XJW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMZVGIZTSMBUGM>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ktbolt]

@msbazzi Thank you for providing the details of your discussion!

Let me address each of your bullet points.

1- Most users want to post process the results -- further than the outputs we can obtain from the solver

svMultiPhysics provides lots of post processing information (e.g. averaged values at caps). I do not see a lot of requests in the SV Forum about post processing. Besides, there are tools like ParaView that are available for this.

2- Many svMultiPhysics users don't know about the existence of tool in Simvascular (me and @aabrown100-git included) . So i think it would be helpful to centralized the solver and post processing in one GitHub location.

There is a Simulation Results Output section in the svMultiPhysics documentation, we can add a post-processing section that discusses tools that users will find helpful for cardiovascular simulations.

Most users don't even know about our GitHub repositories so they will not find any tools there.

3- Keeping in the same repository will help ensure the compatibility with software/solver updates.

General-purpose post-processing tools should not be tied to any solver implementation.

4- Having a centralized folder will standardize the post-processing

Standard post-processing tools should indeed be centralized.

[ktbolt]

And addressing @lpapamanolis comments.

General-purpose post-processing tools would perform routine calculations that are essential for interpreting simulation results (most lab members are separately implementing the same post-processing scripts again and again). Multiple users have asked for post-processing functionalities on the forums. Internally, svSlicer's functionality had previously been reimplemented separately at least by 3 different people.

If Lab members keep implementing their own post-processing scripts again and again then shame on them! There is this thing called Slack where people can ask about things like this. I've got like 100 programs that do various things here. I can move some of them to https://github.com/SimVascular/Tools if it would be useful.

If we consolidate post-processing tools under svMultiPhysics, we would increase visibility internally and to the wider community (along with all the other benefits that @msbazzihttps://github.com/msbazzi mentioned), and this would save all of us a lot of time in the future. We could potentially add this in a separate folder outside the solver path to keep things tidy, for example here:
https://github.com/SimVascular/svMultiPhysics/tree/main/Code/Source/post_processing

Standard post-processing tools should indeed be centralized. Adding them to svMultiPhysics would not increase visibility internally and to the wider community. Adding a Post Processing section to the documentation would.

[ktbolt]

And @alisonmarsden comment.

Perhaps these should formally be part of the SimVascular project on GitHub, but sit outside of the svMultiPhysics solver repository since they are not directly part of the solver codebase.

I agree!

And my very own comments about including post processing tools into svMultiPhysics

1 - They are a separate thing from the solver. A code base should only do things that are related to its primary application.

2 - They are general purpose so they can operate on any VTK file from any solver or other application.

3 - They use VTK which creates a dependency for svMultiPhysics which may soon remove VTK or at least build with just a subset for the XML readers.

4 - Are they to be built and tested when building svMultiPhysics ?

5 - Are they to be part of the svMultiPhysics install ?

Final decision

Do not to not include post-processing tools in svMultiPhysics.

Put post-processing programs in the https://github.com/SimVascular/Tools repository under a post_processing directory.

Do a better job about communicating where useful programs are located.

[mrp089]

I see two problems with the current "tool repositories:"

1. Visibility
   I didn't know about Dave's super useful tool collection until now because it's under his GitHub account. For the also highly useful Tools and SimVascular-Tests, you have to click View all repositories to see them (no updates in three years). Yes, people can and should ask if things have been done before before doing it themselves. Even better (especially for people outside) if commonly used things are easily accessible.
2. Testing
   None of these tools are included in any test suite, which we currently have only for our three solvers (3D, 1D, 0D). That means there is usually no way of telling how to execute these tools in an example, and there is no guarantee that they will work (and will keep working) as intended. We could introduce testing with svMultiPhysics to any tool repository, we just haven't done it.

[ktbolt]

@mrp089 We can update the https://github.com/SimVascular/README.md to highlight useful repositories. I've also pinned the Tools repository.

Some of the programs in cardiovascular were written for users from the SV Forum. Others were used by me for debugging SimVascular problems. We can select a subset to put in Tools with documentation (e.g. https://github.com/ktbolt/cardiovascular/tree/master/select-sv-results/c%2B%2B#readme).

@alisonmarsden Do we include a description of the Lab GitHub repositories in the Lab on-boarding document ?

[alisonmarsden]

I was thinking that we should add a “post processing” project to the SimVascular GitHub (not in the solver repo but outside). This could include the most common 3-4 scripts that people need for things like: * Computing WSS and TAWSS * Integrating flow rates and inlets and outlets to produce waveforms * Computing residence time * ?? These should have tests associated with them. And they should be documented on the website. I will check on your question related to the Lab GitHub. From: Dave Parker ***@***.***> Date: Wednesday, February 5, 2025 at 9:44 AM To: SimVascular/svMultiPhysics ***@***.***> Cc: Alison Lesley Marsden ***@***.***>, Mention ***@***.***> Subject: Re: [SimVascular/svMultiPhysics] Adding svSlicer (Issue SimVascular/Tools#9) @mrp089<https://github.com/mrp089> We can update the https://github.com/SimVascular/README.md to highlight useful repositories. I've also pinned the Tools repository. Screenshot.2025-02-05.at.9.25.38.AM.png (view on web)<https://github.com/user-attachments/assets/c6e86a73-c8ef-49b1-9d3e-70dd1ac39368> Some of the programs in cardiovascular<https://github.com/ktbolt/cardiovascular> were written for users from the SV Forum. Others were used by me for debugging SimVascular problems. We can select a subset to put in Tools<https://github.com/SimVascular/Tools> with documentation (e.g. https://github.com/ktbolt/cardiovascular/tree/master/select-sv-results/c%2B%2B#readme). @alisonmarsden<https://github.com/alisonmarsden> Do we include a description of the Lab GitHub repositories in the Lab on-boarding document ? — Reply to this email directly, view it on GitHub<#9>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADJGJZ24J34WM3WZUQ3DEGD2OJEXTAVCNFSM6AAAAABVY6XJW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMZXGYYDQNRUGU>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[ktbolt]

@alisonmarsden I was planning to add a post_processing directory to Tools. We also can add a meshing directory.

Computing WSS and TAWSS and integrating flow rates and inlets and outlets is already performed by the solver.

Computing residence time can be based on the diffusion solver.

[alisonmarsden]

Ok this sounds good. Let’s make sure to add documentation on post processing capabilities to the website if it’s not already there. From: Dave Parker ***@***.***> Date: Wednesday, February 5, 2025 at 11:35 AM To: SimVascular/svMultiPhysics ***@***.***> Cc: Alison Lesley Marsden ***@***.***>, Mention ***@***.***> Subject: Re: [SimVascular/svMultiPhysics] Adding svSlicer (Issue SimVascular/Tools#9) @alisonmarsden<https://github.com/alisonmarsden> I was planning to add a post_processing directory to Tools<https://github.com/SimVascular/Tools>. We also can add a meshing directory. Computing WSS and TAWSS and integrating flow rates and inlets and outlets is already performed by the solver. Computing residence time can be based on the diffusion solver. — Reply to this email directly, view it on GitHub<#9>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADJGJZ5KVJWHZ2ZPUEZHY2T2OJRXTAVCNFSM6AAAAABVY6XJW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMZXHA2TOMRRG4>. You are receiving this because you were mentioned.Message ID: ***@***.***>