[MOAB-dev] [MCS Sites] Looking for a mesh generation code API
Grindeanu, Iulian R.
iulian at mcs.anl.gov
Mon Oct 7 07:29:28 CDT 2019
Official MOAB list is moab-dev at mcs.anl.gov
You should also use bitbucket
https://bitbucket.org/fathomteam/moab
Thanks,
Iulian
________________________________________
From: Andrew Parker <andrew.parker at fluidgravity.co.uk>
Sent: Monday, October 7, 2019 3:31 AM
To: Grindeanu, Iulian R.; Mahadevan, Vijay S.
Cc: Jain, Rajeev; VanderZee, Evan
Subject: Re: [MCS Sites] Looking for a mesh generation code API
Thank you very much for your help! Based on the below, I think it's best I go for MOAB. Got it compiled at the weekend and ran a few sample problems. I'll no doubt have further questions. Which mailing list is best to hit for questions?
Thanks,
Andy
On 03/10/2019, 19:45, "Iulian Grindeanu" <iulian at anl.gov> wrote:
Hello Andrew,
Thanks for reaching out to us; I think MOAB and MeshKit could serve your
needs.
One question is about input geometry; Or how do you describe your
initial domain? Would you start from an existing mesh (for example a
volume filled with hexahedrons, that you cut yourself ?) Or do you
start from a CAD-like geometry file ? BREP , IGES file ? If you start
from geometry, you would need to work in MeshKit framework; If you start
from an existing mesh, maybe it is easier to just work in MOAB.
Please see below
On 10/3/19 10:10 AM, Mahadevan, Vijay S. wrote:
> Andrew,
>
> I am also cc'ing other MOAB and MeshKit developers so that they can provide their perspective and address some of the questions you have in more detail.
>
> Best,
> Vijay
>
> On 10/1/19, 6:49 AM, "Dr Andrew Parker" <andrew.parker at fluidgravity.co.uk> wrote:
>
> Hi,
>
> I am unsure as to whether what I am looking for is the intended purpose of MeshKit, or indeed I could re-use elements of MeshKit to achieve my goals. If I am honest, I half wonder whether the same question also applies to MOAB. Below I describe what I’m trying to do and I would really appreciate some help/feedback as to whether MeshKit or MOAB could be used to help me. Or a recommendation if you are aware of other tools to consider that may be more appropriate.
>
> I am currently writing my own mesh generation software (c++): specifically in 3D based on a cut-cell methodology. I am not working on a solver, just the mesh generation aspect. The actual algorithms I’m developing is the point of my work and is very much my research. As part of this research, I have the following requirements itemised below for which I’m currently also using self-written code to provide: these are ancillary albeit essential to the actual goal of creating a mesh. It is these aspects of my work that I would like to port to a better written and maintained API as they are not the stated aim of my work, and currently my approach is buggy. My aim would then be to continue to develop my mesh generation software via a cut-cell methodology while offloading the following to MeshKit/Moab. They are:
>
> 1) I have the requirement for unique vertex labelling based on a given point position, so that repeated points get the same ID. Currently I’m just using one of the point locators in VTK.
You would have to maintain your data structure, that points to MOAB
entity handle. You need to familiarize with moab entity handle, which
is just a "pointer" to mesh entities, (vertices, edges, elements, and
even sets of other entity handles)
The best in my opinion would be a
std::map<Point, EntityHandle> vmap;
Point is 3 doubles (or floats?) on which you define your own compare ,
based on some tolerance; Example would be in the ReadSTL reader in MOAB;
(no tolerance there, but tempestremap library has a better example)
> 2) I have the requirement to start from no mesh and build it up from scratch. Vertices->Edges->Faces (defined by edges)->Cells (defined by faces). And to do this cell by cell one at a time. So I need to be able to build up a mesh like that.
In moab, you can create a vertex at a time, and an element at a time;
vertices would have to be created in MOAB only if an new vertex is not
"found" in your map above;
edges, elements, polygons, polyhedra are created in moab with the
same call:
virtual ErrorCode create_element(const EntityType type,
const EntityHandle *connectivity,
const int num_vertices,
EntityHandle &element_handle) = 0;
type can be MBEDGE, ..., MBPOLYHEDRON; for polyhedron type, vertices are
entity handles to faces, not to vertices (faces can be any 2d types, or
polygons)
MOAB does not check for planarity of polygons, or if they are
self-intersecting; It is just a list of vertices, from MOAB point of
view; the same about quads, for example, it is a list of 4 vertices, but
quality is your responsibility (there are mesquite like tools that help)
> 3) The faces need to be allowed to be polygons
yes; polyhedron is a list of faces; your responsibility to enclose a
logical volume; no assumption about orientation of faces within a
polyhedra; in a conforming mesh, a polygon could be a face to 2
polyhedra, or one if at the boundary of domain;
> 4) The cells need to be allowed to be polyhedral
yes
> 5) Edges can be assumed linear
OK
> 6) I have the requirement to split any edge at an arbitrary position, and produce two child edges. This must update the resulting mesh
Updating a mesh is your responsibility, in a way; if you split an edge,
you have to modify the polygons that use that edge, to add a new vertex
to each of the polygons, at the required index; Also, when you modify a
polygon, it is actually better to delete the old one and replace it with
a new one; then you need to update the polyhedra that use that polygon;
What happens to the old edge? Do you keep it or delete it? Your
responsibility also. For edges, you can actually reuse the old edge, and
create only one new; (and redefine connectivity, when you reuse the old
one). Or you delete the old one and create 2 new ones; or keep all 3,
but then maintain yourself a hierarchy
Children/parent adjacencies should work out of the box, as long as you
maintain entities involved
> 7) I have the requirement to split a face in to two child faces, this must update the resulting mesh. The face splitting may be the result of one or two edges being cut.
your responsibility also; because you also change the number of faces in
the polyhedron, it is better to delete the old one and create a new
polyhedron with a new list of faces (polygons)
> 8) I have the requirement to be able to walk back up face and edge trees from children to parents
adjacency calls use vertex adjacencies, which are always maintained (so
a vertex maintains an ordered stl vector of entities adjacent to the
vertex, edges, triangles, ,..., polygons, polyhedra) These well defined
lists are then used to navigate up and down the mesh.
> 9) IO would be good, writing out to VTK is fine.
IO in general is pretty easy, with MOAB
hdf5 format is "complete" , and works in parallel too; visualization of
VTK polyhedra in ViSit or Paraview is not very good, because they
decompose faces in triangles
Polygons are fine.
> 10) I would like to associate meta-data to vertices, edges, face, cells. Integers would be fine. But I need to associate a number of different fields to each topology type. For example cells: fluid/solid cell identifier. Similar requirements for fields on edges and faces.
this is what MOAB tags are for :) It is a different concept, compared to
entity handles; there are many examples, and these fields could be
dense, sparse, integer, real, or even pointing to other mesh entity handles;
> 11) It would be good to be able to refine a hex/tet somewhere within the mesh and have child cells produced within a mesh that may also contain polyhedra
maintaining a hierarchy and a correct mesh is user responsibility; You
can organize hierarchies with "mesh sets", but it is again, user
responsibility; So if you split a hex in 2, you would logically put the
2 new polyhedra in a different "level" set. Do you keep the original hex
or not? If you keep it, of course when you ask for cells connected to a
vertex, you would get that original hex too, along maybe with both new
polyhedra. A lot of user responsibility :)
> 12) Clearly the mesh starts off size zero, so parallel is not an issue. However, it would be really nice once I hit a user defined cell-count to rebalance to n-processors via metis/parmetis. Initially the master would do all the work and then rebalance once there’s a mesh to distribute.
IO with hdf5 works pretty well in parallel, too; we have also examples
of repartitioning using zoltan (which can use metis too). Repartitioning
is also possible "online"
> 13) Hanging nodes and non-conforming meshes need to ok
Again, user responsibility.
1 2 3
4 5
6 7 8
Assume these above vertices, in a plane, such that 1254, 4576, 2387 are
quads; 5 would be a hanging node for quad 2387
if you ask for cells adjacent to vertex 5, you would get only 1254 and
4576; if you really think it should be part of quad 2387, then 2387
should be a pentagon (5 node polygon), 23875. But this would be
conforming mesh.
>
> I hope it’s clear that what I’m looking for is a code base with the above type of API, that I can use to write against that my own mesh-generation software. I am more than happy however to use a codebase that can do the above but whose stated aims go beyond the above. I really have no idea if that type of library exists, but it would be great to get some help as to where to look for the above.
>
> Please get back to me if I need to clarify any of the above. I am not on the mailing lists for MOAB/MeshKit. Finally, I have been evaluating for different purposes MFEM and PUMI with one eye on the requirements above, but those both do not meet all of the above requirements. As I noted, if you think I should look elsewhere at other software that's really helpful advice.
>
> Thanks,
> Andy
>
>
>
More information about the moab-dev
mailing list