Add coronary boundary condition

[ktbolt]

Use Case

Coronary boundary conditions.

Problem

The svMultiPhysics solver currently uses the svZeroDSolver interface for coronary boundary conditions. The svSolver had an internal implementation for coronary boundary conditions.

A coronary boundary condition requires users to create a svZeroDSolver JSON file and add a svZeroDSolver_interface section. This requires understanding about svZeroDSolver JSON file format and other details.

Solution

Add an internal implementation for coronary boundary conditions to svMultiPhysics similar to the current RCR boundary condition.

This will make it convenient for users to use coronary boundary conditions without creating a svZeroDSolver JSON file.

The Fortran code for coronary boundary conditions in svSolver can be converted to C++.

Alternatives considered

It might be better to use the svZeroDSolver internally than write another implementation for coronary boundary conditions.

Additional context

No response

Code of Conduct

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

[ktbolt]

The svSolver coronary boundary condition code is 600 lines of Fortran. This could be challenging to convert to C++ since it is not clear how the svSolver code works.

It would be better not have two implementations of coronary boundary conditions to support and to use existing code in svZeroDSolver.

Specifying a coronary boundary condition in the svMultiPhysics solver XML file causes the appropriate svZeroDSolver JSON data to be created and passed directly to the svZeroDSolver.

[ktbolt]

@chlookaburra What do you think about all this ?

[alisonmarsden]

I would also check in with Noelia and Karthik. One of them may have an svFSI Fortran implementation of the coronary BC in a branch….

…

--------------------------------------------------------------- Alison Marsden, PhD (she / her) Douglass M. and Nola Leishman Professor of Cardiovascular Disease Professor of Pediatrics and Bioengineering, and by courtesy of Mechanical Engineering Institute for Computational and Mathematical Engineering Stanford University https://cbcl.stanford.edu/ www.simvascular.org<http://www.simvascular.org> Co-Director CHIP T32 Program https://med.stanford.edu/cvi/education/chip-t32.html#appl From: Dave Parker ***@***.***> Date: Tuesday, December 9, 2025 at 8:53 AM To: SimVascular/svMultiPhysics ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [SimVascular/svMultiPhysics] Add coronary boundary condition (Issue #481) [https://avatars.githubusercontent.com/u/23109458?s=20&v=4]ktbolt left a comment (SimVascular/svMultiPhysics#481)<https://urldefense.com/v3/__https://github.com/SimVascular/svMultiPhysics/issues/481*issuecomment-3633260786__;Iw!!G92We9drHetJ8EofZw!ZX1a2B6jlIxc92PBIMPLZivFTQqSOgClwOCTdNNpoU47LWnymDdpC774ztcLNZo8O_yWffFVvgFdOrMyjgLfD_yYQz4$> @chlookaburra<https://urldefense.com/v3/__https://github.com/chlookaburra__;!!G92We9drHetJ8EofZw!ZX1a2B6jlIxc92PBIMPLZivFTQqSOgClwOCTdNNpoU47LWnymDdpC774ztcLNZo8O_yWffFVvgFdOrMyjgLfCva9CgA$> What do you think about all this ? — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/SimVascular/svMultiPhysics/issues/481*issuecomment-3633260786__;Iw!!G92We9drHetJ8EofZw!ZX1a2B6jlIxc92PBIMPLZivFTQqSOgClwOCTdNNpoU47LWnymDdpC774ztcLNZo8O_yWffFVvgFdOrMyjgLfD_yYQz4$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ADJGJZ7TDHYJJSVBSN3FYR34A35BFAVCNFSM6AAAAACONKKS36VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMMZTGI3DANZYGY__;!!G92We9drHetJ8EofZw!ZX1a2B6jlIxc92PBIMPLZivFTQqSOgClwOCTdNNpoU47LWnymDdpC774ztcLNZo8O_yWffFVvgFdOrMyjgLfYas6r58$>. You are receiving this because you are subscribed to this thread.

[ktbolt]

@menon-karthik @ngrandeg Have you implemented any coronary BC code ?

[menon-karthik]

@alisonmarsden @ktbolt No, I always just couple with sv0D. I like Dave's idea of reusing sv0D's implementation internally. This can either be done by automatically writing the correct sv0D JSON file for coupling or just creating the sv0D model internally without writing the file. The latter would be better and should work because I implemented the interface to just store the 0D model within the 3D solver the first time it is read. So it does not need the 0D JSON file after the model is first read.

[chlookaburra]

@ktbolt I agree - I think it would be a good idea to reuse sv0D internally to handle the coronary BCs.

Alternatively, if you want to take the coupled .json file approach, Karthik's files on Oak all use the old interface files to sv0D. The file format needs to be edited a little if you are interested in using his files for testing purposes.

[ktbolt]

@chlookaburra @menon-karthik Thank you for your comments !

My initial plan was to create the JSON data internally in the svMultiPhysics code and pass it to sv0D but really sv0D should be doing all of this since svMultiPhysics should not know about the coronary boundary condition format.

And the coronary boundary conditions will need to work with other LPM boundary conditions read from a file.

[menon-karthik]

@ktbolt For what you suggested, I believe the only thing you will need to do in sv0D interface is to implement something like initialize_from_svmultiphysics that is called from svMultiPhysics, instead of the current initialize function. The new function will just need to provide sv0D with all the same information that would otherwise be in a JSON file to create the 0D model.

I guess the decision you have to make is whether you want svMultiPhysics to be agnostic to sv0D formatting (which is what you suggested) or sv0D to be agnostic to svMultiphysics (which is the previous option of creating the JSON internally in svMultiPhysics).

[ktbolt]

@menon-karthik Thanks for the information, will get me started on this.

svMultiPhysics should be agnostic to sv0D formatting.