Roy, I have attached an initial patch to handle the level-1 rule across periodic boundaries but I believe there is still more work to be done. What this patch DOES: - Adds Elem::topological_neighbor(unsigned int side, Mesh &, PeriodicBoundaries *) - Adds a few accessors and setters for getting a pointer to the Periodic Boundaries into MeshRefinement - Replaces calls to neighbor with calls to topological_neighbor throughout MeshRefinement with the proper #ifdefs
At this point I don't have a good test case built on top of libMesh which is a real problem. I have a few problems which I'm running through our software right now to verify that this is doing what I want it to do, but we do need some regression tests for libMesh. I'll work on getting something put together. What I'd like to do at this point is get any feedback you may have. I believe that I'll need to make a few more functions like "has_topological_neighbor" which might need to be used in certain instances. I haven't even started to address the error estimators. If you can think of glaring oversights or design issues with where I'm going please let me know. This patch should work with the current head. I'll post a test case soon.
periodic_AMR_libmesh_current.patch
Description: Binary data
Thanks, Cody On Nov 10, 2010, at 5:00 PM, Roy Stogner wrote: > > > On Wed, 10 Nov 2010, Cody Permann wrote: > >> Sorry I don't mean to spam but I thought of one other issue to consider with >> changing >> around the API for the Periodic BC AMR level one constraint issue. Right >> now the >> PeriodicBoundaries object is held inside of DofMap but for topological >> purposes, >> perhaps it doesn't belong there. At the very least, I clearly need access >> to it from the >> objects dealing with the Mesh. If we pass in the PeriodicBoundaries object >> as a reference to the new topological_neighbor function then the callers >> will need >> access to it only moving the problem "who should own it" problem. >> >> For now I created a pointer in the MeshRefinement object and an accessor in >> DofMap to >> get a reference for the purpose of setting that pointer. This doesn't seem >> like the cleanest >> solution. If you have some better design ideas let me know. > > I thought about the same problem but shoved it to the back of my mind; > you're right to drag it out in the open. PeriodicBoundaries was > originally deep in DofMap because I'd thought that that was the only > class which needed to use it. I could definitely see an argument for, > say, attaching it to a MeshBase instead. > > Other ideas/opinions are welcome. > --- > Roy
------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
