[feature request] add weight to element size

[otaolafranc]

Hello,
I make a second issue, for a feature request, be able to penalize the decreasing of element sizes. for exactly same structured mesh but with more number of elements, the mesh changes a lot when smoothed and gives quite small cells in some regions (also i am observing some problematic results discussed in the other issue but outside of that).
the order is:
coarse mesh not smoothed/ coarse mesh smoothed
finer mesh not smoothed/ finer mesh smoothed

the coarse and finer mesh have the same topology of the mesh (i not sure if it is the correct word to use), its connectivity is the same, simply the number of elements are increase as the size of the 1D discretization is reduced to half of it. this behavior (i dont speak about the problematic edges i am seeing now) as before it was outputting meshes correctly, but the reduction of the elements size, high difference in volume between cells, even if the transition between them is great, it makes the mesh un usable for CFD, as most of the time the speed of a CFD calculation is limited by the smallest volume cell of the hole mesh (with the velocity on that cell also, due to the courant number). and it is specially problematic to not have a 'expected behavior' as i simply refined in every direction and the output of the smoothed mesh changed a LOT (and one was 'usable' the other one no...) here are the two input meshes:

input.tar.gz

[fprotais]

I could reproduce this one, and I am kinda sad about it: my main problem is the quality of the elements. Fixing that does not seem trivial, but needs doing.
I have other priorities now (like getting the code into CGAL), and then vacation, but this will be on my todo list.

A way to avoid the issue is to "restrain elements" to a certain section, by adding target features for example.

And regarding target size specifically, this is on the todo list, but it is not a trivial task to balance it well with the rest of the ingredients.

[otaolafranc]

sorry, i did not understood this part of your comment:

I could reproduce this one, and I am kinda sad about it: my main problem is the quality of the elements. Fixing that does not seem trivial, but needs doing.

what do you mean but reproduce this one? the reduction in size? or the randomized surface errors?

A way to avoid the issue is to "restrain elements" to a certain section, by adding target features for example.

if you mean for the size reduction, the issue is that i am actually using the smoothing to actually smooth out the blocks that i create manually, therefore i want them "free to move" so i can get the smoothed mesh that will be use it to bring back the new postion of the blocks edges.

And regarding target size specifically, this is on the todo list, but it is not a trivial task to balance it well with the rest of the ingredients.

yes, i remember that you mention about this some time ago, I create the issue as i did not found where you mentioned and i also came across this case that surprised me a lot. as, if i do the following workflow:
mesh at lower resolution -> smooth out with your tool -> recreate blocking structure -> remesh finer
it gives actually a great result, it is not like i am getting a bad result at all.

...and then vacation...

have a nice vacations! if you go thought Reims do not hesitate ;) discussing around a beer is always nicer!

[otaolafranc]

I could reproduce this one, and I am kinda sad about it: my main problem is the quality of the elements. Fixing that does not seem trivial, but needs doing. I have other priorities now (like getting the code into CGAL), and then vacation, but this will be on my todo list.

A way to avoid the issue is to "restrain elements" to a certain section, by adding target features for example.

And regarding target size specifically, this is on the todo list, but it is not a trivial task to balance it well with the rest of the ingredients.

also in regards to the "Fixing that does not seem trivial, but needs doing." maybe this contraint helps to give some ideas https://github.com/tkeskita/smoothMesh#quality-constraint-options

[fprotais]

I don't see a reduction in size as an error. My reasoning is a bit long, but in short, it is usually not obvious was the target sizing should be, and strongly enforcing one will got in the wrong direction. That being said, I am working on having target size in the code, but it is tricky to know when to use them and when not too.

Currently, that would more be a choice at the C++ level, but hopefully, I will be able to provide this choice at a python level at some point. (note that currently, it is not implemented at the C++ level either)

I think the fix you got seems like a great idea. I still believe my code as slight problems due to the artefact on the surface: I want it to be able to shrink, but if quality stays great.

Thanks for the reference, my understanding is that my code behave in a different manner, where it is not preferred to put strong constraints, but rather put it in situations where it will not generate bad elements, which is usually doable in my experience, and produces great results :)

