Thanks for your responses. I've been digging into the code and I've realized that if I just wanted to use refinement with LAGRANGE_VEC I would have to modify the function "lagrange_compute_constraints" to accommodate it for LAGRANGE_VEC and call it from the corresponding function in FEInterface::compute_contraints. As for the projection, in the class ProjectionVector, for Lagrange elements the function coarsened_dof_values is not called. I would have to modify the ProjectionVector::operator() so it can handle LAGRANGE_VEC the same way that handles the fe_type.family LAGRANGE. I don't know if I'm leaving something behind. Honestly, I'm a bit overwhelmed with this. I read this paper:
Wolfgang Bangerth, Oliver Kayser-Herold *Data Structures and Requirements for hp Finite Element Software* ACM Transactions on Mathematical Software, vol. 36 (2009), pp. 4/1-4/31. to try to understand the process better. The final conclusion mentions how long it took them to write the code and it's overwhelming. I guess that's how much it took you guys to write the libmesh hp-refinement version. I wanted to understand what I needed to do to achieve my goals of having adaptive mesh refinement for LAGRANGE_VEC elements. At first, I would like to have just h-refinement. Maybe later, once I grasp more concepts and become acquainted with the code, I will extend it to hp-refinement. Miguel On Mon, Jun 2, 2014 at 9:19 PM, Roy Stogner <[email protected]> wrote: > > On Mon, 2 Jun 2014, Paul T. Bauman wrote: > > It can lead to more dofs, but is not a bad idea to try testing. However, >> I'm in unfamiliar territory in that part of the code. I know @roystgnr >> mentioned to me at one point that arbitrary level refinement patterns >> should be supported, but hadn't been exercised. Roy/John/Ben, could you >> guys comment on enforcing a 0-level requirement? It looks like the >> maintain_level_one argument is deprecated and doesn't accomplish what >> Miguel is looking for. Any way to set enforcing 0-level refinement >> patterns? >> > > Currently, not that I know of. It wouldn't be easy to combine with > adaptive coarsening with the current code, either; we currently test > Elem::level() mismatches to determine where to apply constraints, for > example, and the only way to get element with different levels of > refinement to have the same level() would be to flatten the mesh > refinement hierarchy. > > > In Demkowicz's book, they work only with 1-irregular mesh refinement >>> algorithms, is this also the case for libmesh? >>> >> >> Again, in theory libMesh can support 2-irregular and so forth, but >> I'm not sure who has exercised that code, if at all. Roy/John/Ben >> would know better. >> > > I used MeshRefinement::face/edge/node_level_mismatch() years ago, and > there haven't been any code changes that would have been likely to > lead to bit rot in that class. We don't have any test coverage of it > though. > --- > Roy > -- *Miguel Angel Salazar de Troya* Graduate Research Assistant Department of Mechanical Science and Engineering University of Illinois at Urbana-Champaign (217) 550-2360 [email protected] ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
