[Henry Arrigo]

Hello
I need to used overlapping technique for a DFBI case and I know that overlapping approach will help me doing my job. As far as I know STAR-CCM+ has provided this ability. Can someone tell me which version I should use to have access o this method.
thanks.

[abdul099]

You have to use a version which will be released next year at the earliest. With other words: Overlapping grids is not yet available in Star-CCM+. Too bad, but that's fact.

[Henry Arrigo]

Thanks, but the point is there are already some examples about this. see the pictures please.

[abdul099]

Belive me, overlapping grids is not yet implemented in Star-CCM+. Free falling live boats have been simulated either with overlapping grids with COMET (which is no longer available) or with DFBI-morphing or DFBI-rotation and translation with Star-CCM+.

For sure you are not the only one waiting for overlapping grids in Star-CCM+, there are many people asking for this. The guys from CD-adapco are working on it, BUT IT IS NOT YET AVAILABLE!

[Henry Arrigo]

Ok. Thanks anyway. Apparently I should defeat the challenge.

[abdul099]

Depends on your application. For sure overlapping grid can make live easier, but many thinks have also been possible without overlapping grids. When you can't get over it, you should defeat the challenge at least for the moment. It will probably take more than half a year until this long awaited feature is available. I got this information from a developer as there was an open day in the German office just a few days ago.

[Henry Arrigo]

Picking another approach, I decided to do embedded motion. Hope it works as there is no tutorial about that. The original case is studying boat in a free surface but I m trying to do a simplified case to get the main setting. there are some photos

[abdul099]

There is a tutorial, have a look at the "boat in head waves". The principle behind it is the same, the waves can be defined as flat wave when you don't need any waves.

[Henry Arrigo]

Thanks for your suggestion, I set up the case based on "boat it head waves" tutorial, instead of flat wave I defined three field functions for initializing the simulation. two of them represent the initial distribution of water and air and the other one defines the initial hydrostatic pressure. Also I used two trimmer for outer region and polyhedral mesher for inner -embedded- region. I also put 7 of prism layers to the rigid body. With all of these settings when I want to initialize I face floating point exception error and the dialog box refers me to the user 's guide. in the user 's guide I couldn t find anything related to the initialization error. the are some topic relating to troubleshooting in user guide but non of them is for the initialization. how can I remove the problem please?!
I have another question, should I insert prism layer to the interface?

[abdul099]

First try to initialize solution without field functions, just with constant values. When the error still occurs, it will get more difficult to find it, otherwise the error is somewhere in the field functions.

First things I would check beside the field functions is the 6DOF body itself and its parameters. Mass, moments of inertia, initial center of gravity, have you added the boundaries to the 6DOF body etc.
And since the error message complains about a division by zero, also check all input for a zero where it can't be. A velocity can be zero, but the mass of a ship, the gravity, time step or the density of a fluid can"t.

I also wonder why you need two field functions to initialize water and air. There should be only one. Something simple like

$$Centroid[2]<=10?1:0

This prevents any problems when the definition of your two field functions is not consistent.

Next point is: My boss would kill me when I would try to run a case with your mesh. Refine your mesh at the water level. Make sure, all cells on both sides of the interface have about the same size. Usually you can do this by setting the same surface size on both sides, both values for min and target size. It might work not very well due to the use of trimmer on one side and polyhedral mesher on the other side, so twiddle with this values until the cells on both sides are about the same.
A blunt body like this will not experience too much drag due to skin friction, so reducing the number of prism layers would also do a good job.

You don't need prism layers on interfaces, but it might help getting a higher cell quality. When you grow prism layers from the interface, make sure the thickness is big enough to keep jumps in cell sizes low (no tiny prism layers, make them about the same size like the other cells connected to the prism layers). And one prism layer at the interface will be sufficient, there is no boundary layer to resolve.

[Henry Arrigo]

I found that it strongly depends on the number of degrees of freedom. In the case that I turn on Y and Z rotation there is no problem with initialization; when I allow the "Deck" (rigid body part) to rotate in all three directions I get the previous error, "A floating point exception". Also by allowing the RB part to be rotating just in one direction for ex. X an error box pops up which says rigid body "Deck" has no embedding interface (Fig. 1). In the 6DOF properties I assigned the "Deck" to the rigid body part. Is this wrong?
Another question: How does the software identify which part should rotate? In this case for rotation in X direction apparently the whole domain should rotate but for the other two directions (Y & Z) STAR-CCM+ could probably solve the RB motion just by rotating the inner sphere. Is it logical to use a symmetric domain with the embedded motion solver? Should I make any kind of interface from two (circular and rectangular) symmetry planes?
BTW I changed the mesh as you can see.

[abdul099]

Okay, the mesh looks much better now. You still could save some cells by setting the prism layers at the interface to 1, but that shouldn't have any impact on your problem.

What did you mean with symmetrical model? Did you cut it in the middle and try to run only a half model?
That's fine as long as the only allowed rotation has an axis perpendicular to the symmetry plane and no translation perpendicular to the symmetry plane is allowed.

