[deal.II] step-11 boundary element
Hi all I am new to dealii. I have a question on step-11. For a domain with a curved boundary such as step-11 with fe(1), is the boundary element still a bilinear one if mapping order>1? i.e. always 4 dofs on a boundary element? Thanks Alex -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/059f1e7c-9fd5-4fb2-8c36-06e6e0d09483o%40googlegroups.com.
Re: [deal.II] step-11 boundary element
On 7/9/20 1:18 AM, Alex wrote: I am new to dealii. I have a question on step-11. For a domain with a curved boundary such as step-11 with fe(1), is the boundary element still a bilinear one if mapping order>1? i.e. always 4 dofs on a boundary element? Thanks You need to distinguish between the element and the mapping. The element's shape functions are defined on the reference cell, and for a Q1 element (=fe(1)), there are always 4 shape functions in 2d. The *mapping* on the other hand is used to describe how shape functions are transformed from the reference cell to the real cell. This mapping is more complicated when you have a curved boundary than if you have a straight boundary, but it does not affect *how many* shape functions there are. Best W. -- Wolfgang Bangerth email: bange...@colostate.edu 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 dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/220be353-f7e3-968f-4fe9-978fa5b00d84%40colostate.edu.
Re: [deal.II] Geometric Conservation Law
Dear Martin, As an update, I figured out a way to have it work in 3D without needing to use another Evaluate call. The only issue is that I need the quadrature in the reference element since I construct an FE_DQGArbitraryNodes to evaluate the derivative (I do this since the metric Jacobian is in a sense "collocated" on the quadrature points so the gradient needed is just the derivative of the basis functions). I have it passing collocated and uncollocated curvilinear test cases in 3D now perfectly, but I currently construct the FE_DGQArbitraryNodes in mapping_q_generic.cc by explicitly constructing a Quadrature like the testcase (example QGauss if the testcase uses QGauss). I couldn't find a way to extract the reference element quadrature from the MappingQGeneric InternalData, do you have any suggestions? Thank you, Alex On Friday, July 3, 2020 at 6:11:28 PM UTC-4, Alexander Cicchino wrote: > > Dear Martin, > > I would like to start by thanking you for all of your help. Here is a link > to my fork: https://github.com/AlexanderCicchino/dealii > It is not fully working yet, I need your help for the "evaluate" as you > mentioned earlier. I have been trying multiple different ways but cannot > seem to get it to work properly. > First, I have a test setup in: > tests/mappings/mapping_q_generic_GCL_curvilinear.cc > where currently I am outputting everything, this will change in the future > and I will later on add a more complicated curvilinear mesh to test. But, > importantly, the current implementation fails the test. > Also, I made changes to source/fe/mapping_q_generic.cc as you suggested in > the function mentioned above. The last part, which is including the > evaluate is in: > > > https://github.com/AlexanderCicchino/dealii/blob/master/source/fe/mapping_q_generic.cc > > line 1622. We have X_l*grad(X_m) evaluated at each quadrature point, now > we need to somehow have the gradient of that evaluated at the quadrature > points. I assumed after line 1622 that that gradient is written in > "grad_Xl_grad_Xm" which is gradient( X_l * gradient(X_m) ) then I loop > cyclically through it for the conservative curl form. > > Please let me know how you suggest I should proceed/setup the evaluate > call at line 1624. > Also, I noticed that the conservative curl form from Kopriva is not well > posed for 2D. In the past, for 2D we would extend the grid by unit 1 in the > z direction to properly evaluate the metric terms since, for example we > need: d/(d \zeta) ( z* dy / (d\eta) ). Any suggestions on how to implement > the 2D version in mapping Q generic? > > Thank you, > Alex > > On Wednesday, June 24, 2020 at 9:40:55 AM UTC-4, Martin Kronbichler wrote: >> >> 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 >> On 22.06.20 19:59, Alexander Cicchino wrote: >> >> Dear Martin, >> >> Thank you very much! I have been working on making the test case not >> depend on our in house flowsolver's functions. >> I think that implementing Eq. 36 the "conservative curl" form would be >> sufficient. >> Yes this procedure sounds perfect to me, and I agree with the dimension >> of the object described. I have been going through the source code that you >> sent to familiarize myself with the objects. Should I be adding to the >> function maybe_update_q_points_Jacobians_and_grads_tensor or should I >> create a new function for it? >> >> Thank you, >> Alex >> >> On Friday, June 19, 2020 at 5:09:14 AM UTC-4, Martin Kronbichler wrote: >>> >>> 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: >>> >>> >>> https://github.com/dealii/dealii/blob/9e05a87db802ecd073bf7567d77f3491170d84b4/source/fe/mapping_q_generic.cc#L1463-L1592 >>> >>> I skipped the part on the Hessians (second derivative of transformation) >>> because we won't need them. The important parts here
[deal.II] Interest in a step-12-like DG tutorial but for the advection-diffusion equation?
Dear all, I hope you are well. I have been playing with the DG methods within deal.II lately (which has been lots of fun). I really enjoy the way step-12 is written, especially because of the use of the FEInterfaceValue class. In my opinion it makes low level stuff very easily accessible, yet it is relatively easy to understand. However, I am under the impression that there are no similar test for elliptic equations in which you need to use Nitsche method + Symmetric Interior Penalty for the boundary + inner faces respectively. I know of step-39, but it does not use the same "low-levelish" features. I have written such a code for my own pleasure for the laplace equation and I am currently working on its advection-diffusion version (mostly following Larson Chapter 14). Would it be interesting to turn such a case into a deal.II step (that would follow in step-12 footstep) or does the community feel that the existing steps for DG sufficiently cover the ground? Best Bruno -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/b931b23c-b284-4047-a887-d500ac9e8486o%40googlegroups.com.
Re: [deal.II] step-11 boundary element
Thank you. Do you have any recommendation for reference notes or books which explains the math behind mapping? I can see some in Mapping< dim, spacedim > Class Template Reference. Alex On Thursday, July 9, 2020 at 7:01:34 AM UTC-6, Wolfgang Bangerth wrote: > > On 7/9/20 1:18 AM, Alex wrote: > > I am new to dealii. I have a question on step-11. For a domain with a > curved > > boundary such as step-11 with fe(1), is the boundary element still a > bilinear > > one if mapping order>1? i.e. always 4 dofs on a boundary element? Thanks > > You need to distinguish between the element and the mapping. The element's > shape functions are defined on the reference cell, and for a Q1 element > (=fe(1)), there are always 4 shape functions in 2d. > > The *mapping* on the other hand is used to describe how shape functions > are > transformed from the reference cell to the real cell. This mapping is more > complicated when you have a curved boundary than if you have a straight > boundary, but it does not affect *how many* shape functions there are. > > Best > W. > > -- > > Wolfgang Bangerth email: bang...@colostate.edu > > 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 dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/845980b0-a24f-4754-90f5-28293534463fo%40googlegroups.com.
