Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Huge memory and very long time when number of inner boundaries is large #31

Open
TangLaoya opened this issue Jan 12, 2022 · 4 comments
Open

Comments

@TangLaoya
Copy link

Dear Prof. David,
I am still testing the case 'test4.control' I uploaded. I found in the function 'OuterToInnerboundaryDistances', there are 5-level loops, the program hangs there for hours with no top loop moving. I found there are many similar functions, such as 'OuterBoxToInnerboundaryDistances', 'InnerToInnerBoundaryDistances', and so on. I think these functions should be improved to skip unnecessary calculations and comparisons, I tried to improve the function 'OuterToInnerboundaryDistances', but the improvement is still not satisfied. Do you have any good suggestion?

Thanks,
Tang Laoya

Sizer.zip

@DavidAKopriva
Copy link
Collaborator

HOHQMesh is designed for generating meshes for High Order methods, and is curve based, not point based as in a standard finite element generator. Your control file inputs individual points and makes lines between them as curves. The result is a massive (13K?) number of curves that must be examined to see if they are near to each other. No wonder memory and time have exploded. Also by inputting everything as line segments, the mesher has to treat each node as a an element endpoint so that a solver doesn't have to approximate across a slope or curvature singularity. I couldn't plot your whole model, but looking at the outer boundary you have defined 42 curves, of which curves 7-29 are all part of a single line, for instance. What I suggest is for you to look at your model as a collection of curves terminated by points where the curvature is singular. In your outer boundary, I count only 9, not 42 curves that make up the chain. Use splines for curved segments, and coalesce all line segments along a straight line as a single line curve. If the specific nodes are important, then a finite element mesh generator should be used instead of HOHQMesh. I did manage to plot one of your inner boundary squares. The scale difference between it and the outer boundary (you can't even see it on the plot) is so huge that I don't see HOHQMESH ever handling that much of a scale difference.

The issue does raise the question of whether or not the algorithm for determining curve distances can have a special case when either or both of the curves is a straight line, in which case the search can be replaced by a simple algebraic formula. I will add that to the list of possible improvements. That would still not help in your case, however.

@TangLaoya
Copy link
Author

Dear Prof. David,
Thank you very much for your kindly explanation. Currently I processed my model by triangle mesh. I am trying to test whether these domains can be meshed by quadrilateral elements.

I also notices another quad mesh method, Q-morph method, which divide a triangle into 3 quadrilateral elements and then smooth vertices, I also tested the mesher 'Quadriflow', but it can't keep my domain boundaries, and the generated mesh is nearly uniform, there are too many elements generated. On the contrary, your HOHQMesh can generate non-uniform meshes decided by input geometry size, which is attractively because it can generate much less meshes with high quality.

Do you have any good suggestion on some other quad meshers?

Thanks,
Tang Laoya

@DavidAKopriva
Copy link
Collaborator

Yes, it can do that, but not with 13K interior boundaries. The only other quad mesher that I know of is gmsh. I believe it generates a triangle mesh and then uses that to generate a quad mesh. Let me know if that works for you, I'd be curious. One advantage the FEM meshes have is that the user inputs the scales through the boundary points. Since we want to use the boundary curves directly and infer the size from that, there is a lot more work that has to be done, like scaling according to how close curves are together and to themselves. HOHQMesh checks pairs of curves, and with 13K curves, that's a lot of work. There is the start of a mesh based tester to see if a curve crosses itself, but that has issues with resolution, too.

@TangLaoya
Copy link
Author

Dear David,
Thank you very much for your kindly reply.
Yes, HOHQMesh checks pairs of curves, but I think we needn't check every pair of curves, we only need to check them which are 'close enough', but how to check whether they are 'close enough' is still difficult.

I also noticed the gmsh for a long time, but I think it is hard to process multiple domains and the most important, I am not familiar with C++:(

Thanks,
Tang Laoya

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants