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}
(22) 
S  M  T  W  T  F  S 

1

2

3
(2) 
4
(3) 
5
(3) 
6
(2) 
7

8
(1) 
9
(3) 
10
(3) 
11
(1) 
12
(2) 
13
(1) 
14

15

16
(1) 
17
(5) 
18
(1) 
19

20

21

22

23
(2) 
24
(1) 
25

26
(2) 
27

28
(2) 
29

30
(1) 
31
(6) 




From: Roy Stogner <roystgnr@ic...>  20061010 15:31:47

On Tue, 10 Oct 2006, Karl Tomlinson wrote: > Roy Stogner writes: > >> On Mon, 9 Oct 2006, Karl Tomlinson wrote: >> >>> The situation seems different, however, if the degrees of freedom >>> that influence the values on the Dirichlet boundary are not >>> completely constrained by the boundary conditions. >> >> This is actually the case for some of the problems I've run. When >> using CloughTocher elements for second order problems, for example, >> in general it's only weighted sums of nodal gradient degrees of >> freedom that are constrained, but applying the penalty method on edge >> integrals still works fine. > > I'm pleased it still works fine. What size coefficient do you > use for the penalty term (and are the other terms of unit > magnitude)? Or does this not seem to matter much? It does matter, and I wish I had a better understanding of exactly how it matters. Make epsilon too large (e.g. 1e5), and your convergence soon bottoms out as approximation error is swamped by boundary error. Make epsilon too small (e.g. 1e15), and your convergence soon bottoms out as approximation error is swamped by floating point error. I generally set epsilon to 1e10 and cross my fingers. > How should the penalty parameter depend on mesh size? Good question. Obviously to get anything like a consistent formulation in exact arithmetic you probably need to decrease epsilon with h, and to avoid eventually overwhelming your finite element error you probably need some rate like h^{p+1}. But, in practice it seems like there's nothing wrong with using small epsilons on coarse meshes, and if you make epsilon too small on fine meshes then floating point error kills your solution. >> Is there a typo in this paper? In the first term of equation 5, I >> would expect there to be a 1 in the numerator rather than an epsilon. > > I'm seeing a 1 in the numerator of the first term after the > summation sign and I think this is right. The equation seems to > behave appropriately in the limits of Remarks 24. I'm sorry, I meant to say the first term on the second line of equation 5... but on second glance that doesn't look like an obvious mistake either. I must have confused my q's and g's. >> Lemma 3 gives an upper bound, and equations 1415 suggest >> (perhaps misleadingly) that setting gamma too low will increase >> the final error. > > Looking at Remarks 57 in this paper and comparing Equation 32 in > http://math.tkk.fi/~rstenber/Publications/BeckerHansboStenberg.pdf, > I'm guessing that the gamma in equation 15 is a typo and should > not be there. (Warning: the gammas in the two papers seem to be > reciprocals.) > > This second paper goes into more detail on the bound for linear > elements but I haven't worked out why the bound seems to differ by > a factor of 4. I haven't read through the second paper yet; I'll see if I can figure it out today.  Roy 
From: Karl Tomlinson <k.tomlinson@au...>  20061010 10:09:47

