Reference elem #62
Reference elem #62
Conversation
|
libMesh - C++ Finite Element Library » libmesh #376 SUCCESS |
|
libMesh - C++ Finite Element Library » libmesh #377 SUCCESS |
|
libMesh - C++ Finite Element Library » libmesh #378 SUCCESS |
|
ReferenceElem::get() is never going to return NULL, so we might as well return a reference instead of a pointer. But that's just a nitpick and otherwise this looks great so far. My horror at the string parsing is outweighed by my awe at the fact that you've managed to thereby make this Don't Repeat Yourself compliant. |
|
Thanks, will to. My first thought was to actually read the reference elements into a file-scope mesh and return pointers to it, and I may later, but not until I can do something like SerialMesh one_hex8 (libMesh::COMM_SELF);
one_hex8.read("one_hex8.xda");because there is just so much of an underlying assumption at the moment that the mesh lives on comm world. Even still, it'll be nice even in that case to use stringstreams instead of file IO to avoid disk contention in parallel. |
|
*will do. I'll continue working on the larger feature set for a few days and let the queue of other requests thin out... |
|
I guess I don't understand. It seems like there should be lots of ways to do this without needing to have a file that has all of this info in it. Off the top of my head, how about just adding a: static Elem * ref_elem; To each Elem class... then the first time someone calls elem->reference_elem() for a particular type of elem it will build the reference elem if needed and store it in ref_elem for that class. Each successive call will just return ref_elem. So reference_elem() is pure virtual and is implemented by each type of Elem to construct a reference elem of that type. This is probably not the only idea... but I don't see a need for reading this stuff from a file. But of course I haven't thought it through quite as thoroughly as you probably have... |
|
On Mar 28, 2013, at 7:01 PM, "Derek Gaston" <[email protected]mailto:[email protected]> wrote: I guess I don't understand. It seems like there should be lots of ways to do this without needing to have a file that has all of this info in it. That would work as well, right now I'm using code generated automatically from the mesh files we already have, and there is no actual disk access involved. This way we just don't repeatedly define the reference element node locations in different parts of the library. -Ben |
|
I understand - I'll trust your judgement on these issues ;-) |
|
You know, parsing objects from the files via that string layer is but would it be possible instead to have the reference objects |
I'd think we could do that. Up front it will touch a lot more code to implement - each concrete elem class will need a static pointer or reference to is reference, some code to safely initialize that at first call, and a destruction method, but it should be doable. The major complication is that the Elem is a reference counted object, so we need to be sure our static reference counting stuff is initialized before any Elems, and that they are destructed in the proper order. That's the only thing that prevents just defining a static object in each derived class and letting the static creation order fiasco ensue. So an option would be a static function in each Elem that holds such an object and returns a reference, which is more code proliferation but doable if that is the group preference? Actually getting those into a mesh to write out the xda files would require some gymnastics, and probably a standalone utility code "libmesh_reference_elements" or something... |
|
libMesh - C++ Finite Element Library » libmesh #382 SUCCESS |
|
libMesh - C++ Finite Element Library » libmesh #385 SUCCESS |
|
libMesh - C++ Finite Element Library » libmesh #390 SUCCESS |
|
libMesh - C++ Finite Element Library » libmesh #394 SUCCESS |
|
libMesh - C++ Finite Element Library » libmesh #396 SUCCESS |
|
libMesh - C++ Finite Element Library » libmesh #397 SUCCESS |
|
libMesh - C++ Finite Element Library » libmesh #398 SUCCESS |
This patch implements singleton objects for each reference element type. At presenent they are read from our "reference_elements/" files, but that does not scale. My next attempt will be to embed those definitions automatically through static stringstream objects. This is an incrimental feature to support the following usage: Elem *phys_elem; Elem const * ref_elem = phys_elem->reference_elem(); where phys_elem is a typical element and ref_elem is its reference element in parametric coordinates.
|
libMesh - C++ Finite Element Library » libmesh #401 SUCCESS |
|
libMesh - C++ Finite Element Library » libmesh #404 SUCCESS |
|
libMesh - C++ Finite Element Library » libmesh #405 SUCCESS |
|
Speak now - I'm happy with this implementation and will merge it later today so I can rebase the subcell quadrature off of this. I am still building the singletons from static strings - this could easily be refactored later if it is preferable to do static per-Elem instantiations. -Ben |
|
Fine with me for now. |
For the cut cell quadrature subintegration, it would be nice to have singletons that provide acces to the reference cell for each element type. That is, a full-featured Elem that is posed on the reference domain. Consider for example:
This patchset implements the singleton objects. They are read from static strinstream data to avoid disk I/O, and the singleton cache is updated only once, at first access.
Opening this up for comments before I add the Elem interface and implement the missing edges.
-Ben