[bastil]

Niklas,

really great tool missed it so far. This will reduce my reasons from not so often using FOAM from two to one final issue (hopefully 1.6-ext will fix this ggi issues!)
Have you ever considered putting snapEdge to the openfoam-extend repository? I think this would make sense. I will come back with some feedback soon. I have quite complex gemometry to run on.

Regards Bastian

Edit:
- I use Nastran-Files instead of stl, will this work?
- Do I need some .eMesh-File containing the features? Or is this decided my snapEdge using an angle
- From the Ahmed-Pictures from openfoam_user I guess he uses explicit featuere refinement with .eMesh-File in sHM?

[niklas]

Originally Posted by johannes

Hi Niklas,

I'm still trying to get an improved mesh using snapEdge's includeInterior feature. At first sight the resulting mesh looks quite well but there are still some skips and the checkMesh result always shows at least two missed tests.

If you have some time left it would be great if you could have a look at my case (see attached .tar.gz file with my actual settings and files) and maybe you're able to locate a potential for improvement (e.g. snapEdge or sHM parameters, stl file precision, etc...).

I know that you're still working on snapEdge, so I don't expect a 'perfect' mesh, a checkMesh result without errors would be absolutely ok.

Many thanks in advance!

Best regards,
Johannes

Oohh, this is a very nice test case.
I am doing a complete re-write of snapEdge at the moment to better handle internal features.
I will let you know once I have it working.

Originally Posted by bastil

Niklas,

really great tool missed it so far. This will reduce my reasons from not so often using FOAM from two to one final issue (hopefully 1.6-ext will fix this ggi issues!)
Have you ever considered putting snapEdge to the openfoam-extend repository? I think this would make sense. I will come back with some feedback soon. I have quite complex gemometry to run on.

Regards Bastian

Edit:
- I use Nastran-Files instead of stl, will this work?
- Do I need some .eMesh-File containing the features? Or is this decided my snapEdge using an angle
- From the Ahmed-Pictures from openfoam_user I guess he uses explicit featuere refinement with .eMesh-File in sHM?

I dont have any nastran files so it doesnt work at the moment, but it should be easy to add.
N

[bastil]

Originally Posted by niklas

I dont have any nastran files so it doesnt work at the moment, but it should be easy to add.

Fine. I will start looking into this. Is there something else I can do to support this project? I am definitly interested in it. My special interests include parallelization or integration into sHM as step 3 out of for (refine, snap, edgeSnap, layers).

Regards Bastian

[bastil]

Niklas.

here is my first feedback from what I have seen from snapEdge:

• It seems to run with Nastran-Files instead of stl-Files without any modification since the triSurface-Class of OpenFOAM supports both.
• It is very slow: For my test model it spends hours in the following loop:

    forAll(stlPoints, isp)
        {
            addToList(globalStlPoints[is], stlPoints[isp]);
        }

I will investigate further and also try to put it into sHM and maybe parallelize it.

Regards Bastian

[niklas]

Originally Posted by bastil

It seems to run with Nastran-Files instead of stl-Files without any modification

nice.

dont bother trying to investigate the code. i have already re-written it completely and Im using your
case to test it on.

N

[bastil]

Originally Posted by niklas

dont bother trying to investigate the code. i have already re-written it completely and Im using your case to test it on.

Niklas: Sorry I can not send you my case I have to do the test here with us. Can you send me you new code, please? Otherways I will start improving old code?
Some more points:

• Did you consider hosting the tool at openfoam-extend
• Are there plans to integrate this into sHM and for parallelisation?
• How can I support your work?

Regards Bastian

[niklas]

Originally Posted by bastil

Niklas: Sorry I can not send you my case I have to do the test here with us. Can you send me you new code, please? Otherways I will start improving old code?

sorry, my mistake. it wasnt you that sent me the case it was johannes.
Im not going to release a half-done code full of commented info-statements.
You can improve the old code if you want, but the new version handles corners
and internal features in a totally different way and the old algorithm will never
be able to handle this in as a robust way as the new one.
Of course, that wasnt my intention either when I first started this project.

Originally Posted by bastil

[*]Did you consider hosting the tool at openfoam-extend

yes and no i wont.
Its completely free, so if you want you can just take it and claim it as your own and
include it there yourself if you want

Originally Posted by bastil

[*]Are there plans to integrate this into sHM and for parallelisation?

nope, I have talked to opencfd and in the future this utility will become obsolote anyways.

Originally Posted by bastil

[*]How can I support your work?

if it doesnt work, maybe you can send me the geometry

N

[openfoam_user]

Hi Niklas,

thanks a lot for improving your great tool !

Once you have rewritten your code I will try it with my geometry.

Best regards,

Stephane.

[bastil]

Thanks Niklas for the quick answer.

Originally Posted by niklas

nope, I have talked to opencfd and in the future this utility will become obsolote anyways.

That means future releases will include feature lines written by OpenCFD?

Originally Posted by niklas

if it doesnt work, maybe you can send me the geometry

Difficult but I will try my best. I will also come up with code proposals if I have.

Regards Bastian

[niklas]

I have updated the snapEdge utility and you can just download it from the wiki.
Its not 100% done with what I want it be able to do, but it is definitely usable and better
than the old version.

I have been using the available stl's to test it one and have gotten all of them to work.
I will add all of the screenshots to the wiki when the wiki works properly.

The most difficult case is the one from johannes, mainly because the stl is in such a poor shape
that I had to improve it. I've attached 2 pics of before and after of that case here

[bastil]

Hi Niklas,

definitly good news. I will give it a try soon.
The only thing missing now is the integration into snappy, maybe I will try this myself.

Regards Bastian

[johannes]

Hi Niklas,

great job, thanks a lot for the improved snapEdge version.

