[ybeis]

Hi guys,

Although I follow the forum for a long time mainly for OpenFOAM it's the first time I post a new thread as there's something that drivers me literally crazy.

I am conducting an external aero simulation in STAR CCM+ however I am facing one problem and I would like your advice/help.

Here's my setup:

I am provided a geometry of a vehicle which is already cut in half in order to be simulated as a symmetry problem. At y=0 is located the symmetry plane. I set up my case with no problems at all.

When I finish with the meshing, I create a plane and place it at (0,0,0) in order to post process my results. However the generated plane does not intersect with the symmetry plane but only at 1-2 very very small regions (see 1st attachment, I would expect all cells to be "beige" (=derived parts plane) instead of blue(=symmetry plane)). That means that my symmetry plane is not at 0,0,0 but further inside (y>0)

This is confirmed by moving the plane further in. Moving it by -1*10^(-9) the beige color does appear and now my plane snaps the symmetry plane. Now, it is the other way around. Blue turned into beige, beige into blue. (See 2nd attachment)

I wouldn't mind if all cells were blue. That means that my symmetry plane, thus my case is just further inside. What drives me crazy is that a fraction of cells is at y=0 and the remaining at y=-1*10^(-9).


My questions are:

1) First of all, why does this happen? The easiest guess is that my vehicle is not at position y=0. I checked that by trying to create a dummy block part. Then STAR embraced the vehicle's geometry by its 6 points (x_min, x_max, y_min, y_max, z_min, z_max) and y_min was 0. I understand that this is not the best way. Is there any other, more reliable way to check the origin of a geometry in STAR CCM?

2) Does this may lead to "wrong" results?

3) Does the already splitted in half geometry is responsible for generating this problem? Would it be better to insert it as a whole in STAR and then subtract it there from the domain?


Thank you for your time and I am happy to provide more information in case my description is not clear enough.

Best,
Yannis

[LuckyTran]

1) This is what happens when you have practical precision. If you output your CAD in ascii format it's accurate to only 6 decimals, more if you use binary. Regardless, you'll eventually encounter the same issue except maybe at the 1e-12 scale instead of 1e-09.
2) Symmetry planes are symmetry planes. Results are results. Results are only wrong if you misinterpret them by (as a hyperbole) slicing a plane at y=1 m and thinking this is your symmetry plane.
3) There is no such thing as a true zero when they are represented with numbers of limited precision. For the purpose of slicing it at y=0, it would be better to do this in Star. However, this still is predicated on your CAD actually being symmetry about y=0 at the CAD-level which may or may not be the case because either way, you write CAD and import it into Star with limited precision.

But even if you do all that correctly, you are still taking a slice through your mesh which involves calculating and building cell sets of those cells which intersect your slice which is yet an operation creating a new cell set. Results are the interpolating from the mesh onto this planes lice. If you want to post-process the results on the symmetry plane (which already exists as a boundary in your model), then it's recommend to just use that surface/boundary instead of creating new slices.