Doug,
> I am trying to use MappingFEField to represent my high-order mesh points > (which will then be deformed through optimization). Similarly to this thread > High order mesh from Gmsh > <https://groups.google.com/forum/#!searchin/dealii/high$20order$20mesh|sort:date/dealii/8ta3DmMCwsE/0AKQVI_0AQAJ>. > > However, I am using hp-finite element and I would expect different element > geometric orders to exist for cells with different solution orders. > > I see that MappingFEField is currently only instantiated with DoFHandler, and > not hp::DoFHandler, so I tried to add it to the instantiation file > "/fe/mapping_fe_field.inst.in". Unfortunately, it seems like the current > MappingFEField implementation assumes that the finite element is not a > FECollection, etc. and tries to directly operate on it. > > What would be the best way to have different element geometric orders, where > I > can control the metric degrees of freedom? It does not greatly surprise me that it doesn't compile -- what isn't tested generally doesn't work. We'd of course be very happy to accept any patches to make things work. The general approach to making stuff work is to *always* use hp::FEValues objects to evaluate solution fields. You might want to look at some of the functions in VectorTools that can either take a ::DoFHandler or hp::DoFHandler to see how they work and how the code is written to accommodate both kinds of DoF handler classes. A good strategy to implement these kinds of changes is to split things up into a number of incremental changes. Each of these individually doesn't get you to the end point, but fixes one roadblock at a time. I find it much easier to work this way (using many individual pull requests to get to the final goal) than to try and write one monumentally large one, principally because each step individually can be sent through the test suite. (There are 23 tests right now that use this class, so it's reasonably well tested.) If no tests break, then it can't have been so wrong, and one can move on to the next problem. I've definitely implemented things many times that took a sequence of 10 pull requests, each making incremental progress. Writing several new tests in the process is definitely also helpful. I'd suggest you try that approach. Best W. -- ------------------------------------------------------------------------ Wolfgang Bangerth email: [email protected] www: http://www.math.colostate.edu/~bangerth/ -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/30bf75d1-4dc2-c725-91b7-2db13325a6dd%40colostate.edu.
