Scalar field inconsistency at geometry face border?

Mesh generators, CAD programs, and other tools
thomasatelmer
Posts: 22
Joined: 18 Jan 2019, 18:18
Antispam: Yes

Scalar field inconsistency at geometry face border?

Post by thomasatelmer » 16 May 2019, 10:45

Hi Elmer community,

as I found very competent help here for my few past questions, I'd like to tap this ressource once more for a Problem that I don't get fixed on my own, as it seems. I am performing a Navier-Stokes calculation of a simple case, and I get inconsistent results that seemingly depend on the way, how the geometry model is made.

I am preparing the model in Salome 8.3.0 from a Step Import and also produce the mesh there. The Simulation deals with flow in narrow channels, so the "thickness" of the model is sheet-like in large Areas. It gets meshed in Salome just fine, with the element size in thickness direction in the range of sheet thickness. Across such a sheet area, the elements often are flattened. Mesh density is increased at geometry edges. It also solves nicely in Elmer 8.2 in appropriate time, although stability of the solution could be higher. I Attribute this however to the narrowness of the geometry and the fact, that I am simulating water (viscosity in the range of mPas).
The results are viewed in Paraview 5.2. It Shows that from three Areas that should behave in principle identical (e.g. area 2 in the Picture), one (area number 1) is off and Shows a steep drop in the scalar field along a line that corresponds with a face edge in the geometry model, that also lies directly in x-z-plane. Also generally it seems that the Solutions has "steps" in the scalar field at face transitions of the geometry model, although the faces are transitioning tangentially.

Among the possible Solutions paths I have investigated are:
- increasing mesh density: this is currently limited to the amount of Memory in my machine. I am getting an upgrade there in the next few days - for right now I have to live with approx. 1-2 Million Elements. In this range of element numbers, there is no Change of the phenomenon. An artificially coarse mesh does not help either.
- healing the model in salome: the face edges have sometimes lower precision than 1e-6, but healing does not really help there. It does not Change this phenomenon, and meshing and solving still works without Errors thrown....
- I also tried to build the model from scratch in Salome not using Step import, which works as well, and all edges have proper Maximum precision and no Errors. But still the phenomenon remains, in some cases is even more pronounced, depending on meshing Details.
- another time I rotated my models such that no face edges are lying on the principal axis directions, but it also did not Change. The face edges remains problematic.
- using a 120° sector model and apply symmetry. This makes the phenomen seemingly go away (did not Play too much with mesh variants), but mid-term, this is no Course of Action for me as I will Need to apply modifications to the model that make it unsymmetric by Definition.

I hope someone else may have some additional idea what I could try, or even state a Focus as to where apply tweaks, i.e. in which of the Software, Salome or Elmer? (I think Paraview just Shows whatever the other two produce, so I exclude it as possible source of the Problem).

Thanks in advance for your contributions - let me know if I missed an important aspect to explain.

Thomas.
Attachments
result_error.PNG
result_error.PNG (16.7 KiB) Viewed 571 times
face_border.JPG
face_border.JPG (16.18 KiB) Viewed 571 times
mesh_density.JPG
mesh_density.JPG (79.64 KiB) Viewed 571 times

kevinarden
Posts: 256
Joined: 25 Jan 2019, 01:28
Antispam: Yes

Re: Scalar field inconsistency at geometry face border?

Post by kevinarden » 16 May 2019, 13:40

Perhaps the mesh does not share nodes at 1. Did you check for coincident nodes in Salome?

thomasatelmer
Posts: 22
Joined: 18 Jan 2019, 18:18
Antispam: Yes

Re: Scalar field inconsistency at geometry face border?

Post by thomasatelmer » 16 May 2019, 14:39

Hi and thanks for the quick Reply,

I tried now to merge nodes and Elements in my mesh - the functions found a handful of nodes and Elements and merged them, but not as many as to make up the whole Zone "1". Currently the solution is running again, I'll Report out on the results.

BR, Thomas.

mzenker
Posts: 1955
Joined: 07 Dec 2009, 11:49
Location: Germany

Re: Scalar field inconsistency at geometry face border?

Post by mzenker » 16 May 2019, 15:13

Hi,

in order to have generate conformal multibody mesh in Salomé, you have to make a partition in the GEOM module and run the mesher on that one.

HTH,
Matthias

thomasatelmer
Posts: 22
Joined: 18 Jan 2019, 18:18
Antispam: Yes

Re: Scalar field inconsistency at geometry face border?

Post by thomasatelmer » 16 May 2019, 15:21

Good afternoon Matthias,

thanks for this hint, however this was and is Standard procedure for me. Although it is only one volume Body, I use the Partition function and drive the mesh Groups from geometry Groups created within the Partition. So here the inconsitency exists although it is no multibody mesh, this is what makes me wonder...

