I can try it in my test case, I think it should be OK in the symmetric
case: <Q1-Nothing>--<Nothing-Q1>, which could be enough at least for me.
In the nonsymmetric case, for example:
<Q1-Nothing>--<Nothing-Q2>,
we should be able to ask for a restriction on one side and then do the
coupling "manually" as in the symmetric case.
Maybe in the latter case "compare_for_face_domination" should know that we
want to do a kind of cross coupling:
1st element (Q1) of FESystem_1 with second of FESystem_2 (Q2) and viceversa,
while the coupling Nothing<--->Q* should always give "no_requirements".
One possibility is for example to check for FE_Nothing, if there is a pair
with FE_Nothing then do the cross coupling or let the user decide how are
the couplings.
Again, in my case the first solution with "no_requirements" would be enough.
>> It happens when I call "distribute_dofs", because fe_system calls the
>> following function:
>>
>> template <int dim>
>> FiniteElementDomination::Domination
>> FE_Nothing<dim> ::
>> compare_for_face_domination (const FiniteElement<dim> & fe_other) const
>> {
>> if(dynamic_cast<const FE_Nothing<dim>*>(&fe_other) != 0)
>> return FiniteElementDomination::either_element_can_dominate;
>> else
>> return FiniteElementDomination::this_element_dominates;
>> }
>>
>>
>> How should be the behavior of this function in the FE_Nothing case?
>
> I tend to think that we should add another state to the
> FiniteElementDomination enum, say no_requirements, that indicates that we
> don't want to do anything on interfaces between FE_Nothing and anything
> else.
> Then FESystem would also return no_requirements whenever each component of
> the
> FESystem would return no_requirements.
>
> Would that make sense?
>
> W.
>
> -------------------------------------------------------------------------
> Wolfgang Bangerth email: [email protected]
> www: http://www.math.tamu.edu/~bangerth/
>
_______________________________________________
dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii
