[Raphael_Santos]

Hello everyone,

I have been working with snappyHexMesh for some time. In the addLayers' step, I sometimes get that 1 or 2 faces are not extruded. I've been looking for a methodology to identify which faces were not extruded to be able to solve my problem, but I was not successful .

Can you help me with this? Does anyone know how to check which faces were extruded and which were not extruded during the addLayers' step?

At the moment, what I do is time-consuming, as it consists of running the simulation and calculating the y+ and verifying the regions wich y+ is inconsistent.

Thank you,
Raphael

[AtoHM]

There are ways.
When you run snappyHexMesh, the log-file contains this information. There should be a part with the extruded layer thickness and coverage in %.
Also you can always check visually. (I think) depending on the OF-release you use, you can make snappy put out a scalar nSurfaceLayers to better visualize the coverage, like showed here https://www.openfoam.com/documentati...h-displacement

[Yann]

Hi Raphael,

There are a set of writeFlags you can add at the end of your snappyHexMeshDict :

writeFlags
(
    scalarLevels    // write volScalarField with cellLevel for postprocessing
    layerSets       // write cellSets, faceSets of faces in layer
    layerFields     // write volScalarField for layer coverage
);

You can then visualize these fields in paraView, including the "nSurfaceLayers" AtoHM was talking about. (which is really useful to investigate the layer coverage on your geometries!)

AFAIK, these writeFlags have been around for a long time so it should work with pretty much any OpenFOAM version.


Cheers,
Yann

[Raphael_Santos]

Yann and AtoHM, thank you very much.

I just performed the tests and it worked well.

The flags are really helpful and it is what I was looking for, to visualize. But, the site you sent, AtoHM, shows a different method to addLayers, using the mesh shrinking that is useful for what I am doing.

Cheers,
Raphael

[AtoHM]

Hi Yann, I was finally able to test it again myself. I mentioned "depending on the OF-release you use", because I never got it to work myself. Maybe you can help me to get it going.


I tried with the quite recent esi v2012 version and it seems these writeFlags are just ignored for me. I can see that during the snappy run, these files are present in the decomposed folders processor0, processor1, ... But once the mesh is reconstructed, they are gone. I use checkMesh with the -writeAllFields option to get the mesh quality output.
At the start I suspected that a certain debug level is needed to get the output, but this doesn't change anything, despite dumping me alot of unneeded data.
I would be happy for any advice how to get the cellLevels and layer info written out. Thanks!

[Yann]

Hi AtoHM,

Well, if the fields are written in the processors folders, then it means the writeFlags are working.

It seems your issue is related to the reconstruction step. What utility do you use? reconstructPar or reconstructParMesh?

I may have missed something, since I never reconstruct my cases. I either read the decomposed case or just convert it to another (lighter) format for post-processing.

Yann

[AtoHM]

Hi Yann,


Thanks, thats a good hint regarding the reconstruction method, I am using reconstructParMesh. I will try to isolate if this is causing the issue.

[Yann]

OK, this is probably why you have this issue: reconstructParMesh only reconstructs the mesh but writeFlags write data as fields in time step directories.
You have to use reconstructPar if you want these fields to be reconstructed too.

Let me know if it works!
Yann

[AtoHM]

Spot on, Yann. Thanks alot.
Running reconstructPar additionally to reconstructParMesh writes these fields to the time folder and I can visualize in Paraview. Works like a charm now!