I have a question regarding the element types I can use in FSI coupling between OpenFOAM and CalculiX. I recently run some tests with linear and second FE elements. The cases converge but the results seem different and I wonder if second order elements can be used in the coupling at all:
Typically, in FEA second order (Tet) elements are used, as they give more accurate results compared to linear elements (in particular linear Tets) and are more flexible in meshing complex geometries. In a FSI analysis in most cases the deformation of the structure takes place by the fluid pressure. If I would like to transfer the (fluid) pressure to forces for second order elements, as far as understood care has to be taken regarding the force distribution on the different nodes (distinguish between corner node and node on edge).
I wonder if this kind of weighting (to distinguish between corner nodes and edge-nodes) is considered in preCICE for second order FE-elements or if there is no need to consider this (e.g. in a conservative nearest-projection coupling).
Thanks
Best regards
at the moment, there is no consideration for how the forces are applied to the nodes depending on their position in the mesh (corner or edge nodes). This is something that can be looked into, but we need to look at the coupling.
By modifying the value of a force on a node after reading in the forces from preCICE, preCICE will not know this. This can influence the stability and convergence of the Quasi-Newton schemes. preCICE thinks it is applying a specific load, but it actually is not, and therefore the results of the simulation are not due to the forces it sent to CalculiX.
However, I think this raises a good point and does need to be looked at. I think this should be tested after trying out with DLOAD instead.
thanks for your reply. Good to know this. This might be a general issue (not CalculiX only). I think the equivalent nodal force is caused by the shape function of the element. Please see the details here, in particular 3d quadratic isoparametric element:
So this might affect all second order elements in almost every FE-code. Or what do you think?
For the second order tetrahedral elements a pragmatic approach might be to use two different node groups in the mapping, one for displacement (with all nodes to preserve the spatial resolution) and the other one for forces using the mid-nodes only. For the tetrahedral second order element the corner nodes don’t carry any forces, the forces are distributed uniformly on the mid-nodes (each 1/3 of the pressure load). So if preCICE does only see element the mid-nodes for a conservative force mapping in case of second order tetrahedral element, the nodal load onto the individual nodes might be correct. Do you think this makes sense and is feasible?
I followed your suggestion and compared the DLoad in CalculiX with the CLoad on different node groups. I performed the test for tetrahedral second order elements. In one case I applied the corresponding force on all surface nodes (as preCICE seems to do for now), in the other case only on the mid-nodes of the elements to consider the theory for equivalent forces on second order elements. At least for displacement response (what is the most important outcome for me), I didn’t see a different between these conditions. Also the resulting displacement matches very well with the analytical solution. So far for me it seems the preCICE approach should be okay to use a uniform distribution on all nodes.
I read this post and wondered if you had any experience with DLOAD and CalculiX. As far as I know the CalculiX adapter is currently not able to read pressures using DLOAD. So I am thinking about implementing this functionality and wanted to ask if this already exists or if there is any preliminary work on it. Or are there any reasons that would make such an approach questionable?
As far as I can see, you have already dealt with this here, which is why I am curious about your experiences.
Best regards,
Matthias
from my point of view, a major advantage of using forces is that both the normal and the tangential part of the forces can be consistently transferred to the structure. If DLoad is used, I suspect that only the normal portion (the pressure forces from the fluid) can be transferred (I may be wrong). The normal component will be the main component for most applications, but the preCICE adapter in OpenFOAM also calculates the shear component and transfers that to the structure as well.
Hi @Ulrich
I am trying to develop a general way to handle higher order elements in the CalculiX Adapter. My question is with respect to the following part of your answer:
I am trying to figure out if a general way of handling this can be implemented in the adapter code. The corresponding GitHub issue is this one. If you have more thoughts on this it would be of great help if you could comment on the issue.
Handling of higher order elements is a recurring problem and we are thinking of handling it in a general way.
Hi @KyleDavisSA , Hi @IshaanDesai,
I am currently working on an implementation for using DLOADs on the CalculiX side. DLOADs are used on faces, so a faces mesh should be defined for them. As far as I know, a faces mesh in CalculiX is only possible for tetrahedral elements so far, and I’m currently trying to extend that accordingly for hexahedral elements. So I wanted to ask you if you have worked on something like this before or if you are interested in it and maybe you want to give me some hints what you think is important to consider.
Furthermore, if my understanding right now is correct, the preCICE website is a little bit misleading regarding the supported elements part of the CalculiX adapter with respect to this topic, as it states that the restriction to tetrahedral elements only occurs for nearest projection mapping. Correct me if I’m wrong or if you know better. @Ulrich Thank you for your answer. I’m aware of the things you write and on a long term basis, forces are definitely the mature chose, but right now my fluid solver only computes the forces only from the pressure anyway, so I try to profit from consistent precice Mapping by using the pressure.
Besides, as you may be intrested in it, I managed to work on an extension of the CalculiX adapter to enable the use of the MODAL DYNAMIC Analysis of CalculiX, which can lead to great improvement in runtime on CalculiX side.
Your understanding here is indeed correct. To the best of my knowledge no work in the direction of implementing support for hexahedral elements has been done, but perhaps @KyleDavisSA knows more about this.
I rechecked the preCICE website section and to my understanding it correctly states that when a face-centered mesh is defined and if nearest-projection mapping is the choice, then the elements need to be tetrahedral. This is because preCICE only works with surface triangles while computing the mapping using the nearest-projection method. However if a nodes mesh is defined and nearest-neighbor or RBF mapping is used then hexahedral elements would also work. I agree that the documentation could be more clear though, I will rectify this.
This is great, I did not know of this feature but had a quick look in the documentation right now and got a brief idea. Is this Adapter extension something that we can include in the adapter?
I am willing to contribute my changes to the adapter as soon as they are ‘ready enough’, i.e. both the extension for MODAL DYNAMIC and to hexahedral elements together as a pull request.
Especially I would be happy if the community could help to further improve the new capabilities and help me by testing them.
I am certain that the topics you are covering have a wider interest in the preCICE community. Reagrding further improvements and testing, I would personally be very happy to help there! We look forward to your contribution
That would be great! I would, however, encourage you to already now open a draft Pull Request to work on, explaining what steps you are planning to take and keeping your future notes there.
We can always clean it up later and even remove traces of “quick and dirty” solutions. It would definitely make collaboration easier.
It would definitely make collaboration easier.