Wolfgang Bangerth (bangerth at math.tamu.edu)
Tue Feb 28 13:00:26 GMT 2012
Hi Jonathan,
You raise good points, and I have thought about these things to some extent. For some background about my motivation, I should say that for many projects I am working on, adaptivity it not a primary concern. The meshes I am handed are fixed, and the result of a lot of labor. They are expected to be used "as is", which isn't really a bad thing, because it allows me to make "apples to apples" comparisons with other codes. These meshes are primarily for CFD.
Fair enough.
With this in mind, I don't have a concern about loads becoming unbalanced due to adaptivity, or creating a framework in which adaptivity is not possible. So, to directly answer your two questions: 1) If I were to start with a small coarse mesh, and refine until I reach an acceptable level of resolution, I would need to now how to refine the boundaries of the complex geometry I am given. The geometries I am working with are often specified in some sort of CAD file, so in theory, I could write some sort of custom boundary geometry class, like HyperShellBoundary, that would return proper boundary point place based on the curves/surfaces in the CAD file. My knowledge of these types of programs and files is limited, and I am very ignorant of what, if any, API's exist to let me do this. Also, if I am only handed a course mesh with no geometry file, then I'm out of luck.
Right. In know people have written interfaces between deal.II and their favorite brand of CAD program that does what they need. But I have no knowledge how simple/difficult that was.
2) As said, I am willing to forgo adaptive refinement. This seems like a more viable route to me, because it would allow for others to use my code without having to modify it, leaving most of the work to pre-processing. Do you have any suggestions/style tips for getting started this? Would creating a class like parallel::distributed::NonAdaptiveTriangulation but a good place to start? Would you anticipate that DoFHandler would need significant modifications as well?
Before we think about what classes to write or how to modify existing ones, let's first think about what functionality we need. The question of where to place that will then answer itself in many cases.
In the simplest case, when there is no adaptive refinement at all (either you stick with the coarsest mesh, or you simply uniformly refine it), you'll need some way to make sure that degrees of freedom that lie on the boundary between subdomains get the same DoF index from both sides. In the parallel::distributed::DoFHandler (which is in reality part of ::DoFHandler and which is used when using parallel::distributed::Triangulation), what we do is to first let every processor enumerate its the DoFs it "owns" starting at zero, then shift them so that they have globally unique indices, then communicate the numbers of those that lie on interfaces from the owners to those processors that simply mirror them. This algorithm is well described in the paper that discusses parallel::distributed algorithms. I imagine something similar would work just fine in your case. Most of what you need is already available for the numerbing part I'd believe.
To make something like this work, you'd need to have a way that identifies vertices, edges and faces on the interface and can map some id for them to the corresponding id on other processors. Do you have an idea how that could be done? This is, in my mind, one of the trickier parts.
Finally, some algorithms need a layer of ghost cells. How do you intend to address this? Where can a processor learn about the existence of ghost cells in the scenario you envision where each processor only reads in a file that identifies its own processors?
Best
W.
------------------------------------------------------------------------
Wolfgang Bangerth email: bangerth@xxxxxxxxxxxxx
www: http://www.math.tamu.edu/~bangerth/
_______________________________________________
Developers mailing list
Developers@xxxxxxxxxx
http://dealii.org/mailman/listinfo/developers