Re: [deal.II] Re: Assertion error when using FE_Nothing with FESystems with different number of base elements

[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

On Mon, Apr 8, 2024 at 3:18 PM julian...@gmail.com 
wrote:

> 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
>
>
> On Monday, April 8, 2024 at 11:07:52 PM UTC+2 mgha...@ualberta.ca wrote:
>
>> 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
>>
>> On Sun, Apr 7, 2024 at 11:52 PM julian...@gmail.com 
>> wrote:
>>
>>> 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
>>> On Sunday, April 7, 2024 at 12:24:53 AM UTC+2 mgha...@ualberta.ca wrote:
>>>
 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>>> spacedim>::compare_for_domination(const dealii::FiniteElement>>> 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 notimplemented. In
 many cases, this indicates that there simply didn'tappear much of a
 need for it, or that the author of the original codedid not have the
 time to implement a particular case. If you hit thisexception, it is
 therefore worth the time to look into the code tofind out whether you
 may be able to implement the missingfunctionality. If you do, please
 consider providing a patch to thedeal.II development sources (see the
 deal.II website on how to

Re: [deal.II] Re: Assertion error when using FE_Nothing with FESystems with different number of base elements

[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


On Monday, April 8, 2024 at 11:07:52 PM UTC+2 mgha...@ualberta.ca wrote:

> 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
>
> On Sun, Apr 7, 2024 at 11:52 PM julian...@gmail.com  
> wrote:
>
>> 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
>> On Sunday, April 7, 2024 at 12:24:53 AM UTC+2 mgha...@ualberta.ca wrote:
>>
>>> 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>> spacedim>::compare_for_domination(const dealii::FiniteElement>> 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 notimplemented. In 
>>> many cases, this indicates that there simply didn'tappear much of a 
>>> need for it, or that the author of the original codedid not have the 
>>> time to implement a particular case. If you hit thisexception, it is 
>>> therefore worth the time to look into the code tofind out whether you 
>>> may be able to implement the missingfunctionality. If you do, please 
>>> consider providing a patch to thedeal.II development sources (see the 
>>> deal.II website on how tocontribute).*
>>>
>>> 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
>>>
>> -- 
>> 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 
>> 

Re: [deal.II] Re: Assertion error when using FE_Nothing with FESystems with different number of base elements

[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

On Sun, Apr 7, 2024 at 11:52 PM julian...@gmail.com 
wrote:

> 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
> On Sunday, April 7, 2024 at 12:24:53 AM UTC+2 mgha...@ualberta.ca wrote:
>
>> 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> spacedim>::compare_for_domination(const dealii::FiniteElement> 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 notimplemented. In
>> many cases, this indicates that there simply didn'tappear much of a
>> need for it, or that the author of the original codedid not have the
>> time to implement a particular case. If you hit thisexception, it is
>> therefore worth the time to look into the code tofind out whether you
>> may be able to implement the missingfunctionality. If you do, please
>> consider providing a patch to thedeal.II development sources (see the
>> deal.II website on how tocontribute).*
>>
>> 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
>>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/0f0b1e5b-5e10-40b9-a5ed-bf6eba6f4d4en%40googlegroups.com
> 
> .
>

-- 
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 dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/CAP2_OwEcTkCjE54g7QP54PijhcGci4fZfuCFhLH3Ah1Ngw2-2w%40mail.gmail.com.