Re: [deal.II] Issue using component_wise()

[Hermes Sampedro]

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

Regards, 
Hermes

El martes, 19 de abril de 2022 a las 17:02:31 UTC+2, Wolfgang Bangerth 
escribió:

> 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.
>
> Best
> W.
>
> -- 
> 
> Wolfgang Bangerth email: bang...@colostate.edu
> 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 dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/7c117265-e761-48a3-8e75-4b87595eac5en%40googlegroups.com.

Re: [deal.II] Issue using component_wise()

[Hermes Sampedro]

Dear Wolfgang, 

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

Regards
H

El martes, 19 de abril de 2022 a las 16:28:04 UTC+2, Wolfgang Bangerth 
escribió:

> 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.
>
> Best
> W.
>
> -- 
> 
> Wolfgang Bangerth email: bang...@colostate.edu
> 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 dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/5dc1b028-a6b1-4c8c-9939-cc8a540f9c2fn%40googlegroups.com.

Re: [deal.II] Issue using component_wise()

[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


El martes, 5 de abril de 2022 a las 16:41:49 UTC+2, Wolfgang Bangerth 
escribió:

> 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/
>
>

-- 
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/39dd3a68-2785-4076-aa94-3f372e9c84a2n%40googlegroups.com.

[deal.II] 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 *
*void LaplaceProblem::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);*


*}*

-- 
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/1cbc3ba7-22f0-45ef-b40e-afe4d5533133n%40googlegroups.com.

Re: [deal.II] High-order method & HDF5 exporting

[Hermes Sampedro]

Dear Wolfgang, 

Thank you for your answer. I can see that for VTK there is the option of:
*DataOutBase::VtkFlags flags;*
* flags.write_higher_order_cells = true;*

I could not find anything similar for HDF5. When exporting the results and 
the mesh, I can only see the nodes corresponding to the first order, so I 
always get less dof than what I actually have. Is there any option to 
export all the corresponding dof?

Thank you
Regards, 
H

El miércoles, 30 de marzo de 2022 a las 22:05:56 UTC+2, Wolfgang Bangerth 
escribió:

> On 3/30/22 05:40, Hermes Sampedro wrote:
> > 
> > I want to use the function /write_hdf5_parallel()/ with the 
> > corresponding/DataOutFilter/ and /DataOutFilterFlags /to export my 
> > domain solution. I am working with higher-order methods and I can not 
> > find any option on the HDF5 format (and filter) to add the high order 
> > points to the exported vector file. Is that supported?
>
> When you say high order points, are you saying that you want your cells 
> to show up with curved edges (like is possible with VTK/VTU in recent 
> versions)? Or that you want each cell to be subdivided into smaller 
> subdivisions?
>
> I'm not sure the former is possible in HDF5 at all.
>
> Best
> W.
>
> -- 
> 
> Wolfgang Bangerth email: bang...@colostate.edu
> 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 dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/95fa313a-4e51-4ccf-899d-2eb3f1412a7cn%40googlegroups.com.

[deal.II] High-order method & HDF5 exporting

[Hermes Sampedro]

Dear all, 

I want to use the function *write_hdf5_parallel()* with the corresponding* 
DataOutFilter* and *DataOutFilterFlags *to export my domain solution. I am 
working with higher-order methods and I can not find any option on the HDF5 
format (and filter) to add the high order points to the exported vector 
file. Is that supported?

Thank you
Regards, 
H.

-- 
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/75942a59-5308-4346-b05f-8c0f7caaf18fn%40googlegroups.com.

Re: [deal.II] Error with PETScWrappers::PreconditionILU

[Hermes Sampedro]

Dear Timo, 

thank you for your answer. Is there any other option for ILU with parallel 
matrices apart of Block Jacobi? 

Thank you
Regards

El martes, 15 de marzo de 2022 a las 18:45:29 UTC+1, Timo Heister escribió:

> Hi,
>
> > [0]PETSC ERROR: See 
> https://www.mcs.anl.gov/petsc/documentation/linearsolvertable.html for 
> possible LU and Cholesky solvers
> > [0]PETSC ERROR: Could not locate a solver package for factorization type 
> ILU and matrix type mpiaij.
>
> This means that ILU is not available for parallel matrices (mpiaij).
> You need to pick a different preconditioner. You can try
> PreconditionBlockJacobi which is a blocked ILU and probably what you
> wanted to do.
>
>
> On Tue, Mar 15, 2022 at 12:39 PM Hermes Sampedro
>  wrote:
> >
> > Dear all,
> >
> > I am getting a running error that I can not really understand when 
> calling PETScWrappers::PreconditionILU preconditioner(system_matrix). 
> However, it seems to work with PETScWrappers::PreconditionBlockJacobi 
> preconditioner(system_matrix).
> >
> > May I ask for help to understand/solve this issue? The solver function 
> ad error that I get is the following:
> >
> > void LaplaceProblem::solve()
> >
> > {
> >
> > PETScWrappers::MPI::Vector 
> completely_distributed_solution(locally_owned_dofs,mpi_communicator);
> >
> > SolverControl cn(completely_distributed_solution.size(), 1e-8 * 
> system_rhs.l2_norm());
> >
> > PETScWrappers::SolverGMRES solver(cn, mpi_communicator);
> >
> > PETScWrappers::PreconditionILU preconditioner(system_matrix);
> >
> > solver.solve(system_matrix, completely_distributed_solution, system_rhs, 
> preconditioner);
> >
> > constraints.distribute(completely_distributed_solution);
> >
> > locally_relevant_solution = completely_distributed_solution;
> >
> > }
> >
> >
> > [0]PETSC ERROR: - Error Message 
> --
> >
> > [0]PETSC ERROR: See 
> https://www.mcs.anl.gov/petsc/documentation/linearsolvertable.html for 
> possible LU and Cholesky solvers
> >
> > [0]PETSC ERROR: Could not locate a solver package for factorization type 
> ILU and matrix type mpiaij.
> >
> > [0]PETSC ERROR: See https://www.mcs.anl.gov/petsc/documentation/faq.html 
> for trouble shooting.
> >
> > [0]PETSC ERROR: Petsc Release Version 3.13.1, May 02, 2020
> >
> > [0]PETSC ERROR: ./waveLaplaceSolver on a named gbarlogin1 by hsllo Fri 
> Mar 11 11:05:23 2022
> >
> > [0]PETSC ERROR: Configure options 
> --prefix=/zhome/32/9/115503/dealii-candi/petsc-3.13.1 --with-debugging=0 
> --with-shared-libraries=1 --with-mpi=1 --with-x=0 --with-64-bit-indices=0 
> --download-hypre=1 CC=mpicc CXX=mpicxx FC=mpif90 
> --with-blaslapack-dir=/appl/OpenBLAS/0.3.17/XeonE5-2660v3/gcc-11.2.0/lib 
> --with-parmetis-dir=/zhome/32/9/115503/dealii-candi/parmetis-4.0.3 
> --with-metis-dir=/zhome/32/9/115503/dealii-candi/parmetis-4.0.3 
> --download-scalapack=1 --download-mumps=1
> >
> > [0]PETSC ERROR: #1 MatGetFactor() line 4492 in 
> /zhome/32/9/115503/dealii-candi/tmp/build/petsc-lite-3.13.1/src/mat/interface/matrix.c
> >
> > [0]PETSC ERROR: #2 PCSetUp_ILU() line 133 in 
> /zhome/32/9/115503/dealii-candi/tmp/build/petsc-lite-3.13.1/src/ksp/pc/impls/factor/ilu/ilu.c
> >
> > [0]PETSC ERROR: #3 PCSetUp() line 894 in 
> /zhome/32/9/115503/dealii-candi/tmp/build/petsc-lite-3.13.1/src/ksp/pc/interface/precon.c
> >
> > 
> >
> > Exception on processing:
> >
> > 
> >
> > An error occurred in line <431> of file 
> 
>  
> in function
> >
> > void dealii::PETScWrappers::PreconditionILU::initialize(const 
> dealii::PETScWrappers::MatrixBase&, const 
> dealii::PETScWrappers::PreconditionILU::AdditionalData&)
> >
> > The violated condition was:
> >
> > ierr == 0
> >
> > Additional information:
> >
> > deal.II encountered an error while calling a PETSc function.
> >
> > The description of the error provided by PETSc is "See
> >
> > https://www.mcs.anl.gov/petsc/documentation/linearsolvertable.html for
> >
> > possible LU and Cholesky solvers".
> >
> > The numerical value of the original error code is 92.
> >
> >
> >
> >
> > Thank you very much
> >
> > Regards,
> >
> > H
> >
> > --
> > The deal.II project is located at http://www.dealii.org/
&

[deal.II] Error with PETScWrappers::PreconditionILU

[Hermes Sampedro]

Dear all, 

I am getting a running error that I can not really understand when calling 
*PETScWrappers::PreconditionILU 
preconditioner(system_matrix)*. However, it seems to work with  
*PETScWrappers::PreconditionBlockJacobi preconditioner(system_matrix).*

May I ask for help to understand/solve this issue? The solver function ad 
error that I get is the following:

*void LaplaceProblem::solve()*

*   {*

*   PETScWrappers::MPI::Vector 
completely_distributed_solution(locally_owned_dofs,mpi_communicator);*

* SolverControl cn(completely_distributed_solution.size(), 1e-8 * 
system_rhs.l2_norm());*

*  PETScWrappers::SolverGMRES solver(cn, mpi_communicator);*

*   PETScWrappers::PreconditionILU preconditioner(system_matrix);*

* solver.solve(system_matrix, completely_distributed_solution, 
system_rhs, preconditioner); *

*   constraints.distribute(completely_distributed_solution);*

*   locally_relevant_solution = completely_distributed_solution;*

*   }*


[0]PETSC ERROR: - Error Message 
--

[0]PETSC ERROR: See 
https://www.mcs.anl.gov/petsc/documentation/linearsolvertable.html for 
possible LU and Cholesky solvers

[0]PETSC ERROR: Could not locate a solver package for factorization type 
ILU and matrix type mpiaij.

[0]PETSC ERROR: See https://www.mcs.anl.gov/petsc/documentation/faq.html for 
trouble shooting.

[0]PETSC ERROR: Petsc Release Version 3.13.1, May 02, 2020 

[0]PETSC ERROR: ./waveLaplaceSolver on a  named gbarlogin1 by hsllo Fri Mar 
11 11:05:23 2022

[0]PETSC ERROR: Configure options 
--prefix=/zhome/32/9/115503/dealii-candi/petsc-3.13.1 --with-debugging=0 
--with-shared-libraries=1 --with-mpi=1 --with-x=0 --with-64-bit-indices=0 
--download-hypre=1 CC=mpicc CXX=mpicxx FC=mpif90 
--with-blaslapack-dir=/appl/OpenBLAS/0.3.17/XeonE5-2660v3/gcc-11.2.0/lib 
--with-parmetis-dir=/zhome/32/9/115503/dealii-candi/parmetis-4.0.3 
--with-metis-dir=/zhome/32/9/115503/dealii-candi/parmetis-4.0.3 
--download-scalapack=1 --download-mumps=1

[0]PETSC ERROR: #1 MatGetFactor() line 4492 in 
/zhome/32/9/115503/dealii-candi/tmp/build/petsc-lite-3.13.1/src/mat/interface/matrix.c

[0]PETSC ERROR: #2 PCSetUp_ILU() line 133 in 
/zhome/32/9/115503/dealii-candi/tmp/build/petsc-lite-3.13.1/src/ksp/pc/impls/factor/ilu/ilu.c

[0]PETSC ERROR: #3 PCSetUp() line 894 in 
/zhome/32/9/115503/dealii-candi/tmp/build/petsc-lite-3.13.1/src/ksp/pc/interface/precon.c



Exception on processing: 



An error occurred in line <431> of file 

 
in function

void dealii::PETScWrappers::PreconditionILU::initialize(const 
dealii::PETScWrappers::MatrixBase&, const 
dealii::PETScWrappers::PreconditionILU::AdditionalData&)

The violated condition was: 

ierr == 0

Additional information: 

deal.II encountered an error while calling a PETSc function.

The description of the error provided by PETSc is "See

https://www.mcs.anl.gov/petsc/documentation/linearsolvertable.html for

possible LU and Cholesky solvers".

The numerical value of the original error code is 92.




Thank you very much

Regards, 

H

-- 
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/c4109bcf-cd4e-453e-9c81-9ed1230a235cn%40googlegroups.com.

Re: [deal.II] Re: Assemble function, long time

[Hermes Sampedro]

 

Dear Bruno,

I have been reading the examples and documents you pointed out. I tried to 
use SolvereGREMS with PreconditionILU. However, I am getting a running 
error that I can not really understand when calling 
PETScWrappers::PreconditionILU preconditioner(system_matrix). However, it 
seems to work with  PETScWrappers::PreconditionBlockJacobi 
<https://dealii.org/current/doxygen/deal.II/classPETScWrappers_1_1PreconditionBlockJacobi.html>
 
preconditioner(system_matrix). The solver function ad error that I get is 
the following:

*void LaplaceProblem::solve()*

*   {*

*   PETScWrappers::MPI::Vector 
completely_distributed_solution(locally_owned_dofs,mpi_communicator);*

* SolverControl cn(completely_distributed_solution.size(), 1e-8 * 
system_rhs.l2_norm());*

*  PETScWrappers::SolverGMRES solver(cn, mpi_communicator);*

*   PETScWrappers::PreconditionILU preconditioner(system_matrix);*

* solver.solve(system_matrix, completely_distributed_solution, 
system_rhs, preconditioner); *

*   constraints.distribute(completely_distributed_solution);*

*   locally_relevant_solution = completely_distributed_solution;*

*   }*


[0]PETSC ERROR: - Error Message 
--

[0]PETSC ERROR: See 
https://www.mcs.anl.gov/petsc/documentation/linearsolvertable.html for 
possible LU and Cholesky solvers

[0]PETSC ERROR: Could not locate a solver package for factorization type 
ILU and matrix type mpiaij.

[0]PETSC ERROR: See https://www.mcs.anl.gov/petsc/documentation/faq.html 
for trouble shooting.

[0]PETSC ERROR: Petsc Release Version 3.13.1, May 02, 2020 

[0]PETSC ERROR: ./waveLaplaceSolver on a  named gbarlogin1 by hsllo Fri Mar 
11 11:05:23 2022

[0]PETSC ERROR: Configure options 
--prefix=/zhome/32/9/115503/dealii-candi/petsc-3.13.1 --with-debugging=0 
--with-shared-libraries=1 --with-mpi=1 --with-x=0 --with-64-bit-indices=0 
--download-hypre=1 CC=mpicc CXX=mpicxx FC=mpif90 
--with-blaslapack-dir=/appl/OpenBLAS/0.3.17/XeonE5-2660v3/gcc-11.2.0/lib 
--with-parmetis-dir=/zhome/32/9/115503/dealii-candi/parmetis-4.0.3 
--with-metis-dir=/zhome/32/9/115503/dealii-candi/parmetis-4.0.3 
--download-scalapack=1 --download-mumps=1

[0]PETSC ERROR: #1 MatGetFactor() line 4492 in 
/zhome/32/9/115503/dealii-candi/tmp/build/petsc-lite-3.13.1/src/mat/interface/matrix.c

