Hi Joshua, > I have gotten as far as I think I can go without a little help. I > implemented the face domination function, and now the distribute_dofs > function works well (so far as I can tell).
Good progress! I've already committed your changes, and fe_nothing_01 now indeed succeeds (and I have verified that the output is correct too). > One needs to avoid reinit-ing the FEValues objects on an FENothing > cell, but that is not hard for a user to do in practice, and seems to > make reasonable sense. Yes. We may eventually want to support this, but it can wait. > Does it perhaps make sense for us not to trigger an exception in these > cases, but rather have the FENothing return silently with empty > information? I'd rather not. Essentially, what the element describes is a finite element space that can *only describe the zero function* -- i.e. you need to view FE_Nothing not as a FE that has no shape function but as a function space that only includes the zero function. We should make sure that that is what get_data() actually returns, since then all the callers of this function will get correct information. All that needs to be done is figure out what get_data is supposed to compute and fill the output arrays with this information -- which is really only going to require that we fill whatever arrays there are with zeros, zero vectors, zero tensors, etc. If that works, most of the things you mention Should Just Work (TM). Can you try to look up what get_data does and see if you can come up with a trivial implementation? I don't know this part of the library very well at all, so I don't really have any pointers for you at the moment besides trying to read the documentation -- take a look in particular at this page: http://www.dealii.org/developer/doxygen/deal.II/UpdateFlagsEssay.html If you can't find your way around there let me know and we'll get Guido involved who knows this subsystem much better than me. > The other problem is that the code encounters issues when attempting > to create hanging node constraints. I have included this in the test > case, but it is commented out for now. The issue seems to revolve > around the number of active fe indices at a shared face. Beyond that I > don't have a clear idea what is going on. The way to deal with these issues works like this: Can you take the hp/fe_nothing_01 test, and add the minimal number of statements that get you to the next bug? We'll then check this one in as fe_nothing_02 and work on fixing that. Starting from there we'll create fe_nothing_03, etc, each time ticking one bug off the list. Starting with the big test you have is the wrong order, though it is of course where we want to end up with. Such an incremental approach usually makes it easier to focus on individual problems because you can see that after fixing a bug one testcase starts to work, we can put it into the testsuite and not worry about this one aspect any more because continued correctness is checked every night. If we had a big complex testcase we'd have to fix all bugs first before we could see that things work, and if we break some functionality at one point it will be hard to see right away what it was because the program tests so many aspects at once. So, keep sending me a stream of little testcases and we'll go from there! > I have cleaned up the documentation, and can revise it as we go > forward. Thanks a lot for doing this! Best Wolfgang -- ------------------------------------------------------------------------- Wolfgang Bangerth email: [email protected] www: http://www.math.tamu.edu/~bangerth/ _______________________________________________ dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii
