No, i cleared both mesh and solution and then generated a new mesh along with a new initialization.

I can not sense your second sentence : "When the body moves, the initial surface will also be moved. Therefore..." what do you imply?

by the way I built a new non-symmetrical domain and a rigid body on it to me sure that the error has nothing to do with symmetry. Not only I got same error over and over, I faced up something new. I tried to run the simulation when all motions are off. in this case there was no trouble initializing the simulation but after few time steps water level somehow got torn in the vicinity of interface. Fiddling with options I found that "Interface tolerance" could effectively solve this problem, but i m not sure why this just happened?

It 's really become annoying struggling with this software ...:(

AFAIK, all free-surface codes (fluent, starccm, etc) display this behavioir where the size of the cell is gratly discontinous along the direction of the flow.

i would reccomand eliminating the firs prism layer at the interface. another viable option would be to use hexa cells also in the middle of your region. in my experience poly tends to produce high numerical diffusion in a vof simulation, wich in turn might lead to unrealistic pressure field like the one you are experiencing.

Hi anyone.
I am new to starccm and I want to run a simulation with it. i need a tutorial about embedded motion. can any one please help me. thank you.
Hashem

hashem_1064, have a look in the user guide, there's a tutorial section with some examples how to set up an embedded motion case.

Henry, I see it is frustrating to get a result as weird as yours. Unfortunately what I have to say might even rise your frustration.

First forget the post with remeshing / clearing solution etc. I was thinking on one of my cases where I extracted the boundary surface of the volume mesh and used it as initial surface to remesh the case.

Second I only got this error message when the center of mass was shifted. And I don't know what else you did, I just created a body representing the "ship", a sphere, did a split by surface topology, meshed it and the case was running. Of course I run it for just a few time steps, and the result wasn't good. But that's due to my mesh which was very coarse since I was just looking for the reason of you error message. And I don't expect good results with a bad mesh. but the software is capable to do a good job. So don't blame the software, look for the issues in your setup. I'm willing to help you, but not to listen to complaints.

Which error did you get? The floating point exception or the "xx has no embedded interface" message? Have you checked the convective courant number? What about the residuals, do they significantly drop in a time step? How long did you run the simulation before the weird free surface occured? Have you tried a finer mesh? Have you tried to place the body a little further from the inlet boundary? Have you tried some common "tuning" like increasing the viscosity of the gas phas?

Hello Abdul099.
I use "starccm+ v.4.04" and unfortunately seems that it dose not have tutorial about embedded motion.

Hi Abdul,
Great on-going conversation on VOF+DFBI simulation using STAR-CCM+. First of all, I am surprised with not included overlapping mesh feature. Another approach for developer would be AMR (Adapctive Mesh Refinement) technique to resolve free surface (0.5 value of iso surface of volume fraction of water) dynamically for each time-step.

Anyways, back to interface approach, following is my setup configuration. Correct me if I am wrong there:

Body-1:
- CAD: Boat & a spherical domain, and corresponding mesh
- Physics Motion: DFBI Translation & Rotation
- Flow Physics1: Common VOF Multiphase Physics

Body-2:
- CAD: Rectangular domain with substracted corresponding sphere
- Physics Motion: Stationary
- Flow Physics1: Common VOF Multiphase Physics

Now, spheres from both the Bodies are having an in-plane interface with approprite tolerance to have 100% initialization.

Under VOF wave situation, if a Body-1 is asked for 4-DOF [Heave(Tz), and three axis rotations (Rx, Ry, Rz)], then does this approch handle Translation (Tz)? Isn't it violating interface requirement?

If this is not the correct way, then what's missing here?

Thanks.

hashem_1064, there is a reason for newer versions than 4.04. As long as you've got a legal license, you can download it from the user services site.
I don't know if 4.04 can handle embedded rotation and translation (I think it can, but I'm not sure) - but as long as it can handle it, there should be something in the user guide. Search for "Dynamic Fluid Body Interaction".

