It should look like this so it works in hp case.
// This is available only after call to reinit.
unsigned int
FEInterfaceValues::get_component(const unsigned int interface_dof_index) const
{
const auto dof_pair = dofmap[interface_dof_index];
if(dof_pair[0] != numbers::invalid_unsigned_int)
{
return
fe_face_values.get_fe().system_to_component_index(dof_pair[0]).first;
}
else
{
return
fe_face_values_neighbor.get_fe().system_to_component_index(dof_pair[1]).first;
}
}
best
praveen
> On 16 Sep 2024, at 10:37 AM, Praveen C <[email protected]> wrote:
>
> The simplest solution seems to be to add a function like this.
>
> // This is available only after call to reinit.
> unsigned int
> FEInterfaceValues::get_component(const unsigned int interface_dof_index) const
> {
> const auto dof_pair = dofmap[interface_dof_index];
> if(dof_pair[0] != numbers::invalid_unsigned_int)
> {
> return get_fe().system_to_component_index(dof_pair[0]).first;
> }
> else
> {
> return get_fe().system_to_component_index(dof_pair[1]).first;
> }
> }
>
> Or should the component info be built during reinit and stored in the class ?
>
> best
> praveen
>
>> On 16 Sep 2024, at 8:19 AM, Wolfgang Bangerth <[email protected]> wrote:
>>
>> On 9/14/24 08:04, Praveen C wrote:
>>> unsigned int ii = (i < n_cell_dofs) ? i : i - n_cell_dofs;
>>> const auto c =
>>> fe_face_values.get_fe().system_to_component_index(ii).first;
>>
>> Praveen:
>> this makes the assumption that you first have the DoFs from one side, and
>> then the ones from the other side. This may be true in some cases
>> (including, perhaps, yours) but it is not one that you should rely on unless
>> you have a way of asserting that your assumption is correct.
>>
>> I don't think we have a good way of querying this information at the moment.
>> You might have to ask for the DoF indices of both cells, and then of the
>> FEInterfaceValues object, and compare these indices so that when you need
>> information for the FEInterfaceValues object, you know which of the two
>> cells to ask and how.
>>
>> I think a better way would actually be to just implement this sort of
>> functionality in FEInterfaceValues to begin with. The class is not very
>> difficult to understand, and it shouldn't be very difficult to implement
>> what you need. The usual applies: We'd love to have a patch that we can
>> incorporate into the library!
>>
>> Best
>> W.
>>
>> --
>> ------------------------------------------------------------------------
>> Wolfgang Bangerth email: [email protected]
>> www: http://www.math.colostate.edu/~bangerth/
>>
>>
>> --
>> 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 [email protected].
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/dealii/80531e2b-863d-45b5-a0fa-68859f69181e%40colostate.edu.
>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/dealii/FD6F88B0-C31E-4149-A63F-B6EFAE720BB5%40gmail.com.