Dear all,

I have an important update on the situation.

I ran step-22 with Q2^d-Q1 and Q3^d-Q2, and I observed the same behavior. 
Additionally, I found that in my code, even when using Q2, these jumps also 
appear, though on a smaller scale and in fewer locations.

This brings me to an updated question:

   - Is this behavior not significantly affecting the result, and is there 
   any way to improve it?

If this jump is negligible ( or if it is only a visualizing issue), does 
anyone have any suggestions on where else the issue might lie? The relative 
errors remain small, but we lose convergence during refinement when using 
Q3. 
>>> I understand that it is hard to tell without seeing the code, but this 
question fell into this place after noticing that the jump is not only in 
my situation.

*Notes*:

   - For refinement, I am using a fixed fraction of 0.3 for refinement and 
   0.0 for coarsening. I tried different ratios as well.
   - I have tried solving using FGMRES with different preconditioners (MG 
   and/or ILU), and the error convergence remains the same, with the jumps 
   still present in the solution plot. The relative error is consistent across 
   different solvers.
   - I have correctly applied hanging node constraints at the appropriate 
   stages (DoF setup, after system assembly, and after solving).
   - This code should solve for 4 unknowns, 3 of which are vector values, 
   and uses two independent meshes coupled with exact intersection calculation.

If those notes would help anyhow. Thank you all for your support.

Best,
Najwa

On Saturday, September 14, 2024 at 5:55:10 PM UTC+3 Najwa Alshehri wrote:

> Dear developers and users,
>
> I am currently working on a problem involving the coupling of multiple 
> physics. Theoretically, I have shown that a new family of finite element 
> methods is stable for k>= 1. In the case of k = 1, the velocity is 
> approximated by a Q2 finite element [while there are other solutions, I’m 
> focusing here on the velocity for simplicity]. This method should exhibit 
> order "k" convergence,  with adaptive refinement.
>
> The code performs as expected for k=1, both with uniform and adaptive 
> refinement (using an a posteriori error estimator that is theoretically 
> reliable and efficient). However, when moving to k = 2, adaptive 
> refinement does not produce the expected results. I have attached a 
> comparison of the convergence rates between k= 1 (Q2) and k = 2 (Q3). 
> Specifically, while Q2 converges with an H1 norm O(h), I expected Q3 to 
> converge with an H1 norm O(h^2), but the actual result isn’t even 
> proportional to h. Initially, it performs well, but after a few cycles, the 
> issue arises and we lose convergence. (see r
> ate_of_convergance_adp_Q2_Q3.pdf)
>
> *Upon further inspection,* I found that for k=1 (Q2), the solution (see 
> attached plot of one velocity component) is continuous across the domain 
> ( see Velocity-Q2.png). However, for k = 2 (Q3), discontinuities (jumps) 
> appear at certain hanging nodes ( see Velocity-Q2.png and 
> Velocity-Q3_zoomin.png).
>
> Has anyone encountered this issue before? Could this be related to the 
> handling of *hanging node constraints*? Even though I suspect that since 
> hanging node I believe built to handle higher order finite elements.
>
> Or is it only an issue with the *visualization* of higher-order elements? 
> (Note, I did not use GridOut with higher-order mapping in the output.)
>
> I would appreciate any suggestions on how to resolve this issue. 
>
> Best regards,
> Najwa
>

-- 
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/5ae80ecc-b4a2-4d01-a585-3ce2bbb1c83an%40googlegroups.com.

Reply via email to