CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Running, Solving & CFD

Complication in combining subsetMotionSolver and interTrackFoam

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree1Likes
  • 1 Post By WiWo

Reply
 
LinkBack Thread Tools Display Modes
Old   March 14, 2011, 08:19
Default Complication in combining subsetMotionSolver and interTrackFoam
  #1
Senior Member
 
Bernhard
Join Date: Sep 2009
Location: Delft
Posts: 790
Rep Power: 12
Bernhard is on a distinguished road
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


rampSubset.tar.gz

ramp.jpg

rampSubset.jpg
Bernhard is offline   Reply With Quote

Old   March 19, 2011, 15:06
Default
  #2
Senior Member
 
Bernhard
Join Date: Sep 2009
Location: Delft
Posts: 790
Rep Power: 12
Bernhard is on a distinguished road
Any hints or tips to this subject are still very welcome!
Bernhard is offline   Reply With Quote

Old   March 23, 2011, 05:38
Default
  #3
Senior Member
 
Bernhard
Join Date: Sep 2009
Location: Delft
Posts: 790
Rep Power: 12
Bernhard is on a distinguished road
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);


rampSubset2.jpg
Bernhard is offline   Reply With Quote

Old   July 8, 2011, 05:42
Default
  #4
Senior Member
 
Arne Stahlmann
Join Date: Nov 2009
Location: Hanover, Germany
Posts: 209
Rep Power: 8
Arnoldinho is on a distinguished road
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
Quote:
boxToCell
{
box (-10 -10 0.1) (10 10 10);
}
where not the whole domain is covered. After a few iterations I get
Quote:
--> FOAM FATAL ERROR:
bad size -1

From function List<T>::List(const label size)
in file /opt/OpenFOAM/OpenFOAM-1.6-ext/src/OpenFOAM/lnInclude/List.C at line 50.

FOAM aborting
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
Arnoldinho is offline   Reply With Quote

Old   July 13, 2011, 04:04
Default
  #5
Senior Member
 
Bernhard
Join Date: Sep 2009
Location: Delft
Posts: 790
Rep Power: 12
Bernhard is on a distinguished road
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
Bernhard is offline   Reply With Quote

Old   July 13, 2011, 08:06
Default
  #6
Senior Member
 
Arne Stahlmann
Join Date: Nov 2009
Location: Hanover, Germany
Posts: 209
Rep Power: 8
Arnoldinho is on a distinguished road
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
Arnoldinho is offline   Reply With Quote

Old   January 25, 2012, 09:35
Default
  #7
New Member
 
Diego Angeli
Join Date: Mar 2009
Posts: 26
Rep Power: 8
diego_angeli is on a distinguished road
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
diego_angeli is offline   Reply With Quote

Old   January 25, 2012, 09:43
Default
  #8
Senior Member
 
Bernhard
Join Date: Sep 2009
Location: Delft
Posts: 790
Rep Power: 12
Bernhard is on a distinguished road
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.
Bernhard is offline   Reply With Quote

Old   January 25, 2012, 09:50
Default
  #9
Senior Member
 
Arne Stahlmann
Join Date: Nov 2009
Location: Hanover, Germany
Posts: 209
Rep Power: 8
Arnoldinho is on a distinguished road
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
Arnoldinho is offline   Reply With Quote

Old   March 20, 2012, 13:39
Default
  #10
Member
 
Wolfgang W.
Join Date: Nov 2009
Location: Switzerland
Posts: 57
Rep Power: 7
WiWo is on a distinguished road
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
Bernhard likes this.
WiWo is offline   Reply With Quote

Old   March 21, 2012, 06:23
Default
  #11
New Member
 
Diego Angeli
Join Date: Mar 2009
Posts: 26
Rep Power: 8
diego_angeli is on a distinguished road
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
diego_angeli is offline   Reply With Quote

Old   February 8, 2014, 02:23
Default On point
  #12
Member
 
Eric Bryant
Join Date: Sep 2013
Location: Texas
Posts: 42
Rep Power: 3
codder is on a distinguished road
@ Wolfgang

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

Thank you much, Eric
codder is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT -4. The time now is 04:28.