You can subscribe to this list here.
2003 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}
(2) 
_{Oct}
(2) 
_{Nov}
(27) 
_{Dec}
(31) 

2004 
_{Jan}
(6) 
_{Feb}
(15) 
_{Mar}
(33) 
_{Apr}
(10) 
_{May}
(46) 
_{Jun}
(11) 
_{Jul}
(21) 
_{Aug}
(15) 
_{Sep}
(13) 
_{Oct}
(23) 
_{Nov}
(1) 
_{Dec}
(8) 
2005 
_{Jan}
(27) 
_{Feb}
(57) 
_{Mar}
(86) 
_{Apr}
(23) 
_{May}
(37) 
_{Jun}
(34) 
_{Jul}
(24) 
_{Aug}
(17) 
_{Sep}
(50) 
_{Oct}
(24) 
_{Nov}
(10) 
_{Dec}
(60) 
2006 
_{Jan}
(47) 
_{Feb}
(46) 
_{Mar}
(127) 
_{Apr}
(19) 
_{May}
(26) 
_{Jun}
(62) 
_{Jul}
(47) 
_{Aug}
(51) 
_{Sep}
(61) 
_{Oct}
(42) 
_{Nov}
(50) 
_{Dec}
(33) 
2007 
_{Jan}
(60) 
_{Feb}
(55) 
_{Mar}
(77) 
_{Apr}
(102) 
_{May}
(82) 
_{Jun}
(102) 
_{Jul}
(169) 
_{Aug}
(117) 
_{Sep}
(80) 
_{Oct}
(37) 
_{Nov}
(51) 
_{Dec}
(43) 
2008 
_{Jan}
(71) 
_{Feb}
(94) 
_{Mar}
(98) 
_{Apr}
(125) 
_{May}
(54) 
_{Jun}
(119) 
_{Jul}
(60) 
_{Aug}
(111) 
_{Sep}
(118) 
_{Oct}
(125) 
_{Nov}
(119) 
_{Dec}
(94) 
2009 
_{Jan}
(109) 
_{Feb}
(38) 
_{Mar}
(93) 
_{Apr}
(88) 
_{May}
(29) 
_{Jun}
(57) 
_{Jul}
(53) 
_{Aug}
(48) 
_{Sep}
(68) 
_{Oct}
(151) 
_{Nov}
(23) 
_{Dec}
(35) 
2010 
_{Jan}
(84) 
_{Feb}
(60) 
_{Mar}
(184) 
_{Apr}
(112) 
_{May}
(60) 
_{Jun}
(90) 
_{Jul}
(23) 
_{Aug}
(70) 
_{Sep}
(119) 
_{Oct}
(27) 
_{Nov}
(47) 
_{Dec}
(54) 
2011 
_{Jan}
(22) 
_{Feb}
(19) 
_{Mar}
(92) 
_{Apr}
(93) 
_{May}
(35) 
_{Jun}
(91) 
_{Jul}
(32) 
_{Aug}
(61) 
_{Sep}
(7) 
_{Oct}
(69) 
_{Nov}
(81) 
_{Dec}
(23) 
2012 
_{Jan}
(64) 
_{Feb}
(95) 
_{Mar}
(35) 
_{Apr}
(36) 
_{May}
(63) 
_{Jun}
(98) 
_{Jul}
(70) 
_{Aug}
(171) 
_{Sep}
(149) 
_{Oct}
(64) 
_{Nov}
(67) 
_{Dec}
(126) 
2013 
_{Jan}
(108) 
_{Feb}
(104) 
_{Mar}
(171) 
_{Apr}
(133) 
_{May}
(108) 
_{Jun}
(100) 
_{Jul}
(93) 
_{Aug}
(126) 
_{Sep}
(74) 
_{Oct}
(59) 
_{Nov}
(145) 
_{Dec}
(93) 
2014 
_{Jan}
(38) 
_{Feb}
(45) 
_{Mar}
(26) 
_{Apr}
(41) 
_{May}
(125) 
_{Jun}
(70) 
_{Jul}
(61) 
_{Aug}
(66) 
_{Sep}
(60) 
_{Oct}
(110) 
_{Nov}
(27) 
_{Dec}
(30) 
2015 
_{Jan}
(43) 
_{Feb}
(67) 
_{Mar}
(71) 
_{Apr}
(92) 
_{May}
(39) 
_{Jun}
(15) 
_{Jul}
(46) 
_{Aug}
(63) 
_{Sep}
(84) 
_{Oct}
(82) 
_{Nov}
(69) 
_{Dec}
(45) 
2016 
_{Jan}
(92) 
_{Feb}
(91) 
_{Mar}
(148) 
_{Apr}
(43) 
_{May}
(58) 
_{Jun}
(117) 
_{Jul}
(92) 
_{Aug}
(140) 
_{Sep}
(36) 
_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 



1
(6) 
2
(2) 
3
(1) 
4
(2) 
5

6

7
(3) 
8
(2) 
9
(2) 
10

11
(2) 
12

13

14
(7) 
15
(5) 
16
(1) 
17
(8) 
18
(2) 
19

20

21

22
(5) 
23
(5) 
24
(3) 
25
(1) 
26

27

28






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: Michael Povolotskyi <povolotskyi@in...>  20050217 18:00:40

