Issue using component_wise()

[Hermes Sampedro]

Dear all, 

I am facing an issue and would like to ask for some help. I am using a distributed approach using PETS, similar to step-40 and I use a 2 component system (similar to step-29).

Now I am trying to order the dof according to the components. However, I am experiencing that when using DoFRenumbering::component_wise and running with more than 1 MPI rank, my solution vector has inf values. Which, does not happen when using only 1 process, or using the default dof ordering. I am not sure where the problem could be. May I ask for some suggestions to see if I can identify where the issue can be?

My setup function is the following:

Thank you

Regards,

H

template <int dim>

void LaplaceProblem<dim>::setup_system(int en_op)

{

dof_handler.distribute_dofs(fe);

DoFRenumbering::component_wise(dof_handler);

locally_owned_dofs = dof_handler.locally_owned_dofs();

DoFTools::extract_locally_relevant_dofs(dof_handler, locally_relevant_dofs);

locally_relevant_solution.reinit(locally_owned_dofs,

locally_relevant_dofs,

mpi_communicator);

system_rhs.reinit(locally_owned_dofs, mpi_communicator);

constraints.clear();

constraints.reinit(locally_relevant_dofs);

DoFTools::make_hanging_node_constraints(dof_handler, constraints);

constraints.close();

DynamicSparsityPattern dsp(locally_relevant_dofs);

locally_relevant_dofs.n_elements());

DoFTools::make_sparsity_pattern(dof_handler, dsp,constraints,false);

SparsityTools::distribute_sparsity_pattern(dsp,dof_handler.locally_owned_dofs(),mpi_communicator,locally_relevant_dofs);

system_matrix.reinit(locally_owned_dofs,

locally_owned_dofs,

dsp,

mpi_communicator);

//sparsity patterns for auxiliary full  matrices

DynamicSparsityPattern dsp_bc(dof_handler.n_dofs(), dof_handler.n_dofs());

DoFTools::make_sparsity_pattern(dof_handler, dsp_bc);

sparsity_pattern_bc.copy_from(dsp_bc);

BC_sigmaSP.reinit(sparsity_pattern_bc);

BC_ySP.reinit(sparsity_pattern_bc);

sparsity_pattern_K.copy_from(dsp_bc);

Ksigma_a_matrixSP.reinit(sparsity_pattern_K);

Ksigma_b_matrixSP.reinit(sparsity_pattern_K);

Ky_matrixSP.reinit(sparsity_pattern_K);

}

[Wolfgang Bangerth]

On 4/5/22 04:47, Hermes Sampedro wrote:
>
> Now I am trying to order the dof according to the components. However, I am

> experiencing that when using /DoFRenumbering::component_wise/ and running with

> more than 1 MPI rank, my solution vector has inf values. Which, does not
> happen when using only 1 process, or using the default dof ordering. I am not
> sure where the problem could be. May I ask for some suggestions to see if I
> can identify where the issue can be?

This is an excellent problem to check your debugging skills. It *may* of
course be related in some way to the renumbering, but there appears to be no
logical connection between the two. On the other hand, it is easy to check for
the presence of inf values (for example, by outputting the norm of a vector).
There are two ways for inf values to appear in the solution vector: The right
hand side vector has inf values, or the iterative solver does not converge.
Both are easy enough to test. If it's the solver, you need to figure out why
that is.

Best
W.

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

[Hermes Sampedro]

Dear Wolfgang, 

I have not been able to find the issue. I am considering looking for an alternative. I am using 2 components to describe a complex solution (for real and imaginary parts). Assuming that I keep the ordering by default and that I export my solution vector (to work in an external software), what I need in the end is to know for each value of the solution vector, if it corresponds to the real or imaginary part. I realized by debugging that the order is not consistent and it changes depending on the number of dof.

I would like to ask if there is any function or if you could suggest a way to get the vector that contains information about the component type for each node (for example a mask type, where 0 is real and 1 imaginary component). The way I implemented and managed the components, assembly, etc is identical to the one described in step-29.

I would really appreciate your help on this matter.

Thank you very much.

Regards

Hermes

[Wolfgang Bangerth]

On 4/19/22 08:05, Hermes Sampedro wrote:
>
> I have not been able to find the issue. I am considering looking for an
> alternative. I am using 2 components to describe a complex solution (for real
> and imaginary parts). Assuming that I keep the ordering by default and that I
> export my solution vector (to work in an external software), what I need in
> the end is to know for each value of the solution vector, if it corresponds to
> the real or imaginary part. I realized by debugging that the order is not
> consistent and it changes depending on the number of dof.
> I would like to ask if there is any function or if you could suggest a way to
> get the vector that contains information about the component type for each
> node (for example a mask type, where 0 is real and 1 imaginary component). The
> way I implemented and managed the components, assembly, etc is identical to
> the one described in step-29.

Yes, there are a number of functions in namespace DoFTools that you can use to
extract the indices of DoFs based on their vector component.

[Hermes Sampedro]

Dear Wolfgang, 

Thank you, could you please suggest me one in particular?

Regards

H

[Wolfgang Bangerth]

On 4/19/22 08:39, Hermes Sampedro wrote:
>
> Thank you, could you please suggest me one in particular?

Hermes -- they are not actually very difficult to find. Take a look at
https://dealii.org/developer/doxygen/deal.II/namespaceDoFTools.html
and then just read the section headings for different groups of functions.
There is one group that is called "Identifying subsets of degrees of freedom
with particular properties"; that would be a good place to start.

We put a lot of work into writing documentation. It's up to you to make use of it.

[Hermes Sampedro]

Dear Wolfgang, 

That is totally right, thank you very much for the suggestions.

Regards, 

Hermes