[WiWo]

Hello everybody,

I'm working on the oscillation of bubbles inside compliant cylindrical tubes filled with liquid. I use FSI (icoFsiFoam) with an additional inner loop to take care of strong coupling.
So far I consider an axially symmetric case, e.g. one bubble in the center of the cylindrical tube. Thus I though it's a good idea to use a wedge mesh for this purpose (see imagewedge_FSI.jpg). The wedge mesh is constructed according to the criteria given in the guidelines in the user's manual (U-130, U-131). The red mesh represents the fluid region the grey mesh is put on top of it as the solid region also having wedge boundaries. FSI happens at the interface of the two regions.


As soon as I start moving the circular boundary (representing the spherical bubble) in a prescribed way by manipulating the respective boundaryField of motionU, the "axis" boundary of the wedge (the symmetry axis) starts deforming as well (see imagewedge_FSI_deform_cut.jpg) – which is of course not my intention. All the other boundaries (inlet, outlet) stay perfectly in place though. I found out that no matter which boundary I’m actually moving, the "axis" layer always seems to be dragged away by the moving mesh – it doesn’t stay in place! Even if I change the type of "axis" from symmetryPlane to patch or wall, this behavior doesn’t change. Is this effect related to the surfaces of "axis" being collapsed to a line?

I discovered that setting “distancePatches(axis);” instead of “distancePatches(consoleFluid);” in dynamicMeshDict.h stops the axis from moving but makes the mesh motion crash pretty soon. So I’m a little bit lost here. Maybe I need to specify one of the other parameters in dynamicMeshDict.h in a different way? So far they look as follows:

dynamicFvMesh dynamicMotionSolverFvMesh;
twoDMotion no;
solver laplaceFaceDecomposition;
diffusivity quadratic;
frozenDiffusion off;
distancePatches
(
consoleFluid
);

I must admit that I’m not totally aware of the meaning of some of these parameters – so if somebody could explain their purpose and handling, I would be very glad.

Does anybody have an idea about how to solve this problem, e.g. have dynamic mesh motion in a wedge mesh with the symmetry axis staying in place?

I would be very grateful for any help, hints and suggestions!

Best regards,
Wolfgang

[elorriaux]

Hello Wolfgang,

I've already done such mesh motions without too much problems.

I cannot really say what's wrong in your model, but I'm wondering why you still have an axis patch. Your axis patch should contain 0 faces, either there's a problem in your meshing process.

I don't think it can be the sensible point, but I used laplaceCellDecomposition instead of laplaceFaceDecomposition solver.

You can also try to set lower convergence residuals in your tetFemSolution file and see what happens.

I would also try to remove the distancePatches and use a uniform diffusivity.

Regards, Etienne.

[WiWo]

Hi Etienne,

Thanks for your quick reply! I checked my wedge mesh - it seems to be ok. Zero faces in the "axis" patch - as should be. But I still need to declare the patch (as symmetryPlane), right?
I tried the laplaceCellDecomposition and also a uniform diffusivity. Still, the symmetry axis is bent as soon as the mesh starts moving. Is there no way I can tell OpenFoam to regard the axis as fixed (just like the other walls) and leave it as it is?

You mentioned that you have worked on a similar case without problems - could you tell a bit more about the case? Was it also a body moving/expanding in a wedge mesh? Do you have an example which worked?

Thanks again for you efforts!

Best regards,
Wolfgang

[WiWo]

Hi again,

I just ran a few tests with the movingConeMotion tutorial case for icoDyMFoam which also uses wedge mesh and laplaceFaceDecomposition (also tried laplaceCellDecomposition). This case works nicely as long as motion happens only in x direction (the same is true for my bubble case). As soon as motion components in other directions are added, the axis deforms as well. As I was using the mesh provided with the tutorial and the same comportment could be assessed as with my bubble mesh, I'd suggest that the problem is somewhere in the definition of the "axis" or in how the motionSolver treats the axis.

Did you ever try to do mesh motion non-parallel to the symmetry axis?

Cheers,
Wolfgang

[elorriaux]

Hi Wolfgang,

my case was a semi circle lying on the revolution axis, just as yours, but it moves only along the axis. So effectively, your problem is surely due to the motion along the radius axis.

The problem is that you have no control over the axis, since this patch contains 0 faces, whatever the BC you use for the axis. Actually you can even remove this patch from the boundary file, changing the number of patches accordingly at the beginning of the file, you'll see that it will not change anything in your case, this patch is useless.

One idea would be to code to solve your problem. I would try to identify the faces of your front and back planes sharing one common edge to get the faces along the axis (by coding, defining a faceZone or whatever), then see the behavior if you try to fix brutally motionU to 0 along the radius direction over those faces. I've already seen that there was a setValue function in the code to do such things, but I've never used it. It's just an idea, I cannot ensure that it is possible.

You can maybe rework the mesh in order to keep small faces along the axis, using a symmetryPlane for physical variables and a slip condition for motionU, hoping this trick will not influence too much your results.

If the moving patch wasn't in contact with the axis, you could have used the subsetMotionSolver to keep a zone around the axis static, but it's not possible here....

I don't have any other ideas right now, sorry

Good luck

Etienne.

[WiWo]

Hi Etienne,

You are absolutely right. The axis patch - though present in the boundary file - is just ignored because it contains 0 faces. I ran the case again just omitting this patch - there were no complains and nothing changed.
So I went on to have a very thin non-zero symmetry patch at the position of the axis. It looked pretty good and the the I could start the motion without the axis beeing bent. After some time steps, though, the process crashes due to "moving mesh continuity error" skyrocketing. This might be due to my cheating with the axis patch or due to a problem with meshPhi when working with strongly coupled FSI (see thread).

I learned how to handle zones in OF, but didn't succeed so far in prescribing motionU to stay 0 there. You mentioned the function setValue - where can I find this function?

Thanks for your valuable help!
Cheers,
Wolfgang

[elorriaux]

Hi Wolfgang,

sorry for the delay.

The setValues member is available in the fvMatrix class. It can be used to fix the solution in cells and it adapts accordingly the matrix. I think you will have to dig in the mesh motion solver to see if it's usable for this kind of purpose.

Regards, Etienne.