Hi All,I have attached a revised version of the FENothing class, with some additional functionality. I have also included some (simple) test cases--two of which should now work and two don't.
As far as modifications go, I added an optional argument to the constructor which specifies the number of fe components that the nothing element has. Ultimately I'd like to be able to use the element within an FESystem to solve multicomponent problems like Stokes' flow. The interaction of the FENothing with an FESystem is the subject of test 4. Of course, there are a few other hurdles to get through before then, but I still think it is good to think ahead as it may alter how we approach more immediate problems.
Test 1 looks at distributing degrees of freedom, and is working properly.
Test 2 looks at the interaction with the FEValues class, and also seems to be working. I modified the get_data function to return a default data object. Normal fe classes resize the data fields to represent the number of dofs in the element, but all these fields need to be empty since we have no dofs. Wolfgang, I understand your logic that we are trying to represent a zero-function space, but the current element has no support points at which to evaluate this zero-function, so it seems to me that it should return empty data structures rather than zero values, zero tensors, etc. Of course, if anyone ever tried to evaluate the value of this element at a specific point (e.g. a shape_value call) then I think we should throw an exception. Let me know if that makes sense, or if you have a different interpretation. Ultimately I'd just like to have an implementation that "plays nice" with the library!
Test 3 looks at making hanging node constraints. The first issue I encountered was that the FENothing did not implemt the new way of handling hp constraints, so I added trivial implementations of the necessary get_face_interpolation_matrix calls. The real issue I now am running into, for both tests 3 and 4, is that the other elements in the library don't know how to treat the FENothing. I know we originally set the FEQ to be the dominant element, but might it make sense to set the FENothing to always be dominant? The FENothing will always know how to handle constraints regardless of the other element type (i.e. just don't apply any constraints) but the reverse is not true unless we add additional if statements to all the other element definitions in the library.
Anyway, let me know what you think so far, and which direction I should head next.
Best, Josh
fe_nothing.cc
Description: Binary data
fe_nothing.h
Description: Binary data
fe_nothing_01.cc
Description: Binary data
fe_nothing_02.cc
Description: Binary data
fe_nothing_03.cc
Description: Binary data
fe_nothing_04.cc
Description: Binary data
_______________________________________________ dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii
