Multiple domains support?

[TangLaoya]

Dear authors, Thank you very much for providing so powerful hex mesh tool. I am studying your paper and code. I noticed that your input is the surface triangles that define domain. I have a question: do you currently support multiple domains? if yes, could you please also provide such an example?

Thanks, Tang Laoya

In addition, I noticed that the code is very slow in some functions, for example:

void hexGen::InitializeOctree(const char inputFileName, const char outputFileName) { octreeArray.resize(levelId[octreeDepth + 1], false); cutArray.resize(MAX_NUM); cutArray1.resize(MAX_NUM); getLevel.resize(levelId[octreeDepth + 1]); /// too slow, use fill directly /// Tang Laoya @ 02/04/2024 //for (int i = 0; i < getLevel.size(); i++) // for (int j = octreeDepth; j > -1; j--) // if (levelId[j] <= i) { // getLevel[i] = j; break; // } getLevel[0] = 0; for (int i = 1; i < octreeDepth; i++) { std::fill(getLevel.begin()+ levelId[i], getLevel.begin() + levelId[i+1], i); }

ReadRawData(inputFileName, outputFileName);

}

[gt2001]

(1) Thanks for the feedback! Due to the nature of the octree-based algorithm, the code has the capability to support an arbitrary number of domains and an arbitrary genus count. Although I didn't have a complex multiple-domain input file on hand, I created a simplified version and ran it through the code. The input boundary and mesh results are available for review as "sphereInShell_tri.raw" and "sphereInShell.vtk". Please see the attached screenshot for a visual representation:

However, as you may be aware, the method does have a minimum unit length limitation of $\frac{100}{2^9}$. If the objects within the multiple-domain file are too widely spaced, the "resolution" may not be sufficient. In such cases, I would recommend meshing objects that are in close proximity to each other, rather than attempting to mesh all objects simultaneously. I am currently working on increasing the maximum octree depth from 9 to 10, but this will require adjustments to the optimization module parameters to prevent a reduction in convergence rate. This is a work in progress. By the way, another work in progress is to support feature preservation for sharp points and edges in CAD models.

(2) Thank you for your assistance in improving the code efficiency! I am not a C++ expert; my focus is primarily on algorithm design and functionality. I have incorporated your modifications into version 1.3. Your contributions are greatly appreciated!

Best regards, Hua Tong

[TangLaoya]

Hello Dr. Tong, Thank you very much for your kindly reply. The support of multiple domains is great. I will study the example latter. As you mentioned, the maximum octree depth could have a limit of "resolution", that means it is difficult to work for multiple scales problems, for example, the well-logging problem with calculation domain size is 100 m but the pole size could be 1 mm.

On the other hand, I noticed that the code is very slow. I tested an example and found that it runs for more than 1 hour at here: for (i = levelId[octreeDepth] - 1; i > -1; i--) ComputeCellValue(i, getLevel[i]); I wish it could be improved from the algorithm instead of the language.

Thanks, Tang Laoya

[gt2001]

In general, octree-based algorithms possess a certain resolution. A potential solution would be to divide the object into large cubes (maybe 5 5 5), ensuring that the resolution within each cube is sufficient to capture all the intricate details, and then assemble the meshes from each cube. This approach also lends itself well to parallel computing. In our lab, we collaborate with the automotive industry, and the models they provide often feature small details in comparison to their overall size. Thus, implementing parallel computing represents a significant area for future work.

Regarding the ComputeCellValue function, I have attempted to optimize its time complexity. However, it may still be slow due to the creation of numerous small elements. Currently, the primary objective of the project is to demonstrate the algorithm's feasibility. Therefore, I am prioritizing the preservation of sharp features in my current efforts. Thanks for your feedback!

[TangLaoya]

Hello Dr. Tong,

Do you have similar 2-D quad mesh generation code by quadtree? The 3-D case is too slow for me and I need to sweep 3-D hex mesh by 2-D quad mesh.

Thanks, Tang Laoya

[gt2001]

I think 2D sweeping can be done easily in commercial software like hypermesh, ansys, and abaqus. Also, you don't need to stick to quadtree/octree, there are solvers for general 2D mesh generation which generate fewer extraordinary points than the quadtree method does.

[TangLaoya]

Hello Dr. Tong,

Thank you very much for your kindly reply. Can you recommand some open source code which can generate fewer points but high quality quad mesh? I have posted some questions here: https://gitlab.onelab.info/gmsh/gmsh/-/issues/2808 https://gitlab.onelab.info/gmsh/gmsh/-/issues/2809

Thanks, Tang Laoya

[gt2001]

Please try Gmsh, QuadMesh, SALOME, and OpenFOAM

[TangLaoya]

wa, that's great!

On Tue, Oct 22, 2024 at 10:34 AM Hua Tong @.***> wrote:

Closed #1 https://github.com/CMU-CBML/HybridOctree_Hex/issues/1 as completed.

— Reply to this email directly, view it on GitHub https://github.com/CMU-CBML/HybridOctree_Hex/issues/1#event-14774145879, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA5YBWEJBBTDWAUCCUBV5LLZ4W2TPAVCNFSM6AAAAABQLN2Q26VHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJUG43TIMJUGU4DOOI . You are receiving this because you authored the thread.Message ID: @.***>