Assertion error when using FE_Nothing with FESystems with different number of base elements

[Mohamad Ghadban]

Hello,

I am solving a problem in which I use the FE_Nothing class to represent variables that do not exist in parts of the physical domain. My domain is split into two parts: In the first part, I solve for all three variables (I'll call them u1, u2, and u3) and in the second part of the domain I solve for u1 and u2 only. 

For my problem, I use two FESystem objects in the parameter file as follows:

FESystem[FE_Q(1)^3] for the first part of the domain

FESystem[FE_Q(1)^2-FE_Nothing^1] for the second part of the domain.

However, this results in the following assertion error:

An error occurred in line <2478> of file <../deal.II/src/source/fe/fe_system.cc> in function
    dealii::FiniteElementDomination::Domination dealii::FESystem<dim, spacedim>::compare_for_domination(const dealii::FiniteElement<dim, spacedim>&, unsigned int) const [with int dim = 2; int spacedim = 2]
The violated condition was:
    this->n_base_elements() == fe_sys_other->n_base_elements()
Additional information:
    You are trying to use functionality in deal.II that is currently not
    implemented. In many cases, this indicates that there simply didn't
    appear much of a need for it, or that the author of the original code
    did not have the time to implement a particular case. If you hit this
    exception, it is therefore worth the time to look into the code to
    find out whether you may be able to implement the missing
    functionality. If you do, please consider providing a patch to the
    deal.II development sources (see the deal.II website on how to
    contribute).

But when I changed the first FESystem into:

FESystem[FE_Q(1)^2-FE_Q(1)^1] 

it worked fine because the number of base elements in both FESystems is now the same. My question is then, is this assertion necessary?

Thank you,

Mohamad

[julian...@gmail.com]

Hi Mohamad,

You need to create the two FESystems as follows:

FESystem[FE_Q(1)^3-FE_Nothing^2] and FESystem[FE_Nothing^3-FE_Q(1)^2].

This way the first three variables u1, u2 and u3 will be only defined in the first domain and in the second domain we define u1 and u2 as the last two variables.

For more information on FE_Nothing look at step 46 of the deal.II tutorials.

Additionally, I also have some code online that uses FE_Nothing: https://github.com/mathmerizing/TemporalMultirateFEM/blob/main/src%2Fmonolithic_heatwave%2Fmain.cc

Kind regards,

Julian

[Mohamad Ghadban]

Hi Julian

Thanks for the tips. My code is actually based on Step 46, but the difference is that in my case I am not solving for a completely new set of variables in each part of the domain.

Based on what you are suggesting, wouldn't that mean that the total number of variables/components that I would be solving for is 5 (by summing the multiplicities) instead of 3? That's at least what I inferred from Step 46.

Also, is there a more intuitive approach to follow? Because your suggestion means that variables u1 and u2 belong to the first base element in this FESystem

FESystem[FE_Q(1)^3-FE_Nothing^2]

but they belong to a completely different base element in the other FESystem

 

FESystem[FE_Nothing^3-FE_Q(1)^2]

I think the way the logic is conveyed in Step 46 is more intuitive because Stokes variables which exist in the first base element in one FESystem still exist in the first base base element in the other FESystem but are represented by FE_Nothing instead of FE_Q elements.

Thanks,

 Mohamad

--
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/csAJHjYuK88/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/0f0b1e5b-5e10-40b9-a5ed-bf6eba6f4d4en%40googlegroups.com.

[julian...@gmail.com]

Hi Mohamad,

Yes, you understood correctly.

In your example you should have 5 components.

Basically with FENothing you have placeholders for the components that are not used on the current domain.

In your example you have the solution components:

- in domain 1: u_1^1, u_2^1, u_3^1, _, _

- in domain 2: _, _, _, u_1^2, u_2^2.

In your code the _ will be replaced by FENothing components and I used ^1/^2 to show on which domain the component is defined.

I hope this helps.

 Kind regards,

Julian

[Mohamad Ghadban]

I think it makes sense. What you are saying is that the number of components would be summed across all domains regardless of whether they represent the same variables or not, is that correct?

So if, hypothetically speaking, I am solving the same variables u1, u2, and u3 in five different domains, that means that the total number of components will be 15, right?

If that's the case, do you foresee any troubles with the workaround I used, i.e.,

FESystem[FE_Q(1)^2-FE_Q(1)^1]  for the first part of the domain

FESystem[FE_Q(1)^2-FE_Nothing^1] for the second part of the domain

given that it worked fine where the solution I got was as expected? I'm just unsure if that would cause issues in more complicated cases.

Thanks,

Mohamad

To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/6569fe1a-9380-4694-a5f8-a74656347f85n%40googlegroups.com.

[Wolfgang Bangerth]

On 4/6/24 16:24, Mohamad Ghadban wrote:
> *
> *

> But when I changed the first FESystem into:

> *FESystem[FE_Q(1)^2-**FE_Q(1)^1**]*

> it worked fine because the number of base elements in both FESystems is now
> the same. My question is then, is this assertion necessary?

Julian's suggestion works, but if you have two variables that are defined
everywhere and one that is defined in only part of the domain, then what you
are suggesting (working with only three components) makes sense to me.

You've already found how to make that work without getting the assertion. As
to the question of whether the assertion is necessary: Perhaps not, but the
function in question (FESystem::compare_for_domination()) might be
substantially more complicated to implement. The way it is implemented is to
assume that the two elements you are comparing have the same number of base
elements and multiplicities, and in that case determining which element
dominates is a question of determining which base element dominates. If you
wanted to remove the assertion (patches as always welcome!) you have to break
things into smaller components and compare those for domination. Here, if you have
FESystem[FE_Q(1)^3]
and
FESystem[FE_Q(1)^2-FE_Nothing^1]
that would not be too difficult. I bet that could be done in 25 extra lines of
code (again: patches are very much welcome!) but the difficult case is you have
FESystem[FE_Q(1)^3]
and
FESystem[FESystem[FE_Q(1),FE_Q(1)]-FE_Nothing^1]
for example.

Best
Wolfgang

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

[Mohamad Ghadban]

Thank you Dr. Wolfgang! I'll try to implement a patch if I have time for it.

Regards,

Mohamad

--
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/csAJHjYuK88/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/32538aef-9787-40ea-af0e-f230177e0c45%40colostate.edu.