naimishharpal, give your support engineer a call and you will find out, at least overlapping grids is under developement. You can be sure, you're not the only one waiting for it...
And the setup you described it NEARLY the right one. You have to define the motion specification of both region to DFBI embedded rotation. The inner (spherical) domain will do the rotation while both regions will translate according to the translation of the 6DOF-body. The consequence is, it's hard to define a refinement zone near the free surface, as the position of the free surface relative to the mesh changes with the motion of the 6DOF body. Therefore the outer region is NOT static!
Since both regions will translate for the same distance, interfacing doesn't cause any difficulties.

Ok. About the free surface error I solved the problem. As Sail stated, the problem was due to poor quality of interface mesh. I found that using trimmer in the inner domain would result in better convergence, but contrary to what he said about prism layer I found out that using few numbers of prism layer (namely up to 2) is quite remedial. Not having any prism layer on the interface needs smaller cell size which in turn results in high cost CFD analysis. I got negative volume error when I used no prism layer on the interface, so using prism layers helped me having a valid mesh without refining cell size.

Abdul, I should say that I m suspicious with your running because in that case you didn ’t pass release time so the 6-DOF solver didn t trigger yet. Through my experience working with star-ccm+ I v deduced that for some cases it shows haphazard manner in initialization. So I think it is quite possible that for a given setting one meets different initialization attitudes during several initializations. But something is for sure: no matter how the initialization is gone, if the setting is incorrect the solution process will fail.

The errors that I got are two: division by zero and no embedded interface. In doing embedded motion I think naimishharpal ‘s approach is right just in cases which don t involve translational motions, and I should use this approach. I saw similar setup in the user guide. But since I have translational motion maybe I should use 6-DOF motion instead of stationary.

If it's required to have translation motion (either Tx,Ty,Tz, or all of them) together with rotations, then I don't understand the benefit of using sphere based two region approach. If both the domain translate and rotate with zero relativity then what's the point to use it? By creating interface, we even slow down the overall computation. On the other hand, approach of having a single region (no sphere) would be better & 'simple' and serve the same purpose. Isn't it? Correct me here, if I am missing the concept.

To resolve mesh quality over free-surface, the only possible way is to have short of sixth-sense :cool: to feel the probable 6-DOF magnitudes and have controlled volume fine mesh over that region. It's not efficient, but I guess that's the only possible way for now.

On sides, I also tried DFBI Morphing to avoid all above problems but it's a headache. For large T and/or R, the mesh are twisted too much and solver usually ends up with negative volume. The new feature 'cell quality remediation' helps little but you can't avoid unpredictable sudden divergence.

----------
Another concern: Let's say you have some good coarse mesh convergence so far with 6-DOF using single region based DFBI T&R approach, and now you wanna refine the mesh and/or to add a fine control volume mesh. Now, is it going to reset the mesh (coming back to initial position), and did mesh generation? Or refine the mesh on currently oriented domain so that we can continue iterating onwards? Has anyone tried it so far? How is the experience?

Henry, when I tested your case, I set the release time and ramping time to 0, therefore the 6DOF body was released.

Also when you have a translational motion activated, you need to give DFBI motion to the outer region as this region has to do the translation. The problem is, I didn't see in your simulation something different. When I recognized the center of mass didn't coincide with the sphere center, I created a new sphere since I didn't knew the exact position of the sphere center. Due to that, I had a new region (I had to split it again) and didn't see your setting for the second region. But I didn't thought there might be something wrong which is as simple as that.

Regarding the haphazard initialization, you're right. I'm absolutely sure, all software developers on the world include some functions using random numbers in their software. Not because it's neccessary, just to drive some users crazy. Maybe they calculate a hash from the username and the current time and use that as a random number for initialization...
Okay, back to serious mode.
When the mesh is the same, the initialization will produce the same result. Only thing which could cause a difference are roundoff errors of the CPU, therefore it is hardware dependend. But even that didn't ever cause a significant difference in all simulations I ever did.

Do you still get the division by zero?