Thanks, Thomas.

mzenker
Posts: 1955
Joined: 07 Dec 2009, 11:49
Location: Germany

Re: Scalar field inconsistency at geometry face border?

Post by mzenker » 16 May 2019, 15:39

OK - I would then zoom into the problematic region and check if the nodes are really shared... ;)

thomasatelmer
Posts: 22
Joined: 18 Jan 2019, 18:18
Antispam: Yes

Re: Scalar field inconsistency at geometry face border?

Post by thomasatelmer » 16 May 2019, 16:02

Alright, I'll try this, although this is quite cumbersome. To the extend of proper Display on the Screen, I was not able to find inconsistencies inside Salome. This brings me to a Point I did not mention before: I also transform the mesh using ElmerGrid.

elmergrid 8 2 mesh.unv -autoclean -scale 0.001 0.001 0.001

Does this maybe screw up the mesh in places?

Thanks, Thomas.
Last edited by thomasatelmer on 16 May 2019, 19:57, edited 1 time in total.

mzenker
Posts: 1955
Joined: 07 Dec 2009, 11:49
Location: Germany

Re: Scalar field inconsistency at geometry face border?

Post by mzenker » 16 May 2019, 17:03

I would not expact ElmerGrid to screw up the mesh.
However, I normally do the scaling with ElmerSolver using

Coordinate Scaling = 0.001

in the simulation section, instead of scaling with ElmerGrid. I don't know enough about the internal precisions of Salomé, ElmerGrid and ElmerSolver to tell if this can make a difference.
BTW it could be be worthwhile to try to build a small testcase reproducing the problem, so that you don't have to run the whole case every time.

HTH,
Matthias

thomasatelmer
Posts: 22
Joined: 18 Jan 2019, 18:18
Antispam: Yes

Re: Scalar field inconsistency at geometry face border?

Post by thomasatelmer » 17 May 2019, 22:51

Hello alltogether,

thank you so far for your hypotheses and proposals. I did some more digging myself as well, and came to a thought that lastly proved to be the solution. Up to that Point however, we were all wrong :shock:
The reason for the inconsistency seems to be the specific mesh density configuration at that Location which is different from all other Areas in the model. This occurred to me when following Matthias' proposal to zoom into the problematic Region. I did not find any incorrect mesh or gaps, but I realized, that this was the only place, where on the sheet I had an edge on the same Location at the top and at the bottom side of the sheet. In all other Areas, when there was an edge on the one side, there was no edge across the sheet on the other side. This caused the Netgen mesher obviously to mesh this area very fine. For some reason, Elmer calculated something different on this area of fine mesh than for the other Areas.

The cure is simple. I rotated the bottom face by a couple degrees such that nowhere edges lie on each other across the sheet. The calculation result is now completely Rotation symmetric like expected, and convergence is steadily and quickly moving to even lower Targets than ever reachable before.

I assume that the observed Netgen behaviour is just a quirk in my case, as I use this very thin sheetlike geometry, where the Surface mesh structures "bleed" through from one side to the other. On structures with regular aspect Ratio, I did not observe anything like this.

However, one question remains now... why does Elmer calculate results that seemingly are mesh-density-dependent? I will probably run some more Tests to assess which mesh density will affect results and where the no-care-threshold is coming to be (when I finally get my Memory upgrade). But I would definitely appreciate some hints from the cracks here, as to what to check for... is it more depending on aspect Ratio of cells, or pure size, or in my case with the thin sheet, the number of Elements across sheet thickness, etc etc??

So far the News, now I am off to a happy Weekend, having solved a riddle that kept me awake nights Long for the last two weeks.

Greetings and thanks again for your contributions,
Thomas.

raback
Site Admin
Posts: 3464
Joined: 22 Aug 2009, 11:57
Antispam: Yes
Location: Espoo, Finland
Contact:

Re: Scalar field inconsistency at geometry face border?

Post by raback » 22 May 2019, 00:04

Hi

This seems to be quite peculiar behavior. I would guess that it is a combination of extreme mesh density and poorly converging iterative solver. Fine mesh density increases the number of iterations needed and perhaps you terminated the iteration before this region had converged. You could try to play with convergence criteria or number of linear system iterations. Choosing optimal linear solver strategy may sometimes be a challenge.

One could think that this is a scaling issue i.e. that the small elements influence the global norm less than the large elements. However, by default the linear system is scaled and each node will have the same influence on the overall results when solving the linear system.

Finite element results are always mesh dependent. The converged results should approach asymptotically the correct solution as mesh is refined. However, there it is assumed that the linear system is solved accurately which perhaps here was not the case.

-Peter

Post Reply