Roy Stogner writes: > On Mon, 9 Oct 2006, Karl Tomlinson wrote: > >> The situation seems different, however, if the degrees of freedom >> that influence the values on the Dirichlet boundary are not >> completely constrained by the boundary conditions. > > This is actually the case for some of the problems I've run. When > using CloughTocher elements for second order problems, for example, > in general it's only weighted sums of nodal gradient degrees of > freedom that are constrained, but applying the penalty method on edge > integrals still works fine. I'm pleased it still works fine. What size coefficient do you use for the penalty term (and are the other terms of unit magnitude)? Or does this not seem to matter much? >> However, if the boundary data projections don't completely >> constrain the associated degrees of freedom, > > Could you give a concerete example where this wouldn't occur? I think the case you describe above is an example of what I am trying to describe. If I understand correctly the values of the solution on the Dirichlet boundaries are affected by nodal gradient degrees of freedom, but these degrees of freedom represent x and y derivatives. If the boundary does not run exactly in either the x or y direction, then a linear combination of these derivatives affects the value on the boundary. The ((ug),v) integral therefore depends on this linear combination and contributes to equations corresponding to both derivatives but the contributions are linearly dependent. > I don't see even in theory how adding a heavily weighted > ((ug),v) integral on the Dirichlet boundary edges wouldn't > suffice, assuming that you're happy with solving the problem > with Robin boundary conditions rather than Dirichlet. This integral certainly does suffice to ensure that the Robin boundary condition is satisfied. And mathematically (with infinite precision arithmetic) the problem is well constrained. What I'm concerned about is that if the weight is so heavy that the Robin condition is almost a Dirichlet condition, then does it introduce too much numerical error into the conservation equations for the domain? In the example above, the ((ug),v) integral half defines the x and y derivatives (so that the boundary condition is satisfied). In order to satisfy the domain conservation equation, the (grad(u),grad(v)) integrals (or similar) provides the other half of the definition of the x and y derivatives, and some of this information must be obtained from equations that may have been almost swamped by the ((ug),v) term. Perhaps if the penalty weight is chosen appropriately, there is still enough precision. e.g. If the weight is 1e6 (epsilon is 1e6) then this might be good enough to ensure that the Robin condition is effectively a Dirichlet condition (to about 6 significant figures). It would remove about 6 figures of accuracy from the terms in the domain equations but there would still be about 10 significant figures. But I feel this may be an oversimplification. How should the penalty parameter depend on mesh size? It seems that the ratio of magnitudes of the boundary integrals to the domain integrals (of derivatives) is of order h to 1. So the boundary weight should be proportional to 1/h (epsilon to h). I think this is good though as the Robin boundary condition becomes more Dirichlet like as the mesh is refined. > Is there a typo in this paper? In the first term of equation 5, I > would expect there to be a 1 in the numerator rather than an epsilon. I'm seeing a 1 in the numerator of the first term after the summation sign and I think this is right. The equation seems to behave appropriately in the limits of Remarks 24. > > How do you choose gamma in practice? I don't know. I only learned of this Nitsche method as I was trying to understand the penalty method better. I'm actually used to applying Dirichlet boundary conditions by removing degrees of freedom from the system of equations as discussed earlier in this thread. For Lagrange and our Hermite elements we usually know which degrees of freedom are involved. > Lemma 3 gives an upper bound, and equations 1415 suggest > (perhaps misleadingly) that setting gamma too low will increase > the final error. Looking at Remarks 57 in this paper and comparing Equation 32 in http://math.tkk.fi/~rstenber/Publications/BeckerHansboStenberg.pdf, I'm guessing that the gamma in equation 15 is a typo and should not be there. (Warning: the gammas in the two papers seem to be reciprocals.) This second paper goes into more detail on the bound for linear elements but I haven't worked out why the bound seems to differ by a factor of 4. 
From: Mail Delivery System <MailerD<aemon@li...>  20061010 01:16:07

This message was created automatically by mail delivery software. A message that you sent has not yet been delivered to one or more of its recipients after more than 24 hours on the queue on externalmx1.sourceforge.net. The message identifier is: 1GWhbW0000e8IU The date of the message is: Sun, 08 Oct 2006 14:06:00 0200 The subject of the message is: force the Far section. The address to which the message has not yet been delivered is: libmeshusers@... Delay reason: SMTP error from remote mailer after RCPT TO:<libmeshusers@...>: host mail.sourceforge.net [66.35.250.206]: 451Could not complete sender verify callout 451Could not complete sender verify callout for 451<libmeshusers@...>. 451The mail server(s) for the domain may be temporarily unreachable, or 451they may be permanently unreachable from this server. In the latter case, 451you need to change the address or create an MX record for its domain 451if it is suppos No action is required on your part. Delivery attempts will continue for some time, and this warning may be repeated at intervals if the message remains undelivered. Eventually the mail delivery software will give up, and when that happens, the message will be returned to you. 