Dear Alex,
This has been on my list of things to implement and verify with deal.II over a range of examples for quite a while, so I'm glad you bringing the topic up. It is definitely true that our way to define Jacobians does not take those identities into account, but I believe we should add support for them. The nice thing is that only some local computations are necessary, so having the option to use it in the polynomial mapping classes would be great. If you would be interested in this feature and trying to implement things, I'd be happy to guide you to the right places in the code.
Best,
Martin
--
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+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/4f313231-dbb3-445f-923c-9eaff17ab783o%40googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to dea...@googlegroups.com.
Dear Alex,
Great! The first thing we need to know is the equation. I had a
quick look in the paper by Kopriva and I think we want to use
either equation (36) or (37), depending on whether we consider the
conservative or invariant curl form, respectively. In either case,
it appears that we need to do this in a two-step procedure. The
first step is to compute X_l and \nabla_\xi X_m, which in deal.II
speak are the "q_points" and "Jacobians". The implementation in
mapping_q_generic.cc is a bit involved because we have a slow
algorithm (working for arbitrary quadrature rules) and a fast one
for tensor product quadrature rules. Let us consider the fast one
because I think we have most ingredients available, whereas we
would need to fill additional fields for the slow algorithm. The
source code for those parts is here:
I skipped the part on the Hessians (second derivative of transformation) because we won't need them. The important parts here are the extractions of the positions in line 1554 and the extraction of the gradients (contravariant transformations) in line 1575. Those two parts will be the starting point for the second phase we need to do in addition: According to the algorithm by Kopriva, we need to define this as the curl of the discrete interpolation of X_l \nabla_\xi X_m. To get the curl, we need another round through the SelectEvaluator::evaluate() call in that function to get the reference-cell gradient of that object, from which we can then collect the entries of the curl. To call into evaluate one more time, we also need a new data.shape_info object that does the collocation evaluation of derivatives. That should only be two lines that I can show you how and where to add, so let us not worry about that part now. What is important to understand first (in terms of index notation vs tensor notation) is the dimension of the object. I believe that X_l \nabla_\xi X_m is a rank-two tensor, so it has dim*dim components, and we compute the gradient that gives us a dim * dim * dim tensor. Taking the curl in the derivative and inner tensor dimension space, we get rid of one component and up with a dim * dim tensor as expected. The final step we need to do is to divide by the determinant of the Jacobian (contravariant vectors), because the inverse Jacobian in deal.II does not yet pre-multiply with the determinant.
Does that procedure sound reasonable to you? If yes, we could
start putting together the ingredients. It would be good to have a
mesh (the curvilinear case you were mentioning) where we can test
those formulas.
Best,
Martin
To unsubscribe from this group and stop receiving emails from it, send an email to dealii+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/b764b4b7-02d2-4139-95d9-68c30ad4f2a9o%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/b764b4b7-02d2-4139-95d9-68c30ad4f2a9o%40googlegroups.com.
Dear Alex,
Great! I would suggest to start by simply adding new code to the maybe_update_q_points_Jacobians_... function with the option to turn it off or on. Depending on how the final implementation will look like we might want to move that to a separate place, but I think it will be less repetitive if we use a single place.
Best,
Martin
To unsubscribe from this group and stop receiving emails from it, send an email to dealii+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/cf020345-b304-45d2-a228-4081da2d4effo%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/cf020345-b304-45d2-a228-4081da2d4effo%40googlegroups.com.