HexMesh extension [Points_list or Corner_list Class Request ]

[MHS0027]

• classy_blocks version:
• Python version:
• Operating System:

Description

I cant find where a corner projection is stored in a class list
face projections are stored in face_list
edge projections are stored in edge_list

why are corner projections not stored in a corner_list ?

can you create this list please

PS
i have just written an extension to classy blocks in python that creates the hexmesh
(removing the need for blockmesh) -
I know its not what this project was intended for -
but would you be interested in adding this extension to your project ?

Regards
Malcolm

[FranzBangar]

The Point object stores surfaces to be projected to. Vertex inherits from that so you should check vertex_list.vertices for each vertex.projected_to attribute: https://github.com/damogranlabs/classy_blocks/blob/master/src/classy_blocks/construct/point.py

A shortcut could be written as a property in VertexList, if that's what you need.

I would surely like to try your mesher. Does it support grading, surfaces and such stuff? I am a bit worried about speed, though, python is not very famous for being fast. :)

[MHS0027]

Thank you for the reply
I had missed the link in vertex_list (this fixed my issue - now got corner and edge projections working)
you can close this request as it's not needed

Mesher - works with all but two of the examples
It does support grading and curved edges etc

however searchable surfaces - I'm finding tricky
(trying to understand the logic of what multiple searches mean -
ie map to the intersection or map to the closest of two surfaces?
as a non-openfoam user this is a bit of a learning curve)

and

