Complication in combining subsetMotionSolver and interTrackFoam
 

Dear all,

Currently I am working on a kind of tank case, where I model the free surface with interTrackFoam (from 1.6-extend). For now I am quite satisfied with this solver, however, since I have a large bulk part, I want to solve for the mesh motion only in the region near the interface, mainly to save some computational cost (and because it shouldn't pose a problem and doesn't change the physics).

Following some threads on this forum, I selected some cells (cellSet), and updated the dictionaries to use the subsetMotionSolver. However, at this point I encounter a problem. This even happens when the cellSet is the whole domain. I reproduced the problem for the ramp case (from the interTrackFoam tutorials). I attached the case to this thread. Also attached are two figures, illustrating the problem for the regular ramp case, and the case where subset == whole domain. The problem originates in the top right cell here. The next timestep will crash the computation. Of course I left everything else the same.

I have no prior experience with the subset motion solver, but my main suspect is that 'somewhere' the necessary keyword pointNormalsCorrectionPatches (based on the attached figures), is not correctly linked. Unfortunately, I am by no means an expert in OpenFOAM (yet ;))

Any advise, help or hints will be very welcome!

Best regards,
Bernhard


Attachment 6880

Attachment 6881

Attachment 6882

Any hints or tips to this subject are still very welcome!

A small update for this topic.

Based on this bugfix:
https://sourceforge.net/apps/mantisb...view.php?id=54
I upgraded my 1.6-ext version, this solved the issue I posted above, but eventually introcuded something else, which is clear from the attached figure.

By introducing the subset motion solver, these keywords are not longer used:

dynamicFvMesh dynamicMotionSolverFvMesh;
twoDMotion yes;
distancePatches 1 (freeSurface);


Attachment 7000

Bernhard,

I'm sorry to say that I have no solution to your problem. I tried your case, with same results. Further, I got another error when setting the cellSetDict to something like where not the whole domain is covered. After a few iterations I get BTW: Did you ever try this or another case in parallel? I'm having a lot trouble using decomposeParWithSets in combination with the subsetMotionSolver.

Arne

Arne,

Thanks for your reply. Unfortunately, I didn't come to solve this issue yet.

The cellSet you are defining, it think it is empty, since in the attached case, the coordinate for the unused z-direction ranges from 0 to 0.1, so there are no cell centers in your box. I am not familiar with the error you are getting.

No, I did not try to run this case in parallel. For the interTrackFoam solver there are some considerations for running in parallel, you can find some hints on this forum, since for interTrackFoam in general you have to be careful in decomposing the case with respect to the freeSurface patch and finite area part. May the preservePatches keyword in the decomposePar dictionary can help you, but I don't know that for sure.

Bernhard

Damn, I mixed up y and z. Normally, I define z in vertical direction, at least in 3D.

Yes, I already found out that running a dynamic mesh case in parallel with cell sets does not seem to be that easy to set up. I will have a look at preservePatches.

Thanks, Arne

Hello Bernhard,

did you come up with a solution to the interTrackFoam + subset motion solver problem?

I'm experiencing the same problems on another case and I was wondering if the two can work together at all. It seems that the motion solver is only suited for calculations where the motion of the interface with the fixed cells is prescribed.

Thanks, and best regards

Diego

Unfortunately, I was never able to come with some solution to this issue. Probably it is not possible via the dictionaries, but then you have to dig deeper in the code.

An alternative is to set the diffusivity at some locations to zero (maybe you can adjust the solver to read this from 0/ and set this with setFields?), but I don't know in what respect this will increase your solution speed.

As I got an answer notification as well, just a comment from my side: I also gave up using the subSet motion solver, in my case in combination with a modified interDyMFoam solver. I think I somewhen managed to get this working, but it was only in serial mode. As I need parallel calculations, this was no option for me. The second reason was that the motion solver, esp. laplaceFaceDecomposition which I had to use, is rather slow.

Therefore I switched to a direct calculation of the mesh point positions via some distance functions. In my case the bottom is moving and the internal points are only moving in vertical direction. Maybe this works for you as well?

Arne

Hello everybody,

I'm not sure whether anyone is still interested in that topic ... I experienced a similar issue when using bubbleInterTrackFoam.

The problem seems to be related to the search for motionU which is performed in freeSurface.C - specifically inside moveMeshPointsForOldFreeSurfDisplacement() and moveMeshpoints. The solver is searching for either motionU or pointMotionU in order to determine whether to use feMotion or fvMotion. Now, the point is that it searches in mesh().objectRegistry whereas for subsetMotion motionU is registered with the moving mesh which is a different entity under the top level runTime object- see objectRegistry motionU. That's why neither the femotionSolver nor the fvMotionSolver solver gets activated (both bool variables are 0) and you just skip the mesh motion part. I guess that explains why in Bernhards case only the boundary but not the internal mesh moves.

Now, to remedy this issue you must provide the moving mesh (similar to the implementation in icoFsiFoam - file readCouplingProperties.H). Providing the name of your moving region (the one you give your cell set) can be done via a dictionary (here the couplingProperties dictionary) e.g.

word movingRegionName(couplingProperties.lookup("moving Region"));
const fvMesh& motionMesh = runTime.objectRegistry::lookupObject<fvMesh>(movin gRegionName);


I inserted that piece of code in the top level solver and then provided motionMesh to the freeSurface class.

Then we can substitute (all) the calls for mesh().objectRegistry in freeSurface.C by motionMesh.objectRegistry and the solver will search motionU (or pointMotionU) in the objectRegistry of the moving mesh we specified in the dictionary. This procedure provides the freedom to go back to non-subsetMotion quickly by specifying “movingRegion region0” in the dictionary. In that case motionMesh will just be mesh() and everything should work just as before.


Cheers,
Wolfgang

Thank you very much Wolfgang!
After I posted my reply I started looking into the freeSurface class actually suspecting that the point was exactly the one you raised.
But soon after I had no more time to go through it.
I think I'll dig deeper into that and see if your suggestions work also in my case.
If we find out that the change works and provides more flexibility in the choice of moving regions, we could propose the modification to be generally available.

Cheers,

diego

On point
 

@ Wolfgang

Bam - that's how it's done! I suspected my problems originate with objectRegistry.

Thank you much, Eric