naimishharpal, there is a simple reason for the embedded rotation and translation approach: The embedded region can be meshed very fine and rotate for bigger angles while the outer region can be meshed fine just near the free surface.
Just imagine, you've got a ship which doesn't change it's position very much, but rotates around it's longitudinal axis for a big angle due to waves. With a single region, you would need to mesh a big part with a fine mesh. Although interfacing takes some time, it can accelerate the solution process.
But you should always take a model APPROPRIATE to your problem, not just a model with a nice name. For some problems, DFBI embedded rotation and translation is the appropriate model, for other problems it's DFBI rotation and translation and for some other problems you need DFBI morphing.....

DFBI morphing works fine, but like in any morphing case, you have to monitor cell quality and remesh when the distortion gets too high. And morphing takes a lot of time, needs a lot of memory and sometimes you need to remesh. Therefore I would use it only when it's absolutely neccessary. When you've got just a single body in your domain without any surrounding objects, use embedded rotation and translation.
By the way, cell quality remediation is nice, but abolutely no new feature. And it can't cause any miracles. For sure it can't make a mesh destroyed by the morpher including negative volume cells a good mesh you can continue running.

Meshing will always start from the initial surface. As long as you don't change anything on the initial surface, it will mesh the geometry in the initial position, therefore resetting the 6DOF body position. It is not recommended to remesh in this position, as the interpolation of the solution to the new mesh will not match the initial position.
When you need to refine it, it's best to delete the initial surface and remeshed surface representation. Then extract the boundary surface of the volume mesh representation and mesh this surface. To do this, I recommend to prepare your geometry on part level, since this gives you always the option to go back to the initial state. I used this approch several times. Of course, meshing takes some time and causes some interpolation error (switch to higher order stencil interpolation in the mesh continuum). But it works fine and can also be automated by a Java macro.

now all the problems is solved but one thing. I still get the error of "division by zero" when I turn on the rotation about x (longitudinal axis). do you have any Idea?

glad to know you've resolved the meshing problem, and i've also leearnt something by your statement about the validity of the prism layer. cfd is really black magick.

as the xx rotation giving issues i can only offer basic reccomandation, because it never happened to me:

is the inertia different than 0? maybe could be worth trying to put fake value on the off axis value?

have you tried to impose some force to stimulate the rotation, or at least checked the x axis momentum before switching it on? i'm thinking about a naturally instable shape that causes a too big movement. even if it should not be the case of your geometry (symmetric, as far as i know) but maybe htere are some instabilities?

have you tried to increase the ramp time for the switching? i'm not shure how you have set up it, but might it be that you swicth on the movements not alltogheter and you are already the ramp time when it's the x revolution turn?


those are just few things out of my head, it might be worth a try or it might be not...

good luck.

Thank you sail
You know I get the error on the initialization, so logically it has nothing to do with ramp time and naturally instability. My case is symmetric and it has nonzero inertia. I also gave it initial x angular velocity and moment but it did not work.
I still have the problem, I think something is wrong with the set up.

Sir, I am trying to simulate a torpedo type geometry moving on water surface in other words I am trying something similar to the boat in head tutorial. I get the pressure plots but I dont see the wave around the body. what might be the problem???? please help me. (its just a trial since the mesh is not good)

I'm wondering if you don't have waves or you just can't see them.

In the latter case have you tried to create an isosurface of 0.5 vof?

For the former you should explain more in deep your case setup to allow us to debug it. Just a hint: is your mesh fine enough to resolve the waves?

I have created VOF but cant see it, and my mesh is kind of OK like !!!

regards
www.aerosapien.blogspot.com

I would say that your mesh is too coarse to be able to resolve the waves, unless the speed is exceptionally high.

Could you post some plots of the vof on the symmetry and inlet, and the datails of your simulation?

I could finally generate the wave. Biggest blunder which I did was my model size was in mm and the wave amplitude was set in meters, I had simulated a tsunami wave by mistake. Any ways thanks for the supporting me in my problem;)

regards
www.aerosapien.blogspot.com