Input local vessel area

[mrp089]

Problem

We currently provide the area of the blood vessel at the inlet and outlet and linearly interpolate in between. Yet, we have a much more detailed variation of local vessel area from the centerline. Refining the local area yields a pressure variation along the vessel that's much closer to 3D (see Figure 11). Currently, the only way to refine the area is by dividing each vessel into sub-vessels. However, this greatly increases the number of DOFs and (in my experience) worsens the numerical stability of the system by introducing a large number of Lagrange multipliers to couple these vessel segments.

Solution

I think "all we need to do" is to provide the solver with the local area from the centerline. We already discretize each vessel segment with many finite elements that would be reasonably fine to represent local variations in area. We currently ignore that opportunity and instead linearly interpolate between the inlet and outlet areas. Thus, this should only be an input file problem. With the new JSON input file format (#114), we could provide a z coordinate vector with a corresponding area vector and then linearly interpolate the area of each finite element node from those vectors. This way, a user could choose how to resolve the area and retain the legacy behavior of just two input values.

Additional context

Figure 11

Pressure along vessel branches in an aortic coarctation model at peak systole. Compare blue (3D) and orange (1D) lines for one segment per vessel branch (top) and 10 segments per vessel branch (bottom). The pressure variation along each branches in 1D is remarkably close to 3D when discretizing with 10 segments.

Code of Conduct

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

[arsLibera]

Hey @mrp089, I started working on this.

master...arsLibera:svOneDSolver:localVesselArea

You can take a peak at

https://github.com/arsLibera/svOneDSolver/blob/localVesselArea/Code/Source/cvOneDSegmentSpatialCharacteristics.h

to get an idea of how I'm planning to introduce it. Feel free to offer your thoughts.

Forgot to tag Dave: @ktbolt

[ktbolt]

@mrp089 Very nice solution! I wonder how this will affect stability.

Does it make sense to add higher-order elements ?

[arsLibera]

@mrp089, @ktbolt

I've gotten a pretty solid implementation of this going. It's backward compatible with the old inputs. You can try it out here:

master...arsLibera:svOneDSolver:localVesselArea

I attached a basic example of the input file:
./OneDSolver -jsonInput spatially_varying_initial_area_simple_artery.json

Remaining things:

• The VTK loops are hard to parse. I tried my best guess at calculating the values required there. If you happen to know those loops at all maybe you could take a look?
• Should probably add some basic unit test for the spatial characteristics class. That should be pretty quick.
• Need a system test. I'm thinking we can create an input file for a single vessel with a spatial varying area. I like to compute exact solution using a forcing function for validation, but in absence of that maybe you know of some known solutions we can compare to? I'm pretty out of touch with that side of things.

spatially_varying_initial_area_simple_artery.json

[mrp089]

Awesome work, @arsLibera!

• The VTK loops are only for postprocessing and haven't been touched in years. I would not mind breaking/removing that feature entirely and eventually replacing it with a separate postprocessor that takes a 1D solution and 1D input file and renders it as 3D vessels according to user specifications (Output only text and move VTK to a post-processor #119).
• We should test that we still have the old behavior with only the inlet and outlet area as well as a finer discretization. I see you already included a bunch of error checks for inputting z and area!
• We already have a 1D input file for the simulation shown above. However, this will consist of several sub-branches per vessel branch and might be cumbersome to convert to the new format. We could also modify SimVascular's 1D input generator first. This would involve completely rewriting the IO file (which would also simplify a lot). Then we could test anything. However, this requires that we can build SimVascular again.

@ktbolt, thoughts?

[ktbolt]

@arsLibera Very good !

The VTK code should be replaced with VTK XML writers.

[arsLibera]

@mrp089

The VTK loops are only for postprocessing and haven't been touched in years. I would not mind breaking/removing that feature entirely and eventually replacing it with a separate postprocessor that takes a 1D solution and 1D input file and renders it as 3D vessels according to user specifications (#119).

Since you aren't concerned about this I decided to roll back to the legacy behavior. For now, we just won't utilize the spatially varying data in the VTK post-process. @ktbolt do you have an example of the VTK XML writers? Might be good to mention that on @mrp089 's existing issue: #119

We should test that we still have the old behavior with only the inlet and outlet area as well as a finer discretization. I see you already included a bunch of error checks for inputting z and area!

All of the existing conversions from ".in" -> ".json" in the system tests verify the old behavior that uses only the inlet and outlet area.

For a "finer" discretization I think perhaps you are referring to the new behavior with spatially varying areas within a single vessel? I have tried to add something like that with my latest commit -- but I didn't verify it against an analytic solution. Having to dig into the equations would be a little time-consuming for me -- is there anyone that has been working with them and can help with that?

We already have a 1D input file for the simulation shown above. However, this will consist of several sub-branches per vessel branch and might be cumbersome to convert to the new format. We could also modify SimVascular's 1D input generator first. This would involve completely rewriting the IO file (which would also simplify a lot). Then we could test anything. However, this requires that we can build SimVascular again.

I am not sure I understand. Which simulation are you referring to?

Right now, we're still backward compatible with the old file formats (that use only inlet/outlet areas). So we only need to upgrade clients when we're ready to utilize the new JSON format with spatially varying areas.