> > Yes, this is what I am struggling to understand, you have put it very > simply. >
Great! I'm glad that gave you a bit more insight. I only hope you didn't take that as a patronising comment :-) > I can see how this is trivial for linear FE_Q's, and these three links > should make this concrete. > I forgot to say that it makes sense represent the mesh-motion problem with linear elements, since we consider the underlying geometry to have only straight lines between vertices anyway. Yes, this makes sense. To be clear, the functionality in step 2*. A > function that actually moves the triangulation vertices for you based on > this vector*. is not strictly necessary in the present context, is that > right? > For your purposes, no I don't think that this is necessary. It would just be useful for testing and for demonstration in a tutorial. We can showcase the functionality in step-49, e.g. verifying that it undoes the distortion of a cartesian mesh <https://www.dealii.org/developer/doxygen/deal.II/step_49.html#grid_7Demonstratingdistort_random> . I must admit that I lost sight of the fact that you're working in codim-1. If you choose to go down this road (as opposed to the algorithm you've discussed previously) then it would be good to first check what facilities Mesquite has to deal with this. Maybe internally it can project the optimised node positions back onto the original manifold? -- 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]. For more options, visit https://groups.google.com/d/optout.