[0]PETSC ERROR: #2 PCSetUp_ILU() line 133 in 
/zhome/32/9/115503/dealii-candi/tmp/build/petsc-lite-3.13.1/src/ksp/pc/impls/factor/ilu/ilu.c

[0]PETSC ERROR: #3 PCSetUp() line 894 in 
/zhome/32/9/115503/dealii-candi/tmp/build/petsc-lite-3.13.1/src/ksp/pc/interface/precon.c



Exception on processing: 



An error occurred in line <431> of file 

 
in function

void dealii::PETScWrappers::PreconditionILU::initialize(const 
dealii::PETScWrappers::MatrixBase&, const 
dealii::PETScWrappers::PreconditionILU::AdditionalData&)

The violated condition was: 

ierr == 0

Additional information: 

deal.II encountered an error while calling a PETSc function.

The description of the error provided by PETSc is "See

https://www.mcs.anl.gov/petsc/documentation/linearsolvertable.html for

possible LU and Cholesky solvers".

The numerical value of the original error code is 92.





Could you please help me to understand what is happening?

Thank you again for your help
Regards, 
H
El viernes, 11 de marzo de 2022 a las 10:47:37 UTC+1, Hermes Sampedro 
escribió:

> Dear Bruno and Wolfgang, 
>
> thank you very much for your comments and help, it is very helpful. 
> Actually, I think that is what I am experiencing. When running with my 
> actual direct solver a system with 15 elements per direction (4th 
> polynomial order with 0.5million dof), the solver takes 50 seconds. 
> However, increasing to 30 elements per direction (3.5 million dof) the 
> solver takes 1.5 hours. I think this shows how it does not scale well in 
> terms of time as you mentioned. I will definitely try with the iterative 
> solver.
>
> Thannk you again
> Regards, 
> H.
> El jueves, 10 de marzo de 2022 a las 17:17:47 UTC+1, Wolfgang Bangerth 
> escribió:
>
>> On 3/10/22 07:00, Hermes Sampedro wrote: 
>> > I am experiencing long computational times with the solver function.  I 
>> am 
>> > trying to use DoFRenumbering::Cuthill_McKee(dof_handler), 
>> > DoFRenumbering::boost::Cuthill_McKee(dof_handler,false,false) 
>> > but I get even higher computational times. Am I doing something wrong? 
>>
>> Renumbering makes an enormous difference for sparse direct solvers, and 
>> as a 
>> consequence all such solvers I know of do it internally (though they use 
>> variations of the "minimum degree" renumbe

Re: [deal.II] Re: Assemble function, long time

[Hermes Sampedro]

Dear Bruno and Wolfgang, 

thank you very much for your comments and help, it is very helpful. 
Actually, I think that is what I am experiencing. When running with my 
actual direct solver a system with 15 elements per direction (4th 
polynomial order with 0.5million dof), the solver takes 50 seconds. 
However, increasing to 30 elements per direction (3.5 million dof) the 
solver takes 1.5 hours. I think this shows how it does not scale well in 
terms of time as you mentioned. I will definitely try with the iterative 
solver.

Thannk you again
Regards, 
H.
El jueves, 10 de marzo de 2022 a las 17:17:47 UTC+1, Wolfgang Bangerth 
escribió:

> On 3/10/22 07:00, Hermes Sampedro wrote:
> > I am experiencing long computational times with the solver function.  I 
> am 
> > trying to use DoFRenumbering::Cuthill_McKee(dof_handler), 
> > DoFRenumbering::boost::Cuthill_McKee(dof_handler,false,false)
> > but I get even higher computational times. Am I doing something wrong?
>
> Renumbering makes an enormous difference for sparse direct solvers, and as 
> a 
> consequence all such solvers I know of do it internally (though they use 
> variations of the "minimum degree" renumbering, rather than 
> Cuthill-McKee). As 
> a consequence, renumbering yourself likely makes no difference.
>
> But, as you discover and as Bruno already pointed out, even with optimal 
> ordering, direct solvers do not scale well both in terms of overall time 
> and 
> in parallelism. You may want to take a look at the several video lectures 
> on 
> solvers and preconditioners to see what you can do about your case.
>
> Best
> W.
>
> -- 
> 
> Wolfgang Bangerth email: bang...@colostate.edu
> 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 dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/c13e9b57-12cd-48fc-ba62-f48d3da3b6b2n%40googlegroups.com.

Re: [deal.II] Re: Assemble function, long time

[Hermes Sampedro]

Dear Bruno, 

Thank you very much, I will try this.
The last question if it is not too much to ask is about In the 
PreconditionILU matrix:

PETScWrappers::PreconditionILU::PreconditionILU
(const MatrixBase 
<https://dealii.org/current/doxygen/deal.II/classPETScWrappers_1_1MatrixBase.html>
 &  
matrix, const AdditionalData 
<https://dealii.org/current/doxygen/deal.II/structPETScWrappers_1_1PreconditionILU_1_1AdditionalData.html>
 &  
additional_data = AdditionalData 
<https://dealii.org/current/doxygen/deal.II/structPETScWrappers_1_1PreconditionILU_1_1AdditionalData.html>
() )

 Is it correct in this case to use my system_matrix? Is there any example 
in the tutorials about this? I can not find any.

Thank you very much
Regards, 
H.

El jueves, 10 de marzo de 2022 a las 15:29:59 UTC+1, bruno.t...@gmail.com 
escribió:

> If your matrix is symmetric definite positive, you use CG 
> <https://dealii.org/current/doxygen/deal.II/classPETScWrappers_1_1SolverCG.html>.
>  
> Otherwise, you use GMRES 
> <https://dealii.org/current/doxygen/deal.II/classPETScWrappers_1_1SolverGMRES.html>.
>  
> Here is the page for ILU 
> <https://dealii.org/current/doxygen/deal.II/classPETScWrappers_1_1PreconditionILU.html>
>
> Bruno
>
> Le jeu. 10 mars 2022 à 09:18, Hermes Sampedro  a 
> écrit :
> >
> > Thank you for your suggestions. Could you please suggest me what 
> function can work well for using a Krylov solver? I can no see examples.
> > My actual code is implemented using PETS (for sparsematrix, solver, 
> etc). I can see that SLEPcWrappers::SolverKrylovSchur allows PETS matrices.
> >
> >
> > Thank you again
> >
> > El jueves, 10 de marzo de 2022 a las 15:12:19 UTC+1, 
> bruno.t...@gmail.com escribió:
> >>
> >> Hermes,
> >>
> >> I think Cuthill-McKee only works on symmetric matrices, is your matrix
> >> symmetric? Also, the goal of Cuthill-McKee is to help with the fill in
> >> of the matrix.There is no guarantee that it helps with the
> >> performance. If you don't know which preconditioner to use, you can
> >> use ILU (Incomplete LU decomposition). Basically, you use a direct
> >> solver but you drop all the "small" entries in the matrix. It's not
> >> the best preconditioner but you can control how much time you spend in
> >> the "direct solver". The problem with direct solvers is that there is
> >> not much you can do to speed them up. In practice, everybody uses
> >> Krylov solvers because of the problems you are encountering now.
> >>
> >> Best,
> >>
> >> Bruno
> >>
> >> Le jeu. 10 mars 2022 à 09:00, Hermes Sampedro
> >>  a écrit :
> >> >
> >> > Hi Bruno,
> >> >
> >> > Yes, for now, I have to use a direct solver due to the preconditioner.
> >> > I am experiencing long computational times with the solver function. 
> I am trying to use DoFRenumbering::Cuthill_McKee(dof_handler), 
> DoFRenumbering::boost::Cuthill_McKee(dof_handler,false,false)
> >> > but I get even higher computational times. Am I doing something wrong?
> >> >
> >> > In the setup_system() function I do:
> >> > dof_handler.distribute_dofs(fe);
> >> > DoFRenumbering::Cuthill_McKee(dof_handler);
> >> >
> >> > Then thee solver is
> >> > void LaplaceProblem::solve()
> >> > {
> >> > PETScWrappers::MPI::Vector 
> completely_distributed_solution(locally_owned_dofs,mpi_communicator);
> >> > SolverControl cn;
> >> > PETScWrappers::SparseDirectMUMPS solver(cn, mpi_communicator);
> >> > solver.solve(system_matrix, completely_distributed_solution, 
> system_rhs);
> >> > constraints.distribute(completely_distributed_solution);
> >> > locally_relevant_solution = completely_distributed_solution;
> >> > }
> >> >
> >> > Thank you
> >> > Regards,
> >> > H
> >> >
> >> > El jueves, 10 de marzo de 2022 a las 14:54:13 UTC+1, 
> bruno.t...@gmail.com escribió:
> >> >>
> >> >> Hermes,
> >> >>
> >> >> For large systems, Krylov solvers are faster and require less memory
> >> >> than direct solvers. Direct solvers scale poorly, in terms of memory
> >> >> and performance, with the number of unknowns. The only problem with
> >> >> Krylov solvers is that you need to use a good preconditioner. The
> >> >> choice of the preconditioner depends on the system that you want to
> >> >

Re: [deal.II] Re: Assemble function, long time

[Hermes Sampedro]

Thank you for your suggestions. Could you please suggest me what function 
can work well for using a Krylov solver? I can no see examples.
My actual code is implemented using PETS (for sparsematrix, solver, etc). I 
can see that SLEPcWrappers::SolverKrylovSchur allows PETS matrices.


Thank you again

El jueves, 10 de marzo de 2022 a las 15:12:19 UTC+1, bruno.t...@gmail.com 
escribió:

> Hermes,
>
> I think Cuthill-McKee only works on symmetric matrices, is your matrix
> symmetric? Also, the goal of Cuthill-McKee is to help with the fill in
> of the matrix.There is no guarantee that it helps with the
> performance. If you don't know which preconditioner to use, you can
> use ILU (Incomplete LU decomposition). Basically, you use a direct
> solver but you drop all the "small" entries in the matrix. It's not
> the best preconditioner but you can control how much time you spend in
> the "direct solver". The problem with direct solvers is that there is
> not much you can do to speed them up. In practice, everybody uses
> Krylov solvers because of the problems you are encountering now.
>
> Best,
>
> Bruno
>
> Le jeu. 10 mars 2022 à 09:00, Hermes Sampedro
>  a écrit :
> >
> > Hi Bruno,
> >
> > Yes, for now, I have to use a direct solver due to the preconditioner.
> > I am experiencing long computational times with the solver function. I 
> am trying to use DoFRenumbering::Cuthill_McKee(dof_handler), 
> DoFRenumbering::boost::Cuthill_McKee(dof_handler,false,false)
> > but I get even higher computational times. Am I doing something wrong?
> >
> > In the setup_system() function I do:
> > dof_handler.distribute_dofs(fe);
> > DoFRenumbering::Cuthill_McKee(dof_handler);
> >
> > Then thee solver is
> > void LaplaceProblem::solve()
> > {
> > PETScWrappers::MPI::Vector 
> completely_distributed_solution(locally_owned_dofs,mpi_communicator);
> > SolverControl cn;
> > PETScWrappers::SparseDirectMUMPS solver(cn, mpi_communicator);
> > solver.solve(system_matrix, completely_distributed_solution, system_rhs);
> > constraints.distribute(completely_distributed_solution);
> > locally_relevant_solution = completely_distributed_solution;
> > }
> >
> > Thank you
> > Regards,
> > H
> >
> > El jueves, 10 de marzo de 2022 a las 14:54:13 UTC+1, 
> bruno.t...@gmail.com escribió:
> >>
> >> Hermes,
> >>
> >> For large systems, Krylov solvers are faster and require less memory
> >> than direct solvers. Direct solvers scale poorly, in terms of memory
> >> and performance, with the number of unknowns. The only problem with
> >> Krylov solvers is that you need to use a good preconditioner. The
> >> choice of the preconditioner depends on the system that you want to
> >> solve.
> >>
> >> Best,
> >>
> >> Bruno
> >>
> >> Le jeu. 10 mars 2022 à 02:51, Hermes Sampedro
> >>  a écrit :
> >> >
> >> > Dear Bruno,
> >> >
> >> > Thank you again for your answer.
> >> >
> >> > I managed to solve now a system of 3.5 million DOF using the same 
> solver as I posted above, SparseDirectMUMPS. Now, in release mode, the 
> assembling takes a few minutes instead of hours, however, the solver 
> function takes approximately 1.5h (per frequency iteration) using 40 
> processes in parallel (similar to step-40).
> >> >
> >> > I was expecting to get faster performance when running in parallel 
> with 40 processes, especially because I need to run for several 
> frequencies. I would like to ask if you also would expect faster 
> performance. Would that be solved using the solver that you suggested 
> (Krylov)?
> >> >
> >> >
> >> > Thank you
> >> >
> >> > Regards,
> >> >
> >> > H
> >> >
> >> >
> >> > El lunes, 7 de marzo de 2022 a las 15:04:19 UTC+1, 
> bruno.t...@gmail.com escribió:
> >> >>
> >> >> Hermes,
> >> >>
> >> >> The problem is that you are using a direct solver. Direct solvers
> >> >> require a lot of memory because the inverse of a sparse matrix is
> >> >> generally not sparse. If you use a LU decomposition, which I think
> >> >> MUMPS does, you need a dense matrix to store the LU decomposition.
> >> >> That's a lot of memory! You will need to use a Krylov to solve a
> >> >> problem of this size.
> >> >>
> >> >> Best,
> >> >>
> >

Re: [deal.II] Re: Assemble function, long time

[Hermes Sampedro]

Hi Bruno, 

Yes, for now, I have to use a direct solver due to the preconditioner. 
I am experiencing long computational times with the solver function.  I am 
trying to use DoFRenumbering::Cuthill_McKee(dof_handler), 
DoFRenumbering::boost::Cuthill_McKee(dof_handler,false,false) 

but I get even higher computational times. Am I doing something wrong?

In the setup_system() function I do: 
dof_handler.distribute_dofs(fe);
DoFRenumbering::Cuthill_McKee(dof_handler);

Then thee solver is
* void LaplaceProblem::solve()*
* {*
* PETScWrappers::MPI::Vector 
completely_distributed_solution(locally_owned_dofs,mpi_communicator);*
* SolverControl cn;*
* PETScWrappers::SparseDirectMUMPS solver(cn, mpi_communicator);*
* solver.solve(system_matrix, completely_distributed_solution, system_rhs);*
* constraints.distribute(completely_distributed_solution);*
* locally_relevant_solution = completely_distributed_solution;*
*}*

Thank you
Regards, 
H

El jueves, 10 de marzo de 2022 a las 14:54:13 UTC+1, bruno.t...@gmail.com 
escribió:

> Hermes,
>
> For large systems, Krylov solvers are faster and require less memory
> than direct solvers. Direct solvers scale poorly, in terms of memory
> and performance, with the number of unknowns. The only problem with
> Krylov solvers is that you need to use a good preconditioner. The
> choice of the preconditioner depends on the system that you want to
> solve.
>
> Best,
>
> Bruno
>
> Le jeu. 10 mars 2022 à 02:51, Hermes Sampedro
>  a écrit :
> >
> > Dear Bruno,
> >
> > Thank you again for your answer.
> >
> > I managed to solve now a system of 3.5 million DOF using the same solver 
> as I posted above, SparseDirectMUMPS. Now, in release mode, the assembling 
> takes a few minutes instead of hours, however, the solver function takes 
> approximately 1.5h (per frequency iteration) using 40 processes in parallel 
> (similar to step-40).
> >
> > I was expecting to get faster performance when running in parallel with 
> 40 processes, especially because I need to run for several frequencies. I 
> would like to ask if you also would expect faster performance. Would that 
> be solved using the solver that you suggested (Krylov)?
> >
> >
> > Thank you
> >
> > Regards,
> >
> > H
> >
> >
> > El lunes, 7 de marzo de 2022 a las 15:04:19 UTC+1, bruno.t...@gmail.com 
> escribió:
> >>
> >> Hermes,
> >>
> >> The problem is that you are using a direct solver. Direct solvers
> >> require a lot of memory because the inverse of a sparse matrix is
> >> generally not sparse. If you use a LU decomposition, which I think
> >> MUMPS does, you need a dense matrix to store the LU decomposition.
> >> That's a lot of memory! You will need to use a Krylov to solve a
> >> problem of this size.
> >>
> >> Best,
> >>
> >> Bruno
> >>
> >> Le dim. 6 mars 2022 à 07:19, Hermes Sampedro  a 
> écrit :
> >> >
> >> > Dear Bruno,
> >> >
> >> > Thank you very much for the comments. The problem was that I was 
> running in Debug mode without knowing. Now, after changing to Release the 
> assembling time is considerably reduced.
> >> >
> >> > Moreover, I am experiencing another issue that I would like to ask. 
> My mesh is done with hyper_cube() in 3D and 5 refinements. The dof is 
> around 3 million. When running, I always get a memory issue and the program 
> stops. I realized that the problem is in the line that executes 
> solver.solve(system_matrix, completely_distributed_solution, system_rhs);
> >> > I am using SparseMatrix and I do not fully understand where the 
> problem could come from. The matrices are initialized beforehand, what 
> reason do you think It could produce a memory issue in the solver?
> >> >
> >> > Below is the full solver function:
> >> >
> >> > template 
> >> > void LaplaceProblem::solve()
> >> > {
> >> > PETScWrappers::MPI::Vector 
> completely_distributed_solution(locally_owned_dofs,mpi_communicator);
> >> > SolverControl cn;
> >> > PETScWrappers::SparseDirectMUMPS solver(cn, mpi_communicator);
> >> > solver.solve(system_matrix, completely_distributed_solution, 
> system_rhs);
> >> > constraints.distribute(completely_distributed_solution);
> >> > locally_relevant_solution = completely_distributed_solution;
> >> > }
> >> >
> >> >
> >> > Thank you again for your help
> >> > Regards
> >> > H.
> >> >
> >> > El jueves, 3 de marzo de 2022 a las 1

Re: [deal.II] Re: Assemble function, long time

[Hermes Sampedro]

 

Dear Bruno,

Thank you again for your answer. 

I managed to solve now a system of 3.5 million DOF using the same solver as 
I posted above, *SparseDirectMUMPS. *Now, in release mode, the assembling 
takes a few minutes instead of hours, however,  the solver function takes 
approximately 1.5h (per frequency iteration) using 40 processes in parallel 
(similar to step-40). 

I was expecting to get faster performance when running in parallel with 40 
processes, especially because I need to run for several frequencies.  I 
would like to ask if you also would expect faster performance. Would that 
be solved using the solver that you suggested (Krylov)?


Thank you

Regards, 

H

El lunes, 7 de marzo de 2022 a las 15:04:19 UTC+1, bruno.t...@gmail.com 
escribió:

> Hermes,
>
> The problem is that you are using a direct solver. Direct solvers
> require a lot of memory because the inverse of a sparse matrix is
> generally not sparse. If you use a LU decomposition, which I think
> MUMPS does, you need a dense matrix to store the LU decomposition.
> That's a lot of memory! You will need to use a Krylov to solve a
> problem of this size.
>
> Best,
>
> Bruno
>
> Le dim. 6 mars 2022 à 07:19, Hermes Sampedro  a 
> écrit :
> >
> > Dear Bruno,
> >
> > Thank you very much for the comments. The problem was that I was running 
> in Debug mode without knowing. Now, after changing to Release the 
> assembling time is considerably reduced.
> >
> > Moreover, I am experiencing another issue that I would like to ask. My 
> mesh is done with hyper_cube() in 3D and 5 refinements. The dof is around 3 
> million. When running, I always get a memory issue and the program stops. I 
> realized that the problem is in the line that executes 
> solver.solve(system_matrix, completely_distributed_solution, system_rhs);
> > I am using SparseMatrix and I do not fully understand where the problem 
> could come from. The matrices are initialized beforehand, what reason do 
> you think It could produce a memory issue in the solver?
> >
> > Below is the full solver function:
> >
> > template 
> > void LaplaceProblem::solve()
> > {
> > PETScWrappers::MPI::Vector 
> completely_distributed_solution(locally_owned_dofs,mpi_communicator);
> > SolverControl cn;
> > PETScWrappers::SparseDirectMUMPS solver(cn, mpi_communicator);
> > solver.solve(system_matrix, completely_distributed_solution, system_rhs);
> > constraints.distribute(completely_distributed_solution);
> > locally_relevant_solution = completely_distributed_solution;
> > }
> >
> >
> > Thank you again for your help
> > Regards
> > H.
> >
> > El jueves, 3 de marzo de 2022 a las 15:13:30 UTC+1, bruno.t...@gmail.com 
> escribió:
> >>
> >> Hermes,
> >>
> >> There is a couple of things that you could do but it probably won't 
> give you a significant speed up. Are you sure that you are running in 
> Release mode and not in Debug? Do you evaluate complicated functions in the 
> assembly?
> >> A couple changes that could help:
> >> - don't use fe.system_to_component_index(i).first and 
> fe.system_to_component_index(j).first everywhere. Just define const k = ... 
> and const m = ... and use k and m. That might help the compiler with some 
> optimizations
> >> - move the two if for the cell assembly outside the for loop on the 
> quadrature point, similar to what you did for the boundaries. This could 
> potentially help quite a bit if the cpu often gets the branch prediction 
> wrong
> >>
> >> Best,
> >>
> >> Bruno
> >>
> >> On Thursday, March 3, 2022 at 4:31:04 AM UTC-5 hermes...@gmail.com 
> wrote:
> >>>
> >>> Dear all,
> >>>
> >>> I am experiencing long times when computing the assembling and I would 
> like to ask if this is common or there is something wrong with my 
> implementation.
> >>>
> >>> My model is built in a similar way as step-29 and step-40 (using 
> complex values ad solving with a direct solver using distributed parallel 
> implementation).
> >>> Now I am running larger systems with 3.5million dof and the assembling 
> took 16h, while the solver function took much less.
> >>>
> >>> I can show the structure of my assembly_system() function to ask if 
> there is something that can be done in order to speed up the process:
> >>>
> >>> void Problem::assemble_system()
> >>> {
> >>> for (unsigned int i = 0; i < dofs_per_cell; ++i) {
> >>> for (unsigned int j = 0; j < dofs_per_cell; ++j)
> >>> 

[deal.II] Re: Assemble function, long time

[Hermes Sampedro]

Dear Bruno, 

Thank you very much for the comments. The problem was that I was running in 
Debug mode without knowing. Now, after changing to Release the assembling 
time is considerably reduced.

Moreover, I am experiencing another issue that I would like to ask. My mesh 
is done with hyper_cube() in 3D and 5 refinements. The dof is around 3 
million. When running, I always get a memory issue and the program stops. I 
realized that the problem is in the line that executes 
*solver.solve(system_matrix, 
completely_distributed_solution, system_rhs);*
I am using SparseMatrix and I do not fully understand where the problem 
could come from. The matrices are initialized beforehand, what reason do 
you think It could produce a memory issue in the solver?

Below is the full solver function:

* template *
* void LaplaceProblem::solve()*
* {*
* PETScWrappers::MPI::Vector 
completely_distributed_solution(locally_owned_dofs,mpi_communicator);*
* SolverControl cn;*
* PETScWrappers::SparseDirectMUMPS solver(cn, mpi_communicator);*
* solver.solve(system_matrix, completely_distributed_solution, system_rhs);*
* constraints.distribute(completely_distributed_solution);*
* locally_relevant_solution = completely_distributed_solution;*
*}*


Thank you again for your help
Regards
H.

El jueves, 3 de marzo de 2022 a las 15:13:30 UTC+1, bruno.t...@gmail.com 
escribió:

> Hermes,
>
> There is a couple of things that you could do but it probably won't give 
> you a significant speed up. Are you sure that you are running in Release 
> mode and not in Debug? Do you evaluate complicated functions in the 
> assembly?
> A couple changes that could help:
> - don't use *fe.system_to_component_index(i).first *and 
> f*e.system_to_component_index(j).first  
> *everywhere. Just define const k = ... and const m = ... and use k and m. 
> That might help the compiler with some optimizations
> - move the two if for the cell assembly outside the for loop on the 
> quadrature point, similar to what you did for the boundaries. This could 
> potentially help quite a bit if the cpu often gets the branch prediction 
> wrong 
>
> Best,
>
> Bruno 
>
> On Thursday, March 3, 2022 at 4:31:04 AM UTC-5 hermes...@gmail.com wrote:
>
>> Dear all, 
>>
>> I am experiencing long times when computing the assembling and I would 
>> like to ask if this is common or there is something wrong with my 
>> implementation.
>>
>> My model is built in a similar way as step-29 and step-40 (using complex 
>> values ad solving with a direct solver using distributed parallel 
>> implementation).
>> Now I am running larger systems with 3.5million dof and the assembling 
>> took 16h, while the solver function took much less.
>>
>>  I can show the structure of my assembly_system() function to ask if 
>> there is something that can be done in order to speed up the process:
>>
>>
>> *void Problem::assemble_system()*
>> *{*
>> * for (unsigned int i = 0; i < dofs_per_cell; ++i) {*
>> * for (unsigned int j = 0; j < dofs_per_cell; ++j)*
>> * {*
>> * for (unsigned int q_point = 0; q_point < n_q_points; ++q_point)*
>> * { *
>> * if (fe.system_to_component_index(i).first == 
>> fe.system_to_component_index(j).first)*
>> * {*
>> * cell_matrix(i, j) += *
>>
>> * }*
>> * if (fe.system_to_component_index(i).first != 
>> fe.system_to_component_index(j).first)*
>> * {*
>> * cell_matrix(i, j) += *
>> * }*
>>
>> * }*
>>
>> // Boundaries
>> * if (fe.system_to_component_index(i).first == 
>> fe.system_to_component_index(j).first)*
>> * {*
>> * for (unsigned int face_no : GeometryInfo::face_indices())*
>> * if (cell->face(face_no)->at_boundary() && 
>> (cell->face(face_no)->boundary_id() == 0))*
>> * {*
>> * fe_face_values.reinit(cell, face_no);*
>> * for (unsigned int q_point = 0; q_point < n_face_q_points; ++q_point)*
>> * cell_matrix(i, j) += *
>> * }*
>> * }*
>> * if (fe.system_to_component_index(i).first != 
>> fe.system_to_component_index(j).first)*
>> * {*
>> * for (unsigned int face_no : GeometryInfo::face_indices())*
>> * {*
>> * if (cell->face(face_no)->at_boundary() && 
>> (cell->face(face_no)->boundary_id() == 0))*
>> * {*
>> * fe_face_values.reinit(cell, face_no);*
>> * for (unsigned int q_point = 0; q_point < n_face_q_points;++q_point)*
>> * cell_matrix(i, j) += *
>> * }*
>> * }*
>>
>> * }*
>>
>> * } *
>> *}*
>>
>>
>> Thank you very much.
>> Regards, 
>> Hermes
>>
>

-- 
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/d80cbd1c-7d1f-4042-a9e8-e8382a721790n%40googlegroups.com.

[deal.II] Assemble function, long time

[Hermes Sampedro]

Dear all, 

I am experiencing long times when computing the assembling and I would like 
to ask if this is common or there is something wrong with my implementation.

My model is built in a similar way as step-29 and step-40 (using complex 
values ad solving with a direct solver using distributed parallel 
implementation).
Now I am running larger systems with 3.5million dof and the assembling took 
16h, while the solver function took much less.

 I can show the structure of my assembly_system() function to ask if there 
is something that can be done in order to speed up the process:


*void Problem::assemble_system()*
*{*
* for (unsigned int i = 0; i < dofs_per_cell; ++i) {*
* for (unsigned int j = 0; j < dofs_per_cell; ++j)*
* {*
* for (unsigned int q_point = 0; q_point < n_q_points; ++q_point)*
* { *
* if (fe.system_to_component_index(i).first == 
fe.system_to_component_index(j).first)*
* {*
* cell_matrix(i, j) += *

* }*
* if (fe.system_to_component_index(i).first != 
fe.system_to_component_index(j).first)*
* {*
* cell_matrix(i, j) += *
* }*

* }*

// Boundaries
* if (fe.system_to_component_index(i).first == 
fe.system_to_component_index(j).first)*
* {*
* for (unsigned int face_no : GeometryInfo::face_indices())*
* if (cell->face(face_no)->at_boundary() && 
(cell->face(face_no)->boundary_id() == 0))*
* {*
* fe_face_values.reinit(cell, face_no);*
* for (unsigned int q_point = 0; q_point < n_face_q_points; ++q_point)*
* cell_matrix(i, j) += *
* }*
* }*
* if (fe.system_to_component_index(i).first != 
fe.system_to_component_index(j).first)*
* {*
* for (unsigned int face_no : GeometryInfo::face_indices())*
* {*
* if (cell->face(face_no)->at_boundary() && 
(cell->face(face_no)->boundary_id() == 0))*
* {*
* fe_face_values.reinit(cell, face_no);*
* for (unsigned int q_point = 0; q_point < n_face_q_points;++q_point)*
* cell_matrix(i, j) += *
* }*
* }*

* }*

* } *
*}*


Thank you very much.
Regards, 
Hermes

-- 
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/299f4da5-cf2f-470f-8076-c759c092549fn%40googlegroups.com.

[deal.II] Assembling

[Hermes Sampedro]

Dear all, 

I am experiencing long time to computee the assembling and I would like to 
ask if this is common or there is something wrong with my implementation.

My model is built in a similar way as step-29 and step-40 (using complex 
values ad solving with a direct solver using distributed parallel 
implementation). I can show the structure of my assembly_system() function 
to see if there is something that can be in another way to save some time:

void Problem::assemble_system()
{
for (unsigned int i = 0; i < dofs_per_cell; ++i)
{
for (unsigned int j = 0; j < dofs_per_cell; ++j)
{
//Look that both are from the same compontent (real or imag)
for (unsigned int q_point = 0; q_point < n_q_points; ++q_point)
{

if (fe.system_to_component_index(i).first == 
fe.system_to_component_index(j).first)
{


}

-- 
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/84151a52-e3c1-4cad-9d63-02ff5e2a6816n%40googlegroups.com.

Re: [deal.II] Solution mismatch (FullMatrix vs. PETScWrappers::MPI::SparseMatrix)

[Hermes Sampedro]

Thank you very much

Regards

El martes, 8 de febrero de 2022 a las 23:40:58 UTC+1, Timo Heister escribió:

> > *L_operator(local_dof_indices[i],local_dof_indices[j]) = 
> cell_matrix(i,j);*
>
> *This looks incorrect, because global pairs of indices will happen more 
> than once in a normal assembly (with a continuous finite element). You have 
> to add the contribution using +=.*
>
>
> On Tue, Feb 8, 2022, 16:52 Hermes Sampedro  wrote:
>
>>
>> Dear Wolfgang, 
>>
>> Thank you for the clarification. In that case, I am missing some 
>> operation somewhere...
>>
>> Let me clarify what I am doing. Apart from building the system_matrix, I 
>> save the operator L in the assembling process. But I did not do any 
>> distribute_local_to_global nor compress to that operator, as I do for the 
>> system matrix. Is that wrong?
>>
>>
>> 
>> *for (const auto &cell : dof_handler.active_cell_iterators())*
>> * if (cell->is_locally_owned())*
>> *{*
>> * for (unsigned int i = 0; i < dofs_per_cell; ++i)*
>> * { ..*
>> * for (unsigned int j = 0; j < dofs_per_cell; ++j)*
>> * {. .*
>> * cell_matrix(i, j)= *
>> * *
>> * L_operator(local_dof_indices[i],local_dof_indices[j]) = 
>> cell_matrix(i,j);*
>> * }*
>> * }*
>>
>> * cell->get_dof_indices(local_dof_indices);*
>> * constraints.distribute_local_to_global(cell_matrix,*
>> * cell_rhs,*
>> * local_dof_indices,*
>> * system_matrix,*
>> * system_rhs);*
>> *}*
>> *system_matrix.compress(VectorOperation::add);*
>> *system_rhs.compress(VectorOperation::add);*
>>
>> 
>>
>> I checked the content of the matrics by solving a very small case. I 
>> found that indeed system_matrix is different to the saved operator L.  Do 
>> you have any suggestion where the different is coming from? Both are taken 
>> from the same assembling, the difference is that system_matrix applies 
>> *distribute_local_to_global() 
>> and compress().*
>>
>> Thank you again.
>> Regards
>> El martes, 8 de febrero de 2022 a las 22:22:37 UTC+1, Wolfgang Bangerth 
>> escribió:
>>
>>> On 2/8/22 09:06, Hermes Sampedro wrote: 
>>> > 
>>> > I checked that in both cases, the operators/system_matrix have the 
>>> same 
>>> > values just in the assemble_system() function. I was wondering if 
>>> there 
>>> > is something internally that change somehow the systme_matrix. I can 
>>> see 
>>> > that after checking the values of the operators I have the following 
>>> > lines which I am not sure if there is something happening: 
>>>
>>> No functions in deal.II touch your linear system unless you specifically 
>>> call a function that takes a matrix or vector as argument. So, if you 
>>> have the distribute_local_to_global() call for one type of matrix, you 
>>> need to call it for the other kind of matrix as well. But these 
>>> functions do not internally store some kind of magic pointer to the 
>>> matrix and right hand side so that at some later point, when you're not 
>>> watching, they do something nefarious to your matrix :-) 
>>>
>>> My suggestion would be to make sure that before the solve, the two 
>>> matrices and corresponding right hand sides are the same. This is often 
>>> awkward if the objects are large, but you can test this by outputting 
>>> the norm of these objects. 
>>>
>>> Then check that the solution is also the same. My guess is that for some 
>>> reason, either the matrix or the rhs are different. 
>>>
>>> Best 
>>> W. 
>>>
>>> -- 
>>>  
>>> Wolfgang Bangerth email: bang...@colostate.edu 
>>> 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 dealii+un...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/dealii/0b63fba4-0c3f-4727-9ce2-18ddc897aba9n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/dealii/0b63fba4-0c3f-4727-9ce2-18ddc897aba9n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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/fa14a63c-bbdf-4ae4-9f25-b8346897232fn%40googlegroups.com.

Re: [deal.II] MPI & component_wise

[Hermes Sampedro]

Thank you very much

Regards

El martes, 15 de febrero de 2022 a las 16:11:08 UTC+1, Wolfgang Bangerth 
escribió:

> On 2/15/22 01:52, Joss G. wrote:
> > *** Caution: EXTERNAL Sender ***
> > 
> > Thank you again. It seems I am having bit of trouble.
> > 
> > I used: parallel::distributed:Vector locally_relevant_solution;
> > 
> > In the documentation is written to call 
> > #include but the file is not there. Using 
> > #include I get the following error:
> > 
> > *:* *error: *‘*Vector*’ in namespace ‘*dealii::parallel::distributed*’ 
> does 
> > not name a template type
> > 
> > 
> > What am I doing wrong?
>
> I misspelled the name of the class. It is 
> LinearAlgebra::distributed::Vector 
> and it is used in a number of tutorial programs (37, 48, 50, 59, 66, ...).
>
> Best
> W.
>
> -- 
> 
> Wolfgang Bangerth email: bang...@colostate.edu
> 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 dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/74369abb-ca82-427a-a140-1207a1b86b9dn%40googlegroups.com.

Re: [deal.II] Solution mismatch (FullMatrix vs. PETScWrappers::MPI::SparseMatrix)

[Hermes Sampedro]

Dear Wolfgang, 

Thank you for the clarification. In that case, I am missing some operation 
somewhere...

Let me clarify what I am doing. Apart from building the system_matrix, I 
save the operator L in the assembling process. But I did not do any 
distribute_local_to_global nor compress to that operator, as I do for the 
system matrix. Is that wrong?


*for (const auto &cell : dof_handler.active_cell_iterators())*
* if (cell->is_locally_owned())*
*{*
* for (unsigned int i = 0; i < dofs_per_cell; ++i)*
* { ..*
* for (unsigned int j = 0; j < dofs_per_cell; ++j)*
* {. .*
* cell_matrix(i, j)= *
* *
* L_operator(local_dof_indices[i],local_dof_indices[j]) = cell_matrix(i,j);*
* }*
* }*

* cell->get_dof_indices(local_dof_indices);*
* constraints.distribute_local_to_global(cell_matrix,*
* cell_rhs,*
* local_dof_indices,*
* system_matrix,*
* system_rhs);*
*}*
*system_matrix.compress(VectorOperation::add);*
*system_rhs.compress(VectorOperation::add);*


I checked the content of the matrics by solving a very small case. I found 
that indeed system_matrix is different to the saved operator L.  Do you 
have any suggestion where the different is coming from? Both are taken from 
the same assembling, the difference is that system_matrix applies 
*distribute_local_to_global() 
and compress().*

Thank you again.
Regards
El martes, 8 de febrero de 2022 a las 22:22:37 UTC+1, Wolfgang Bangerth 
escribió:

> On 2/8/22 09:06, Hermes Sampedro wrote:
> > 
> > I checked that in both cases, the operators/system_matrix have the same 
> > values just in the assemble_system() function. I was wondering if there 
> > is something internally that change somehow the systme_matrix. I can see 
> > that after checking the values of the operators I have the following 
> > lines which I am not sure if there is something happening:
>
> No functions in deal.II touch your linear system unless you specifically 
> call a function that takes a matrix or vector as argument. So, if you 
> have the distribute_local_to_global() call for one type of matrix, you 
> need to call it for the other kind of matrix as well. But these 
> functions do not internally store some kind of magic pointer to the 
> matrix and right hand side so that at some later point, when you're not 
> watching, they do something nefarious to your matrix :-)
>
> My suggestion would be to make sure that before the solve, the two 
> matrices and corresponding right hand sides are the same. This is often 
> awkward if the objects are large, but you can test this by outputting 
> the norm of these objects.
>
> Then check that the solution is also the same. My guess is that for some 
> reason, either the matrix or the rhs are different.
>
> Best
> W.
>
> -- 
> 
> Wolfgang Bangerth email: bang...@colostate.edu
> 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 dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/0b63fba4-0c3f-4727-9ce2-18ddc897aba9n%40googlegroups.com.

[deal.II] Solution mismatch (FullMatrix vs. PETScWrappers::MPI::SparseMatrix)

[Hermes Sampedro]

Dear all, 

I am experiencing strange behaviour in what I am trying to do and I would 
like to ask for a bit of support.

I have a running solver done with a distributed MPI implementation. The 
solver is similar to step-29, where real and imaginary parts are used and a 
2N system is solved.
Now I want to apply reduced basis methods to it and to do that I will solve 
a FullMatrix system Lx=b by x=L^1*b.
For now, and to have a sanity check,  what I am doing is to convert the 
operators (PETScWrappers::MPI::SparseMatrix) to FullMatrix after 
assemble_system(), 
 and solve the system by inverting the operator and using vmult(). However, 
the results are different when I solve with sparse matrix compared to 
FullMatrix.
The solver code is bellow, where * locally_relevant_solution *is the 
solution for the distributed system and *solution_rb* is thee 
for the FullMatrix system.
__
* void Problem::solve()*
*{*
*//Distributed solver*
* PETScWrappers::MPI::Vector 
completely_distributed_solution(locally_owned_dofs,mpi_communicator);*
* SolverControl cn;*
* PETScWrappers::SparseDirectMUMPS solver(cn, mpi_communicator);*
* solver.solve(system_matrix, completely_distributed_solution, system_rhs);*
* constraints.distribute(completely_distributed_solution);*
* locally_relevant_solution = completely_distributed_solution;*
*// Full matrix solver*
* FullMatrix Linv(dof_handler.n_dofs(),dof_handler.n_dofs()); *
* Vector solution_rb(dof_handler.n_dofs());*
* Linv.invert(L);*
* Linv.vmult(solution_rb,b,false);*
*}*
__

I checked that in both cases, the operators/system_matrix have the same 
values just in the assemble_system() function. I was wondering if there is 
something internally that change somehow the systme_matrix. I can see that 
after checking the values of the operators I have the following lines which 
I am not sure if there is something happening:

_
*...*
* constraints.distribute_local_to_global(cell_matrix,*
* cell_rhs,*
* local_dof_indices,*
* system_matrix,*
* system_rhs);*
* }*
* system_matrix.compress(VectorOperation::add);*
* system_rhs.compress(VectorOperation::add);*
_


An example of how the results mismatch is given in the following figure 
where the dotted line corresponds to the solution with FullMatrix and the 
line corresponds to the distributed solution.

[image: result.png]

I have to add that the distributed solver that I have is validated and 
thus, I trust the solutions. It looks like there is a multiplication factor 
somewhere, that I am missing where using the FullMatrix. 

Thank you very much for your help. Regards, 



-- 
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/03437f5b-5d49-4b84-8367-7e9d34f382e8n%40googlegroups.com.

Re: [deal.II] Ordering using multi-components

[Hermes Sampedro]

Dear Wolfgang Bangerth,

Thank you very much for your answer and for pointing to the relevant steps 
examples.

I would like to be sure that I am doing the right thing. First, I used 
DoFRenumbering::component_wise(dof_handler) and got the desired order, 
thank you. Then I use the extractors
*const FEValuesExtractors::Scalar real_component(0);*
* const FEValuesExtractors::Scalar imag_component(1);*

*Is it correct the following approach to get the global mass matrix of one 
component? *I get a big 2x2 block matrix with non-zero values on the left 
top block. Is this corresponding to the global mass matrix of one of the 
components?
*Mass_matrix_tmp(i,j)+=((fe_values[real_component].value(i, q_point) * 
fe_values[real_component].value(j, q_point)) * fe_values.JxW(q_point));*


Thank you again.
Best regards, 

El lunes, 8 de noviembre de 2021 a las 23:04:48 UTC+1, Wolfgang Bangerth 
escribió:

>
> Joss:
>
> > It is not very clear to me what is the order followed when using 
> > multi-components. As an example to put my question more clear I cann 
> > point to step-29 where there are 2 components used.
> > 
> > My common sense would be that the system_matrix global operator would 
> > have first real and then the imaginar components. However, printing the 
> > matrix and looking at it, I can see the values are somehow intercalated 
> > (rows and columns).
> > *Could someone please clarify this?*
>
> The way we typically like to think about this is that the DoFHandler 
> chooses "some" order that simply is what it is. If you want something 
> specific, you need to say so explicitly. In your case, if you want all 
> of the real components first and then all of the imaginary components, 
> then you need to say that that is what you want, and the way to do that 
> is DoFRenumbering::component_wise(). This function is used in any number 
> of tutorial programs, see for example step-20 and step-22.
>
>
> > I would also like to ask how can I get the mass matrix of one of the 
> > components. Using the following for each cell and locating for the 
> > global matrix I get the two components (again not sure how the order 
> is...)
> > /Mass_matrix(i,j)+=((fe_values.shape_value(i, q_point) * 
> > fe_values.shape_value(j, q_point)) * fe_values.JxW(q_point));/
>
> This results in a different matrix than you want: If the matrix was 
> structured by component (i.e., it is a 2x2 block matrix), then each of 
> the four blocks will end up with a mass matrix. That's likely not what 
> you intended.
>
> On the other hand...
>
> > 
> > On the other hand, using the following, does not allow me to use the 
> > local_dof_indices function, as using only one component, the dof is half:
> > /Mass_matrix(i,j)+=((fe_values.shape_value_component(i, q_point,0) * 
> > fe_values.shape_value(j, q_point,0)) * fe_values.JxW(q_point));/
>
> ...this will only put a mass matrix into the top left block.
>
> The general strategy to working with all multi-component problems is to 
> use the "extractors". See again step-20, step-22, and the documentation 
> module about vector-valued problems.
>
> Best
> W.
>
>
> -- 
> 
> Wolfgang Bangerth email: bang...@colostate.edu
> 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 dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/4753691e-f4e5-4934-9553-a7fa958496bcn%40googlegroups.com.

[deal.II] n components with matrix-free and MPI

[Hermes Sampedro]

Dear all, 

I am having some trouble understanding how to have access to the different 
components (2 for complex values) in a matrix-free implementation and MPI. 
I need to have access to each component to perform the different operations 
to them in the *local_apply()* function.

I saw this documentation 
(https://www.dealii.org/current/doxygen/deal.II/classFEEvaluation.html, 
@Handling multi-component systems) which get the components using 
BlockVectors. 
However, I define in my class *FESystem  fe;  *and after, 
*fe(FE_Q(degree), 
2) * to have 2 components and use LinearAlgebra::distributed::Vector 

 for 
the solution, dst, scr.
In this case, is it possible to have access to the different components 
using blocks() as it is done in the example (
https://github.com/dealii/dealii/blob/master/tests/matrix_free/matrix_vector_stokes_noflux.cc,
 
line 67) using for example phi.read_dof_values(src.block(0)) ?


I would really appreciate it if I can get help on this matter.

Regards, 
H.



-- 
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/320fbf7d-9532-4c2f-9952-46e3f501316en%40googlegroups.com.

[deal.II] Re: MatrixFree & complex-valued Helmholtz equation

[Hermes Sampedro]

Hi again, 
I realized that there is an option to set* n_components*. Is it the right 
parameter to choose the number of components (assuming that I set the right 
components on FE_Q)?

*using LaplaceType = 
MatrixFreeOperators::LaplaceOperator>*

*LaplaceType Laplace_matrix;*

If this is right, I would like to ask the last question if you do not mind. 
Assuming that I create a MatrixFreeOperators::LaplaceOperator and a 
MatrixFreeOperators::MassOperator
for example:

*MassType mass_matrx;*
*LaplaceType Laplace_matrix;  *


How could I get an operator* K * that contains both, mass matrix (*M*) and 
laplace (*L*) matrix as for example: *K = M + L*? Is that possible with 
this approach?

Thank you again
Regards, 
H.




El martes, 19 de octubre de 2021 a las 11:27:11 UTC+2, Hermes Sampedro 
escribió:

> Thank you very much for the answer. 
> I read step-67 and 59 and is somewhere mentioned that there are many 
> different ways to deal with multiple components. In my case (complex 
> values) need only 2.
> I was wondering if it is possible to use the 
> MatrixFreeOperators::LaplaceOperator 
> and MatrixFreeOperators::MassOperato with 2 components. If so, could you 
> please give me some clues? 
>
> Thank you very much.
> Regards, 
> Hermes
>
> El lunes, 18 de octubre de 2021 a las 6:32:54 UTC+2, peterrum escribió:
>
>> Hi Hermes,
>>
>> I would suggest that you first take a look at step-67 (
>> https://www.dealii.org/developer/doxygen/deal.II/step_67.html): it deals 
>> with systems with multiple components. Although I am not particular 
>> familiar with step-29, I guess you can express your complex system as two 
>> component system so that many aspects shown in step-67 could be used here.
>>
>> PM
>>
>> On Friday, 15 October 2021 at 14:02:10 UTC+2 hermes...@gmail.com wrote:
>>
>>> Dear all, 
>>>
>>> I still have issues figuring out how to have access to the component 
>>> index when doing a MatrixFree implementation with complex values. I would 
>>> really appreciate it if someone could help me.
>>>
>>> Thank you very much
>>> Regards, 
>>> H
>>>
>>> El miércoles, 13 de octubre de 2021 a las 19:07:07 UTC+3, Hermes 
>>> Sampedro escribió:
>>>
>>>> Good evening, 
>>>>
>>>> I am implementing the problem presented in step-29 using a MatrixFree 
>>>> approach as presented in step-37.
>>>>
>>>> I have few questions that I would like to ask regarding the 
>>>> local_apply() function (shown in step-37):
>>>>
>>>>- I am confused about the way of having access to the different 
>>>>complex components. In this case, as the double for loop (i, j) is 
>>>>avoided,  the condition  
>>>>
>>>> *if(phi.system_to_component_index(i).first==phi.system_to_component_index(j).fsst)
>>>>   * is 
>>>>not longer valid. How can I include it in this particular case?
>>>>- In step-29 we had in the assemble_system(): *cell_matrix(i, j) 
>>>>+=(((fe_values.shape_value(i, q_point) *fe_values.shape_value(j, 
>>>> q_point)) 
>>>>*(-omega * omega) +(fe_values.shape_grad(i, q_point) 
>>>>*fe_values.shape_grad(j, q_point)) *c * c) *fe_values.JxW(q_point));  * 
>>>> Is 
>>>>it right to write it here as: 
>>>>*(omega*omega)*phi.get_values(q)+phi.get_gradient(q)*(c*c)*phi.JxW(q);*
>>>>- The same has to be repeated for 
>>>>
>>>>
>>>> [image: Captura de pantalla 2021-10-13 a las 18.54.55.png]
>>>>
>>>> Thank you very much
>>>> Regards, 
>>>> H.
>>>>
>>>

-- 
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/ce86d354-f1ed-4132-818e-01ae46e92c50n%40googlegroups.com.

[deal.II] Re: MatrixFree & complex-valued Helmholtz equation

[Hermes Sampedro]

Thank you very much for the answer. 
I read step-67 and 59 and is somewhere mentioned that there are many 
different ways to deal with multiple components. In my case (complex 
values) need only 2.
I was wondering if it is possible to use the 
MatrixFreeOperators::LaplaceOperator 
and MatrixFreeOperators::MassOperato with 2 components. If so, could you 
please give me some clues? 

Thank you very much.
Regards, 
Hermes

El lunes, 18 de octubre de 2021 a las 6:32:54 UTC+2, peterrum escribió:

> Hi Hermes,
>
> I would suggest that you first take a look at step-67 (
> https://www.dealii.org/developer/doxygen/deal.II/step_67.html): it deals 
> with systems with multiple components. Although I am not particular 
> familiar with step-29, I guess you can express your complex system as two 
> component system so that many aspects shown in step-67 could be used here.
>
> PM
>
> On Friday, 15 October 2021 at 14:02:10 UTC+2 hermes...@gmail.com wrote:
>
>> Dear all, 
>>
>> I still have issues figuring out how to have access to the component 
>> index when doing a MatrixFree implementation with complex values. I would 
>> really appreciate it if someone could help me.
>>
>> Thank you very much
>> Regards, 
>> H
>>
>> El miércoles, 13 de octubre de 2021 a las 19:07:07 UTC+3, Hermes Sampedro 
>> escribió:
>>
>>> Good evening, 
>>>
>>> I am implementing the problem presented in step-29 using a MatrixFree 
>>> approach as presented in step-37.
>>>
>>> I have few questions that I would like to ask regarding the 
>>> local_apply() function (shown in step-37):
>>>
>>>- I am confused about the way of having access to the different 
>>>complex components. In this case, as the double for loop (i, j) is 
>>>avoided,  the condition  
>>>
>>> *if(phi.system_to_component_index(i).first==phi.system_to_component_index(j).fsst)
>>>   * is 
>>>not longer valid. How can I include it in this particular case?
>>>- In step-29 we had in the assemble_system(): *cell_matrix(i, j) 
>>>+=(((fe_values.shape_value(i, q_point) *fe_values.shape_value(j, 
>>> q_point)) 
>>>*(-omega * omega) +(fe_values.shape_grad(i, q_point) 
>>>*fe_values.shape_grad(j, q_point)) *c * c) *fe_values.JxW(q_point));  * 
>>> Is 
>>>it right to write it here as: 
>>>*(omega*omega)*phi.get_values(q)+phi.get_gradient(q)*(c*c)*phi.JxW(q);*
>>>- The same has to be repeated for 
>>>
>>>
>>> [image: Captura de pantalla 2021-10-13 a las 18.54.55.png]
>>>
>>> Thank you very much
>>> Regards, 
>>> H.
>>>
>>

-- 
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/1a09964f-2421-49c2-ac5f-76bcdfb61888n%40googlegroups.com.

[deal.II] Re: MatrixFree & complex-valued Helmholtz equation

[Hermes Sampedro]

Dear all, 

I still have issues figuring out how to have access to the component index 
when doing a MatrixFree implementation with complex values. I would really 
appreciate it if someone could help me.

Thank you very much
Regards, 
H

El miércoles, 13 de octubre de 2021 a las 19:07:07 UTC+3, Hermes Sampedro 
escribió:

> Good evening, 
>
> I am implementing the problem presented in step-29 using a MatrixFree 
> approach as presented in step-37.
>
> I have few questions that I would like to ask regarding the local_apply() 
> function (shown in step-37):
>
>- I am confused about the way of having access to the different 
>complex components. In this case, as the double for loop (i, j) is 
>avoided,  the condition  
>
> *if(phi.system_to_component_index(i).first==phi.system_to_component_index(j).fsst)
>   * is 
>not longer valid. How can I include it in this particular case?
>- In step-29 we had in the assemble_system(): *cell_matrix(i, j) 
>+=(((fe_values.shape_value(i, q_point) *fe_values.shape_value(j, q_point)) 
>*(-omega * omega) +(fe_values.shape_grad(i, q_point) 
>*fe_values.shape_grad(j, q_point)) *c * c) *fe_values.JxW(q_point));  * Is 
>it right to write it here as: 
>*(omega*omega)*phi.get_values(q)+phi.get_gradient(q)*(c*c)*phi.JxW(q);*
>- The same has to be repeated for 
>
>
> [image: Captura de pantalla 2021-10-13 a las 18.54.55.png]
>
> Thank you very much
> Regards, 
> H.
>

-- 
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/ca6ad5c7-9c02-46d8-a1d5-7e5cd2d15acfn%40googlegroups.com.

Re: [deal.II] SparseMatrix

[Hermes Sampedro]

Dear Wolfgang,

Thank you for your answer. Knowing that this is the way to do that, helped
me to found the problem I had.

Thank you again.
H.

El vie, 1 oct 2021 a las 17:43, Wolfgang Bangerth ()
escribió:

> On 10/1/21 7:33 AM, Hermes Sampedro wrote:
> >
> > I would like to ask how can I access certain values of a sparseMatrix.
> > First I tried by using the global indices which does not work:
> >
> > /my_sparse_matrix(local_dof_indices[i], local_dof_indices[j])/
>
> That is how it is supposed to work. Can you explain what "does not work"
> mean in more specific terms?
>
> Best
>   W.
>
>
> --
> 
> Wolfgang Bangerth  email: bange...@colostate.edu
> 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 a topic in the
> Google Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/dealii/mRdtYt5wnRo/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/b1367fc7-48b6-d20e-697d-a086648a30b5%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 dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/CAB%3DnHhZdt4UKY6KE-bCRqPBBNDAEyoHdf8quvvgBY5%2BSTDsFDg%40mail.gmail.com.

[deal.II] SparseMatrix

[Hermes Sampedro]

Dear all, 

I would like to ask how can I access certain values of a sparseMatrix.
First I tried by using the global indices which does not work:

*my_sparse_matrix(local_dof_indices[i], local_dof_indices[j])*

I can not see any function to get the value. I found the function *val*, 
but it is not fully clear to me.

I would appreciate some help.


Thank you

Regards, 

H.



-- 
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/f408c3c5-db25-4b34-bdc0-9569c2aea3a1n%40googlegroups.com.

Re: [deal.II] Re: step-29 & step-40

[Hermes Sampedro]

Thank you very much.

Regards,
Hermes

El mar, 14 sept 2021 a las 16:28, Bruno Turcksin ()
escribió:

> Hermes,
>
> You probably don't need to use reinit() in your case. You want to use
> reinit() if the structure of the matrix changes with frequency. For
> example, if you change the degree of finite elements you need to call
> reinit(). If you want to change the values but the structure matrix is
> unchanged then you don't need to call reinit(). Instead, you can simply do
> matrix = 0; to clean the matrix.
>
> Best,
>
> Bruno
>
> On Tuesday, September 14, 2021 at 10:18:19 AM UTC-4 hermes...@gmail.com
> wrote:
>
>> Dear Bruno thank you very much for pointing step-17, I could solve the
>> problem.
>>
>> I would like to ask the last question. I am computing step-29 in parallel
>> for different frequencies. I have a loop for each of the frequencies as
>> follows:
>>
>>
>> make_grid();
>>
>> setup_system();
>>
>> assemble_system(sI[0]);
>>
>>
>>
>>
>>*for* ( *int* i = 0; i < Ns; ++i)
>>
>> {
>>
>> update_system(sI[i]);
>>
>> solve();
>>
>> output_results();
>>
>> }
>>
>> In orther to not setup the system and assemble in each iteration I
>> created update_system() to update the system matrix  as it change due to
>> the frequency. I need to do system_matrix .reinit before the update to
>> clean the matrix which I realize is time comsuming. I would like to ask if
>> there is another efficient way to update the matrix.
>>
>> Thank you
>> Regards,
>> H
>>
>>
>>
>> El mar, 14 sept 2021 a las 14:11, Bruno Turcksin ()
>> escribió:
>>
>>> Hermes,
>>>
>>> Le mar. 14 sept. 2021 à 05:19, Hermes Sampedro
>>>  a écrit :
>>> >
>>> > Should I use dealii::PETScWrappers::MPI::SparseMatrix system_matrix
>>> instead? If so could ou please help me to with the reinit() function? I do
>>> not fully understand how to call it.
>>>
>>> That's right, you need the matrix to be distributed too. Take a look
>>> at step-17 to see how to use PETScWrappers.
>>>
>>> Best,
>>>
>>> Bruno
>>>
>>> --
>>> 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/r3NGr6TnxXs/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
>>> https://groups.google.com/d/msgid/dealii/CAGVt9eNeuUqiA8-c0Zd%3DNn%2BTNx%2BVT3-xao0io8QT_D0rk0WjgQ%40mail.gmail.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 a topic in the
> Google Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/dealii/r3NGr6TnxXs/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/9f145b3a-044f-46f3-8adf-84a552c2a35en%40googlegroups.com
> <https://groups.google.com/d/msgid/dealii/9f145b3a-044f-46f3-8adf-84a552c2a35en%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CAB%3DnHhbx0rmQy3Mv9ctBZTao6AbdyjD3QCQFyjqie%2B2VOc9GVg%40mail.gmail.com.

Re: [deal.II] Re: step-29 & step-40

[Hermes Sampedro]

Dear Bruno thank you very much for pointing step-17, I could solve the
problem.

I would like to ask the last question. I am computing step-29 in parallel
for different frequencies. I have a loop for each of the frequencies as
follows:


make_grid();

setup_system();

assemble_system(sI[0]);




   *for* ( *int* i = 0; i < Ns; ++i)

{

update_system(sI[i]);

solve();

output_results();

}

In orther to not setup the system and assemble in each iteration I created
update_system() to update the system matrix  as it change due to the
frequency. I need to do system_matrix .reinit before the update to clean
the matrix which I realize is time comsuming. I would like to ask if there
is another efficient way to update the matrix.

Thank you
Regards,
H



El mar, 14 sept 2021 a las 14:11, Bruno Turcksin ()
escribió:

> Hermes,
>
> Le mar. 14 sept. 2021 à 05:19, Hermes Sampedro
>  a écrit :
> >
> > Should I use dealii::PETScWrappers::MPI::SparseMatrix system_matrix
> instead? If so could ou please help me to with the reinit() function? I do
> not fully understand how to call it.
>
> That's right, you need the matrix to be distributed too. Take a look
> at step-17 to see how to use PETScWrappers.
>
> Best,
>
> Bruno
>
> --
> 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/r3NGr6TnxXs/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/CAGVt9eNeuUqiA8-c0Zd%3DNn%2BTNx%2BVT3-xao0io8QT_D0rk0WjgQ%40mail.gmail.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/CAB%3DnHhY_ysNsV2eCyKwKnSdHYC-mEzDWAKiLX7%3Dh-iEF47U0JQ%40mail.gmail.com.

Re: [deal.II] Re: step-29 & step-40

[Hermes Sampedro]

Dear Bruno, thank you for your answer it helped me to solve the problem.

I had some issues with Trilinos library so I decided to implement step-29
in parallel (similar to step-40) using dealii::PETSxWrappers. I get an
error on the solve() function on the red line:

*template* <*int* dim>

*void* UltrasoundProblem::solve()

{

PETScWrappers::MPI::Vector
completely_distributed_solution(locally_owned_dofs,mpi_communicator);

SolverControl cn;

PETScWrappers::SparseDirectMUMPS solver(cn, mpi_communicator);

solver.solve(system_matrix, completely_distributed_solution, system_rhs);

constraints.distribute(completely_distributed_solution);

locally_relevant_solution = completely_distributed_solution;

}

where it was declared:

  dealii::PETScWrappers::SparseMatrix system_matrix;

  dealii::PETScWrappers::MPI::Vector   locally_relevant_solution;

  dealii::PETScWrappers::MPI::Vector   system_rhs;

[0]PETSC ERROR: - Error Message
--

[0]PETSC ERROR: Nonconforming object sizes

[0]PETSC ERROR: Preconditioner number of local rows 51842 does not equal
resulting vector number of rows 26114

[0]PETSC ERROR: See https://www.mcs.anl.gov/petsc/documentation/faq.html
for trouble shooting.

[0]PETSC ERROR: Petsc Release Version 3.13.1, May 02, 2020

[0]PETSC ERROR: ./step-29 on a  named gbarlogin1 by hsllo Tue Sep 14
11:11:04 2021

[0]PETSC ERROR: Configure options
--prefix=/zhome/32/9/115503/dealii-candi/petsc-3.13.1 --with-debugging=0
--with-shared-libraries=1 --with-mpi=1 --with-x=0 --with-64-bit-indices=0
--download-hypre=1 CC=mpicc CXX=mpicxx FC=mpif90
--with-blaslapack-dir=/appl/OpenBLAS/0.3.17/XeonE5-2660v3/gcc-11.2.0/lib
--with-parmetis-dir=/zhome/32/9/115503/dealii-candi/parmetis-4.0.3
--with-metis-dir=/zhome/32/9/115503/dealii-candi/parmetis-4.0.3
--download-scalapack=1 --download-mumps=1

[0]PETSC ERROR: #1 PCApply() line 436 in
/zhome/32/9/115503/dealii-candi/tmp/build/petsc-lite-3.13.1/src/ksp/pc/interface/precon.c

[0]PETSC ERROR: #2 KSP_PCApply() line 281 in
/zhome/32/9/115503/dealii-candi/tmp/build/petsc-lite-3.13.1/include/petsc/private/kspimpl.h

[0]PETSC ERROR: #3 KSPSolve_PREONLY() line 22 in
/zhome/32/9/115503/dealii-candi/tmp/build/petsc-lite-3.13.1/src/ksp/ksp/impls/preonly/preonly.c

[0]PETSC ERROR: #4 KSPSolve_Private() line 694 in
/zhome/32/9/115503/dealii-candi/tmp/build/petsc-lite-3.13.1/src/ksp/ksp/interface/itfunc.c

[0]PETSC ERROR: #5 KSPSolve() line 853 in
/zhome/32/9/115503/dealii-candi/tmp/build/petsc-lite-3.13.1/src/ksp/ksp/interface/itfunc.c





Exception on processing:




An error occurred in line <807> of file

in function

void dealii::PETScWrappers::SparseDirectMUMPS::solve(const
dealii::PETScWrappers::MatrixBase&, dealii::PETScWrappers::VectorBase&,
const dealii::PETScWrappers::VectorBase&)

The violated condition was:

ierr == 0

Additional information:

deal.II encountered an error while calling a PETSc function.

The description of the error provided by PETSc is "Nonconforming

object sizes".

The numerical value of the original error code is 60.




Aborting!

-




Should I use dealii::PETScWrappers::MPI::SparseMatrix system_matrix
instead? If so could ou please help me to with the reinit() function? I do
not fully understand how to call it.


Thank you

Regards,

H

El vie, 10 sept 2021 a las 14:56, Bruno Turcksin ()
escribió:

> Hermes,
>
> There is no recommended way to write a plain .txt file, it's left to the
> user to write their own function. The reason deal.II provides a function to
> write a .vtu file is that you need to use a very specific format. There is
> no format that you need to follow when writing a .txt file.
>
> Best,
>
> Bruno
>
> On Friday, September 10, 2021 at 5:58:45 AM UTC-4 hermes...@gmail.com
> wrote:
>
>> Dear Bruno,
>>
>> Thank you very much for your help.
>>
>> I would kindly like to ask what is the recommended way in Dealii to write
>> on a plain .txt file the results of a single point when using MPI. I solve
>> for different frequencies and would like to write the solution after each
>> iteration. In the non-parallel version it works as follows:
>>
>> *ofstream myfile;*
>>
>> * myfile.open ("solution.txt");*
>>
>>
>>
>> *   for ( int freq = 0; freí< 10; ++i)*
>>
>> *{*
>>
>> *setup_system();*
>>
>> *assemble_system(freq);*
>>
>> *solve();*
>>
>> * output_results(myfile);*
>>
>> *}*
>>
>> *myfile.close();*
>>
>>
>>
>>The function  *output_results(myfile) *takes care of writing the
>> solution of a single point in a plain .txt file for each frequency.
>>
>>
>> Step-40 shows a way to write .vtu files format when using MPI, but I did
>> not find any function to write the plain so

Re: [deal.II] Re: step-29 & step-40

[Hermes Sampedro]

Dear Bruno,

Thank you very much for your help.

I would kindly like to ask what is the recommended way in Dealii to write
on a plain .txt file the results of a single point when using MPI. I solve
for different frequencies and would like to write the solution after each
iteration. In the non-parallel version it works as follows:

*ofstream myfile;*

* myfile.open ("solution.txt");*



*   for ( int freq = 0; freí< 10; ++i)*

*{*

*setup_system();*

*assemble_system(freq);*

*solve();*

* output_results(myfile);*

*}*

*myfile.close();*



   The function  *output_results(myfile) *takes care of writing the
solution of a single point in a plain .txt file for each frequency.


Step-40 shows a way to write .vtu files format when using MPI, but I did
not find any function to write the plain solution.

I would appreciate any suggestions on how to do that using Dealii.


Thank you again.

Regards,

H.



El jue, 9 sept 2021 a las 14:36, Bruno Turcksin ()
escribió:

> Hermes,
>
> The following line is wrong:
> *DynamicSparsityPattern dsp(locally_relevant_dofs.n_elements(),
> locally_relevant_dofs.n_elements());*
>
> This constructor says that you want a sparsity pattern that has 
> *locally_relevant_dofs.n_elements()
> *elements. This is not the case. You want a sparsity pattern that has as
> many elements as the total numbers of dofs. Also since you want to use MPI,
> you need to provide a third argument, the locally_owned IndexSet.
>
> You can also simply use:
> *DynamicSparsityPattern dsp(locally_relevant_dofs);*
>
> Best,
>
> Bruno
>
> On Thursday, September 9, 2021 at 5:29:56 AM UTC-4 hermes...@gmail.com
> wrote:
>
>> Dear all,
>>
>> I adapted step-29 to run in parallel, similar as step-40. With 1 MPI rank
>> it works, however, when using more than 1 rank I  get a running error
>> (attached is the full output)
>>
>> *An error occurred in line <74> of file
>> 
>> in function*
>>
>> *void dealii::DoFTools::make_sparsity_pattern(const DoFHandler> spacedim> &, SparsityPatternType &, const AffineConstraints &,
>> const bool, const types::subdomain_id) [dim = 2, spacedim = 2,
>> SparsityPatternType = dealii::DynamicSparsityPattern, number = double]*
>>
>> *The violated condition was: *
>>
>> *sparsity.n_rows() == n_dofs*
>>
>> *Additional information: *
>>
>> *Dimension 26752 not equal to 51842*
>>
>> I found out that the problem is in the setp_system() function. The
>> problematic line is in red. Could you please help me to figure out the
>> issue?
>>
>>
>> *template *
>>
>> *  void UltrasoundProblem::setup_system()**  {*
>>
>> *deallog << "Setting up system... ";*
>>
>> * deallog << "OK1... ";*
>>
>> *dof_handler.distribute_dofs(fe);*
>>
>> * 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);*
>>
>>*  VectorTools::interpolate_boundary_values(dof_handler,** 1,*
>> *DirichletBoundaryValues(),**constraints);*
>>
>> *  constraints.close();*
>>
>> *DynamicSparsityPattern dsp(locally_relevant_dofs.n_elements(),
>> locally_relevant_dofs.n_elements());*
>>
>> *DoFTools::make_sparsity_pattern(dof_handler,
>> dsp,constraints,false);//THIS*
>>
>>
>> * 
>> 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);*
>>
>> *  }*
>>
>>
>> Thank you very much
>>
>> H.
>>
>>
>>
>> --
> 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/r3NGr6TnxXs/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/f621e3ee-3bce-49b3-9151-1b5a3e4edc55n%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 gr

[deal.II] step-29 & step-40

[Hermes Sampedro]

Dear all, 

I adapted step-29 to run in parallel, similar as step-40. With 1 MPI rank 
it works, however, when using more than 1 rank I  get a running error 
(attached is the full output)

*An error occurred in line <74> of file 

 
in function*

*void dealii::DoFTools::make_sparsity_pattern(const DoFHandler &, SparsityPatternType &, const AffineConstraints &, 
const bool, const types::subdomain_id) [dim = 2, spacedim = 2, 
SparsityPatternType = dealii::DynamicSparsityPattern, number = double]*

*The violated condition was: *

*sparsity.n_rows() == n_dofs*

*Additional information: *

*Dimension 26752 not equal to 51842*

I found out that the problem is in the setp_system() function. The 
problematic line is in red. Could you please help me to figure out the 
issue?


*template *

*  void UltrasoundProblem::setup_system()**  {*

*deallog << "Setting up system... ";*

* deallog << "OK1... ";*

*dof_handler.distribute_dofs(fe);*

* 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);*

   *  VectorTools::interpolate_boundary_values(dof_handler,** 1,*
*DirichletBoundaryValues(),**constraints);*

*  constraints.close();*

*DynamicSparsityPattern dsp(locally_relevant_dofs.n_elements(), 
locally_relevant_dofs.n_elements());*

*DoFTools::make_sparsity_pattern(dof_handler, 
dsp,constraints,false);//THIS*

* 
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);*

*  }*


Thank you very much

H.



-- 
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/5808c00f-8c0a-47e2-9dcd-43dc1ec8068cn%40googlegroups.com.
{\rtf1\ansi\ansicpg1252\cocoartf2513
\cocoatextscaling0\cocoaplatform0{\fonttbl\f0\fnil\fcharset0 Menlo-Regular;}
{\colortbl;\red255\green255\blue255;\red0\green0\blue0;\red255\green255\blue255;}
{\*\expandedcolortbl;;\csgray\c0;\cspthree\c10\c8\c10;}
\paperw11900\paperh16840\margl1440\margr1440\vieww10800\viewh8400\viewkind0
\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\pardirnatural\partightenfactor0

\f0\fs22 \cf2 \cb3 \CocoaLigature0 bash-3.2$ mpirun -np 2 ./step-29\
DEAL::Running with Trilinos on 2 MPI rank(s)...\
DEAL::Running with Trilinos on 2 MPI rank(s)...\
\
\
An error occurred in line <74> of file  in function\
void dealii::DoFTools::make_sparsity_pattern(const DoFHandler &, SparsityPatternType &, const AffineConstraints &, const bool, const types::subdomain_id) [dim = 2, spacedim = 2, SparsityPatternType = dealii::DynamicSparsityPattern, number = double]\
The violated condition was: \
sparsity.n_rows() == n_dofs\
Additional information: \
Dimension 26752 not equal to 51842.\
\
Stacktrace:\
---\
#0  2   libdeal_II.g.9.3.0.dylib0x00011657f83f _ZN6dealii8DoFTools21make_sparsity_patternILi2ELi2ENS_22DynamicSparsityPatternEdEEvRKNS_10DoFHandlerIXT_EXT0_EEERT1_RKNS_17AffineConstraintsIT2_EEbj + 719: 2   libdeal_II.g.9.3.0.dylib0x00011657f83f _ZN6dealii8DoFTools21make_sparsity_patternILi2ELi2ENS_22DynamicSparsityPatternEdEEvRKNS_10DoFHandlerIXT_EXT0_EEERT1_RKNS_17AffineConstraintsIT2_EEbj \
#1  3   step-29 0x0001032168a8 _ZN6Step2917UltrasoundProblemILi2EE12setup_systemEv + 456: 3   step-29 0x0001032168a8 _ZN6Step2917UltrasoundProblemILi2EE12setup_systemEv \
#2  4   step-29 0x000103201787 _ZN6Step2917UltrasoundProblemILi2EE3runEv + 167: 4   step-29 0x000103201787 _ZN6Step2917UltrasoundProblemILi2EE3runEv \
#3  5   step-29 0x0001032014b3 main + 211: 5   step-29 0x0001032014b3 main \
#4  6   libdyld.dylib   0x7fff67eb1cc9 start + 1: 6   libdyld.dylib   0x7fff67eb1cc9 start \
\
\
Calling MPI_Abort now.\
To break execution in a GDB session, execute 'break M

Re: [deal.II] point_value, Real&Imaginary parts, step-29

[Hermes Sampedro]

Thank you for your answer, I could make it work.

Regards,
Hermes

El mar, 7 sept 2021 a las 4:28, Wolfgang Bangerth ()
escribió:

> On 9/6/21 3:27 AM, Hermes Sampedro wrote:
> > Thank you very much. I have been trying and I only get the real part of
> the
> > solution and it seems not to be right so far. Would be possible to make
> it
> > work for complex numbers?
>
> Hermes,
> do you think you could come up with a small, self-contained program that
> illustrates what isn't working? It's often not very difficult to debug
> once
> one has a small testcase, but it's often very difficult to come up with a
> testcase without access to the original program that someone says isn't
> working.
>
> Best
>   W.
>
> --
> 
> Wolfgang Bangerth  email: bange...@colostate.edu
> 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 a topic in the
> Google Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/dealii/Ru1_uMbix30/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/9f61547f-7058-08e8-7511-81240ba06b31%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 dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/CAB%3DnHhb5GA4dfY5scftaLeddNTqVdfoFesdP5Ah59F%3DnejUkBQ%40mail.gmail.com.

Re: [deal.II] point_value, Real&Imaginary parts, step-29

[Hermes Sampedro]

Thank you very much. I have been trying and I only get the real part of the
solution and it seems not to be right so far. Would be possible to make it
work for complex numbers?

Thank you
H.

El vie, 27 ago 2021 a las 9:33, 'peterrum' via deal.II User Group (<
dealii@googlegroups.com>) escribió:

> Hi Hermes,
>
> I have extended the documentation a bit. See
> https://github.com/dealii/dealii/pull/12714.
>
> Maybe you could give us a short feedback if `VectorTools::point_values()`
> is working for complex numbers. If this is not the case, we can extend the
> function for this use case.
>
> PM
>
> On Tuesday, 24 August 2021 at 15:39:49 UTC+2 peterrum wrote:
>
>> You need to pass a vector of points.
>>
>> PM
>>
>> On Tuesday, 24 August 2021 at 15:26:05 UTC+2 hermes...@gmail.com wrote:
>>
>>> Thank you.
>>>
>>> Doing something similar:
>>>
>>>   *const* MappingQ1 mapping;
>>>
>>>   Utilities::MPI::RemotePointEvaluation evaluation_cache;
>>>
>>>   VectorTools::point_values(mapping, dof_handler,
>>> locally_relevant_solution, Point<2>(0.2, 0.2), evaluation_cache);
>>>
>>>
>>> I get the following error:
>>>
>>>  error: no matching function for call to 'point_values'
>>>
>>>   VectorTools::point_values(mapping, dof_handler,
>>> locally_relevant_solution, Point<2>(0.2, 0.2), evaluation_cache);
>>>
>>>
>>>
>>> I checked the parameters and seems to be ok. What can be producing the
>>> error?
>>>
>>> Thank you again
>>>
>>> H
>>>
>>> El mar, 24 ago 2021 a las 14:59, 'peterrum' via deal.II User Group (<
>>> dea...@googlegroups.com>) escribió:
>>>
>>>> Hi Hermes,
>>>>
>>>> You don't need to do anything regarding the setup (it is done within
>>>> the function). Just take at a look at:
>>>> https://github.com/dealii/dealii/blob/44b6aadb35aca2333e4bfb6c9ce29c613f4dc9e9/tests/remote_point_evaluation/vector_tools_evaluate_at_points_01.cc#L214-L216
>>>>
>>>> I'll extend the documentation with an example today or tomorrow!
>>>>
>>>> Hope that helps,
>>>> PM
>>>>
>>>> On Tuesday, 24 August 2021 at 14:46:46 UTC+2 hermes...@gmail.com wrote:
>>>>
>>>>> Thank you for pointing that function.
>>>>>
>>>>> I am having some problems when creating the mapping and I am not sure
>>>>> if the function call is right. Could you please help me with that?
>>>>>
>>>>>   std::vector<*double*> pointSol;
>>>>>
>>>>>   Mapping mapping;
>>>>>
>>>>>
>>>>>
>>>>>   dealii::Utilities::MPI::RemotePointEvaluation remotePoint;
>>>>>
>>>>>   remotePoint.reinit();
>>>>>
>>>>>   pointSol = VectorTools::point_values(mapping,
>>>>> dof_handler,locally_relevant_solution,Point<2>(0.2, 0.2),remotePoint);
>>>>>
>>>>>
>>>>>
>>>>> Thank you
>>>>>
>>>>> H
>>>>>
>>>>>
>>>>>
>>>>> El mar, 24 ago 2021 a las 14:12, Martin Kronbichler (<
>>>>> kronbichl...@gmail.com>) escribió:
>>>>>
>>>>>> Dear Hermes,
>>>>>>
>>>>>> Did you try VectorTools::point_values,
>>>>>> https://www.dealii.org/current/doxygen/deal.II/namespaceVectorTools.html#a1ad6eceb6cbeaa505baf7f938289bbde
>>>>>> ?
>>>>>>
>>>>>> As an alternative, you can also check if the point is in the locally
>>>>>> owned cell of the respective cell, and run the evaluation only on that 
>>>>>> MPI
>>>>>> rank. You can then use an MPI collective, like MPI_Bcast or deal.II's
>>>>>> version Utilities::MPI::broadcast, to get the solution to all MPI ranks
>>>>>> (typically with another collective to make all ranks agree on who sends 
>>>>>> the
>>>>>> information).
>>>>>>
>>>>>> Best,
>>>>>> Martin
>>>>>>
>>>>>> This is a variant that allows the evaluation even on remote processes.
>>>>>> On 24.08.21 14:05, Hermes Sampedro wrote

Re: [deal.II] Massively parallel & inverse matrix solver

[Hermes Sampedro]

Thank you for the answer. I am solving for real and imaginary parts.
What solver would you suggest using? Is it any example in any of the steps?

Thank you
Hermes.

El mié, 1 sept 2021 a las 20:11, Daniel Arndt ()
escribió:

> Hermes,
>
> The SparseDirectUMFPACK solver doesn't work with MPI parallel matrices.
> You will need to find another solver based on the matrix class you are
> using. Standard choices would be GMRES or CG but I am assuming that your
> linear system might also be non-symmetric or indefinite.
>
> Best,
> Daniel
>
>
>
> Am Mi., 1. Sept. 2021 um 11:53 Uhr schrieb Hermes Sampedro <
> hermesampe...@gmail.com>:
>
>> Dear all,
>>
>> I am trying to solve a similar problem as step-29 but including the
>> massive parallel solution as presented in step-40.
>> I would like to ask how the solve() function would be in this case.
>>
>> In step-29:
>> //LU decomposition and inverse matrix
>> SparseDirectUMFPACK A_direct;
>> A_direct.initialize(system_matrix);
>>
>> //Solve with inverse matrix
>> A_direct.vmult(solution, system_rhs);
>>
>> When applying massive parallel computations, my initial guess was:
>>
>> LA::MPI::Vector
>> completely_distributed_solution(locally_owned_dofs,mpi_communicator);
>> //LU decomposition and inverse matrix
>> SparseDirectUMFPACK A_direct;
>> A_direct.initialize(system_matrix);
>>
>> //Solve with inverse matrix
>> A_direct.vmult(completely_distributed_solution, system_rhs);
>>  locally_relevant_solution = completely_distributed_solution;
>>
>>
>>  However, I get a *no matching member function for call to 'vmult'*
>> error.
>>
>> How can I use this LU decomposition and inverse matrix solver using MPI?
>>
>>
>> Thank you,
>>
>> Regards,
>>
>> H
>>
>> --
>> 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/ded2e156-7bd7-4474-aa5f-fb57e8540926n%40googlegroups.com
>> <https://groups.google.com/d/msgid/dealii/ded2e156-7bd7-4474-aa5f-fb57e8540926n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> 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/ul4Aa_5t3n0/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/CAOYDWbKG87reQPBrhZu0RwoZHrMXMtVWS9Ui6EoFCWtmemG1vQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/dealii/CAOYDWbKG87reQPBrhZu0RwoZHrMXMtVWS9Ui6EoFCWtmemG1vQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CAB%3DnHhYgcGWSv7aNs-9XzUL1C%3DBVeSFSecCEK1ZXocG-3qP%2B2A%40mail.gmail.com.

[deal.II] Massively parallel & inverse matrix solver

[Hermes Sampedro]

Dear all,

I am trying to solve a similar problem as step-29 but including the massive 
parallel solution as presented in step-40.
I would like to ask how the solve() function would be in this case.

In step-29:
//LU decomposition and inverse matrix
SparseDirectUMFPACK A_direct;
A_direct.initialize(system_matrix);

//Solve with inverse matrix
A_direct.vmult(solution, system_rhs);

When applying massive parallel computations, my initial guess was:

LA::MPI::Vector
completely_distributed_solution(locally_owned_dofs,mpi_communicator);
//LU decomposition and inverse matrix
SparseDirectUMFPACK A_direct;
A_direct.initialize(system_matrix);

//Solve with inverse matrix
A_direct.vmult(completely_distributed_solution, system_rhs);
 locally_relevant_solution = completely_distributed_solution;


 However, I get a *no matching member function for call to 'vmult'* error. 

How can I use this LU decomposition and inverse matrix solver using MPI?


Thank you,

Regards,

H

-- 
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/ded2e156-7bd7-4474-aa5f-fb57e8540926n%40googlegroups.com.

Re: [deal.II] point_value, Real&Imaginary parts, step-29

[Hermes Sampedro]

Thank you.

Doing something similar:

  *const* MappingQ1 mapping;

  Utilities::MPI::RemotePointEvaluation evaluation_cache;

  VectorTools::point_values(mapping, dof_handler,
locally_relevant_solution, Point<2>(0.2, 0.2), evaluation_cache);


I get the following error:

 error: no matching function for call to 'point_values'

  VectorTools::point_values(mapping, dof_handler,
locally_relevant_solution, Point<2>(0.2, 0.2), evaluation_cache);



I checked the parameters and seems to be ok. What can be producing the
error?

Thank you again

H

El mar, 24 ago 2021 a las 14:59, 'peterrum' via deal.II User Group (<
dealii@googlegroups.com>) escribió:

> Hi Hermes,
>
> You don't need to do anything regarding the setup (it is done within the
> function). Just take at a look at:
> https://github.com/dealii/dealii/blob/44b6aadb35aca2333e4bfb6c9ce29c613f4dc9e9/tests/remote_point_evaluation/vector_tools_evaluate_at_points_01.cc#L214-L216
>
> I'll extend the documentation with an example today or tomorrow!
>
> Hope that helps,
> PM
>
> On Tuesday, 24 August 2021 at 14:46:46 UTC+2 hermes...@gmail.com wrote:
>
>> Thank you for pointing that function.
>>
>> I am having some problems when creating the mapping and I am not sure if
>> the function call is right. Could you please help me with that?
>>
>>   std::vector<*double*> pointSol;
>>
>>   Mapping mapping;
>>
>>
>>
>>   dealii::Utilities::MPI::RemotePointEvaluation remotePoint;
>>
>>   remotePoint.reinit();
>>
>>   pointSol = VectorTools::point_values(mapping,
>> dof_handler,locally_relevant_solution,Point<2>(0.2, 0.2),remotePoint);
>>
>>
>>
>> Thank you
>>
>> H
>>
>>
>>
>> El mar, 24 ago 2021 a las 14:12, Martin Kronbichler (<
>> kronbichl...@gmail.com>) escribió:
>>
>>> Dear Hermes,
>>>
>>> Did you try VectorTools::point_values,
>>> https://www.dealii.org/current/doxygen/deal.II/namespaceVectorTools.html#a1ad6eceb6cbeaa505baf7f938289bbde
>>> ?
>>>
>>> As an alternative, you can also check if the point is in the locally
>>> owned cell of the respective cell, and run the evaluation only on that MPI
>>> rank. You can then use an MPI collective, like MPI_Bcast or deal.II's
>>> version Utilities::MPI::broadcast, to get the solution to all MPI ranks
>>> (typically with another collective to make all ranks agree on who sends the
>>> information).
>>>
>>> Best,
>>> Martin
>>>
>>> This is a variant that allows the evaluation even on remote processes.
>>> On 24.08.21 14:05, Hermes Sampedro wrote:
>>>
>>> Dear all,
>>>
>>> I am trying to extend my implementation with parallel computing. I would
>>> like to get the solution in a single point when having a distributed
>>> system. For example, in step-40 I have the *locally_relevant_solution* at
>>> the output_result(...) function.
>>> In a non distributed implementation I used:
>>>
>>>   Vector<*double*> vecSol (fe.n_components());
>>>
>>>   VectorTools::point_value(dof_handler, solution,Point<2>(0.2,
>>> 0.2),vecSol);
>>>
>>>
>>> What is the easiest way to do that? Is it possible to check if the point
>>> is inside the *locally_relevant_solution? *Or would be more appropriate
>>> to create a copy of the solution in a global vector and get the point from
>>> there?
>>>
>>>
>>> Thank you
>>>
>>> H
>>>
>>> El mié, 11 ago 2021 a las 10:12, Hermes Sampedro ()
>>> escribió:
>>>
>>>> Thank you very much, I could make it work.
>>>>
>>>> Regards,
>>>> Hermes
>>>>
>>>> El mar, 10 ago 2021 a las 19:46, Jean-Paul Pelteret (<
>>>> jppel...@gmail.com>) escribió:
>>>>
>>>>> Another thing: You probably also need to initialise with the right
>>>>> number of components. So something like
>>>>> Vector vecSol (fe.n_components());
>>>>>
>>>>>
>>>>> On 10. Aug 2021, at 19:40, Jean-Paul Pelteret 
>>>>> wrote:
>>>>>
>>>>> Hi Hermes,
>>>>>
>>>>> You don’t say what errors you’re seeing, but my guess is that it now
>>>>> doesn’t compile. This variant of the function (the one that Daniel linked
>>>>> to) returns void, s

Re: [deal.II] point_value, Real&Imaginary parts, step-29

[Hermes Sampedro]

Thank you for pointing that function.

I am having some problems when creating the mapping and I am not sure if
the function call is right. Could you please help me with that?

  std::vector<*double*> pointSol;

  Mapping mapping;



  dealii::Utilities::MPI::RemotePointEvaluation remotePoint;

  remotePoint.reinit();

  pointSol = VectorTools::point_values(mapping,
dof_handler,locally_relevant_solution,Point<2>(0.2, 0.2),remotePoint);



Thank you

H



El mar, 24 ago 2021 a las 14:12, Martin Kronbichler (<
kronbichler.mar...@gmail.com>) escribió:

> Dear Hermes,
>
> Did you try VectorTools::point_values,
> https://www.dealii.org/current/doxygen/deal.II/namespaceVectorTools.html#a1ad6eceb6cbeaa505baf7f938289bbde
> ?
>
> As an alternative, you can also check if the point is in the locally owned
> cell of the respective cell, and run the evaluation only on that MPI rank.
> You can then use an MPI collective, like MPI_Bcast or deal.II's version
> Utilities::MPI::broadcast, to get the solution to all MPI ranks (typically
> with another collective to make all ranks agree on who sends the
> information).
>
> Best,
> Martin
>
> This is a variant that allows the evaluation even on remote processes.
> On 24.08.21 14:05, Hermes Sampedro wrote:
>
> Dear all,
>
> I am trying to extend my implementation with parallel computing. I would
> like to get the solution in a single point when having a distributed
> system. For example, in step-40 I have the *locally_relevant_solution* at
> the output_result(...) function.
> In a non distributed implementation I used:
>
>   Vector<*double*> vecSol (fe.n_components());
>
>   VectorTools::point_value(dof_handler, solution,Point<2>(0.2,
> 0.2),vecSol);
>
>
> What is the easiest way to do that? Is it possible to check if the point
> is inside the *locally_relevant_solution? *Or would be more appropriate
> to create a copy of the solution in a global vector and get the point from
> there?
>
>
> Thank you
>
> H
>
> El mié, 11 ago 2021 a las 10:12, Hermes Sampedro ()
> escribió:
>
>> Thank you very much, I could make it work.
>>
>> Regards,
>> Hermes
>>
>> El mar, 10 ago 2021 a las 19:46, Jean-Paul Pelteret (<
>> jppelte...@gmail.com>) escribió:
>>
>>> Another thing: You probably also need to initialise with the right
>>> number of components. So something like
>>> Vector vecSol (fe.n_components());
>>>
>>>
>>> On 10. Aug 2021, at 19:40, Jean-Paul Pelteret 
>>> wrote:
>>>
>>> Hi Hermes,
>>>
>>> You don’t say what errors you’re seeing, but my guess is that it now
>>> doesn’t compile. This variant of the function (the one that Daniel linked
>>> to) returns void, so you should call it before outputting the result:
>>>
>>> Vector vecSol;
>>> VectorTools::point_value(dof_handler, solution,Point<2>(0.2, 0.2),vecSol)
>>> std::cout << "Solution at (0.2,0.2): "<< vecSol << std::endl;
>>>
>>> This will hopefully get you what you want.
>>>
>>> Best,
>>> Jean-Paul
>>>
>>>
>>> On 10. Aug 2021, at 16:09, Hermes Sampedro 
>>> wrote:
>>>
>>> Thank you for your answer. I am not sure if I fully understand your
>>> suggestion. Do you mean something like that:
>>>
>>>  Vector<*double*> vecSol;
>>>  std::cout << "Solution at (0.2,0.2): "<<
>>> VectorTools::point_value(dof_handler, solution,Point<2>(0.2, 0.2),vecSol)<<
>>> std::endl;
>>>
>>>
>>> I still get some errors. Is there not any way to get for example the
>>> real part of *solution* easily and use it directly on the point_value
>>> as in step-3?
>>>
>>> Thank you
>>> H
>>>
>>> El mar, 10 ago 2021 a las 15:49, Daniel Arndt ()
>>> escribió:
>>>
>>>> Hermes,
>>>>
>>>> Use another overload. The one returning the solution as a parameter
>>>> should work:
>>>> https://www.dealii.org/current/doxygen/deal.II/namespaceVectorTools.html#acd358e9b110ccbf4a7f76796d206b9c7
>>>>
>>>> Best,
>>>> Daniel
>>>>
>>>> Am Di., 10. Aug. 2021 um 09:41 Uhr schrieb Hermes Sampedro <
>>>> hermesampe...@gmail.com>:
>>>>
>>>>> Dear all,
>>>>>
>>>>> It is explained in Step-3 how to evaluate the solution in a point. I
>>>>> am trying to do t

Re: [deal.II] point_value, Real&Imaginary parts, step-29

[Hermes Sampedro]

Dear all,

I am trying to extend my implementation with parallel computing. I would
like to get the solution in a single point when having a distributed
system. For example, in step-40 I have the *locally_relevant_solution* at
the output_result(...) function.
In a non distributed implementation I used:

  Vector<*double*> vecSol (fe.n_components());

  VectorTools::point_value(dof_handler, solution,Point<2>(0.2,
0.2),vecSol);


What is the easiest way to do that? Is it possible to check if the point is
inside the *locally_relevant_solution? *Or would be more appropriate to
create a copy of the solution in a global vector and get the point from
there?


Thank you

H

El mié, 11 ago 2021 a las 10:12, Hermes Sampedro ()
escribió:

> Thank you very much, I could make it work.
>
> Regards,
> Hermes
>
> El mar, 10 ago 2021 a las 19:46, Jean-Paul Pelteret ()
> escribió:
>
>> Another thing: You probably also need to initialise with the right
>> number of components. So something like
>> Vector vecSol (fe.n_components());
>>
>>
>> On 10. Aug 2021, at 19:40, Jean-Paul Pelteret 
>> wrote:
>>
>> Hi Hermes,
>>
>> You don’t say what errors you’re seeing, but my guess is that it now
>> doesn’t compile. This variant of the function (the one that Daniel linked
>> to) returns void, so you should call it before outputting the result:
>>
>> Vector vecSol;
>> VectorTools::point_value(dof_handler, solution,Point<2>(0.2, 0.2),vecSol)
>> std::cout << "Solution at (0.2,0.2): "<< vecSol << std::endl;
>>
>> This will hopefully get you what you want.
>>
>> Best,
>> Jean-Paul
>>
>>
>> On 10. Aug 2021, at 16:09, Hermes Sampedro 
>> wrote:
>>
>> Thank you for your answer. I am not sure if I fully understand your
>> suggestion. Do you mean something like that:
>>
>>  Vector<*double*> vecSol;
>>  std::cout << "Solution at (0.2,0.2): "<<
>> VectorTools::point_value(dof_handler, solution,Point<2>(0.2, 0.2),vecSol)<<
>> std::endl;
>>
>>
>> I still get some errors. Is there not any way to get for example the real
>> part of *solution* easily and use it directly on the point_value as in
>> step-3?
>>
>> Thank you
>> H
>>
>> El mar, 10 ago 2021 a las 15:49, Daniel Arndt ()
>> escribió:
>>
>>> Hermes,
>>>
>>> Use another overload. The one returning the solution as a parameter
>>> should work:
>>> https://www.dealii.org/current/doxygen/deal.II/namespaceVectorTools.html#acd358e9b110ccbf4a7f76796d206b9c7
>>>
>>> Best,
>>> Daniel
>>>
>>> Am Di., 10. Aug. 2021 um 09:41 Uhr schrieb Hermes Sampedro <
>>> hermesampe...@gmail.com>:
>>>
>>>> Dear all,
>>>>
>>>> It is explained in Step-3 how to evaluate the solution in a point. I am
>>>> trying to do the same for Step-29, to evaluate the real and imaginary parts
>>>> separately in a single point:
>>>>
>>>> *std::cout << "Solution at (0.2,0.2): "<<
>>>> VectorTools::point_value(dof_handler, solution,Point<2>(0.2, 0.2))<<
>>>> std::endl;*
>>>>
>>>> I do not have any problems compiling however, an error occurs when
>>>> running:
>>>>
>>>> *The violated condition was:  dof.get_fe(0).n_components() == 1*
>>>>
>>>> What is the proper way to call the real and imaginary parts of the
>>>> solution at a particular point here?
>>>>
>>>>
>>>> Thank you very much!
>>>>
>>>> H.
>>>>
>>>> --
>>>> 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/54a2d44e-194a-43c0-aa7f-9fddd5bd0dean%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/dealii/54a2d44e-194a-43c0-aa7f-9fddd5bd0dean%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>
>>> --
>>> The de

[deal.II] Loop update & assemble

[Hermes Sampedro]

Hello, 

I am working with step-29 and I would like to compute the solution for 
different frequency values (omega). For now, I am implementing a loop that 
updates *omega*, do the assemble and solve it. However, the simulations are 
slow due to the assembling in every loop iteration. Is there any other way 
to update the value in a more efficient way? Is there any other step 
example that works with that?

Thank you very much
Regards, 
H

-- 
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/672ed13e-c9f0-4e1c-ab80-98e9d76089d3n%40googlegroups.com.

Re: [deal.II] point_value, Real&Imaginary parts, step-29

[Hermes Sampedro]

Thank you very much, I could make it work.

Regards,
Hermes

El mar, 10 ago 2021 a las 19:46, Jean-Paul Pelteret ()
escribió:

> Another thing: You probably also need to initialise with the right number
> of components. So something like
> Vector vecSol (fe.n_components());
>
>
> On 10. Aug 2021, at 19:40, Jean-Paul Pelteret 
> wrote:
>
> Hi Hermes,
>
> You don’t say what errors you’re seeing, but my guess is that it now
> doesn’t compile. This variant of the function (the one that Daniel linked
> to) returns void, so you should call it before outputting the result:
>
> Vector vecSol;
> VectorTools::point_value(dof_handler, solution,Point<2>(0.2, 0.2),vecSol)
> std::cout << "Solution at (0.2,0.2): "<< vecSol << std::endl;
>
> This will hopefully get you what you want.
>
> Best,
> Jean-Paul
>
>
> On 10. Aug 2021, at 16:09, Hermes Sampedro 
> wrote:
>
> Thank you for your answer. I am not sure if I fully understand your
> suggestion. Do you mean something like that:
>
>  Vector<*double*> vecSol;
>  std::cout << "Solution at (0.2,0.2): "<<
> VectorTools::point_value(dof_handler, solution,Point<2>(0.2, 0.2),vecSol)<<
> std::endl;
>
>
> I still get some errors. Is there not any way to get for example the real
> part of *solution* easily and use it directly on the point_value as in
> step-3?
>
> Thank you
> H
>
> El mar, 10 ago 2021 a las 15:49, Daniel Arndt ()
> escribió:
>
>> Hermes,
>>
>> Use another overload. The one returning the solution as a parameter
>> should work:
>> https://www.dealii.org/current/doxygen/deal.II/namespaceVectorTools.html#acd358e9b110ccbf4a7f76796d206b9c7
>>
>> Best,
>> Daniel
>>
>> Am Di., 10. Aug. 2021 um 09:41 Uhr schrieb Hermes Sampedro <
>> hermesampe...@gmail.com>:
>>
>>> Dear all,
>>>
>>> It is explained in Step-3 how to evaluate the solution in a point. I am
>>> trying to do the same for Step-29, to evaluate the real and imaginary parts
>>> separately in a single point:
>>>
>>> *std::cout << "Solution at (0.2,0.2): "<<
>>> VectorTools::point_value(dof_handler, solution,Point<2>(0.2, 0.2))<<
>>> std::endl;*
>>>
>>> I do not have any problems compiling however, an error occurs when
>>> running:
>>>
>>> *The violated condition was:  dof.get_fe(0).n_components() == 1*
>>>
>>> What is the proper way to call the real and imaginary parts of the
>>> solution at a particular point here?
>>>
>>>
>>> Thank you very much!
>>>
>>> H.
>>>
>>> --
>>> 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/54a2d44e-194a-43c0-aa7f-9fddd5bd0dean%40googlegroups.com
>>> <https://groups.google.com/d/msgid/dealii/54a2d44e-194a-43c0-aa7f-9fddd5bd0dean%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>> --
>> 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/Ru1_uMbix30/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/CAOYDWb%2BR0bRTVxB-F22Hwk_ZexN4%3DVwCbZ7ZKqs3JjEaHFhncA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/dealii/CAOYDWb%2BR0bRTVxB-F22Hwk_ZexN4%3DVwCbZ7ZKqs3JjEaHFhncA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
> --
> 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
> "de

Re: [deal.II] point_value, Real&Imaginary parts, step-29

[Hermes Sampedro]

Thank you for your answer. I am not sure if I fully understand your
suggestion. Do you mean something like that:

 Vector<*double*> vecSol;

 std::cout << "Solution at (0.2,0.2): "<<
VectorTools::point_value(dof_handler, solution,Point<2>(0.2, 0.2),vecSol)<<
std::endl;




I still get some errors. Is there not any way to get for example the real
part of *solution* easily and use it directly on the point_value as in
step-3?


Thank you

H

El mar, 10 ago 2021 a las 15:49, Daniel Arndt ()
escribió:

> Hermes,
>
> Use another overload. The one returning the solution as a parameter should
> work:
> https://www.dealii.org/current/doxygen/deal.II/namespaceVectorTools.html#acd358e9b110ccbf4a7f76796d206b9c7
>
> Best,
> Daniel
>
> Am Di., 10. Aug. 2021 um 09:41 Uhr schrieb Hermes Sampedro <
> hermesampe...@gmail.com>:
>
>> Dear all,
>>
>> It is explained in Step-3 how to evaluate the solution in a point. I am
>> trying to do the same for Step-29, to evaluate the real and imaginary parts
>> separately in a single point:
>>
>> *std::cout << "Solution at (0.2,0.2): "<<
>> VectorTools::point_value(dof_handler, solution,Point<2>(0.2, 0.2))<<
>> std::endl;*
>>
>> I do not have any problems compiling however, an error occurs when
>> running:
>>
>> *The violated condition was:  dof.get_fe(0).n_components() == 1*
>>
>> What is the proper way to call the real and imaginary parts of the
>> solution at a particular point here?
>>
>>
>> Thank you very much!
>>
>> H.
>>
>> --
>> 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/54a2d44e-194a-43c0-aa7f-9fddd5bd0dean%40googlegroups.com
>> <https://groups.google.com/d/msgid/dealii/54a2d44e-194a-43c0-aa7f-9fddd5bd0dean%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> 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/Ru1_uMbix30/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/CAOYDWb%2BR0bRTVxB-F22Hwk_ZexN4%3DVwCbZ7ZKqs3JjEaHFhncA%40mail.gmail.com
> <https://groups.google.com/d/msgid/dealii/CAOYDWb%2BR0bRTVxB-F22Hwk_ZexN4%3DVwCbZ7ZKqs3JjEaHFhncA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CAB%3DnHhZrnXUeYt5FrKa66oTwoV8WJ8b%3DFqLFJ9pfP%3DUHRTyV%2BQ%40mail.gmail.com.

[deal.II] point_value, Real&Imaginary parts, step-29

[Hermes Sampedro]

Dear all, 

It is explained in Step-3 how to evaluate the solution in a point. I am 
trying to do the same for Step-29, to evaluate the real and imaginary parts 
separately in a single point:

*std::cout << "Solution at (0.2,0.2): "<< 
VectorTools::point_value(dof_handler, solution,Point<2>(0.2, 0.2))<< 
std::endl;*

I do not have any problems compiling however, an error occurs when running:

*The violated condition was:  dof.get_fe(0).n_components() == 1*

What is the proper way to call the real and imaginary parts of the solution 
at a particular point here?


Thank you very much!

H.

-- 
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/54a2d44e-194a-43c0-aa7f-9fddd5bd0dean%40googlegroups.com.

Re: [deal.II] Output file

[Hermes Sampedro]

Thank you very much for your answer. Is it then not possible to use somehow
the DataOut approach presented in step-29 and use a 'txt' parameter in the
.prm file?

In case of doing that manually as you suggested, how could I access the
real and imaginary parts in the solution vector (step-29)?

Doing something like:

   ofstream myfile;

myfile.open ("solution.txt");

myfile << "Point:\t" <<
VectorTools::point_value(dof_handler,solution,Point<2>(1./3, 1./3));

myfile.close();


I get an error when running:


dof.get_fe(0).n_components() == 1


Thank you again for the help.

Regards,

H



El mié, 4 ago 2021 a las 16:12, Wolfgang Bangerth ()
escribió:

> On 8/4/21 7:49 AM, Hermes Sampedro wrote:
> >
> > I am working with step-29 and I was wondering what is the best way to
> import
> > the solution vectors (real, imaginary and intensity solutions) into
> Matlab. Is
> > it possible to export one point of the solution into a txt file? Or what
> would
> > be the easiest way using Dealii for that?
>
> It depends on what you actually want to do with it. I believe that Matlab
> can
> read VTK or VTU files, but these are tailored towards visualization. If
> you
> want the solution at a small number of individual points, you can evaluate
> it
> with VectorTools::point_value() and then output these values by hand.
>
> Best
>   W.
>
> --
> 
> Wolfgang Bangerth  email: bange...@colostate.edu
> 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 a topic in the
> Google Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/dealii/CoL0PqpZ5v8/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/2596a4f4-4a43-4276-43d1-bf3d36fb3d98%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 dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/CAB%3DnHhb_3Twk3XEe_UG7djCZrt-a%2B4iT-dAVdU_kFqRC7KSRSA%40mail.gmail.com.

[deal.II] Output file

[Hermes Sampedro]

Hello, 

I am working with step-29 and I was wondering what is the best way to 
import the solution vectors (real, imaginary and intensity solutions) into 
Matlab. Is it possible to export one point of the solution into a txt file? 
Or what would be the easiest way using Dealii for that?

Thank you
Regards, 
H

-- 
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/2f512507-45ef-4c96-ac66-faa5624941dan%40googlegroups.com.

[deal.II] Higher order elements

[Hermes Sampedro]

Dear all, 

I would like to ask how to handle higher-order elements. I would need to 
use 4th order. Looking at the first tutorials, I found that using FE_Q, it 
is possible to use only 1st and 2nd order.

https://www.dealii.org/current/doxygen/deal.II/classFE__Q.html#ac36967b6e5de1ff1f4d54e0fa779d876

Thank you

-- 
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/ec51d175-3495-4065-a2cc-4e7bd229e984n%40googlegroups.com.