Thanks for the invite, if I pass over there, I'll definitely reach out !

[otaolafranc]

I don't see a reduction in size as an error. My reasoning is a bit long, but in short, it is usually not obvious was the target sizing should be, and strongly enforcing one will got in the wrong direction. That being said, I am working on having target size in the code, but it is tricky to know when to use them and when not too.

I'm with you, a target size for a target size it is outside of optimal, but i would say that the correct target at least in applications for cfd would be homogeneous size, specially before pillowing.

Thanks for the reference, my understanding is that my code behave in a different manner, where it is not preferred to put strong constraints, but rather put it in situations where it will not generate bad elements, which is usually doable in my experience, and produces great results :)

If i understood correctly, you resolve the equation for the untangling, where the other code simply calculates the position by centroidal smoothing (average of the cell center if i remember correctly) and it calculates the quality before and after, if the quality improves the new position is kept if the quality is reduced it goes back. and I can confirm as i discused with the developer at the time one of the issues he solved with that was the 'contraction' of cells in structured meshes for concave surfaces where they were moving all to the concave surfaces.

in any case, there are two fully different 'issues':

• one that is not a issue per se, the reduction in size of the mesh (original reason of this issue) where two meshes with same structure and different refinement give quite different propagation groups (i call propagation groups to the edges in blue that you showed here) and at least from our tests (i am in charge of meshing and a college of the CFD) the finner case where it makes a quite small cells, makes the mesh unusable, where the original before the smoothing it is. furthemore, the different behavior between coarse and finner that at least from my naive perspective from outside it looks stage as i would imagine giving same position for the propagation groups but finer refinement. As i mention, this would be awsome to have but i can see how it is a difficult tast. ideally, what i would like is 'make the mesh smooth and as homogeneous as you can' kind of thing.

• the 'noise' on the surface, this before i was NOT having it, for example, the case with the finer mesh, it looked perfect (out side of having small elements) but it was smooth on the surface, now as you can see there are some strange surface cells. I dont know if it comes from a external library that you have a dependency or in a newer version of the code, i do not recall updating and having problems after, just begining having problems a random day.

another example of the 'noise' on surface that i am observing:

[fprotais]

Could you share this specific example? The problem happens on a flat area, so it definitely looks like a bug somewhere.

And bug aside, this example show that my code will give quite a different layout to maximize quality. But there, the final mesh is indeed the best (expect the bug, again). The sizing field is not on my immediate todolist, but it will come.

[otaolafranc]

Could you share this specific example? The problem happens on a flat area, so it definitely looks like a bug somewhere.

no problem: test.tar.gz
but stills, in the refined mesh taht you see in the first post of this issue (bottom second column) in my image is showing the two issues i mentionned, but previously (i think last week) it was showing ONLY the first issue, not the second. so something changed somewhere?
here it was the output of last week (as you can see there is only the 1st issue but the surface was way cleanner)

And bug aside, this example show that my code will give quite a different layout to maximize quality.

I am with you, BUT if i do this exact same mesh but refined, and smooth it out, in terms of SJ yes it will be great, but unusable, where the non refined one, it is great for SJ but also for CFD.

[otaolafranc]

okey! by chance i found the issue! it is in my side, i checked the surface.mesh and the mesh i was exporting (to use) had internal faces, so the surface.mesh have internal faces and this screws up with the snappying @fprotais
it still shows some minor deviation that in theory should not be there but it made disapear the error on the flat surface

and also in the images on the previous post, there is some 'noise' on the surface still.

[fprotais]

Then we got a bug that's fixed :) I should have checked for that, but forgot!
But we still have the sizing requirement to add, so I leave the issue open.

The face exiting there patch on curve area will always happen, this can be strongly enforced with an input curve if you want to avoid it. And target sizes won't matter much here: the guy decided to slide even if the sizing was not changes much.

BTW: target sizes are one thing, but anisotropic targets are a totally other beast. Here, by trying to enforce a pure isotropic sizing, we may have bad effects with the fact that the mesh is anisotropic. Those things are difficult to predict, and I just mention them to note that you probably want the second of the two, and that is a really non trivial thing to have ;)