Add documentation for volumetric coupling with the CalculiX adapter

[IshaanDesai]

Documentation for volumetric coupling functionality implemented in the CalculiX adapter. Feature PR: precice/calculix-adapter#146

[MakisH]

A note on the motivation for splitting the tensors into multiple data fields would be useful (related to precice/precice#2085). I guess this also comes with some limitations: how does IQN work with such data?

[IshaanDesai]

I have removed the data that can be read and written on a elements-mesh because this PR should be solely about volumetric coupling and not about multiscale mechanics. I will add the documentation associated to multiscale mechanics in a separate PR.

[MakisH]

Does this mean that we can define such an elements-mesh but we cannot currently read/write anything on it? We should then give more context on why that is, what we aim for, and how this still might be useful to someone at this state.

[IshaanDesai]

Does this mean that we can define such an elements-mesh but we cannot currently read/write anything on it?

We can attempt to read and write and of the data that we current support in the adapter. But not all data exists on a quadrature point of an element. Hence the use of elements-mesh is a bit open-ended. With precice/calculix-adapter#135 we are able to read strains and write stresses and stiffness values to CalculiX.

We should then give more context on why that is, what we aim for, and how this still might be useful to someone at this state.

I would explain it in the following way:

1. We do not officially support data on the elements-mesh because we do not have test cases with relevant physical scenarios.
2. Currently we aim to support read strains, and writing stresses and stiffness, because we have a multiscale mechanics application case at hand.
3. The elements-mesh is useful to someone who wants to play with volumetric coupling with CalculiX. A user can look at this like an experimental feature which we are still testing.

Are these explanations satisfactory?

[MakisH]

because we do not have test cases with relevant physical scenarios.

this sounds independent: we might not have a test case but still support. The interest here is what the adapter can actually do at the moment, even if experimental/not officially supported.

I guess not even stresses will work at the moment without #135, since you do all this additional work there. Would temperatures work? This is also the main target for some users. Heat fluxes (in some form)?

The rest sounds good.

[IshaanDesai]

this sounds independent: we might not have a test case but still support. The interest here is what the adapter can actually do at the moment, even if experimental/not officially supported.

Good point.

I guess not even stresses will work at the moment without #135, since you do all this additional work there.

Correct.

Would temperatures work? This is also the main target for some users. Heat fluxes (in some form)?

Temperatures and heat sources (not fluxes) should work with elements-mesh. We would have to of course test things, but by design it should work.