Yes I began this project by reviewing step-8 <https://www.google.com/url?q=https%3A%2F%2Fdealii.org%2F8.4.1%2Fdoxygen%2Fdeal.II%2Fstep_8.html&sa=D&sntz=1&usg=AFQjCNE8fid8PZJVBvCz_Ixx08I0EOi-8A> and the Handling vector valued problems <https://dealii.org/8.4.1/doxygen/deal.II/group__vector__valued.html> module. That led me to using extractors.
step-57 <http://www.google.com/url?q=http%3A%2F%2Fwww.dealii.org%2Fdeveloper%2Fdoxygen%2Fdeal.II%2Fstep_57.html&sa=D&sntz=1&usg=AFQjCNE6vPIRLDSt5O067SsyGpHe2_cctg> almost clarifies my problem; but unfortunately I don't see its exact weak form, and rather it just references back to the Stokes tutorial. The term present_velocity_gradients[q]*phi_u[j]*phi_u[i] from its matrix assembly caught my eye. I think this is similar to my v*gradz*w, which per a quick test I did is equivalent to gradz*w*v. My understanding is that dealii:: Tensor::operator* automatically transposes (at least in the abstract) rank 1 tensors to make dot products, which makes all of this work. Since step-57 <http://www.google.com/url?q=http%3A%2F%2Fwww.dealii.org%2Fdeveloper%2Fdoxygen%2Fdeal.II%2Fstep_57.html&sa=D&sntz=1&usg=AFQjCNE6vPIRLDSt5O067SsyGpHe2_cctg> has to assume something about the indexing of present_velocity_gradients[q], maybe Timo or Liang Zhao can definitively answer my original question. What's the best way to draw a specific person's attention to a question on the mailing list? :) On Thursday, April 6, 2017 at 11:38:33 AM UTC+2, Jean-Paul Pelteret wrote: > > Ok great, I'm glad that you're getting somewhere. So lets try to get to > the bottom of this indexing issue (as a side note, and in case anyone else > is interested, in this issue > <https://github.com/dealii/dealii/issues/3646> we've started discussing > how to document the index-related functions in a bit more detail). > > Can I ask a quick question: Are you familiar with the step-8 > <https://dealii.org/8.4.1/doxygen/deal.II/step_8.html> tutorial? This is > the tutorial that details how vector-valued shape functions work in > deal.II, and also what it means to ask (without the help of an extractor) > for the gradient of one (primitive) shape function associated with a vector > field. Although the tutorial described an application in solid mechanics, > exactly the same concepts apply in your scenario. I think that this should > give more insight into how one might go from the weak general form to a > explicit assembly pseudo-code for a vector valued field. Its also better > explained than anything that I could fit into this text-box, but if you > don't find that to be the case then I've also expanded on it in this PDF > <https://github.com/jppelteret/code-gallery/blob/353c02d31d76fdd76851a7313681d4d8bd1c42f4/Linear_Elastic_Active_Skeletal_Muscle_Model/doc/theory/theory-linear_elastic_active_muscle_model.pdf> > (from > page 5 is relevant). > > Using the extractors means that you (typically) don't have to worry about > the manual component indexing via calls to > const unsigned int component_i = fe.system_to_component_index > <https://dealii.org/developer/doxygen/deal.II/classFiniteElement.html#a27220a135402b96c7e6eecbb04acda56> > (i).first; > This allows one to get, for a primitive vector shape function, its only > spatial component that is non-zero. The extractors help by filtering out > the shape functions associated with other fields and reinterprets and > collects the shape function value/gradient information for the given field. > > -- 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 dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
