Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

## RE: [Libmesh-users] adaptive refinements with linear elements

 RE: [Libmesh-users] adaptive refinements with linear elements From: Roy Stogner - 2005-02-18 01:32:27 ```On Thu, 17 Feb 2005, KIRK, BENJAMIN (JSC-EG) (NASA) wrote: > a non-refined element the refined elements degrees-of-freedom are > constrained in terms of the non-refined elements DOFs. What is happening in > this case is the refined elements matrix contributions are being aliased > back to the non-refined element (as well they should). However, they never > get constrained out as you would like them to because of the > element-by-element BC application process. Should that be happening in a 2D code with Lagrange elements? It seems like any constrained nodes in that case should be interior nodes. > I have envisioned another set of DOF constraints that basically impose > dirichlet values. I'll work on that over the weekend and hopefully get you > something to try next week. Would you describe the method you're implementing? I'd like something which could be generalized to non-Lagrange elements or fourth order problems if possible... of course, I don't know if that is possible at all, but maybe hearing your ideas would give me a few. --- Roy ```

 RE: [Libmesh-users] adaptive refinements with linear elements From: KIRK, BENJAMIN (JSC-EG) (NASA) - 2005-02-17 23:09:00 ```I effectively re-implemented the penalty method in your code by changing Fe(i) += ... Ke(i,j) += ... to Fe(i) += 1.e30*... Ke(i,j) += 1.e30*... in the Dirichlet BC section, and everything worked out fine. The problem is that when you have an adaptively refined element neighboring a non-refined element the refined elements degrees-of-freedom are constrained in terms of the non-refined elements DOFs. What is happening in this case is the refined elements matrix contributions are being aliased back to the non-refined element (as well they should). However, they never get constrained out as you would like them to because of the element-by-element BC application process. By using the penalty approach you circumvent this issue because of some quirks in floating-point arithmetic (1.e30 + 1.e0 = 1.e30). However, there should be a more convenient way to impose boundary conditions without resorting to this approach. I have envisioned another set of DOF constraints that basically impose dirichlet values. I'll work on that over the weekend and hopefully get you something to try next week. In the meantime I advocate the above approach. Thanks for pointing this out! -Ben -----Original Message----- From: libmesh-users-admin@... [mailto:libmesh-users-admin@...] On Behalf Of Michael Povolotskyi Sent: Thursday, February 17, 2005 9:31 AM To: John Peterson Cc: libmesh-users@... Subject: Re: [Libmesh-users] adaptive refinements with linear elements Hi, this is the code (Poisson.C) and the input file (Poisson.in). As for the possibility to set BC in a wrong way ... of course, everything is possible but it worked well with a single grid and with uniform grid refinement. Michael. John Peterson wrote: > Hi, > > If possible, you should post your entire code to the list. I'm sure > one of us could find any problems with boundary conditions, etc. > fairly quickly that way. I think you mentioned you were not using the > penalty method as in the examples. Is it possible you are not setting > the BC's correctly on the triangular elements? > > -John > > > Michael Povolotskyi writes: > > Dear Libmesh developers, > > with your help we are getting some progress. > > > > As you have suggested we tried linear elements (Tri3 and Quad4). > > In this case the countour lines look continuous everywhere. > > > > However, we still see some differences between Tri3 and Quad4 elements. > > The solution with Quad4 looks very nicely. > > > > The solution with Tri3 has some problems. > > Namely, there are several nodes that lie at the boundary with the boundary condition u = 0.0 whose > > value depends on the adaptive grid refinement. > > > > Without refinement the value is equal to 0.0, as it should be. > > Then we did 5 adaptive refinements and the values were: > > -0.004 1e-15 1e-15 1e-27 -0.001 . > > > > The futher refinements lead to a constant value at these nodes of about -0.002. > > > > The value of about 0.001 seems to be too much for the numerical error. > > > > Thank you very much, > > we hope that our feedback is usefull. > > > > Michael. > -- ------------------------------------------------------------ Michael Povolotskyi, Ph.D. University of Rome "Tor Vergata" Department of Electronic Engineering Viale Politecnico, 1 - 00133 Rome - Italy Phone + 39 06 72597367 Fax + 39 06 2020519 http://www.optolab.uniroma2.it/pages/moshe/moshe.html ------------------------------------------------------------- ```
 RE: [Libmesh-users] adaptive refinements with linear elements From: KIRK, BENJAMIN (JSC-EG) (NASA) - 2005-02-22 19:00:43 ```Imagine a refined edge in 2D normal to a Dirichlet-valued surface. The hanging node on this edge has its degrees of freedom constrained in terms of the two adjacent test/trial functions, one of which lives on the Dirichlet boundary. As such, the corresponding test function should be 0, but this is not imposed in any way by the DofMap. I think I'll hold off on any implementation until after the FE Rodeo in 2 weeks. It will be easier to hash through the details at a face-to-face meeting. I want to be sure that any changes will also work for the non-Lagrange case. Michael, can you use the penalty hack/fix for the time being? As for a reference, see "Computational Grids", G.F. Carey, Taylor & Francis, 1997. (specifically, pg. 211) Perhaps I can write something up more formally and include it in the documentation. -Ben -----Original Message----- From: Roy Stogner [mailto:roystgnr@...] Sent: Thursday, February 17, 2005 7:32 PM To: KIRK, BENJAMIN (JSC-EG) (NASA) Cc: libmesh-users@... Subject: RE: [Libmesh-users] adaptive refinements with linear elements On Thu, 17 Feb 2005, KIRK, BENJAMIN (JSC-EG) (NASA) wrote: > a non-refined element the refined elements degrees-of-freedom are > constrained in terms of the non-refined elements DOFs. What is > happening in this case is the refined elements matrix contributions > are being aliased back to the non-refined element (as well they > should). However, they never get constrained out as you would like > them to because of the element-by-element BC application process. Should that be happening in a 2D code with Lagrange elements? It seems like any constrained nodes in that case should be interior nodes. > I have envisioned another set of DOF constraints that basically impose > dirichlet values. I'll work on that over the weekend and hopefully > get you something to try next week. Would you describe the method you're implementing? I'd like something which could be generalized to non-Lagrange elements or fourth order problems if possible... of course, I don't know if that is possible at all, but maybe hearing your ideas would give me a few. --- Roy ```
 Re: [Libmesh-users] adaptive refinements with linear elements From: Michael Povolotskyi - 2005-02-23 12:50:01 ```Yes, the fix works for a linear equation we want to solve. For the moment we have some problems with nonlinear implementation so it is difficult to say if the fix will be ok also for a nonlinear case. Thank you for the reference. Michael. KIRK, BENJAMIN (JSC-EG) (NASA) wrote: > Imagine a refined edge in 2D normal to a Dirichlet-valued surface. The > hanging node on this edge has its degrees of freedom constrained in terms of > the two adjacent test/trial functions, one of which lives on the Dirichlet > boundary. As such, the corresponding test function should be 0, but this is > not imposed in any way by the DofMap. > > I think I'll hold off on any implementation until after the FE Rodeo in 2 > weeks. It will be easier to hash through the details at a face-to-face > meeting. I want to be sure that any changes will also work for the > non-Lagrange case. Michael, can you use the penalty hack/fix for the time > being? > > As for a reference, see > "Computational Grids", G.F. Carey, Taylor & Francis, 1997. (specifically, > pg. 211) > > Perhaps I can write something up more formally and include it in the > documentation. > > -Ben > > > > > > -----Original Message----- > From: Roy Stogner [mailto:roystgnr@...] > Sent: Thursday, February 17, 2005 7:32 PM > To: KIRK, BENJAMIN (JSC-EG) (NASA) > Cc: libmesh-users@... > Subject: RE: [Libmesh-users] adaptive refinements with linear elements > > > On Thu, 17 Feb 2005, KIRK, BENJAMIN (JSC-EG) (NASA) wrote: > > >>a non-refined element the refined elements degrees-of-freedom are >>constrained in terms of the non-refined elements DOFs. What is >>happening in this case is the refined elements matrix contributions >>are being aliased back to the non-refined element (as well they >>should). However, they never get constrained out as you would like >>them to because of the element-by-element BC application process. > > > Should that be happening in a 2D code with Lagrange elements? It seems like > any constrained nodes in that case should be interior nodes. > > >>I have envisioned another set of DOF constraints that basically impose >>dirichlet values. I'll work on that over the weekend and hopefully >>get you something to try next week. > > > Would you describe the method you're implementing? I'd like something which > could be generalized to non-Lagrange elements or fourth order problems if > possible... of course, I don't know if that is possible at all, but maybe > hearing your ideas would give me a few. > --- > Roy > -- ------------------------------------------------------------ Michael Povolotskyi, Ph.D. University of Rome "Tor Vergata" Department of Electronic Engineering Viale Politecnico, 1 - 00133 Rome - Italy Phone + 39 06 72597367 Fax + 39 06 2020519 http://www.optolab.uniroma2.it/pages/moshe/moshe.html ------------------------------------------------------------- ```
 RE: [Libmesh-users] adaptive refinements with linear elements From: Roy Stogner - 2005-02-18 01:32:27 ```On Thu, 17 Feb 2005, KIRK, BENJAMIN (JSC-EG) (NASA) wrote: > a non-refined element the refined elements degrees-of-freedom are > constrained in terms of the non-refined elements DOFs. What is happening in > this case is the refined elements matrix contributions are being aliased > back to the non-refined element (as well they should). However, they never > get constrained out as you would like them to because of the > element-by-element BC application process. Should that be happening in a 2D code with Lagrange elements? It seems like any constrained nodes in that case should be interior nodes. > I have envisioned another set of DOF constraints that basically impose > dirichlet values. I'll work on that over the weekend and hopefully get you > something to try next week. Would you describe the method you're implementing? I'd like something which could be generalized to non-Lagrange elements or fourth order problems if possible... of course, I don't know if that is possible at all, but maybe hearing your ideas would give me a few. --- Roy ```
 Re: [Libmesh-users] adaptive refinements with linear elements From: Michael Povolotskyi - 2005-02-18 16:36:15 ```Hello Ben, thank you for the hint. In fact, our final goal is to solve a non-linear Poisson equation. That's why we are interested in a "non-penalty" methods and we are looking forward to the new DOF constraints. We'd greatly appreciate if you give us a reference that explains the DOF constraints that are already implemented in Libmesh. Michael. KIRK, BENJAMIN (JSC-EG) (NASA) wrote: > I effectively re-implemented the penalty method in your code by changing > > Fe(i) += ... > Ke(i,j) += ... > > to > > Fe(i) += 1.e30*... > Ke(i,j) += 1.e30*... > > in the Dirichlet BC section, and everything worked out fine. > > The problem is that when you have an adaptively refined element neighboring > a non-refined element the refined elements degrees-of-freedom are > constrained in terms of the non-refined elements DOFs. What is happening in > this case is the refined elements matrix contributions are being aliased > back to the non-refined element (as well they should). However, they never > get constrained out as you would like them to because of the > element-by-element BC application process. > > By using the penalty approach you circumvent this issue because of some > quirks in floating-point arithmetic (1.e30 + 1.e0 = 1.e30). However, there > should be a more convenient way to impose boundary conditions without > resorting to this approach. > > I have envisioned another set of DOF constraints that basically impose > dirichlet values. I'll work on that over the weekend and hopefully get you > something to try next week. In the meantime I advocate the above approach. > > Thanks for pointing this out! > > -Ben > > > > > > -----Original Message----- > From: libmesh-users-admin@... > [mailto:libmesh-users-admin@...] On Behalf Of Michael > Povolotskyi > Sent: Thursday, February 17, 2005 9:31 AM > To: John Peterson > Cc: libmesh-users@... > Subject: Re: [Libmesh-users] adaptive refinements with linear elements > > > Hi, > this is the code (Poisson.C) and the input file (Poisson.in). > > As for the possibility to set BC in a wrong way ... of course, everything is > possible but it worked well with a single grid and with uniform grid > refinement. Michael. > > John Peterson wrote: > >>Hi, >> >>If possible, you should post your entire code to the list. I'm sure >>one of us could find any problems with boundary conditions, etc. >>fairly quickly that way. I think you mentioned you were not using the >>penalty method as in the examples. Is it possible you are not setting >>the BC's correctly on the triangular elements? >> >>-John >> >> >>Michael Povolotskyi writes: >> > Dear Libmesh developers, >> > with your help we are getting some progress. >> > >> > As you have suggested we tried linear elements (Tri3 and Quad4). >> > In this case the countour lines look continuous everywhere. >> > >> > However, we still see some differences between Tri3 and Quad4 elements. >> > The solution with Quad4 looks very nicely. >> > >> > The solution with Tri3 has some problems. >> > Namely, there are several nodes that lie at the boundary with the > > boundary condition u = 0.0 whose > >> > value depends on the adaptive grid refinement. >> > >> > Without refinement the value is equal to 0.0, as it should be. >> > Then we did 5 adaptive refinements and the values were: >> > -0.004 1e-15 1e-15 1e-27 -0.001 . >> > >> > The futher refinements lead to a constant value at these nodes of about > > -0.002. > >> > >> > The value of about 0.001 seems to be too much for the numerical error. >> > >> > Thank you very much, >> > we hope that our feedback is usefull. >> > >> > Michael. >> > > > -- ------------------------------------------------------------ Michael Povolotskyi, Ph.D. University of Rome "Tor Vergata" Department of Electronic Engineering Viale Politecnico, 1 - 00133 Rome - Italy Phone + 39 06 72597367 Fax + 39 06 2020519 http://www.optolab.uniroma2.it/pages/moshe/moshe.html ------------------------------------------------------------- ```