Variable wall material properties for STRUCT and LELAS

[schwarz-e]

For projects where the stiffness of a vessel is known to vary spatially, variable wall properties are needed.

My plan is to add the ability to input a .vtu with a "varWallProps" nodal data array where the first value is used as the Young's modulus and the second is the Poisson ratio.

When added, the LELAS/STRUCT modules will interpolate the element-wise modulus/ratio from the nodal values using the nodal shape functions and use that to calculate the resulting stress from deformation.

Additional benefit will be a structure for adding additional variable wall properties as necessary for future developments (i.e. anisotropic inputs).

@ktbolt adding this despite the freeze in case it's useful to some people in the meantime

[ktbolt]

@schwarz-e This sounds good; it will be several months before the new C++ solver is ready.

You should add two separate VTK NodeData arrays, one for Young's modulus and one for the Poisson ratio. This makes it clear what the data is, seen problems with this kind of thing in svSolver. It will also be easier to implement in the current Fortran svFSI version.

How do you create the VTU files? I worked on an interactive VTK app for this based on selecting points on centerlines but never finished it.

[schwarz-e]

I already implemented and opened a pull request for them as a single data array- I know it might be clearer to have separate, but in the interest in flexibility having them together seemed like a good choice (I can document it's usage in svFSI-Tests to help users who are interested).

Right now for my application I'm creating the wall using a structured grid, and at some of the points I have control points where the material properties are explicitly defined. I use spline interpolation over the "rectilinear patches" of the structured grid to propagate to every point on the input vtu. This is pretty specific to my current application, but in theory you could write a script for any function on the mesh wall (i.e. calculate distance to centerline/thicknesss at each node and then calculate wall properties based on that)

[ktbolt]

@schwarz-e Issues are used to initiate code development for an enhancement or a bug fix. This allows other developers to evaluate and discuss things like

• usefulness and impact the addition of any code may have on the code base
• how new code might best be integrated into existing code
• how the additional work fits in with the current development plan
• how the new functionality it can be used, updates to the solver input format, etc.
• how it can be tested
• how it is to be documented
• solver job examples

It's not clear how your changes may affect the stability of the code, which tests need to be rerun, etc.

[vvedula22]

Since this is already implemented, I will review this pull request and merge it with the master branch. However, we may have to create a separate issue for creating a general framework for loading element/node-wise wall properties. I got this request multiple times where people are interested to load spatially-dependent anisotropic model parameters (e.g., HGO model).

I am inclined to use the current domain-based setup and name the variables in the vtu file as something like, _<property_name> such as HGO_a4, HO_a, Guccione_C, etc.

[schwarz-e]

@ktbolt I have some tests and example files that I used to test functionality (i.e. ensuring that when identical properties are applied to every node it yields the same result as the non-variable wall solution). I can open a pull request in svFSI-Tests to share those files and modify svFSI_master.inp to document usage.

@vvedula22 I agree that it would be good to have more checks around the variable wall input, but I worry that having to add a data array for every single variable would get pretty unwieldy when working with more complex variable wall inputs such as anisotropic stiffness tensor. What if we made it so the mapping between varWallProp's indexes and which parameter they map to was specified in the svFSI.inp file? i.e.:

""Add equation: struct {
...
...
...

Constitutive model: nHK
Density: 1000.0
Elasticity modulus array: 1
Poisson ratio array: 2

...
...""

where the array specifies which position in varWallProps the parameter lives?

[ktbolt]

@schwarz-e Great! Add the tests to svFSI-Tests following the naming convention used there.

I think scalar arrays should have separate variables. Tensors should be a single variable.

[vvedula22]

@schwarz-e I guess your implementation is similar to the way we load variable wall properties for CMM equation and looks mostly fine. However, a few areas could be modified, if not now, but sooner or later.

1. We should not have the variable wall properties in the vtu file as a single array. For instance, in the example you shared, there is an array varWallProps that stores both elasticity modulus and Poisson ratio as a vector. I'd recommend not using indexes and hard-coded entries (such as index 1 is for Elasticity_modulus and index 2 is for Poisson_ratio) but use a verbose file where each property is defined in the vtu file. For e.g., a separate scalar field should be provided in the vtu file for each property such as Elasticity_modulus and Poisson_ratio.

Internally, we could still store these properties either as a global nodal array or as properties of the mesh. We should then loop over all the possible properties and identify the fields that are provided through the vtu file and the ones that are provided as constants in the equation/domain section of the input file.

2. I also think we should stay away from declaring these data structures for all the nodes (e.g., `tnNo) but only for that particular mesh. For e.g., if we are doing an FSI simulation, we don't have to declare these properties for all the nodes but only on the solid domain where we usually provide these values as input.

Note that CMM implementation is a one-off thing where there are exactly two parameters and that the size is dependent on whether we are initializing the CMM or performing a full FSI with CMM. However, what you are interested in here is more general as this involves several possible material models with several combinations of input parameters.

If you agree, for the time being, I will close your pull-request without merging it. However, I saved a patch and have your modifications on my computer on a local branch. I will create a separate issue for implementing variable wall properties in a more verbose and generic format that can be easily extended to all the material models. Will use your test case in svFSI_Tests for testing it and seek your help as needed.