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.
Close
From: Roy Stogner <roystgnr@ic...>  20050218 01:32:27

On Thu, 17 Feb 2005, KIRK, BENJAMIN (JSCEG) (NASA) wrote: > a nonrefined element the refined elements degreesoffreedom are > constrained in terms of the nonrefined elements DOFs. What is happening in > this case is the refined elements matrix contributions are being aliased > back to the nonrefined element (as well they should). However, they never > get constrained out as you would like them to because of the > elementbyelement 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 nonLagrange 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 
From: KIRK, BENJAMIN (JSCEG) (NASA) <benjamin.kirk1@na...>  20050217 23:09:00

I effectively reimplemented 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 nonrefined element the refined elements degreesoffreedom are constrained in terms of the nonrefined elements DOFs. What is happening in this case is the refined elements matrix contributions are being aliased back to the nonrefined element (as well they should). However, they never get constrained out as you would like them to because of the elementbyelement BC application process. By using the penalty approach you circumvent this issue because of some quirks in floatingpoint 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: libmeshusersadmin@... [mailto:libmeshusersadmin@...] On Behalf Of Michael Povolotskyi Sent: Thursday, February 17, 2005 9:31 AM To: John Peterson Cc: libmeshusers@... Subject: Re: [Libmeshusers] 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 1e15 1e15 1e27 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  
From: KIRK, BENJAMIN (JSCEG) (NASA) <benjamin.kirk1@na...>  20050222 19:00:43

Imagine a refined edge in 2D normal to a Dirichletvalued 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 facetoface meeting. I want to be sure that any changes will also work for the nonLagrange 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 (JSCEG) (NASA) Cc: libmeshusers@... Subject: RE: [Libmeshusers] adaptive refinements with linear elements On Thu, 17 Feb 2005, KIRK, BENJAMIN (JSCEG) (NASA) wrote: > a nonrefined element the refined elements degreesoffreedom are > constrained in terms of the nonrefined elements DOFs. What is > happening in this case is the refined elements matrix contributions > are being aliased back to the nonrefined element (as well they > should). However, they never get constrained out as you would like > them to because of the elementbyelement 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 nonLagrange 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 
From: Michael Povolotskyi <povolotskyi@in...>  20050223 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 (JSCEG) (NASA) wrote: > Imagine a refined edge in 2D normal to a Dirichletvalued 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 facetoface > meeting. I want to be sure that any changes will also work for the > nonLagrange 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 (JSCEG) (NASA) > Cc: libmeshusers@... > Subject: RE: [Libmeshusers] adaptive refinements with linear elements > > > On Thu, 17 Feb 2005, KIRK, BENJAMIN (JSCEG) (NASA) wrote: > > >>a nonrefined element the refined elements degreesoffreedom are >>constrained in terms of the nonrefined elements DOFs. What is >>happening in this case is the refined elements matrix contributions >>are being aliased back to the nonrefined element (as well they >>should). However, they never get constrained out as you would like >>them to because of the elementbyelement 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 nonLagrange 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  
From: Roy Stogner <roystgnr@ic...>  20050218 01:32:27

On Thu, 17 Feb 2005, KIRK, BENJAMIN (JSCEG) (NASA) wrote: > a nonrefined element the refined elements degreesoffreedom are > constrained in terms of the nonrefined elements DOFs. What is happening in > this case is the refined elements matrix contributions are being aliased > back to the nonrefined element (as well they should). However, they never > get constrained out as you would like them to because of the > elementbyelement 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 nonLagrange 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 
From: Michael Povolotskyi <povolotskyi@in...>  20050218 16:36:15

Hello Ben, thank you for the hint. In fact, our final goal is to solve a nonlinear Poisson equation. That's why we are interested in a "nonpenalty" 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 (JSCEG) (NASA) wrote: > I effectively reimplemented 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 nonrefined element the refined elements degreesoffreedom are > constrained in terms of the nonrefined elements DOFs. What is happening in > this case is the refined elements matrix contributions are being aliased > back to the nonrefined element (as well they should). However, they never > get constrained out as you would like them to because of the > elementbyelement BC application process. > > By using the penalty approach you circumvent this issue because of some > quirks in floatingpoint 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: libmeshusersadmin@... > [mailto:libmeshusersadmin@...] On Behalf Of Michael > Povolotskyi > Sent: Thursday, February 17, 2005 9:31 AM > To: John Peterson > Cc: libmeshusers@... > Subject: Re: [Libmeshusers] 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 1e15 1e15 1e27 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  