I need to do some work on collapsed edges (I can't find any in your examples)

Speed is not fast - around 80 sec per 100k cells on my desktop which is fast enough for my current needs
(The code required for the face projections caused a real slowdown in speed and needs to be looked at again)

I have a few more days to sort the searchable surfaces - if I get this working I will load it to the clone on GitHub
if not - I may not get back to this for a few months

Many thanks for your work on classy blocks It has been a real help for my research project

Regards
Malcolm

[FranzBangar]

OK, I'm looking forward to seeing your work!
I'm happy to hear my work is useful to anyone :)

[MHS0027]

I just sent you a link to the cb-extension that creates a mesh - It works with all the example files
to make it work put the classy_blocks/extensions folder inside the classy_blocks folder update the init.py
add the two lines described in the readme to the classy_blocks Python script

the folder ext_examples contains all of the examples with their generated meshes in .vtk format (so you can view in paraview)

The code is nowhere near as elegant as your original and is far from being in a publishable state
I need to set this project down for the next months but
if you think this could be a worthwhile extension to your project
I will put more work in to make it publishable in the autumn
Please send me any scripts that make the code fail
(and I know the searchable surface implementation is incorrect and incomplete)
Regards
Malcolm

[FranzBangar]

Wow, I tried that out, checked the code and must say I'm impressed!
I'll let you know where to place your code and you'll create a pull request so that your contribution is noted in the repo.

One more thing - I thought (because is so incredibly slow) about porting this whole thing to OpenFOAM's C++ framework, now it seems we're doing vice versa, recreating OpenFOAM with python. What are your thoughts about that? What is the goal of your quite monumental task you have completed?

[MHS0027]

Glad to hear you got it working

It's my first Python program (the last code I wrote was in FORTRAN 77 in 1995) so the style is not very Python

I think the first thing to decide is
is this an extension -> which means no changes to classy_blocks ?
or
are we going to integrate this feature into classy_block -> which means removing some duplications
eg
merge HexCellList with BlockList (HexCellList does not automatically update_neighbours)
merge HexCell with Cell (HexCell stores vertex_indices as well as vertices (if i thought hard enough i could probably remove this need)
merge HexVertexList with VertexList - add a list of positions as well as a list of vertices (i needed this to speed up the duplicate vertex finder)
merge HexVertex with Vertex (HexVertex adds a list of cells to which the vertex is attached - useful for the neighbor search after all the blocks have meshed)
merge write_vtk from HexMesh and Mesh - both do the same thing with different data sets
change the way the geometry dictionary is stored - at present its dictionary of strings - should stored as a dictionary of values and convert these to strings when the blockmeshdict is written (this would avoid having to decode the geometry strings on every projection)

and then there will be a few additions
eg I need to add a patch as a neighbor on a cell to enable the application of boundary conditions on the mesh
and I would like to understand better how your interpolation functions work I am sure if I understood oop better this could
simplify some of the edge curve fitting stuff

none of these are a big deal - they just drive some change back into classy_blocks

so it depends on whether you think the effort is worth it on your side

In terms of porting Openfoam to Python - I am afraid I am not an OpenFOAM user (and never have been)
The last time I looked at CFD source code was in 1987 (that was before Star-CD was launched)
There appears to be a healthy OpenFoam userbase so I don't see the demand

I am currently doing a PhD relating to the application of machine learning to electric motor simulation
So I am playing with finite elements
My interest in classy_blocks is that (with HexMesh) it provides a geometry template for a class of electric
motor design that allows me to sweep a range of dimensions and automatically recreate the mesh for each
analysis

I think a more interesting task would be to graft a simple GUI front end onto classy-blocks
(think of a stripped-down version of cubit) that would automatically write the Python script
(like the ParaView macro feature) for the geometry creation

Regards
Malcolm

[FranzBangar]

I have created a new branch wip_meshing. Fork the repo, add your stuff to that branch and make a pull request so that your contribution will be duly noted. We can talk about merging or separating responsibilities within objects later.

Now I get why OF environment is not for you and I support your work with python, it's perfectly legit. In any case, I believe there's still much to be optimized if speed becomes an issue for more folks.

I've been thinking about GUI lately and I guess this is a logical next step for classy... Just haven't decided yet whether to use paraview, FreeCAD or something else?

[MHS0027]

Ok
I am new to github - so Ive got to watch some videos on how to do some of this stuff
I meshed your new cyclone example this morning

It meshed first time but showed that the vertex deletion/rebuilding is a real bottleneck
with 160k duplicated vertices this process is slow on my machine (will think about how to speed this up)
Regards

[FranzBangar]

Don't worry about that right now. Just add the code, however duplicated it may be, then we'll refactor it to something decent-ish.

[MHS0027]

Ok - what a week I've had to get this in any sort of shape to contribute

Contributing sets a pretty high bar for code checking and typing
The HexMesh extension now passes - with some issues, I think I need your help to fix

• python -m pytest - creates several numpy depreciation warnings (none of these are in hexmesh)
• ruff check src tests - all passed with lint.select but this line fails when I do a git commit - in the end I deleted the lint.select line in the toml fiile
• mypy src tests - flag three errors - these are properties in an inherited class - I don't understand why I get these
• src\classy_blocks\extensions\hexprojections.py:176: error: "EdgeData" has no attribute "label" [attr-defined]
  src\classy_blocks\extensions\hexdeltas.py:174: error: "Edge" has no attribute "third_point" [attr-defined]
  src\classy_blocks\extensions\hexdeltas.py:206: error: "Edge" has no attribute "point_array" [attr-defined]
  do you know how I fix these ?
  also I have several warnings relating to scypy.KDTree that I have simply used type ignore on

the black checks and isort checks all run ok

• I have added the extension to the Hexmesh_Extension branch of the forked repository on my account
• (I don't have permission to write to the wip_mesher repository - which is a good thing for now)

I have not written any tests (writing tests is all new to me and something I need to learn but not now)
I have run all the examples and the timed results on my 10-year-old desktop are in the hexmesh_benchmaring.xls file
This compares the meshing speed of all the scripts (we average 80 seconds per 100k cells - I think this is as fast
as we are going to get)

This initial release is a lot faster on the big models than the example code I sent last week - your cyclone example
caused me to revisit all the duplicate vertex-checking stuff - which is now much better/quicker and avoids the creation
of too many duplicate vertices

I think the one thing you will like is that I have added the block ID to the mesh vtk files
This allows you to have a different color for each block - this would add color to the pictures on your tutorials
(when I get exploded views working in paraview I will send you some pictures)

Finally - can you point me toward some understandable documentation on searchable surfaces

• what is the logic behind what they are supposed to do - project to the surface or is the surface a clipping mechanism
• its not at all obvious from the pictures in open foam website(s)

Regards
Malcolm

[FranzBangar]

To me it looks like you're slightly overdoing it, on a work-in-progress branch not every commit has to pass all tests.
Some warnings from tests come from my functions (still have to sort it out), scipy isn't a typed library at all so it's OK to ignore warnings there. But at this point it doesn't really matter, we'll sort stuff out along the way, together with optimization (which awaits me as well)...

You should make a pull request and I give it a blessing. I've never contributed so far so I can't really give you exact instructions. I guess it should be something like this: https://opensource.com/article/19/7/create-pull-request-github

About searchable surfaces. There's no documentation that I'm aware of and projection to multiple surfaces is still a work in progress even in both OF branches. As to my understanding, it's just moving to the closest point on the surface, something like this:

• vertex to a single surface: move it to the nearest point on the surface
• vertex to two surfaces: make an edge from intersection, then move to the closest point on the edge
• vertex to three surfaces: move it to the intersection point
• edge to surface: move each (cell) point to the closest one on the surface
• edge to two surfaces: redefine the edge by the intersection
• surface: again, nearest points
  I once browsed through the actual code but at the moment can't look for it. I'll let you know if I dig something up.

Thank you for your excellent contribution, it expands the usability quite a lot!

[MHS0027]

It's brilliant when what you first thought was hard turns out to be easy (do you like the picture ?)
Thanks