Hi Phillip, Yes, the formulation we're using indeed has a factor of the form $\eta/h_F^q$, where $q$ is an integer.
Since we have a fourth order equation, (rather) loosely speaking our solution is expected to be in $H^2$, so we have penalty terms involving jumps in both the solution and the gradient of the solution across faces. >From dimensional considerations, one can see that we need $q = 3$ for the terms involving jumps of the solution, while $q = 1$ for terms involving jumps of the solution gradient. I spent many, many hours trying to ensure that the correct $h_F$ was being used upon anisotropic (local) refinement, but it turns out deal.II indeed handles it correctly...it's simply that $\eta$ matters a lot too. =D Best regards, -Sean On Wednesday, August 28, 2024 at 6:37:29 AM UTC-4 [email protected] wrote: > Good to know it works now! > Out of curiosity: > Does the penalization in your jump terms include the edge size? > The formulation of SIP for Poisson that I know has a factor of $\eta/h_F$ > with $\eta$ being the penalty parameter. > Consequently, smaller edges are penalized more which could be worth trying. > Best, > Philipp > On Tuesday, August 27, 2024 at 11:06:15 PM UTC+2 Sean Carney wrote: > >> Wolfgang, >> >> My apologies for the delayed response to your helpful suggestions. I have >> been in the process of moving this last week, and only >> now am I finding some time to come back to my 4th order interface >> problem. :-) >> >> >> But if the element is discontinuous, how do you enforce that the solution >> "should not be discontinuous"? >> >> >> I suppose this is a rhetorical question, but, to be clear, continuity of >> the solution is of course enforced weakly by incorporating >> into the bilinear form terms that penalize jumps in the solution across >> quadrilateral edges. >> >> >> >> The only suggestion I have is to double-check that all lifting or >> stabilization terms you have use a stabilization factor that is large >> enough >> for the small edge size you have on the refined side, not just for the >> large edge. >> >> >> In the end, it turns out that the penalty parameter (that is weakly >> enforcing continuity of the discrete solution) was simply not large >> enough. >> >> This is a little embarrassing to admit, but alas, it is indeed the case. >> This outcome of course does not preclude the existence of >> bugs in the code, but at least it's another piece of evidence that the >> method is implemented properly. It just needs to be used properly. =D >> >> Actually, I did play around with the value of the parameter; for example, >> I tried setting it equal to e.g. $p(p+1)$, as in Step 47, I tried >> setting it equal to 10, as it is in a numerical example described in the >> literature, but cranking up the penalty parameter to 50, for example, >> was sufficient to observe results consistent with what we would expect >> from theory. >> >> Of course, the ambiguity that comes with introducing a penalty parameter >> is a standard "complaint" one might expect from working >> with an interior penalty method. I guess this experience shows there are >> some merit to these complaints. >> >> Anyhow, if it can help anyone in the future that wants to implement an >> adaptive mesh refinement with an interior penalty method: >> please don't be afraid to liberally experiment with the numerical value >> of one's penalty parameter. >> >> Best regards, >> -Sean >> >> >> > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/c3e1fa7b-a42a-40aa-a6b7-85c254b941bdn%40googlegroups.com.
