apf::makeMdsBox
KennethEJansen opened this issue · comments
outModel.txt
I am trying to extend this capability or find a comparable way to introduce slightly more complicated geometric models. As I am not a strong C++ coder, I am starting with the output (outModel.dmg) I get from a case that IS a box and trying to understand the file contents to see what the most feasible route from the following three options: Before listing let me state what I want. I want to be able to handle a box with a hole that extends completely through the box such that it is a a 2D box with a hole extruded into the third dimension. Here are options I am considering:
- just make a text file by hand and call it outModel_hole.dmg that gives a topologically correct description. If I succeed with that, is there a command that I can just load that file instead of the following call gmi_model* model = apf::makeMdsBox(2,2,2,1,1,1,0);
If yes, then I could use some help filing in a few questions that I have in the attached file. - If that route is a dead end (and perhaps even if it is not) does SCOREC/core have eh capability to build a mesh from coordinates and connectivity without classification ( I regularly use matchedNodeElmReader that reads coordinates, connectivity, and nodal classification and then builds out the rest of the entity classification based on logic from the simple box model) and THEN discover the underlying geometric model? If yes, does this work with an unclassified parallel mesh (we developed matchedNodeElmReader specifically to handle meshes that were too large to fit in most serial machines).
- if that route is a bust, how feasible is it to extend the BoxBuilder tool set to BoxWithHoleBuilder.
OK now back to one Attached is a the outModel.dmg where I have added comments to reflect my understanding. Here are my questions:
- are lines 2 and 3 suppose to be bounding box coordinates (each line is 0 0 0)
- lines 3 through 10 appear to be the 8 coordinates but again, these seem to not have any real coordinates (all 0 0 0)
- the next 12 lines appear to be edge numbers with startVert# and endVert#
- logically, I think it is next building the faces with a face number and a 1 (what does the 1 mean) on a line then the number of edges in the closure on the next line followed by the edge numbers. If I have the edges defined right in 3, these edges do NOT form a loop ( 1 2 0 3 in terms of verts is 0-2 1-3 0-1 2-3 when I would have expected 0-1 1-2 2-3 3-0 but I suppose with no actual coordinates i am forced to guess a lot here. I am also unsure what the 0 next to my assumed edge number means. Are these meant to reflect direction/usage?
- after all 6 faces are "constructed" from edge non-loops I am guessing (see comments) that the single region 0 is defined from teh 6 faces that make its closure Again there is a 1 next to that region-number 0 that I am unsure of followed by a 6 which I assume is how many faces will follow and then the face number with an uncertain-meaning 0.
Here is a sketch based on my guess (lacking coordinates) of the model but, as noted above, it seems odd that edges don't form a loop based on these coordinate definitions (or is that not a requirement and not satisfied??)
OutModel.pdf
So, if the order of the listed edges is not important and the extra numbers do not need to accurately reflect direction/usage then the attached file might work for a hole defined by two new half cyldinder faces which introduce 6 new edges (I assume trying to do that with two new periodic edges that have no defining vertices is a bad idea) and 4 new vertices. I will also upload a sketch of the new model to show my assumed numbering.
OutModel box and box w hole .pdf
outModel_hole.txt
Specifically, will the following line from phBC.cc work to load my "hand made" dmg?
133 if (gmi_has_ext(modelfile, "dmg"))
134 m = gmi_load(modelfile);
in place of calling apf::makeMdsBox?
UPDATE. I just tried the above and it worked which probably does not surprise the more experienced folks. Moving on to making a branch of the code that can interpret a classification file that makes use of those new model entities and obviously writing the mesh generator that generates the mesh on that shape with matching classification.
Obviously it will not work if I don't give it an acceptable dmg model so if any folks reading this know dmg's construction syntax well enough to review my outModel_hole.txt file and/or answer questions about what those extra columns are, whether they are really needed in this case (@cwsmith knows better what the code really needs from this model but it might be only a consistent set of tagged model entities??)
@KennethEJansen I don't have much experience setting up the geometric models from scratch. Is there a reason that you can't use a model that's been derived from CAD/Simmetrix?
That is our normal route but, when the meshes approach a billion elements that workflow breaks down on integer overflows (which you helped me resolve last year). In this particular case, we are taking a Simmetrix mesh of the airfoil made in SimModeler from CAD but then we extract the 2D mesh and rebuild our own extrusion from that with as many extrusion layers as we like. Note, Simmetrix extrusion only works in serial and we hit lots of snags before getting this approach to work effectively.
We have been doing this for box geometries for a couple of years now and I am just trying to extend that to the next most interesting topological case (which covers airfoils).
For the record, @KennethEJansen and I discussed the hand-coded dmg approach, and a workflow using mdlConvert starting from a Simmetrix/Parasolid model (as @jacobmerson pointed out above). The first step towards the mdlConvert workflow is running it on a Simmetrix/Parasolid box and box w/hole model to see if it preserves geometric model entity ids.