In example 40, the results are significantly different between the first-order and second-order finite element meshes

[ztdep...@gmail.com]

the adaptivited mesh are very diffent as shown in attachments.

[Wolfgang Bangerth]

On 11/6/23 03:12, ztdep...@gmail.com wrote:
> **

>
> the adaptivited mesh are very diffent as shown in attachments.

@ztdep:
We don't actually know what you are asking: Your post has no question. We also
don't know what it is you did: The post doesn't show how you modified step-40.
Finally, you do not say why you think that the result is wrong or surprising:
You just show a picture, but for all we know this may be correct.

Please spend a bit of thought in formulating questions in such a way that it
is clear what you are asking, why you are asking it, and what is behind the
question you are asking.

Best
W.

--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/

[ztdepyahoo]

The default setting is  'fe(2)" , we can clearly see a refined region in  the resulting mesh. While after i changed it to "fe(1)", we cann't see this region. 

This is what i wnat to know .

	ztdepyahoo
ztdep...@gmail.com

---- Replied Message ----

From	Wolfgang Bangerth<bang...@colostate.edu>
Date	11/7/2023 02:59
To	<dea...@googlegroups.com>
Subject	Re: [deal.II] In example 40, the results are significantly different between the first-order and second-order finite element meshes

--
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 a topic in the Google Groups "deal.II User Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dealii/VcsXMXhl_YQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dealii+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/e17928b7-f1d0-e5f2-83b9-872ba95e492a%40colostate.edu.

[blais...@gmail.com]

Changing to Fe1 really alters the solution, so consequently the kelly error estimator will also give you a different error estimation and thus a different mesh adaptation.

If your mesh adaptation is based on an error estimator, altering the finite element interpolation order will alter the solution and thus alter the mesh adaptation process.

[Abbas Ballout]

ztdep,
You got me curious 

You can output the results of the Kelly error estimate with something like this in the data output: 

    Vector<float> estimated_error_per_cell(triangulation.n_active_cells());
    KellyErrorEstimator<dim>::estimate(
        dof_handler,
        QGauss<dim - 1>(fe.degree + 1),
        std::map<types::boundary_id, const Function<dim> *>(),
        locally_relevant_solution,
        estimated_error_per_cell);
    data_out.add_data_vector(estimated_error_per_cell, "kelly");

and you'll see that the estimate is horrible with fe(1). Why? because the estimate is based on the jump of the gradients across cells and fe(1) isn't cutting it 
So if you output the gradient with:

    GradientPostprocessor<dim> gradient_postprocessor;
    data_out.add_data_vector(locally_relevant_solution, gradient_postprocessor);
(copy paste the postprocessor from https://www.dealii.org/current/doxygen/deal.II/classDataPostprocessorVector.html) 

You can see in Paraview that the gradient doesn't look continuous/clean across elements when you use fe(1). 
So this isn't weird and unexpected. 

Apparently the gradient approx with bi-linear fe(1) is bad? 

The only way would be for me to be 100% sure would be to write these terms down and check for myself. 
If you do it let me know.