Hello, the situation gets clearer. I have just checked the matrix. It turnes that: a) if I don't call dof_map.constrain_element_matrix_and_vector(), then the matrix comes out as I intend; b) if I call dof_map.constrain_element_matrix_and_vector(), then the corresponding raw has additional elements. In case a) the boundary nodes are okay, but the solution is discontinuous. In case b) the solution is continuous, but the boundary conditions are disturbed. The question is: is it possible somehow to have both continuous solution and apply boundary conditions in our way (not with a penalty method)? Thank you for your help, Michael. Roy Stogner wrote: > On Thu, 17 Feb 2005, Michael Povolotskyi wrote: > >> we set boundary condition in such a way that a row in the matrix that >> correspond to >> the boundary node i looks like this: >> >> 0 .... 0 1 0 .... 0, >> >> where 1 stands at the ith position. >> >> We apply the boundary condition while assembling the matrix. >> Not all the Dirichlet boundary points are wrong  just a few. >> And not always the same. > > > Have you checked the assembled system matrix, to make sure those rows > came out the way you intended? Have you checked the solution vector, > to make sure the Dirichlet node errors are there and not just another > GMVrelated glitch? Are you sure the nodes end up exactly right with > uniform refinement? >  > Roy Stogner >   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: Michael Povolotskyi <povolotskyi@in...>  20050217 15:41:18

Hi, we set boundary condition in such a way that a row in the matrix that correspond to the boundary node i looks like this: 0 .... 0 1 0 .... 0, where 1 stands at the ith position. We apply the boundary condition while assembling the matrix. Not all the Dirichlet boundary points are wrong  just a few. And not always the same. Michael. Roy Stogner wrote: > On Thu, 17 Feb 2005, Michael Povolotskyi wrote: > >> 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. > > > How are you setting the boundary conditions? Are you reinforcing them > at every solve? Are all your Dirichlet boundary nodes wrong, and if > so are they wrong in the same direction? >  > Roy Stogner >   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: Michael Povolotskyi <povolotskyi@in...>  20050217 15:32:02

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: Roy Stogner <roystgnr@ic...>  20050217 15:21:46

On Thu, 17 Feb 2005, Michael Povolotskyi wrote: > 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. How are you setting the boundary conditions? Are you reinforcing them at every solve? Are all your Dirichlet boundary nodes wrong, and if so are they wrong in the same direction?  Roy Stogner 
From: John Peterson <peterson@cf...>  20050217 14:47:02

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. 
From: Michael Povolotskyi <povolotskyi@in...>  20050217 11:21:29

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. 
From: KIRK, BENJAMIN (JSCEG) (NASA) <benjamin.kirk1@na...>  20050217 02:33:49

I will look through this in detail as soon as I can. We are in the middle of a simulated mission right now, so I can't even breathe until Friday. Sorry, but I'm sure we can straighten this out in relatively short order. Ben Original Message From: Michael Povolotskyi [mailto:povolotskyi@...] Sent: Wednesday, February 16, 2005 11:18 AM To: KIRK, BENJAMIN (JSCEG) (NASA) Cc: 'Roy Stogner'; libmeshusers@... Subject: Re: [Libmeshusers] hanging nodes and triangular elements Today we performed a set of tests in order to understand where the problem is (if any). We are solving the equation \nabla^2 u = exp((x^2 + y^2)) on a square 1.0<= x <= 1.0, 1.0<= y <= 1.0 The boundary conditions are as follows: u = 1.0 if 1.0<=x<=0.8, y = 1.0 u = 1.0 if 0.8<=x<=1.0, y = 1.0 u = 0.0 if 0.4<=x<=0.4, y = 1.0 For the rest of the boundary we assume natural boundary conditions (von Neumann). In order to implement the Dirichlet boundary conditions we DON'T use the penalty function method shown in the examples. Instead we assign boundary values to the nodes that lie on the boundary. We found that the code produces a reasonable solution if: a) there is no mesh refinement; b) if there is uniform mesh refinement; We have tested both triangular and rectangular finite elements, both first and second approximation order. The "problems" start to appear when we use the adaptive mesh refinement. Detailed study shows that the same problems occur BOTH with triangular and rectangular elements (in contrast to what I informed yesterday). We send a solution visualised by GMV program in files example_fullview.pdf and example_magnified.pdf. One can see in Fig. example_magnified.pdf that the solution at some points (indicated by red circles) is not continuous. We tried different solvers. The solution changes very slightly, but the problem persists. In order to be more specific we attach our code (Poisson.C) and the input file Poisson.in that the program reads. We don't understand if we are using libmesh in a wrong way or if there is a problem in libmesh itself. Thank you for your time, Michael. KIRK, BENJAMIN (JSCEG) (NASA) wrote: > Are you using CG as the iterative solver? I just realized that the > constraints are inserted into the system matrix in such a way that the > solution vector automatically satisfies the constraints, but this is > not symmetric. > > Try running your problem when CG and then with GMRES or BiCG. If the > latter two work then the aforementioned problem is probably the source > of your difficulty. Let me know & I'll get a patch together. > > Ben > > > > Original Message > From: libmeshusersadmin@... > [mailto:libmeshusersadmin@...] On Behalf Of Roy > Stogner > Sent: Tuesday, February 15, 2005 12:18 PM > To: Michael Povolotskyi > Cc: libmeshusers@... > Subject: Re: [Libmeshusers] hanging nodes and triangular elements > > > On Tue, 15 Feb 2005, Michael Povolotskyi wrote: > > >>Yes, the code works correctly with uniformly refined triangular >>elements. >> >>Could you, please, tell how can I check if the nodes are in a correct >>order? > > > If you're getting good results with uniform refinement, there's likely > nothing wrong with your coarse mesh  the distorted triangle problem > was just the only thing I'd ever seen that would give you problems > with a triangular mesh but not a quadrilateral mesh. > > Could you specify exactly what problems you're getting with adaptive > triangles that you aren't seeing with uniform triangles or adaptive > quads? Is it a bad convergence rate, a crash, or something else? >  > Roy Stogner > > >  > SF email is sponsored by  The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. Discover which products truly live up to the hype. Start > reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Libmeshusers mailing list Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers >   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  