Yeah I know, the case I uploaded is quite complex, but judging from the screenshots after the recent update, snapEdge seems to work quite well with such a geometry.

I did a re-run of my testcase using the new snapEdge version but still could not get a flawless mesh since some chamfers remained. Nevertheless the overall result was a lot better than before - just had a few skewed faces reported by checkMesh.

I played around with different values for tolerance and relaxation - with limited success. Would it be possible to send me the snapEdgeDict you used to run my case?

You mentioned a low stl quality and you're right because I turned down the quality settings when creating the stl files to reduce filesize. As you certainly know, most CAD systems have a conversation or facet tolerance and an angle tolerance for specifying the quality of an stl geometry; do you have a general rule for setting these values (maybe in respect to the desired surface cell size)?

Thanks + best regards,
Johannes

[bastil]

Niklas,

I did some tests on my (really complex) geometries. It definitely looks much better now - great.
Only remaining bottleneck I have is the execution time wich is about 1 hour for one iteration. I have to look into this.

Regards Bastian

[niklas]

@johannes

I dont know what it was with your geometry, but if I extract the stl feature-lines it results in features on what seems to be planar surfaces. This can cause problems beacuse the mesh dont have any features there and
if your tolerance is too large it can grab the mesh features that belong to other stl features.

And it is not possible with this method to capture all the features perfectly.
If you look at the following animation maybe you will understand why.
http://openfoam.nequam.se/cases/snapTest.avi
What you see is that the feature line covered by the faces with an angle of 45 deg to the left attracts
the upper line and to the right it switches and attracts the lower line.
Where these lines meet there is an edge that just grows smaller and smaller and
in order to prevent bad faces I have limited the edges to go below 1/10 of the smallest edge length

set relaxation to 0.1 and play with the number of iterations, I used these angle settings.

featureAngle 20;
excludeEdgeAngle 70;
parallelAngle 30.0;

maybe I should add that I couldnt get it to work with the geometry you sent me, but I had to
treat it in ANSA and also that it works better if you make the mesh abit finer, some parts just have
1-2 cells between the features

@bastil
ahh, now I understand why you want to run it in parallell.
I havent tested it in parallell myself so I dont know if it will work.
It should work (in principle), but I dont know how it will treat the mesh processor boundaries.
It is possible that I have to add some specieal treatment there in order to remove false features.

After each iteration I am using the movePoints functionality which is overkill, but I
use it to make life simpler when calculating face-normals (and because I want to add
a smoother on the entire mesh later)
what you can try to do is to move it outside the loop (in snapEdge.C)

        //mesh.movePoints(newPoints);
        //mesh.checkMesh();
        Info << "Done!" << endl;
    }
mesh.movePoints(newPoints);

[norman1981]

Originally Posted by bastil

Hi Niklas,

definitly good news. I will give it a try soon.
The only thing missing now is the integration into snappy, maybe I will try this myself.

Regards Bastian

Hi Everyone,

first of all, thank you Niklas for sharing this tool. I am working on ship hydrodynamics, I tried many times in the past to generate grid good enough to capture yacht fins or transom edges using snappyHexMesh without success, therefore I'll give a try to your tool and I will let you know (I hope you'll have some time to give me some advices if I'll need some help )
Anyway, yesterday I integrated your last snapEdge version into snappyHexMesh for fun. I referred to the the snappyHexMesh version that comes with OpenFOAM-1.5-dev (I am using this OF version) . If someone has a heavy working snapEdge test case to give me I would like to test this snapEdgeHexMesh tool before saying it is working and sharing it

Kind regards

Norman

[bastil]

Originally Posted by norman1981

Anyway, yesterday I integrated your last snapEdge version into snappyHexMesh for fun. I referred to the the snappyHexMesh version that comes with OpenFOAM-1.5-dev (I am using this OF version) . If someone has a heavy working snapEdge test case to give me I would like to test this snapEdgeHexMesh tool before saying it is working and sharing it

Great work Norman. I would be highly interested in this. I am sorry I can not share my case but I would propose to use the motorbike snappy testcase which is similar to what I do. Maybe refine the mesh and try running the whole thing (casellate, snap with edges and layers) in parallel.
I can also offer you to install your "beta" version here, run some tests and provide you with a feedback afterwards. In that case you can sent me your beta "snapEdgeHexMesh"

Regards Bastian

[bastil]

Originally Posted by niklas

@bastil
ahh, now I understand why you want to run it in parallell.

Thanks for you proposals Niklas. I will give it a try. The reason for running it in parallel is not just speed. We run the whole process in parallel because of memory limitations and we cant (and dont want) to include a serial process in here.

Regards Bastian

[johannes]

Hi Niklas,

thanks for your explanations and the video. I think I know what you mean.

Regarding the planar surfaces on the stl geometry, that's an issue from the stl creation process I (have to) use, because my CAD system is only able to convert volume bodies into an stl file but not surfaces. This means I have to extrude all the surfaces in normal direction in order to create volumes.

Now if the extrusion thickness is chosen too small compared to the snapEdge tolerance, snapEdge could be attracted by stl features on the 'opposite' side of the stl volume body.
I'll check with an increased stl thickness and will also try your angle settings.

Best regards,
Johannes

[ziad]

Hi Johannes,

I create my stl files using salome GEOM and it is capable of exporting individual surfaces into ascii/binary stl files. GEOM won't import stl files though.

Ziad

[johannes]

Hi Ziad,

thanks for your input, nice to know it works with Salome. As long as there's an import feature for step or iges files I'll give it a try. Another option would be to edit the volume body stl file and delete all unnecessary faces.

Basically, I would like the geometry processing workflow to be a as simple and streamlined as possible without involving too many different software tools.
Btw: My existing procedure was working without problems for standard sHM meshing so far.

Best regards,
Johannes