NedelecSZ with adaptive mesh refinement

[Daniel Garcia-Sanchez]

Hi,

I read in the documentation that the NedelecSZ element does not support non-conforming meshes at this time.

That means that I can not do adaptive mesh refinement with NedelecSZ?

If that is the case, I would be happy to contribute and make this element compatible with adaptive mesh refinement.

Could you indicate me what is left and which is the direction I should take to add adaptive mesh refinement to NedelecSZ?

I understand that I have to add the capability to treat hanging nodes to the class, suggestions/indications are welcome :)

Thanks!

Dani

[Bruno Turcksin]

Dani,

On Tuesday, June 25, 2019 at 12:52:09 PM UTC-4, Daniel Garcia-Sanchez wrote:

That means that I can not do adaptive mesh refinement with NedelecSZ?

That's correct.

If that is the case, I would be happy to contribute and make this element compatible with adaptive mesh refinement.

Could you indicate me what is left and which is the direction I should take to add adaptive mesh refinement to NedelecSZ?

This post briefly discuss the problem. Apparently it is non-trivial but I can't really comment on it (I've never used Nedelec element)

Best,

Bruno

[Daniel Garcia-Sanchez]

Bruno,

On Tuesday, June 25, 2019 at 7:04:07 PM UTC+2, Bruno Turcksin wrote:

This post briefly discuss the problem. Apparently it is non-trivial but I can't really comment on it (I've never used Nedelec element)

Thanks for the reference. Yes, it seems that this is a non-trivial problem. Although from what I understand from the post.

• The new FE_NedelecSZ element can be used with complex meshes, but can not be refined
• The old FE_Nedelec element can only be used with a simple grid but it can be refined.

According to Alexander Grayver, deal.II interface does not permit dynamic constraints (that is, constraints, which depend on a cell orientation). This problem does not seem easy to solve.

Best,

Daniel

[Bruno Turcksin]

Daniel

Le mar. 25 juin 2019 à 13:55, Daniel Garcia-Sanchez
<danielga...@gmail.com> a écrit :

> Thanks for the reference. Yes, it seems that this is a non-trivial problem. Although from what I understand from the post.
>
> The new FE_NedelecSZ element can be used with complex meshes, but can not be refined
> The old FE_Nedelec element can only be used with a simple grid but it can be refined.

Yes, that's correct. The old Nedelec can be refined but I would trust
it only if you have rectangles/regular hex .

Best,

Bruno

[Daniel Garcia-Sanchez]

Bruno,

On Tuesday, June 25, 2019 at 8:06:09 PM UTC+2, Bruno Turcksin wrote:

Yes, that's correct. The old Nedelec can be refined but I would trust
it only if you have rectangles/regular hex .

In that case, I think that the old FE_Nedelec should be good for my application.

Best,

Daniel

 

[Wolfgang Bangerth]

On 6/25/19 11:55 AM, Daniel Garcia-Sanchez wrote:
> According to Alexander Grayver, deal.II interface does not permit dynamic
> constraints (that is, constraints, which depend on a cell orientation). This
> problem does not seem easy to solve.

That's only partly true. The DoFTools::make_hanging_node_constraints() class,
and the interface it uses to the FiniteElement class, can not deal with such
constraints. It assumes that the constraints have the same form on each cell
with a hanging node.

But one doesn't have to go through this function. One could just as well write
a function that is specific to the FE_NedelecSZ element and that computes
these kinds of constraints and puts them into AffineConstraints. I've done
that for other elements before, though I'm not sure there is an example in
deal.II itself. I'd be happy to provide my code as an example, though.

Best
W.

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

[Alexander]

Wolfgang,

indeed, this should be possible to do it that way. Would you mind putting an example to the mentioned github issue? I might give it a thought in the background if I see more details.

Best

Alexander

[Daniel Garcia-Sanchez]

Hi Wolfang,

On Tuesday, June 25, 2019 at 9:49:15 PM UTC+2, Wolfgang Bangerth wrote:

But one doesn't have to go through this function. One could just as well write
a function that is specific to the FE_NedelecSZ element and that computes
these kinds of constraints and puts them into AffineConstraints. I've done
that for other elements before, though I'm not sure there is an example in
deal.II itself. I'd be happy to provide my code as an example, though.

It would be great if you can provide your code :) You can post it or email it

Alexader,

On Wednesday, June 26, 2019 at 11:59:24 AM UTC+2, Alexander wrote:

indeed, this should be possible to do it that way. Would you mind putting an example to the mentioned github issue? I might give it a thought in the background if I see more details. 

 

Let me know if your are going to take care of this or need help!

If you take care of this that would be great otherwise I can give it try

Best,

Daniel

[Alexander]

Hi Daniel,

 

Let me know if your are going to take care of this or need help!

If you take care of this that would be great otherwise I can give it try

Please feel free to take a leading role here. I'm happy to help and look at your code, but I won't be able to lead this myself in the next months (I have to write funding proposals...)

Best

Alexander

[Wolfgang Bangerth]

On 6/26/19 3:59 AM, Alexander wrote:
> indeed, this should be possible to do it that way. Would you mind putting an
> example to the mentioned github issue? I might give it a thought in the
> background if I see more details.

OK, attached is some code that builds the constraints that correspond to this
rather esoteric paper (but also one I enjoyed working on the most because it's
just so weird!):
https://www.math.colostate.edu/~bangerth/publications/2016-nonconforming.pdf

The paper identifies 3 different ways how one could define hanging node
constraints for this element, and they are implemented in the function I
attach. The code is a couple of years old, but if something doesn't compile
any more, it should be easy to update.

Best
Wolfgang

[Daniel Garcia-Sanchez]

Wolfgang,

On Wednesday, June 26, 2019 at 3:50:22 PM UTC+2, Wolfgang Bangerth wrote:

OK, attached is some code that builds the constraints that correspond to this
rather esoteric paper (but also one I enjoyed working on the most because it's
just so weird!):
   https://www.math.colostate.edu/~bangerth/publications/2016-nonconforming.pdf

The paper identifies 3 different ways how one could define hanging node
constraints for this element, and they are implemented in the function I
attach. The code is a couple of years old, but if something doesn't compile
any more, it should be easy to update.

 

Thanks for the code. I'll work on this. 

Alexader,

On Wednesday, June 26, 2019 at 3:38:34 PM UTC+2, Alexander wrote:

Please feel free to take a leading role here. I'm happy to help and look at your code, but I won't be able to lead this myself in the next months (I have to write funding proposals...) 

That sounds good.

Good luck with your proposals!

Best,

Dani