Multilevel DoFRenumbering for a distributed Triangulation

[julius...@gmail.com]

Hey,

I hope this is the right place to ask my question.

I have a working Stokes solver using a multigrid preconditioner, which relies on the block structure of the velocity pressure system, for a serial triangulation. Recently, I started to extend my program to distributed triangulations and encountered the following problem:

--------------------------------------------------------

An error occurred in line <4486> of file <.../source/dofs/dof_handler_policy.cc> in function

    dealii::internal::DoFHandlerImplementation::NumberCache dealii::internal::DoFHandlerImplementation::Policy::ParallelDistributed<dim, spacedim>::renumber_mg_dofs(unsigned int, const std::vector<long unsigned int>&) const [with int dim = 2; int spacedim = 2]

The violated condition was: 

    index_set.is_element(i)

Additional information: 

    Renumberings that change the locally owned mg dofs partitioning are currently not implemented for the multigrid levels

My DoFHandler passed was initialized with a FESystem characterizing velocity-pressure functions. Using DoFRenumbering::component_wise() on the active set of cells/dofs worked as in the serial case, however, the renumbering on any level throws the exception above (for more than one mpi proc). 

Is there a particular reason that this should never be allowed because it would break dealii functionality in other places, or, was there just no need to do this before?

I am very hesitant to touch dealii code that deep. Currently, I tend to write a mapping between the component-wise and block-wise dof numbering transferring between the block structure my functionalities rely on and the original structure. Any suggestions would be appreciated.

Thanks in advance :)

Best,

Julius

[julius...@gmail.com]

Hey,

I have checked the interfaces I used (multigrid, matrix, vectors, ...). It seems that by using separate DoFHandlers, one for the velocity and one for the pressure component, I could come up with the very same block structure. However, I could not find any make_sparsity_pattern() variants for rectangular matrices using different DoFHandlers for the domain and range, neither in MGTools nor in DoFTools. Are there any predefined?

Thanks for your help!

Best,

Julius

[Daniel Arndt]

Hey Julius,

I don't think there are any but it should not be that difficult to implement one yourself. The implementation f these functions is not that complicated.

Of course, we are happy for any patches in that direction. ;-)

Best,

Daniel

--
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+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/25ab80fe-e1b5-4818-97f3-17d6a8ef640bn%40googlegroups.com.

[Wolfgang Bangerth]

On 2/5/21 4:07 PM, Daniel Arndt wrote:
> I have checked the interfaces I used (multigrid, matrix, vectors, ...). It
> seems that by using separate DoFHandlers, one for the velocity and one for the
> pressure component, I could come up with the very same block structure.
> However, I could not find any make_sparsity_pattern() variants for rectangular
> matrices using different DoFHandlers for the domain and range, neither in
> MGTools nor in DoFTools. Are there any predefined?

There is

void
make_sparsity_pattern(const DoFHandler<dim, spacedim> &dof_row,
const DoFHandler<dim, spacedim> &dof_col,
SparsityPatternType & sparsity);

in namespace DoFTools.

Best
W.

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

[julius...@gmail.com]

Perfect, thank you very much. Unfortunately, the make_sparsity_pattern() method I was looking for is displayed after make_flux_sparsity_pattern() in my online docu., so I overlooked them, sorry for that.

That's a good starting point to add a method for each level and I need some flux sparsity for my DG variants, too. For any patches, I will address you on GitHub.

Thanks a lot!
Best,
Julius 

[Wolfgang Bangerth]

On 2/5/21 11:56 AM, julius...@gmail.com wrote:
>
> Is there a particular reason that this should never be allowed because it
> would break dealii functionality in other places, or, was there just no need
> to do this before?
>
> I am very hesitant to touch dealii code that deep. Currently, I tend to write
> a mapping between the component-wise and block-wise dof numbering transferring
> between the block structure my functionalities rely on and the original
> structure. Any suggestions would be appreciated.

Julius,
I think it's just that it hasn't been implemented. I'm no expert on the
multilevel stuff, but see no reason why that shouldn't be allowed in principle.

As always, patches are welcome!