Anyway, a floating point exception right at initialisation shouldn't be caused by allowed or not allowed motions. At this point of the simulation, the 6DOF solver doesn't do anything, so it can't cause the problem. What you see is some symptoms caused by another problem which we have to find.

The error message you got now (no embedded interface) is suspicious. It's also written "Check initial position of center of mass!". There is something wrong with your 6DOF body setup, but I'm not sure if it has something to do with the floating point exception. I've got the feeling I would had something similar before (not exactly the same) and therefore I've got some ideas what to check. But I can't point on it without seeing it and my license server is not running without restarting my machine (but that's too late for today). As your model is just a testcase, you might send it to me (I think the testcase is not confidential?) and I can have a look on it. Just let me know and I will send you my email address.

[Henry Arrigo]

Thank you. That s true, it s not confidential and I can sent you the model. Please give me your e-mail address and I ll send you the model.

[abdul099]

I had a look on your sim-file and found the issue: Like I said, the issue is the 6DOF body setup. With the embedded rotation and translation model, the initial center of mass has to fit the initial center of the embedding sphere or cylinder. This can easily be found in the user guide, right at the first side where the basic description of the embedded rotation and translation is located. Not satisfying this requirement causes the "No embedding interface found" message, which also says "Check initial position of center of mass". It's a little bit weird, because it works even with a shifted initial center of mass when switching of some of the motions. I suppose that's just an unexpected behaviour which makes it work.

Anyway, I fixed this issue and build up a full model and it works fine, even with all 6 degrees of freedom.

I also checked the rest of the setup and found some potential for improvements:

- For the air phase, switch on constant density model instead of ideal gas. There will be neither be significant pressure differences in your model, nor any natural convection. You don't need an ideal gas model, it causes just additional computational effort due to an additional transport equation to solve.
- You can also switch off the VOF waves model. I doesn't cause any direct issues, but is not necessary when you don't use any VOF wave. And one could get confused due to an activated model which doesn't do anything.
- Decrese the number of iterations in the 6DOF solver. In every time step, the displacements and rotation angles of the 6DOF body should level out within let's say 3 or 4 iterations. When it needs more, it's an indicator for a too big time step size. (Apparently your time step should be small enough to need no further reduction). Monitor heave and pitch every iteration while running the first time steps. This will show you how many iterations the 6DOF solver needs. This could save a lot of computational effort.
- Also reduce the number of inner iterations. There shouldn't be 20 inner iterations needed.
- As I mentioned before, you should put only 1 prism layer to the interface. This is just to prevent cells from getting too distorted, not to resolve any boundary layer. Reducing it to 1 will save cells and speed up your simulation.
- The cells at the sphere surface near your volumetric control are not the best, as they are long but small. Also try to minimize jumps in cell sizes near the interface.
- In the outer region, you might try an anisotropic refinement in the volumetric control. This will also help saving cells while the mesh resolution in vertical direction can get quite high.

Hope this helps

[fastwave]

Hello Abdul,
you seem to have done a lot of testing on this topic so I would like to ask a question I may. I noticed above that henry initialised the solution using field functions and not using the VOF wave. This is usually the way in most CFD codes but in StarCCM+ most of the people I know use teh VOF wave even for flat sea surface just because it is easier.
The questions is, do you know if there is a difference in computation speed if you avoid the VOF wave model?

Thank you in advance

[abdul099]

No, a flat VOF wave should only automatically set up the field functions for initialization and shouldn't affect the solution process. Manually created field functions just gives more flexibility than a flat wave, that's all.

[Henry Arrigo]

Thank you abdul.
I applied your comments and run the simulation again. It s mind boggling since with the same settings it sometimes works and sometimes dose not. Locating the center of mass on the center of the sphere for the first time it worked well but after regenerating the mesh I got the same error again. Also in some cases there is no error even having all the motions on and in some cases the error still occurs.
I think that in the case of symmetrical problems in which the coordinate frame is on the symmetry plane "off diagonal moments of inertia" is needed too.

[abdul099]

With a symmetrical model, you can't switch on all motions! In your model, any rotation in X- or Z-axis would make the model non-symmetrical and therefore should not be activated. It's not up to the off-diagonal moments of inertia. When you want to allow all 6 degrees of freedom, you will need a full model.

What do you mean with "after regenrating the mesh"?

I agree it's a little bit confusing as some error messages do appear sometimes and sometimes not. But the reason for an error message is usually a setup error (when it's not a bug). You shouldn't look for the cases when your simulation runs with the current settings but look for the right setup for your simulation.
Several tries with the same settings will give the same result. When the results are different, something else is different as well.

[Henry Arrigo]

I just mentioned "off diagonal moments of inertia" by considering the scientific basis of the problem not necessarily to find the cause for the error. Think about a given body which it s moments of inertia should be measured relative to a coordinate frame not located on its COM. In this case Ixy, Ixz and Iyz do exist. So I think for symmetrical cases it s needed to give the software such data.
By regenerating I mean clearing the mesh an then meshing it.

[abdul099]

Did you run the simulation before clearing and meshing again? In this case, it has to give the error message when you don't clear the solution before meshing.
When the body moves, the initial surface will also be moved. Therefore the sphere center is shifted while the initial center of mass isn't.