Official MOAB list is [email protected] You should also use bitbucket https://bitbucket.org/fathomteam/moab Thanks, Iulian ________________________________________ From: Andrew Parker <[email protected]> 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" <[email protected]> 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" <[email protected]> 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 > > >