Add optional unit conversion factor when coupling to svZeroD

[aabrown100-git]

Problem

When using an svZeroD coupled boundary condition, pressure and flow rate are passed between svMultiPhysics and svZeroDSolver without any conversion. This forces the units to be the same in each input file. This is somewhat limiting, since units that are natural for the 0D domain (e.g. mmHg) are not typical for the 3D domain (e.g. Pa).

Solution

Allow the user to specify pressure and flowrate conversion factors in the xml input file. For example,

<svZeroDSolver_interface> 
     <Coupling_type> semi-implicit </Coupling_type>
     <Configuration_file> svzerod_3Dcoupling.json </Configuration_file>
     <Shared_library> ../../../../svZeroDSolver/build/src/interface/libsvzero_interface.dylib </Shared_library>  
     <Initial_flows> 0.0 </Initial_flows>
     <Initial_pressures> 0.0 </Initial_pressures>
     <Pressure_conversion_factor> 0.00750062 </Pressure_conversion_factor> <!-- Pa to mmHg -->
     <Flowrate_conversion_factor> 1e6 </Flowrate_conversion_factor> <!-- m^3 to mL -->
   </svZeroDSolver_interface> 

Additional context

This feature is available for genBC, although in genBC the conversion is performed on the 0D side of the communication.

Code of Conduct

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

[ktbolt]

@aabrown100-git Using the same units for 0D and 3D seems natural since the units used in the mesh and all boundary conditions must be consistent and that is the responsibility of the user. This is why I would like to remove the mesh scaling parameter.

Having conversion factors external to the 0D JSON file will be another obscure detail that a user will need to get right.

[aabrown100-git]

@ktbolt I think if we make it an optional parameter, then there shouldn't be any additional confusion for the user. It will just be an available convenience function.

For my own work, without this capability, I will have to convert all the parameter values in my sv0D configuration file. Not a huge deal, but somewhat annoying, and also more prone to errors that defining two conversion factors.

[ktbolt]

@aabrown100-git Adding these extra parameters will require

• updates to Parameters classes
• updates to solver parameter processing
• updates to the 0D solver API
• adding testing
• adding documentation
• adding SV CFD Tool GUI updates (maybe)

This is a lot of work for perhaps a singular use case, a lot less work to write a Python script to scale the parameters.

Maybe a better solution is to add a scaling parameter to the 0D solver JSON file ?

[aabrown100-git]

@ktbolt Okay good points, although I was able to implement the feature pretty quickly with Cursor. Probably should've waited for further discussion, but it wasn't too much work. I think adding a scaling parameter to the 0D solver JSON file is a good idea too, but I'm less familiar with sv0D than svMultiPhysics.

[chlookaburra]

@aabrown100-git I see @ktbolt 's argument, and, as someone who uses this 3D/0D coupling file, I also think this should be self-contained in the .json file and not the .xml file if your goal is to use this only for the BCs. That way, if people do have flows and/or pressures they input into only the 0D json file, they can convert the units there too (so you are helping both solver communities). Any chance you can employ your mastery of "vibe coding" to put this into the .json file instead if it is not too much work ? (I still live a Cursor-less life...)

[aabrown100-git]

@chlookaburra Thanks for the input! I'll look into it. @ncdorn is it possible/easy to implement this conversion factor on the sv0D side?

@chlookaburra @ktbolt Just want to clarify, what's the advantage of implementing this on the sv0D side vs the svMultiPhysics side? Not sure I completely understand

[chlookaburra]

@aabrown100-git My reasoning is that the .json file should be self-contained and clearly define everything that goes into the 0D solver (in other words, a user without any prior knowledge of the interface should be able to stare the .json file alone and know exactly what is going into the 0D solver and what units are being used).

We have moved past the (haunted) .dat era of this 3D/0D interface evolution, and so I really hope we can add this to the .json file and not have to change things on an external file.... @ktbolt - is that in line with your thought process?

[aabrown100-git]

@chlookaburra
I guess my feeling is if a user is setting up a 3D-0D simulation, they have to understand the 3D part (.xml) as well. So to me it feels just as reasonable to have these conversion factors defined on the 3D side.

But happy to help consider implementing this on the 0D side. Are you thinking of having these conversion factors in the .json under "simulation_parameters"?

[ncdorn]

I think it would be relatively straightforward to implement a dyn/cm2 -> mmHg unit conversion on the 0D side in "simulation_parameters", if that is what you all decide is the ideal route.

[ktbolt]

@chlookaburra My primary objection is to do any scaling because it will be so easy to get it wrong. When you are doing a simulation then create the input files with values that are consistent with how they are to be used in a 3D context. This is what a user does with the 3D mesh and boundary conditions.

The user can of course create the 0D files incorrectly but that is part of a more complex process and not just typing a number in wrong. Or is it two numbers you can type in wrong ?

I would suggest not adding a unit conversion on the 0D side, forget what I said about that.

[chlookaburra]

@ktbolt I see, so you are disapproving the feature in general—no new changes to the xml or json.

In terms of where it is implemented, if at all, I believe it is much cleaner to add this to the 0D .json (compared to .xml) if many people need this for their work and if it is straightforward/optional ... "simulation_parameters" sounds good to me in that regard.

[aabrown100-git]

I have been convinced of the evils of scaling/conversion factors. Easy and safer to just use consistent units between 3D and 0D. I will close this issue and #465.