[deal.II] Re: More CutFEM examples

[simon...@gmail.com]

Hi,

> Is there a similar tutorial for solving linear static analysis using 
CutFEM, especially with illustration of how to setup boundary conditions.

There is no tutorial for this. You would set the boundary conditions weakly 
at the immersed boundaries. Here are two papers on linear elasticity with 
cutfem

dx.doi.org/10.1007/978-3-319-71431-8_2

dx.doi.org/10.1007/s10444-020-09785-z

This does not cover all possible boundary conditions one can have in linear 
elasticity, but it is a starting point.

> Also, is it possible adopt CutFEM for topology optimization? How would 
one go about it?

Yes. There have been several papers written on this. Here are two:

dx.doi.org/10.1016/j.cma.2019.03.016

dx.doi.org/10.1002/nme.5621

I'm sure one could find more with some searching.

Compared to for example SIMP (as in step 79), the benefit is that the 
discretization of the PDE is more accurate. The price is that the 
implementation is much more complicated.

Best,
Simon

On Sunday, July 14, 2024 at 4:00:04 AM UTC+2 sk.bi...@gmail.com wrote:

> Hi,
>
> Step-85 shows example of CutFEM for Poisson's equation. Is there a similar 
> tutorial for solving linear static analysis using CutFEM, especially with 
> illustration of how to setup boundary conditions. 
>
> Also, is it possible adopt CutFEM for topology optimization? How would one 
> go about it?
>
> Appreciate any comments on this.
>
> Regards
> SK
>

-- 
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/b6c9dce6-0694-4e8b-84ac-a05829e8342en%40googlegroups.com.

Re: [deal.II] "constraints for degree of freedom ... should not be stored ... " after SolutionTransfer

[Simon]

I figured out the problem. 

In my make_constraints() function, I re-initialized the AffineConstraints 
object indeed with 
the locally releveant DoFs as you said (although this is not necessary in 
the serial version of my code). 

Thanks for pointing out to this!

-Simon

Wolfgang Bangerth schrieb am Montag, 10. Juni 2024 um 19:05:01 UTC+2:

>
> On 6/10/24 00:13, Simon wrote:
> > No, the program that produced the error is serial not parallel.
>
> I think then I'd need to see the whole program :-)
>
> Best
> W.
>

-- 
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/11ee8fef-a9e5-45e2-968c-e8382b743c3bn%40googlegroups.com.

Re: [deal.II] "constraints for degree of freedom ... should not be stored ... " after SolutionTransfer

[Simon]

No, the program that produced the error is serial not parallel.

Best,
Simon

Wolfgang Bangerth schrieb am Montag, 10. Juni 2024 um 04:30:33 UTC+2:

> On 6/8/24 07:51, Simon wrote:
> > 
> > Before refinement, dofHandler stored 138 DoFs, after refinement 202.
> > 
> > I could not reproduce the error on a minimal example.
> > However, it is not clear to me why
> > make_hanging_constraints() reports an error associated with dof index 
> 167,
> > if I cleared the constraints object before hand and can be certain that 
> my 
> > DoFHandler has 202 DoFs.
> > So the sequence of distributing DoFs, followed by clearing constraints 
> and 
> > calling make hanging node constraints should work independently of how 
> my 
> > program arrived at these lines of code. Is this not true?
> > 
> > Any general hints as for the problem source and narrowing down the 
> problem?
>
> Did you initialize the AffineConstraints object with index sets for the 
> locally owned and/or locally relevant DoFs? If so, you will have to 
> re-initialize it with the now larger/different number of DoFs you have 
> after 
> mesh refinement.
>
> 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/66d6a3fd-eb61-45ab-9ca1-509ed97bdc39n%40googlegroups.com.

[deal.II] "constraints for degree of freedom ... should not be stored ... " after SolutionTransfer

[Simon]

Dear all,

I am doing a SolutionTransfer in the same fashion as described in the docu 
of SolutionTransfer class. 
After calling
-triangulation.execute_coarsening_and_refinement(); 
I proceed with
-dofHandler.distribute_dofs(feSystem);
-constraints.clear();
-DoFTools::make_hanging_node_constraints(dofHandler, constraints);
where my feSystem has 2 blocks (3 copies of FE_Q<3(1) and 1 copy of 
FE_DGQ<3>(0))

The function 
DoFTools::make_hanging_node_constraints(dofHandler, constraints)

throws

  dealii::types::global_dof_index dealii::AffineConstraints<
number>::calculate_line_index(size_type) const [with number = double; 
dealii::types::global_dof_index = unsigned int; size_type = unsigned int]
The violated condition was: 
local_lines.is_element(line_n)
Additional information: 
The index set given to this constraints object indicates constraints
for degree of freedom 167 should not be stored by this object, but a
constraint is being added. 

Before refinement, dofHandler stored 138 DoFs, after refinement 202. 

I could not reproduce the error on a minimal example.
However, it is not clear to me why
make_hanging_constraints() reports an error associated with dof index 167, 
if I cleared the constraints object before hand and can be certain that my 
DoFHandler has 202 DoFs. 
So the sequence of distributing DoFs, followed by clearing constraints and 
calling make hanging node constraints should work independently of how my 
program arrived at these lines of code. Is this not true?

Any general hints as for the problem source and narrowing down the problem? 

Thanks,
Simon
 
 



-- 
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/8c7a9d55-549e-4750-9141-88add9f91470n%40googlegroups.com.

[deal.II] mapping of global dof indices after solution transfer

[Simon]

Dear all,

I am storing a std::vector of size N holding global DOF 
indices living at some nodes of my mesh where we have measured experimental 
values.
After doing a SolutionTransfer motivated by AMR, I want to have the new 
global DOF indices at the same nodes, so the new vector of indices has the 
same size N.

I feel the only way to do this is to store the indices along with their 
support points before I enter the AMR cycle (so far I only store the 
indices) and determine the new indices after refinement by looping over the 
new mesh and check the support points for equality.

Is there a more efficient solution for this problem?

Thanks,
Simon

-- 
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/0e4febd6-d884-4584-a33c-49ba8f255c37n%40googlegroups.com.

Re: [deal.II] Sparsity pattern error in the context of diffuse domain with hp-capability and CIP

[Simon Sticko]

Hi.


1. Is there a way to deal make a correct sparsity pattern accounting for 
hanging nodes, FENothing elements and coupling of faces that have ghost penalty 
or is this really a feature that isn't implemented in deal.ii ?


If you do not care so much about performance at this stage, you can just avoid 
passing the face_has_flux_coupling lambda to make_flux_sparsity_pattern (the 
version that takes cell and face couplings). You will then get a flux coupling 
over all faces. This gives a sparsity pattern with more entries than you need, 
but you will not get an exception.

The alternative is to choose the face_has_flux_coupling lambda more carefully. 
The problem is that you are trying to assign values to entries in the matrix 
that does not exist in the sparsity pattern.



2. Should I assemble the matrix without taking care of the constraints and 
apply them afterwards ?


No, see 1.



3. Why do the sparsity patterns differ from one call to another ?


The implementation of the two functions are different. The simpler function has 
a bug in it. There is an open issue for this:

https://github.com/dealii/dealii/issues/12037

but since there is a workaround, it has not been prioritized.


Best,
Simon


On 01/05/2024 23:39, 'Matthias Nicola Henssler' via deal.II User Group wrote:

Dear all,

*Background :* I am currently trying to implement a diffuse domain formulation 
to solve the poisson equation whilst penalizing the jumps in gradient in very 
similar way to what step-85 showcases. The nuance relative to the mentioned 
tutorial stems the need for AMR close to the boundary.
Having worked through this problem without neglecting the outside of the domain 
(contrary to what is shown in step-85 with the use of FENothing in the 
FECollection object for all the elements for which the level set is positive on 
all vertices), I found myself wanting to implement this feature again.

*Issue :* Taking good care to assigne FENothing only to the cells that extend 
beyond an arbitrary threshold to avoid computing the face values on a cell 
who's neighbor is neglected, I got the following error when computing the flux 
sparsity pattern. Note that hanging nodes are taken into account. Note that 
this issue arise only if cells are flagged for ghost penalty and if elements 
(outside the domain of interest) are attributed the FENothing finite element.



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

     const unsigned int           n_components = fe_collection.n_components();
     Table<2, DoFTools::Coupling> cell_coupling(n_components, n_components);
     Table<2, DoFTools::Coupling> face_coupling(n_components, n_components);
     cell_coupling[0][0] = DoFTools::always;
     face_coupling[0][0] = DoFTools::always;


     const bool                      keep_constrained_dofs = true;
     constraints.clear();
     DoFTools::make_hanging_node_constraints(dof_handler, constraints);
     constraints.close();
     DoFTools::make_flux_sparsity_pattern(dof_handler,
                                           dsp,
                                           constraints,
                                           keep_constrained_dofs,
                                           cell_coupling,
                                           face_coupling,
                                           numbers::invalid_subdomain_id);


-
The violated condition was:
     matrix_values->column() == column
Additional information:
     You are trying to access the matrix entry with index <14,142>, but
     this entry does not exist in the sparsity pattern of this matrix.
-

Having tried the following sister make_flux_sparsity_pattern() function call 
without explicitly passing the cell and face couplings, I get this error:
-
An error occurred in line <4467> of file 
 
in function
     void dealii::AffineConstraints::add_entries_local_to_global(const std::vector&, const 
dealii::AffineConstraints&, const std::vector&, dealii::SparsityPatternBase&, bool, 
const dealii::Table<2, bool>&) const [with number = double]
The violated condition was:
     false
Additional information:
     You are trying to use functionality in deal.II that is currently not
     implemented. In many cases, this indicates that there simply didn't
     appear much of a need for it, or that the author of the original code
     did not have the time to implement a particular case. If you hit this
     exception, it is therefore worth the time to look into the code to
     find out whether you may be able to implement the missing
     functionality. If you do, please consider providing a patch to the
     deal.II development sources (see the deal.II website on how to
     contribute).
--

Re: [deal.II] Sparsity pattern error in the context of diffuse domain with hp-capability and CIP

[Simon Sticko]

Hi.


1. Is there a way to deal make a correct sparsity pattern accounting for 
hanging nodes, FENothing elements and coupling of faces that have ghost penalty 
or is this really a feature that isn't implemented in deal.ii ?


If you do not care so much about performance at this stage, you can just avoid 
passing the face_has_flux_coupling lambda to make_flux_sparsity_pattern (the 
version that takes cell and face couplings). You will then get a flux coupling 
over all faces. This gives a sparsity pattern with more entries than you need, 
but you will not get an exception.

The alternative is to choose the face_has_flux_coupling lambda more carefully. 
The problem is that you are trying to assign values to entries in the matrix 
that does not exist in the sparsity pattern.



2. Should I assemble the matrix without taking care of the constraints and 
apply them afterwards ?


No, see 1.



3. Why do the sparsity patterns differ from one call to another ?


The implementation of the two functions are different. The simpler function has 
a bug in it. There is an open issue for this:

https://github.com/dealii/dealii/issues/12037

but since there is a workaround, it has not been prioritized.


Best,
Simon


On 01/05/2024 23:39, 'Matthias Nicola Henssler' via deal.II User Group wrote:

Dear all,

*Background :* I am currently trying to implement a diffuse domain formulation 
to solve the poisson equation whilst penalizing the jumps in gradient in very 
similar way to what step-85 showcases. The nuance relative to the mentioned 
tutorial stems the need for AMR close to the boundary.
Having worked through this problem without neglecting the outside of the domain 
(contrary to what is shown in step-85 with the use of FENothing in the 
FECollection object for all the elements for which the level set is positive on 
all vertices), I found myself wanting to implement this feature again.

*Issue :* Taking good care to assigne FENothing only to the cells that extend 
beyond an arbitrary threshold to avoid computing the face values on a cell 
who's neighbor is neglected, I got the following error when computing the flux 
sparsity pattern. Note that hanging nodes are taken into account. Note that 
this issue arise only if cells are flagged for ghost penalty and if elements 
(outside the domain of interest) are attributed the FENothing finite element.



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

     const unsigned int           n_components = fe_collection.n_components();
     Table<2, DoFTools::Coupling> cell_coupling(n_components, n_components);
     Table<2, DoFTools::Coupling> face_coupling(n_components, n_components);
     cell_coupling[0][0] = DoFTools::always;
     face_coupling[0][0] = DoFTools::always;


     const bool                      keep_constrained_dofs = true;
     constraints.clear();
     DoFTools::make_hanging_node_constraints(dof_handler, constraints);
     constraints.close();
     DoFTools::make_flux_sparsity_pattern(dof_handler,
                                           dsp,
                                           constraints,
                                           keep_constrained_dofs,
                                           cell_coupling,
                                           face_coupling,
                                           numbers::invalid_subdomain_id);


-
The violated condition was:
     matrix_values->column() == column
Additional information:
     You are trying to access the matrix entry with index <14,142>, but
     this entry does not exist in the sparsity pattern of this matrix.
-

Having tried the following sister make_flux_sparsity_pattern() function call 
without explicitly passing the cell and face couplings, I get this error:
-
An error occurred in line <4467> of file 
 
in function
     void dealii::AffineConstraints::add_entries_local_to_global(const std::vector&, const 
dealii::AffineConstraints&, const std::vector&, dealii::SparsityPatternBase&, bool, 
const dealii::Table<2, bool>&) const [with number = double]
The violated condition was:
     false
Additional information:
     You are trying to use functionality in deal.II that is currently not
     implemented. In many cases, this indicates that there simply didn't
     appear much of a need for it, or that the author of the original code
     did not have the time to implement a particular case. If you hit this
     exception, it is therefore worth the time to look into the code to
     find out whether you may be able to implement the missing
     functionality. If you do, please consider providing a patch to the
     deal.II development sources (see the deal.II website on how to
     contribute).
--

[deal.II] Re: Sparsity pattern error in the context of diffuse domain with hp-capability and CIP

[simon...@gmail.com]

Hi. 

1. Is there a way to deal make a correct sparsity pattern accounting for 
hanging nodes, FENothing elements and coupling of faces that have ghost 
penalty or is this really a feature that isn't implemented in deal.ii ? 


If you do not care so much about performance at this stage, you can just 
avoid passing the face_has_flux_coupling lambda to 
make_flux_sparsity_pattern (the version that takes cell and face 
couplings). You will then get a flux coupling over all faces. This gives a 
sparsity pattern with more entries than you need, but you will not get an 
exception. 

The alternative is to choose the face_has_flux_coupling lambda more 
carefully. The problem is that you are trying to assign values to entries 
in the matrix that does not exist in the sparsity pattern. 


2. Should I assemble the matrix without taking care of the constraints and 
apply them afterwards ? 


No, see 1. 


3. Why do the sparsity patterns differ from one call to another ? 


The implementation of the two functions are different. The simpler function 
has a bug in it. There is an open issue for this: 

https://github.com/dealii/dealii/issues/12037 

but since there is a workaround, it has not been prioritized. 


Best, 
Simon 

On Thursday, May 2, 2024 at 12:40:00 AM UTC+2 matthias...@epfl.ch wrote:

> Dear all,
>
> *Background :* I am currently trying to implement a diffuse domain 
> formulation to solve the poisson equation whilst penalizing the jumps in 
> gradient in very similar way to what step-85 showcases. The nuance relative 
> to the mentioned tutorial stems the need for AMR close to the boundary. 
> Having worked through this problem without neglecting the outside of the 
> domain (contrary to what is shown in step-85 with the use of FENothing in 
> the FECollection object for all the elements for which the level set is 
> positive on all vertices), I found myself wanting to implement this feature 
> again. 
>
> *Issue :* Taking good care to assigne FENothing only to the cells that 
> extend beyond an arbitrary threshold to avoid computing the face values on 
> a cell who's neighbor is neglected, I got the following error when 
> computing the flux sparsity pattern. Note that hanging nodes are taken into 
> account. Note that this issue arise only if cells are flagged for ghost 
> penalty and if elements (outside the domain of interest) are attributed the 
> FENothing finite element. 
>
>
>
> DynamicSparsityPattern dsp(dof_handler.n_dofs(), dof_handler.n_dofs());
> 
> const unsigned int   n_components = 
> fe_collection.n_components();
> Table<2, DoFTools::Coupling> cell_coupling(n_components, n_components);
> Table<2, DoFTools::Coupling> face_coupling(n_components, n_components);
> cell_coupling[0][0] = DoFTools::always;
> face_coupling[0][0] = DoFTools::always;
>
>
> const bool  keep_constrained_dofs = true;
> constraints.clear();
> DoFTools::make_hanging_node_constraints(dof_handler, constraints);
> constraints.close();
> DoFTools::make_flux_sparsity_pattern(dof_handler,
>   dsp,
>   constraints,
>   keep_constrained_dofs,
>   cell_coupling,
>   face_coupling,
>   numbers::invalid_subdomain_id);
>
>
> -
> The violated condition was: 
> matrix_values->column() == column
> Additional information: 
> You are trying to access the matrix entry with index <14,142>, but
> this entry does not exist in the sparsity pattern of this matrix.
> -
>
> Having tried the following sister make_flux_sparsity_pattern() function 
> call without explicitly passing the cell and face couplings, I get this 
> error:
> -
> An error occurred in line <4467> of file 
> 
>  
> in function
> void 
> dealii::AffineConstraints::add_entries_local_to_global(const 
> std::vector&, const dealii::AffineConstraints&, const 
> std::vector&, dealii::SparsityPatternBase&, bool, const 
> dealii::Table<2, bool>&) const [with number = double]
> The violated condition was: 
> false
> Additional information: 
> You are trying to use functionality in deal.II that is currently not
> implemented. In many cases, this indicates that there simply didn't
> appear much of a need for it, or that the author of the original code
> did not have the time to i

Re: [deal.II] trilinos sparsity pattern: end iterator of last locally owned row triggers trilinos error

[Simon]

"Would you be willing to create a complete example, and open a bug report 
for
this on github?"

Sure. I opened an issue 
https://github.com/dealii/dealii/issues/16414

Do you think this bug has a quick solution?
I am interested in the columns of the rows. 
I did not see a different way to do this than using the row iterators.

Best,
Simon

On Thursday, January 4, 2024 at 9:50:36 PM UTC+1 Wolfgang Bangerth wrote:


Simon: 

> attached is a minimal example with 125 dofs, where dofs with indices 0-74 
> live on proccesor 0 and dofs with indices 75-124 live on processor 1 
> (two MPI processes). 
> 
> Consider the following code to loop over the rows of a Trilinos sparsity 
pattern: 
> // make_sparsity_pattern,... 
> for(unsigned int row = 0; row < dofHandler.n_dofs(); ++row) 
> { 
>if( ! sparsityPattern.row_is_stored_locally(row)) continue; 
>auto it = sparsityPattern.begin(row); 
>auto itend = sparsityPattern.end(row); 
>// do something with the columns 
>while(it != itend) { it->column();...} 
> } 
> 
> For row=74 on processor 0, there is an error 
> 
> 
dealii::TrilinosWrappers::SparsityPatternIterators::Accessor::visit_present_row()
 

> "An error with error number -1 occurred while calling a Trilinos 
function" 
> 
> The mentioned Trilinos function is ExtractGlobalRowCopy() and the error 
number 
> suggests an access to a row which is not locally owned. 
> This makes sense to me because 
> sparsityPattern.end(74) calls visit_present_row(75), 
> which is indeed not locally owned. 
> 
> Not sure whether I miss something or this is a bug. 

A bug. And a timely one in view of the fact that I have been thinking about 
exactly this issue recently: 
https://github.com/dealii/dealii/pull/16406 
Would you be willing to create a complete example, and open a bug report 
for 
this on github? 

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/4f17ab8a-c292-4601-83dc-16e43a9c69a9n%40googlegroups.com.

[deal.II] trilinos sparsity pattern: end iterator of last locally owned row triggers trilinos error

[Simon]

Dear all,

attached is a minimal example with 125 dofs, where dofs with indices 0-74 
live on proccesor 0 and dofs with indices 75-124 live on processor 1
(two MPI processes).

Consider the following code to loop over the rows of a Trilinos sparsity 
pattern:
// make_sparsity_pattern,...
for(unsigned int row = 0; row < dofHandler.n_dofs(); ++row)
{
   if( ! sparsityPattern.row_is_stored_locally(row)) continue;
   auto it = sparsityPattern.begin(row); 
   auto itend = sparsityPattern.end(row); 
   // do something with the columns
   while(it != itend) { it->column();...}
}

For row=74 on processor 0, there is an error 

dealii::TrilinosWrappers::SparsityPatternIterators::Accessor::visit_present_row()
"An error with error number -1 occurred while calling a Trilinos function"

The mentioned Trilinos function is ExtractGlobalRowCopy() and the error 
number
suggests an access to a row which is not locally owned. 
This makes sense to me because 
sparsityPattern.end(74) calls visit_present_row(75),
which is indeed not locally owned.

Not sure whether I miss something or this is a bug.
My expectation was to use the begin and end iterators on all locally owned 
rows.

Thank you,
Simon

-- 
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/cb270b3a-8c45-40cf-9efe-2a579fdab28an%40googlegroups.com.

#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 

#include 

#include 
#include 
#include 

#include 

#include 

namespace dealiiLA
{
  using namespace dealii::TrilinosWrappers;
} 

int main(int argc, char *argv[])
{
dealii::Utilities::MPI::MPI_InitFinalize mpiInitialization(argc, argv, 1);
MPI_Comm const &mpiCommunicator(MPI_COMM_WORLD);

dealii::parallel::distributed::Triangulation<3> tria(mpiCommunicator);
dealii::GridGenerator::hyper_cube(tria);
tria.refine_global(2);

dealii::DoFHandler<3> dofHandler(tria);
dealii::FE_Q<3> fe(1);
dofHandler.distribute_dofs(fe);

dealii::DoFRenumbering::component_wise(dofHandler);

dealii::IndexSet locallyOwnedDofs = dofHandler.locally_owned_dofs();

dealiiLA::SparsityPattern sparsityPattern;
sparsityPattern.reinit(locallyOwnedDofs, mpiCommunicator);
dealii::DoFTools::make_sparsity_pattern(dofHandler,
  sparsityPattern,
  dealii::AffineConstraints(),
  false,
  
dealii::Utilities::MPI::this_mpi_process(
mpiCommunicator));
sparsityPattern.compress();

for(unsigned int i=0; i

Re: [deal.II] access all elements of a row of a trilinos sparse matrix

[Simon Wiesheier]

Yes, basically I want to compute a matrix-vector product.
But if my system has say 500k DoFs, I only need say 1k elements of the
result of vmult, because the number of rows I am interested in is quite
small -- they correspond to a small set of DoFs living on the boundary.

For efficiency reasons, I decided to loop manually over the rows I am
interested in.
In a serial program, that worked smoothly. But if I get the gist of your
message, vmult and extracting the relevant elements is the only way to do
this in parallel, right?

Thank you,
Simon

Wolfgang Bangerth  schrieb am Fr., 29. Dez. 2023,
19:02:

> On 12/28/23 12:22, Simon wrote:
> >
> > I want to build the scalar product between rows of a
> > TrilinosWrappers::SparseMatrix and a TrilinosWrappers::MPI::Vector.
>
> This sounds like you're computing a matrix-vector product -- the dot
> products
> you compute are the elements of the resulting vector.
>
> As you have learned, it isn't entirely trivial to determine how
> information
> must be transmitted in parallel for these kinds of operations. But it is
> also
> not necessary: The parallel matrix classes all have matrix-vector
> ("vmult")
> operations implemented. Why not use those?
>
> 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 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/8e748b05-a6da-45d6-bd2a-23b552c818e6%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/CAM50jEs67zos%3D4oJ3fGs2_J_-T-2vsywjb6xVdd7BTqXd5%2B6AQ%40mail.gmail.com.

[deal.II] access all elements of a row of a trilinos sparse matrix

[Simon]

Dear all,


I want to build the scalar product between rows of a
TrilinosWrappers::SparseMatrix and a TrilinosWrappers::MPI::Vector. 
I implemented this by looping over the elements of the rows via iterators 
(it = systemMatrix.begin(row) , itend = systemMatrix.end(row) 
-> while (it != itend) { ... it++; } )
Inside while, I calculate it->value (to get the matrix element) times 
vec(it->column()) 
(to get the corresponding vector element) and sum it up.
I calculate the scalar product for a set of rows and store the result in a 
FullMatrix 
which I finally write to a file from the master process,
after gathering the local full matrices from all processors.
Attached is a small example which demonstrates this in practice.

In a parallel program, vec(it->column()) only works if it->column() is a 
locally owned element of the vector. So I wrapped this read access in 
if( vec.in_local_range(it->column() ) .
Another problem is the following:
Say row 5 lives on processor 0 and has non-zero entries at columns 
10,15,20,25,30.
Columns 10,15,20 live on processor 0 as well but columns 25,30 live on 
processor 1. 
Then, I will never add the contributions to the scalar product from columns 
25 and 30 because on processor 1, 
systemMatrix.begin(5) == systemMatrix.end(5)
which is also stated in the docu.

How can I deal with this?


Best,
Simon

-- 
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/03085575-2931-4755-abcd-7b7a31df102dn%40googlegroups.com.

#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 

#include 

#include 
#include 
#include 

#include 

#include 
#include 
#include 
#include 

namespace dealiiLA
{
  using namespace dealii::TrilinosWrappers;
} // namespace dealiiLA

int main(int argc, char *argv[])
{

const unsigned intmasterProcessRank = 0;
dealii::Utilities::MPI::MPI_InitFinalize mpiInitialization(argc, argv, 1);
MPI_Comm const &mpiCommunicator(MPI_COMM_WORLD);
unsigned int processorRank = 
dealii::Utilities::MPI::this_mpi_process(mpiCommunicator);
dealii::ConditionalOStream pCout(std::cout, processorRank == 
masterProcessRank);

// make grid
dealii::parallel::distributed::Triangulation<3> tria(mpiCommunicator);
dealii::GridGenerator::hyper_cube(tria);
tria.refine_global(2);

// distribute dofs
dealii::DoFHandler<3> dofHandler(tria);
dofHandler.distribute_dofs(dealii::FE_Q<3>(1));

dealii::IndexSet locallyOwnedDofs = dofHandler.locally_owned_dofs();
dealii::IndexSet locallyRelevantDofs;
dealii::DoFTools::extract_locally_relevant_dofs(dofHandler, 
locallyRelevantDofs);

dealii::AffineConstraints constraintMatrix;
constraintMatrix.clear();
constraintMatrix.reinit(locallyRelevantDofs);
dealii::DoFTools::make_hanging_node_constraints(dofHandler, 
constraintMatrix);
constraintMatrix.close();

// sparse matrix and sparsity pattern
dealiiLA::SparsityPattern sparsityPattern;
sparsityPattern.reinit(locallyOwnedDofs, mpiCommunicator);
dealii::DoFTools::make_sparsity_pattern(dofHandler,
  sparsityPattern,
  constraintMatrix,
  false,
  
dealii::Utilities::MPI::this_mpi_process(
mpiCommunicator));
sparsityPattern.compress();

dealiiLA::SparseMatrix systemMatrix;
systemMatrix.reinit(sparsityPattern);

// create dummy vector
dealii::TrilinosWrappers::MPI::Vector vec;
vec.reinit(locallyOwnedDofs, mpiCommunicator);
for(unsigned int i=0; i rows{10, 40, 70, 100, 120}; //nDoFs = 125
dealii::FullMatrix matrix(rows.size(), 1);
// populate fullmatrix
for(unsigned int i = 0; i < rows.size(); ++i)
{
  unsigned int idx = rows[i];
  auto it = systemMatrix.begin(idx);
  auto itend = systemMatrix.end(idx);
  // loop over row idx (first contribution)
  while(it != itend)
  {
matrix(i, 0) += vec.in_local_range((*it).column()) ? ((*it).value() + 
1) * vec((*it).column()) : 0.0;
it++;
  }
  // second contribution
  if(vec.in_local_range(idx))
matrix(i, 0) += vec(idx);
}

// send local matrices to processor 0
std::vector> gathered = 
  dealii::Utilities::MPI::gather(mpiCommunicator, matrix, 0);

// write the matrix from processor 0
if(processorRan

Re: [deal.II] construct TrilinosWrappers::SparseMatrix from TrilinosWrappers::BlockSparseMatrix to use Amesos direct solver

[Simon]

Timo,

" What I have done in several codes (and what is used in ASPECT), is to 
always create block matrices and vectors but to put all DoFs into a single 
block when a direct solver is used. This decision can be made at rintime. 
Inside the solve routine you can just access block_matrix.block(0,0), which 
is a SparseMatrix. Same for the vector. This way, there are no different 
code paths, different types, or copies involved. "

In terms of readability, this sounds like the best solution. 

My motivation to use block structures even for direct solvers is to compute
norms of the pressure or the velocity, if we talk about the Stokes system.
Or in general, having access to the individual blocks to write them to 
files,...

If I am not mistaken, you create a nested finite element system with one 
block

FESystem<3>feVelocity( FE_Q<3>(degree), 3 );
FE_DGQ<3>   fePressure(degree-1);
FESystem<3>nestedFE ( feVelocity, 1, fePressure, 1 ); 

resulting in a 1x1 block system.
But it is not clear to me how to compute the norms of velocity and pressure 
in that case.
So far, I used a Block indices object as returned by 
DoFTools::count_dofs_per_fe_block()
since I compute the l2-norm only of the unconstrained DoFs. 

That said, how do you access the velocity and pressure block when working 
with direct solvers?

Thank you,
Simon
Timo Heister schrieb am Dienstag, 19. Dezember 2023 um 20:02:30 UTC+1:

> What I have done in several codes (and what is used in ASPECT), is to 
> always create block matrices and vectors but to put all DoFs into a single 
> block when a direct solver is used. This decision can be made at rintime. 
> Inside the solve routine you can just access block_matrix.block(0,0), which 
> is a SparseMatrix. Same for the vector. This way, there are no different 
> code paths, different types, or copies involved.
>
> --
> Timo Heister
> http://www.math.clemson.edu/~heister/
> --
> *From:* dea...@googlegroups.com  on behalf of 
> Wolfgang Bangerth 
> *Sent:* Monday, December 18, 2023 4:37:34 PM
> *To:* dea...@googlegroups.com 
> *Subject:* Re: [deal.II] construct TrilinosWrappers::SparseMatrix from 
> TrilinosWrappers::BlockSparseMatrix to use Amesos direct solver 
>  
> This Message Is From An External Sender: Use caution when opening links or 
> attachments if you do not recognize the sender.
>
>
> On 12/18/23 12:44, Simon wrote:
> >
> > I use a BlockSolver for the solution and right hand side of the
> > linear system to compute the various norms (non-linear solver) of the
> > the individual blocks. For a direct solver, I would now use a
> > SparseMatrix as matrix type and a BlockVector as vector type. At each
> > solve, I convert the BlockVector to a standard Vector, which I guess
> > is not too expensive. This mix (SparseMatrix and BlockVector) should
> > not cause any undue problems, right? Or would you not recommend
> > this?
> No. This seems like a reasonable approach to me.
> Best
>   W.
>
> --
> The deal.II project is located at 
> https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.dealii.org%2F&data=05%7C02%7Cheister%40clemson.edu%7Cb26c1543ea3f4a770d1a08dc00118fcd%7C0c9bf8f6ccad4b87818d49026938aa97%7C0%7C0%7C638385322953674220%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=FCQhyskq54Y%2B9Uc7oyauIeXMsI5CLzO12RE%2FCDG1w3Y%3D&reserved=0
>  
> <http://www.dealii.org/>
> For mailing list/forum options, see 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fforum%2Fdealii%3Fhl%3Den&data=05%7C02%7Cheister%40clemson.edu%7Cb26c1543ea3f4a770d1a08dc00118fcd%7C0c9bf8f6ccad4b87818d49026938aa97%7C0%7C0%7C638385322953674220%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=QKshKRkLcezx3WBxZW4FajigvudlynOE6GClmS9nNnY%3D&reserved=0
>  
> <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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fdealii%2F15994792-761a-4899-b7e6-af2fc6ba2932%2540colostate.edu&data=05%7C02%7Cheister%40clemson.edu%7Cb26c1543ea3f4a770d1a08dc00118fcd%7C0c9bf8f6ccad4b87818d49026938aa97%7C0%7C0%7C638385322953674220%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=Lmjub869SyEbNQ5DTAN4RNnzG41%2B2XEWpPs6s97c9OU%3D&reserve

Re: [deal.II] construct TrilinosWrappers::SparseMatrix from TrilinosWrappers::BlockSparseMatrix to use Amesos direct solver

[Simon]

 "This. I don't see a different way of doing things. Though I might just 
always 
create both objects and then call distribute_local_to_global() with one or 
the 
other matrix object, depending on your run-time flags. "

Your approach sounds more reasonable than copying data back and forth at 
every Newton step
for a possibly large linear system.

I use a BlockSolver for the solution and right hand side of the linear 
system to compute the various norms (non-linear solver) 
of the the individual blocks.
For a direct solver, I would now use a SparseMatrix as matrix type and a 
BlockVector as vector type.
At each solve, I convert the BlockVector to a standard Vector, which I 
guess is not too expensive.
This mix (SparseMatrix and BlockVector) should not cause any undue 
problems, right?
Or would you not recommend this?

Best
Simon





Wolfgang Bangerth schrieb am Montag, 18. Dezember 2023 um 18:03:13 UTC+1:

> On 12/18/23 04:47, Simon wrote:
> > 
> > Can you think of an elegant solution or must the non-zero values be 
> copied via 
> > a loop
> > over the individual blocks?
>
> This. I don't see a different way of doing things. Though I might just 
> always 
> create both objects and then call distribute_local_to_global() with one or 
> the 
> other matrix object, depending on your run-time flags.
>
> 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/9b61d0e7-6ea3-4db9-aa6a-578304bee319n%40googlegroups.com.

[deal.II] construct TrilinosWrappers::SparseMatrix from TrilinosWrappers::BlockSparseMatrix to use Amesos direct solver

[Simon]

Dear all,

there are several discussions, e.g.
https://groups.google.com/g/dealii/c/KU7g_YCNVRE/m/h7ab-2gRCAAJ?hl=en 
or 
https://groups.google.com/g/dealii/c/DdMiTjuPx6Q/m/UeH4fmmBAwAJ?hl=en
about the usage of TrilinosWrappers::BlockSparseMatrix in the context of 
direct solvers 
in a distributed framework.
Still, only TrilinosWrappers::SparseMatrix can be feeded to 
TrilinosWrappers::SparseDirect solvers.  

I am solving a 2x2 block system with iterative and direct solvers (decision 
is made at run-time via .prm file). 
Clearly, I do not need a BlockSparseMatrix for a direct solve, however, 
to have a similar code base also for the iterative solve (where I need a 
block preconditioner), 
I decided to use block quantities for each solver type. 

It is not a big deal to copy a BlockVector into a Vector, but what is an 
efficient scheme (my problem is non-linear) to 
copy a BlockSparseMatrix into a SparseMatrix as needed for the direct 
solvers coming with trilinos?
Conceptually, I am looking for a constructor 
SparseMatrix (const BlockSparseMatrix &) 
or a copy_from function. 
For instance, the std::memcpy function is used in 
SparseMatrix::reinit (const Epetra_CrsMatrix & *, **copy_values* = true) ,
but I am not sure whether it can be used when translating between Block and 
standard SparseMatrix. 

Can you think of an elegant solution or must the non-zero values be copied 
via a loop
over the individual blocks?

Best regards,
Simon



-- 
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/70bcce5b-73c4-4550-ac0c-368ce549e0bfn%40googlegroups.com.

Re: [deal.II] extract_surface_mesh() does not extract refined cells

[Simon Wiesheier]

No worries :-)

Setting the boundary ids on the coarse grid did the trick (no need to do it
again on the refined grid).

A short follow-up:
After extracting the surface mesh (Triangulation<2,3>),
I want to get rid of the Z-coordinate to obtain a Triangulation<2>.
Unfortunately, GridGenerator::flatten_triangulation<2, 3, 2>(...)
does not work in the presence of hanging nodes.

Any workarounds for this issue?

Best,
Simon

Am Di., 5. Dez. 2023 um 21:48 Uhr schrieb Luca Heltai :

> By the way:
>
> Sorry if my reply was not too precise at the beginning, and if it sound
> harsh, but I cannot not run your code on my iPhone (yet), even though I’m
> working on it.
>
> :)
>
> Till then, may I suggest that you provide as much information as you can,
> if you want people to answer quickly? Asking people to download the code,
> put it somewhere where deal.II is available and then running it and
> debugging it is unlikely to produce a quick answer other than “can you tell
> us more?”.
>
> Luca
>
> Il giorno 5 dic 2023, alle ore 9:25 PM, Simon Wiesheier <
> simon.wieshe...@gmail.com> ha scritto:
>
> 
> Dear Luca,
>
> the program I provided writes the volume mesh as well as the surface mesh
> to vtk files.
> If you compare these files, for instance in paraview, you will see that
> the locally refined cells are not extracted.
>
> Best,
> Simon
>
> Am Di., 5. Dez. 2023 um 21:14 Uhr schrieb Luca Heltai <
> luca.hel...@gmail.com>:
>
>> Dear Simon,
>>
>> What do you mean by “demonstrates”? The function you refer to is supposed
>> to work with locally refined grids. What is the behavior you observe? What
>> error do you get?
>>
>> You will have to map dofs on the surface to dofs on the bulk manually.
>> The output of the function only returns a map of tria iterators to face
>> iterators, not dof to dof.
>>
>> Luca
>>
>> Il giorno 5 dic 2023, alle ore 2:23 PM, Simon 
>> ha scritto:
>>
>> Dear all,
>>
>>
>> attached is a minimal example which demonstrates that the function
>> "extract_surface_mesh()" in the GridGenerator namespace
>> does not extract refined cells.
>> That is, it seems to work only for globally refined meshes.
>> There is a comment in the implementation of this function:
>> // Create boundary mesh and mapping
>> // from only level(0) cells of the volume mesh.
>>
>> Since the documentation states nothing about the usage of this function
>> for adaptively
>> refined meshes (like it is done in flatten_triangulation, for instance),
>> I am not sure whether this is desired behavior or not.
>>
>> In my case, I probably do not need the full power of this function.
>> All I want to do is to "copy" the solution values on a surface of the
>> volume mesh
>> to a surface mesh, and to associate a DoFHandler object to the surface
>> mesh
>> that allows me to do further postprocessing.
>> So I do not care about the boundary and manifold id as well
>> as the return type, however, my volume mesh may contain hanging nodes.
>>
>>
>>
>> Best regards,
>> Simon
>>
>> --
>> 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/f3252992-4761-41b1-a691-05c5265f89bfn%40googlegroups.com
>> <https://groups.google.com/d/msgid/dealii/f3252992-4761-41b1-a691-05c5265f89bfn%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/AB275257-5021-4A2C-ACA1-C2A44D8FB070%40gmail.com
>> <https://groups.google.com/d/msgid/dealii/AB275257-5021-4A2C-ACA1-C2A44D8FB070%40gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
&

Re: [deal.II] extract_surface_mesh() does not extract refined cells

[Simon Wiesheier]

Dear Luca,

the program I provided writes the volume mesh as well as the surface mesh
to vtk files.
If you compare these files, for instance in paraview, you will see that the
locally refined cells are not extracted.

Best,
Simon

Am Di., 5. Dez. 2023 um 21:14 Uhr schrieb Luca Heltai :

> Dear Simon,
>
> What do you mean by “demonstrates”? The function you refer to is supposed
> to work with locally refined grids. What is the behavior you observe? What
> error do you get?
>
> You will have to map dofs on the surface to dofs on the bulk manually. The
> output of the function only returns a map of tria iterators to face
> iterators, not dof to dof.
>
> Luca
>
> Il giorno 5 dic 2023, alle ore 2:23 PM, Simon 
> ha scritto:
>
> Dear all,
>
>
> attached is a minimal example which demonstrates that the function
> "extract_surface_mesh()" in the GridGenerator namespace
> does not extract refined cells.
> That is, it seems to work only for globally refined meshes.
> There is a comment in the implementation of this function:
> // Create boundary mesh and mapping
> // from only level(0) cells of the volume mesh.
>
> Since the documentation states nothing about the usage of this function
> for adaptively
> refined meshes (like it is done in flatten_triangulation, for instance),
> I am not sure whether this is desired behavior or not.
>
> In my case, I probably do not need the full power of this function.
> All I want to do is to "copy" the solution values on a surface of the
> volume mesh
> to a surface mesh, and to associate a DoFHandler object to the surface mesh
> that allows me to do further postprocessing.
> So I do not care about the boundary and manifold id as well
> as the return type, however, my volume mesh may contain hanging nodes.
>
>
>
> Best regards,
> Simon
>
> --
> 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/f3252992-4761-41b1-a691-05c5265f89bfn%40googlegroups.com
> <https://groups.google.com/d/msgid/dealii/f3252992-4761-41b1-a691-05c5265f89bfn%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/AB275257-5021-4A2C-ACA1-C2A44D8FB070%40gmail.com
> <https://groups.google.com/d/msgid/dealii/AB275257-5021-4A2C-ACA1-C2A44D8FB070%40gmail.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/CAM50jEvtuTu_vUKmg-mTGQC7tdk4v6YE7TayaA6cjnrWjqa3Zg%40mail.gmail.com.

[deal.II] extract_surface_mesh() does not extract refined cells

[Simon]

Dear all,


attached is a minimal example which demonstrates that the function 
"extract_surface_mesh()" in the GridGenerator namespace 
does not extract refined cells. 
That is, it seems to work only for globally refined meshes. 
There is a comment in the implementation of this function:
// Create boundary mesh and mapping
// from only level(0) cells of the volume mesh.

Since the documentation states nothing about the usage of this function for 
adaptively
refined meshes (like it is done in flatten_triangulation, for instance), 
I am not sure whether this is desired behavior or not.

In my case, I probably do not need the full power of this function. 
All I want to do is to "copy" the solution values on a surface of the 
volume mesh 
to a surface mesh, and to associate a DoFHandler object to the surface mesh
that allows me to do further postprocessing.
So I do not care about the boundary and manifold id as well
as the return type, however, my volume mesh may contain hanging nodes.



Best regards,
Simon

-- 
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/f3252992-4761-41b1-a691-05c5265f89bfn%40googlegroups.com.

#include 
#include 
#include 
#include 

#include 

#include 

using namespace dealii;

int main()
{

  Triangulation<3> tria, triaTmp;
  
  dealii::Point<3> center;
  double radius = 2.5;
  unsigned int boundaryID = 2;

  GridGenerator::hyper_cube_with_cylindrical_hole(triaTmp,
radius,
7.5,
2.0,
1,
false);
  triaTmp.refine_global(2);

  // symmetry in global Z
  std::set::active_cell_iterator> cellsToRemove;
  for (const auto &cell : triaTmp.active_cell_iterators())
if ( cell->center()[2] > 1.0)
  cellsToRemove.insert(cell);
  dealii::GridGenerator::create_triangulation_with_removed_cells(triaTmp,
  cellsToRemove,
  tria);
  // one local refinement along hole
  for (const auto &cell : tria.active_cell_iterators())
for (unsigned int f = 0; f < dealii::GeometryInfo<3>::faces_per_cell; ++f)
  {
dealii::Point<3> faceCenter(cell->face(f)->center());
faceCenter[2] = 0.0;
if ((std::abs(center.distance(faceCenter)) < radius))
  cell->set_refine_flag();
  }
  tria.execute_coarsening_and_refinement();

  // set boundary ID for surface mesh
  for (const auto &cell : tria.active_cell_iterators())
for (unsigned int f = 0; f < dealii::GeometryInfo<3>::faces_per_cell; ++f)
  if(std::abs(cell->face(f)->center()[2]) < 1e-5 && cell->face(f)->at_boundary())
cell->face(f)->set_boundary_id(boundaryID);

  // extract surface mesh
  dealii::Triangulation<2, 3> tria2d;
  dealii::GridGenerator::extract_boundary_mesh(
tria,
tria2d,
std::set{boundaryID});

  // output the volume mesh
  std::ofstream file("tria.vtk");
  dealii::GridOut   gridOut;
  dealii::GridOutFlags::Vtk vtkFlags(true, true, true, false);
  gridOut.set_flags(vtkFlags);
  gridOut.write_vtk(tria, file);

  // and the surface mesh
  std::ofstream file2d("tria2d.vtk");
  gridOut.write_vtk(tria2d, file2d);

  return 0;
}

[deal.II] anisotropic refinement with regard to global coordinate direction

[Simon]

Dear all,

attached is a minimal example in which I create two simple triangulations 
(tria1, tria2),
merge them, and finally anisotropically refine all cells 
(RefinementCase<3>::cut_xz).
I also write the merged triangulation to a file for visualizations sake.

My objective is to refine only in the global xy plane, that is, in global 
z-direction, I want to have one element everywhere (if hanging nodes allow 
that, of course).
For the given example,
RefinementCase<3>::cut_xz 
is correct for tria1, but not for tria2. 
I read the documenation which states that anisotropic refinement occurs 
w.r.t the local coordinate system of the cell, so I am not really surprised 
about the above result.

Anyway, is there a way to perform anisotropic with regard to the global 
system?
My ideas was to, based on the local orientation of the cell system, pass a 
different RefinementCase when marking the cells for refinement.
The TriaAccessor class offers the combined_face_orientation() function, but 
I am
not sure if it helps here.

Thank you for your input!

Best,
Simon


-- 
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/68df0485-a2dc-4c75-abdf-27dd52e87bb5n%40googlegroups.com.

#include 
#include 
#include 
#include 

#include 

using namespace dealii;

int main()
{

  Triangulation<3> tria, tria1, tria2;
  
  GridGenerator::hyper_cube_with_cylindrical_hole(tria1,
2.5,
7.5,
15.0,
1,
false);
  GridGenerator::hyper_cube(tria2, 7.5, 22.5);
  GridTools::shift(dealii::Point<3>{0,-15.0,-7.5}, tria2);
  // merge them
  dealii::GridGenerator::merge_triangulations<3>(tria1, tria2, tria);
  // execute global refinements
  for (unsigned int i = 0; i<2; ++i)
{
  for(const auto &cell : tria.active_cell_iterators())
cell->set_refine_flag(RefinementCase<3>::cut_xz);
  tria.execute_coarsening_and_refinement();
} 

  // output the mesh
  std::ofstream file("tria.vtk");
  dealii::GridOut   gridOut;
  dealii::GridOutFlags::Vtk vtkFlags(true, true, true, false);
  gridOut.set_flags(vtkFlags);
  gridOut.write_vtk(tria, file);

  return 0;
}

Re: [deal.II] "is protected within this context" error for BlockSparseMatrix iterators

[Simon Wiesheier]

Thank you for the fix!

I have to stick to deal.ii 9.4.0 for a while which I installed via spack.
Is there anything I can add to my user code or do I have to recompile the
library with your changes?

Best
Simon

Wolfgang Bangerth  schrieb am Di., 31. Okt. 2023,
20:17:

>
> > dealii::BlockSparseMatrix systemMatrix;
> > auto systemMatrixIteratorEnd = systemMatrix.end(0);
> > auto systemMatrixIteratorBegin = systemMatrix.begin(0);
> > if (systemMatrixIteratorBegin != systemMatrixIteratorEnd)
> > std::cout<<"Example"< >
> > Using deal.ii 9.4.0, this results in the compilation error
> >
> > include/deal.II/lac/matrix_iterator.h:184:20: error: ‘bool
> > dealii::BlockMatrixIterators::Accessor > false>::operator==(const
> > dealii::BlockMatrixIterators::Accessor&) const
> > [with BlockMatrixType =
> > dealii::BlockMatrixBase >]’ is protected
> > within this context
> >184 |   return (accessor == other.accessor);
> >
> > include/deal.II/lac/block_matrix_base.h:1475:3: note: declared protected
> > here
> >   1475 |   Accessor::operator==(const Accessor
> > &a) const
> >
> >
> > Everything works if BlockSparseMatrix is replaced by SparseMatrix.
> >
> > Is there anything I miss here?
>
> No, it's just an (interesting) bug. I have the fix here:
>https://github.com/dealii/dealii/pull/16225
> Thanks for pointing it out and providing a good testcase!
>
> Best
>   W.
>
> --
> 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/28af670a-d40b-4a33-9585-bea821f6a254%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/CAM50jEu1vM%3Djgm__mQq7NivOhqOjzFS3cZsCHUtL%3DeS3wgdN5Q%40mail.gmail.com.

[deal.II] "is protected within this context" error for BlockSparseMatrix iterators

[Simon]

Dear all,

dealii::BlockSparseMatrix systemMatrix;
auto systemMatrixIteratorEnd = systemMatrix.end(0);
auto systemMatrixIteratorBegin = systemMatrix.begin(0);
if (systemMatrixIteratorBegin != systemMatrixIteratorEnd) std::cout<<
"Example"<::operator==(const 
dealii::BlockMatrixIterators::Accessor&) const 
[with BlockMatrixType = 
dealii::BlockMatrixBase >]’ is protected 
within this context
  184 |   return (accessor == other.accessor);

include/deal.II/lac/block_matrix_base.h:1475:3: note: declared protected 
here
 1475 |   Accessor::operator==(const Accessor &a) 
const


Everything works if BlockSparseMatrix is replaced by SparseMatrix.

Is there anything I miss here?

Best
Simon


-- 
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/b21d1915-c54a-4711-8b18-a8fa09d06a80n%40googlegroups.com.

[deal.II] inverse operation to AffineConstraints.condense() (recovering full system matrix)

[Simon]

Dear all, 

the "Constraints on Degrees of Freedom" module introduces several 
approaches to deal with constraints.
I implemented the "second" approach, that is, distributing the constraints 
on the fly when assembling the linear system using the 
constraints.distribute_local_to_global() function.
Since I plan to move from serial to distributed versions of my program in 
the future, 
it makes sense to stick to this approach as mentioned in the module.

After assembling and solving the linear system, I need the uncondensed 
system matrix and right hand side to perform a sensitivity analysis.
In particular, I need the rows and entries of the system matrix and RHS 
corresponding to constrained dofs. 
However, the constraints.distribute_local_to_global() function sets these 
entries all to zero (except the diagonal value of the system matrix).
My solution to deal with this is to basically copy my assembly function 
and, 
instead of distributing the constraints with the constraints object --
constraints.distribute_local_to_global() --
I distributed them with the cell iterator --
cell-> distribute_local_to_global(),
which does not care about the constraints.

This solution is of course very inefficient as for efficiency and code 
re-use.
As I said, it is basically a copy of my assembly function,
although most of the system matrix "is already there". 

So is there a more efficient way to recover the full system matrix based on 
the condensed system matrix?

Thanks for your help!

Best,
Simon


-- 
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/bcd7ffe7-34e0-4205-8296-c538a74b49efn%40googlegroups.com.

[deal.II] A question on licenses

[Simon Sticko]

Hi.

The function

GridIn::read_msh

uses the Gmsh-api internally to read a mesh from file.  However, Gmsh is
distributed under GPL and not LGPL.

Does this mean that one can not use this function if one wants to use
deal.II under LGPL?

Best,
Simon

-- 
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/CAMhmiLjUDyd0d2MoUc%2BLPk6-LhJ1R9oXuNM9n6VHfTV9CK9Bhw%40mail.gmail.com.

Re: [deal.II] How to compute derivatives of the composite function with the reference cell mapping

[Simon Sticko]

Hi.


If my element is not aligned with the axes, [...]
is this what meant by the "perfect Cartesian" situation?


Yes, exactly. If this is not what you have, I'm afraid the idea of generating 
the quadratures in real space is not an option.


Another option I was contemplating is to apply the
NonMatching::DiscreteQuadratureGenerator on a fake triangulation
with just one element.  Then I simply would need to interpolate
(evaluate) my real-space function at this one element and let the
class' implementation do the magic for me.  This is probably cheaper
and about equally accurate?


That sounds doable and cheaper. If you are going for this, FEFieldFunction 
might be useful:
https://www.dealii.org/developer/doxygen/deal.II/classFunctions_1_1FEFieldFunction.html

Regarding accuracy, you typically get the same order of accuracy. That is, say 
you that you use Lagrange elements of order p in the finite element space for 
you pde solution, and compare using the exact level set function with one that 
has been interpolated (also onto a space of elements of order p), then you 
typically see that

Exact level set function=> error ~ C_1 h^q
Interpolated level set function => error ~ C_2 h^q

(error in some global norm)

However, I know one expert who have claimed that the difference between the 
constants C_1 and C_2 can be surprisingly large for some problems. But I am 
unaware of any publication that has actually compared this.

Just out of curiosity (and if it is not a research secret), what is your use 
case? Why do you need to generate many quadratures for the same cell?

Best,
Simon

On 04/08/2023 12:39, Anton Evgrafov wrote:

Dear Simon,

Thank you very much for your reply.  The wrapper code looks
embarrassingly simple!


If you are working with a perfectly Cartesian background I would expect that it 
would actually be faster to generate the quadrature in real space and then 
transform the quadrature to reference space before passing it to FEValues. If you 
want to do this the functions cell->bounding_box() and 
BoundingBox::real_to_unit(..) are useful.


That I did not think about for some reason :)
If my element is not aligned with the axes, won't I risk getting
quadrature points outside of the element though? Or is this what you
meant by the "perfect Cartesian" situation?  Also I am not 100% clear
at the moment about how to change the quadrature weights after the
physical->unit transformation, as I would need access to Jacobian
determinants.

Another option I was contemplating is to apply the
NonMatching::DiscreteQuadratureGenerator on a fake triangulation
with just one element.  Then I simply would need to interpolate
(evaluate) my real-space function at this one element and let the
class' implementation do the magic for me.  This is probably cheaper
and about equally accurate?

/Anton

On Fri, Aug 4, 2023 at 12:07 PM Simon Sticko  wrote:


Hi.

I have done this in the past. I dug up the wrapper function I had for it, in 
case we decide that we should add it to the library:

https://github.com/dealii/dealii/pull/15838

The problem with this approach is that evaluating the reference space level set 
function gets very expensive. QuadratureGenerator uses many function calls and 
we have to use the Jacobian and its derivative in the transformation. This 
makes this approach significantly slower than using an interpolated level set 
function.

If you are working with a perfectly Cartesian background I would expect that it 
would actually be faster to generate the quadrature in real space and then 
transform the quadrature to reference space before passing it to FEValues. If you 
want to do this the functions cell->bounding_box() and 
BoundingBox::real_to_unit(..) are useful.

Best,
Simon

On 03/08/2023 23:11, Anton wrote:

Hello,

I would like to use the NonMatching::QuadratureGenerator class directly, 
as I need to generate multiple (as in many!, unfortunately) nonmatching quadratures 
for the same cell.  Therefore I would like to avoid the route of interpolating the 
level set function onto the whole mesh etc, as described in CutFEM tutorial.

Therefore I am thinking about calling the "generate" function, which only needs 
a level set function and a bounding box as inputs.  According to the documentation the 
level set function should provide the gradient and the Hessian.  I would like to do this 
in the reference cell coordinates, so that I can simply use this quadrature later via 
FEView as one normally does.
   * The bounding box I presume is the hypercube [0,1]^{dim} for the meshes I 
am interested in. (Can one request them for the reference cell and not the 
triangulation cell?)

   * The level set function should also be reasonably straightforward.  I know the 
function in the physical coordinates (say, f(x)) and all its derivatives.  I can also get 
the map from reference to physical coordinates via FEView, let us call this 

Re: [deal.II] How to compute derivatives of the composite function with the reference cell mapping

[Simon Sticko]

Hi.

I have done this in the past. I dug up the wrapper function I had for it, in 
case we decide that we should add it to the library:

https://github.com/dealii/dealii/pull/15838

The problem with this approach is that evaluating the reference space level set 
function gets very expensive. QuadratureGenerator uses many function calls and 
we have to use the Jacobian and its derivative in the transformation. This 
makes this approach significantly slower than using an interpolated level set 
function.

If you are working with a perfectly Cartesian background I would expect that it 
would actually be faster to generate the quadrature in real space and then 
transform the quadrature to reference space before passing it to FEValues. If you 
want to do this the functions cell->bounding_box() and 
BoundingBox::real_to_unit(..) are useful.

Best,
Simon

On 03/08/2023 23:11, Anton wrote:

Hello,

I would like to use the NonMatching::QuadratureGenerator class directly, 
as I need to generate multiple (as in many!, unfortunately) nonmatching quadratures 
for the same cell.  Therefore I would like to avoid the route of interpolating the 
level set function onto the whole mesh etc, as described in CutFEM tutorial.

Therefore I am thinking about calling the "generate" function, which only needs 
a level set function and a bounding box as inputs.  According to the documentation the 
level set function should provide the gradient and the Hessian.  I would like to do this 
in the reference cell coordinates, so that I can simply use this quadrature later via 
FEView as one normally does.
  * The bounding box I presume is the hypercube [0,1]^{dim} for the meshes I am 
interested in. (Can one request them for the reference cell and not the 
triangulation cell?)

  * The level set function should also be reasonably straightforward.  I know the 
function in the physical coordinates (say, f(x)) and all its derivatives.  I can also get 
the map from reference to physical coordinates via FEView, let us call this map x=M(y).  
The issue is how to extract the derivatives of this map so that the chain rule can be 
applied?  I am mostly working with Q1 maps, so of course I could figure out the 
derivatives "by hand".  I am just wondering if there is a more intelligent 
(code-wise) way of doing this?

--
The deal.II project is located at http://www.dealii.org/ 
<http://www.dealii.org/>
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en 
<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 
<mailto:dealii+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/4ac38563-e467-4f1d-8cb4-ee35379515a6n%40googlegroups.com
 
<https://groups.google.com/d/msgid/dealii/4ac38563-e467-4f1d-8cb4-ee35379515a6n%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/f1642630-6453-2028-1345-3db743d814f2%40gmail.com.

Re: [deal.II] try catch of "ExcDereferenceInvalidCell"

[Simon Wiesheier]

" So I am not sure how you would ever use an `Assert(...)` in optimized
release mode (where you want to run your program to get any
performance). "

I was indeed considering my program in debug mode.
Based on what you said, there is no way for me to catch
the failed .reinit call in optimized released mode
and using if-statements is the proper way for me
to handle my conditions.
Is that correct?

" Have you considered looking into our FEPointEvaluation [1] and related
"nonmatching" facilities?"

Yes, I already use FEPointEvaluation to evaluate the interpoland
at arbitrary points.
What other "nonmatching" facilities do you think may be helpful?
As said, I have to evaluate the interpoland (first and second derivatives)
at arbitrary points in real space --
as often as there are quadrature points on my geometry in each assembly.

Best,
Simon



Am Fr., 4. Aug. 2023 um 00:02 Uhr schrieb Matthias Maier :

> Have you considered looking into our FEPointEvaluation [1] and related
> "nonmatching" facilities?
>
> I have the feeling that we already provide the right data structures for
> your interpolation/evaluation needs - in particular with an efficient
> and fast implementation. An example usage can be found in step-19.
>
> Best,
> Matthias
>
> [1]
> https://www.dealii.org/current/doxygen/deal.II/classFEPointEvaluation.html
>
> --
> 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/87zg37bx9e.fsf%4043-1.org.
>

-- 
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/CAM50jEuBtewGX962LmiPtQyLPbz%2BScvDJ_7akdtFQFdmmVcoOQ%40mail.gmail.com.

Re: [deal.II] try catch of "ExcDereferenceInvalidCell"

[Simon Wiesheier]

Let me please clarify my last concerns in this regard:

The operations
GridTools::find_active_cell_around_point and
feValues.reinit
are executed at quadrature point level and performance
is really important in our application.

The reason why I wanted to use an
try/catch block is to surrogate the use of an if-statement.
Consider these two variants:

Variant 1:

disable_abort_on_exception();
try
{
   feValues.reinit(cell,...);
}
catch(dealii::Exception Base exception & )
{
   Assert(checkSecondRunTimeCondition, ...)
   // do something
}

Variant 2:

if(cell->state()==-1)
{
Assert(checkSecondRunTimeCondition, ...)
   // do something
}
else
{
 feValues.reinit(cell,...);
}

As you can see, there are two conditions I have to check at every
quadrature point.
Clearly, Variant 2 implements an if-requests and is probably not the way to
go.


1. So with regard to performance, would you prefer Variant 1
(as the try/catch introduces less overhead compared to the if-statement)?
2. If so, is the call of "disable_abort_on_exception()" good
coding practice or would you refrain from doing so?
In the main function of our program, we have a try/catch with
catch(dealii::ExceptionBase exception &).
Given that, in my opinion  "disable_abort_on_exception()"
should cause any undue behavior.

Best,
Simon


Am Do., 3. Aug. 2023 um 14:21 Uhr schrieb Wolfgang Bangerth <
bange...@colostate.edu>:

> On 8/2/23 15:58, Simon Wiesheier wrote:
> >
> > Does that make sense?
> > Or do you see a better solution, like checking
> > cell->status() right after GridTools::find_active_cell_around_point?
>
> This. If the function you call returns an error code in the form of an end
> iterator, just test for that rather than doing something with this
> iterator
> and wait to see what happens. It is always worth checking errors as early
> as
> possible.
>
> 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 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/53307567-6cd6-3f21-2c63-a5eedf5367f5%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/CAM50jEsCfErRV8-Su0gw4MyJS13W%3DwfbY5mCZY2_LXYMcm8efw%40mail.gmail.com.

Re: [deal.II] try catch of "ExcDereferenceInvalidCell"

[Simon Wiesheier]

" You can call
   deal_II_exceptions::disable_abort_on_exception();
which converts the call to abort() to raising an actual exception.  "
This worked indeed.

" But I do want to ask what you plan to do if you derefernce an
end-iterator. "

I see your point, let me briefly sketch what I want to do:
I have an interpoland to which I attach a triangulation.
When I want to evaluate the interpoland at a real point,
I first call GridTools::find_active_cell_around_point
to find the cell where the point lives along with the
unit cell coordinates.
Then, I call the .reinit function to actually evaluate
values, gradients, ... of the interpoland.
However, it may be the case that the evaluation point is
outside the domain of the triangulation, in which case
.reinit aborts the program, for the reasons you mentioned.
In those cases, I also want to abort the program but with a more
meaningfull message.
In particular, I want to inform the user about the domain of
the interpoland, the point where evaluation failed, and
workarounds how to circumvent such out-of-bound evaluations,...
I want to do this by throwing on instance of a class that derives from
dealii::ExceptionBase
in the catch block.

Does that make sense?
Or do you see a better solution, like checking
cell->status() right after GridTools::find_active_cell_around_point?

Best,
Simon



Am Mi., 2. Aug. 2023 um 18:51 Uhr schrieb Wolfgang Bangerth <
bange...@colostate.edu>:

> On 7/30/23 11:20, Simon Wiesheier wrote:
> >
> > Of course, it does not make sense to dereference such an iterator.
> > That's the reason why I wanted to catch this operation, and do something
> else
> > instead. In my case, aborting the program is absolutely not necessary as
> I
> > would have a workaround.
> >
> > But, if I understand you, there is no way for me to catch the exception
> from
> > my question, right?
>
> You can call
>deal_II_exceptions::disable_abort_on_exception();
> which converts the call to abort() to raising an actual exception.
>
> But I do want to ask what you plan to do if you derefernce an
> end-iterator.
> That should simply never happen -- it's a bug in the program to do this,
> comparable to a segmentation fault when dereferencing a NULL pointer. The
> right approach is to ensure that that doesn't happen, not to come up with
> a
> backup plan to do something else if it does happen.
>
> 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 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/a025ea76-c601-e504-a586-a9e54b3e20bd%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/CAM50jEtwn6wJEUGridcnAQzRZpGo6dg2JzzN-UW-MmuRbqgvjQ%40mail.gmail.com.

Re: [deal.II] try catch of "ExcDereferenceInvalidCell"

[Simon Wiesheier]

"
The
former is for logic errors inherent in the program that cannot be recovered
from -- say, trying to dereference triangulation.end()"

Of course, it does not make sense to dereference such an iterator.
That's the reason why I wanted to catch this operation, and do something
else instead. In my case, aborting the program is absolutely not necessary
as I would have a workaround.

But, if I understand you, there is no way for me to catch the exception
from my question, right?

Best
Simon

Wolfgang Bangerth  schrieb am So., 30. Juli 2023,
18:33:

>
> Simon,
>
> > I want to catch exceptions thrown by fePointEval.reinit(...),
> > where fePointEval is an object of type FEPointEvaluation.
> >
> > Here is a snippet of code demonstrating the issue:
> >
> > try
> > {
> >   fePointEval.reinit(...);
> > }
> > catch(dealii::ExceptionBase & exception)
> > {
> > std::cout<<"exception is catched"< > throw MyClass(...);
> > }
> >
> > where MyClass is derived from dealii::ExceptionBase.
> >
> > The exception ExcDereferenceInvalidCell is definitely thrown because the
> message
> > " You tried to dereference a cell iterator "
> > is printed on my screen, if I try to evaluate the function attached to
> the
> > FEPointEvaluation
> > object outside its domain.
>
> The documentation of deal.II rarely is clear about what "throwing an
> exception" means. That depends on whether you use Assert or AssertThrow.
> The
> former is for logic errors inherent in the program that cannot be
> recovered
> from -- say, trying to dereference triangulation.end(). You need to fix
> the
> program to deal with this, and so we use Assert which simply aborts the
> program (even though perhaps the documentation may say that it "throws the
> exception") after showing the error message.
>
> We use AssertThrow (which really does 'throw' an exception) for situations
> that are run-time errors. Say the file you opened cannot be read, or
> you're
> out of memory -- in general, for situations where the *program* is
> correct,
> but perhaps its *input* is not.
>
> 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 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/e3b7f84f-d4ee-5854-83a4-add287e86415%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/CAM50jEs%3DQUou46YHjpnEdcSU9Xp8zzJyJ7FtXS_O0N4Lbo9Gnw%40mail.gmail.com.

Re: [deal.II] Query regarding solution of linear system in deal.ii using linear solver

[Simon Sticko]

Hi.

From your attached files it looks like you have saved the matrix and rhs with 
quite few digits. Do you get the same result if you increase the number of 
digits you write to your std::ofstream object?

Compare:
https://en.cppreference.com/w/cpp/io/manip/setprecision

Best,
Simon

On 29/07/2023 16:36, Krish wrote:

Hello,

I am solving a problem that has 30 degrees of freedom. The newton update 
solution obtained from deal.ii (using both Direct and CG solver) seems to be 
less accurate (differs after 4 significant digits)  from the newton update 
solution obtained from Matlab using the same tangent_matrix and system_rhs. I 
am getting the two following solutions from the same tangent_matrix and 
system_rhs (data files containing the tangent_matrix and system_rhs attached).

     Matlab solution deal.ii solution

                  0                   0
   -0.003033422503555  -0.00303356000
                                      0                   0
   -0.002439900952733  -0.00243999000
                       0                   0
   -0.002737307578376  -0.00273743000
    0.001007226333711   0.00100724000
   -0.001069740617723  -0.00106978000
    0.001663965890031   0.00166397000
   -0.002605547185476  -0.00260561000
    0.001113032138953   0.00111304000
   -0.001469379092482  -0.00146943000
    0.000916401048149   0.00091638000
                       0                   0
    0.001674445763014   0.00167444000
                                       0                   0
    0.001041269520982   0.00104126000
   -0.000  -0.000
                   0                   0
    0.003033422503555   0.00303356000
                      0                   0
    0.002439900952733   0.00243999000
                                      0                   0
    0.002737307578376   0.00273743000
    0.001007226333711   0.00100724000
    0.001069740617723   0.00106978000
    0.001663965890031   0.00166397000
    0.002605547185476   0.00260561000
    0.001113032138953   0.00111304000
    0.001469379092482   0.00146943000

I am trying to figure out what could be the reason behind it and how to get a 
more accurate solution.

Thank you in advance.

Krish

--
The deal.II project is located at http://www.dealii.org/ 
<http://www.dealii.org/>
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en 
<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 
<mailto:dealii+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/ac75c294-7b25-4351-82e5-dd7ad3fd410bn%40googlegroups.com
 
<https://groups.google.com/d/msgid/dealii/ac75c294-7b25-4351-82e5-dd7ad3fd410bn%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/7fb5ded9-2382-bd5b-a9a2-39df063df956%40gmail.com.

[deal.II] try catch of "ExcDereferenceInvalidCell"

[Simon]

Dear all,

I want to catch exceptions thrown by fePointEval.reinit(...), 
where fePointEval is an object of type FEPointEvaluation.

Here is a snippet of code demonstrating the issue:

try
{
 fePointEval.reinit(...);
}
catch(dealii::ExceptionBase & exception)
{
   std::cout<<"exception is catched"

Re: [deal.II] point_value for a vector-valued Problem / FESystem

[Simon Sticko]

Hi.

There are several point_value functions. Right now, you are calling one that 
only works for scalar elements:

https://www.dealii.org/current/doxygen/deal.II/namespaceVectorTools.html#a7be5c7eed52308898dfaad91c4cff204

You need to call the more general function:

https://www.dealii.org/current/doxygen/deal.II/namespaceVectorTools.html#acd358e9b110ccbf4a7f76796d206b9c7

by passing a vector with each components value as the last argument to the 
function:

Vector value(n_solution_components);
VectorTools::point_value(dof_handler,
 solution,
 point,
 value);

Best,
Simon

On 20/07/2023 12:54, 'Jost Arndt' via deal.II User Group wrote:

Dear everyone,

I have trouble understanding in how to evaluate a solution at a given point 
correctly.
Described in Step-3 for example the function point_value is used to evaluate 
the solution at (0.3, 0.3), and I want to do something quite similar.
However, my solution is vector valued (i.e. I use FESystem ), and I get the 
following error message

 >>An error occurred in line <181> of file 
<./include/deal.II/numerics/vector_tools_point_value.templates.h> in function
     typename VectorType::value_type dealii::VectorTools::point_value(const dealii::Mapping&, const dealii::DoFHandler&, const VectorType&, const 
dealii::Point&) [with int dim =
2; VectorType = dealii::Vector; int spacedim = 2; typename 
VectorType::value_type = double]
The violated condition was:
     dof.get_fe(0).n_components() == 1
Additional information:
     Finite element is not scalar as is necessary for this function


However in the documentation it says "Evaluate a possibly vector-valued finite element 
function defined by the given DoFHandler 
<https://dealii.org/developer/doxygen/deal.II/classDoFHandler.html> and nodal vector 
fe_function at the given point point". So I am curious how to evaluate my solution at a 
few fixed points? Did I miss something?

Performance-wise it does not have to be perfect at all, as I want to evaluate 
only ~400 points on a few hundered solutions (time-steps).

Best,

Jost

--
The deal.II project is located at http://www.dealii.org/ 
<http://www.dealii.org/>
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en 
<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 
<mailto:dealii+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/7e2a3e13-aef1-4a0e-a357-8dafc3bdf958n%40googlegroups.com
 
<https://groups.google.com/d/msgid/dealii/7e2a3e13-aef1-4a0e-a357-8dafc3bdf958n%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/229072fe-6f09-1470-35b6-ee34ddc308fd%40gmail.com.

Re: [deal.II] Re: Linking error when compiling examples: error: cannot find -lhdf5-shared

[Simon Wiesheier]

In case you do not need hdf5, you can install dealii without hdf5 enabled as

spack install dealii~hdf5

which worked in my case.

Best
Simon

Am Mo., 17. Apr. 2023 um 12:03 Uhr schrieb Amit Sharma <
amitsharmass1...@gmail.com>:

> There is some issue with dealii-9.4.0 with spack. I uninstall everything
> and install dealii-9.3.1 which works fine. Details are below if anyone
> needs it.
>
> spackv0.17
> cmake-3.16.3
> spack install dealii@9.3.1 target=x86_64
>
> Best Regards,
> Amit Sharma
>
> On Friday, April 7, 2023 at 5:51:45 PM UTC+5:30 Simon wrote:
>
>> Is there already a solution to this issue?
>>
>> I have the same problem as Amit Sharm;
>> hdf5 is loaded.
>>
>> Best
>> Simon
>>
>> amitshar...@gmail.com schrieb am Freitag, 31. März 2023 um 15:05:26
>> UTC+2:
>>
>>> Dear Bruno,
>>>
>>> Yes, I loaded hdf5(version-1.10.7) and I tried same with latest version
>>> available on spack.
>>>
>>> Thanks,
>>> Amit
>>>
>>> On Friday, March 31, 2023 at 6:27:13 PM UTC+5:30 bruno.t...@gmail.com
>>> wrote:
>>>
>>>> Amit,
>>>>
>>>> Did you load the hdf5 package? You can check using `spack find
>>>> --loaded`.
>>>>
>>>> Best,
>>>>
>>>> Bruno
>>>>
>>>> On Friday, March 31, 2023 at 4:51:02 AM UTC-4 amitshar...@gmail.com
>>>> wrote:
>>>>
>>>>> Hello everyone,
>>>>>
>>>>> I installed dealii using spack manager. I started learning dealii
>>>>> using examples but I am getting a linking error.
>>>>>
>>>>> Scanning dependencies of target step-1
>>>>> [ 33%] Building CXX object CMakeFiles/step-1.dir/step-1.cc.o
>>>>> [ 66%] Linking CXX executable step-1
>>>>> /home/amit/spack/opt/spack/linux-ubuntu20.04-skylake/gcc-9.4.0/binutils-2.38-e2nnae3w7g55p34q7m3tsngmmrol2iba/bin/ld.gold:
>>>>> error: cannot find -lhdf5-shared
>>>>> collect2: error: ld returned 1 exit status
>>>>> make[3]: *** [CMakeFiles/step-1.dir/build.make:223: step-1] Error 1
>>>>> make[2]: *** [CMakeFiles/Makefile2:272: CMakeFiles/step-1.dir/all]
>>>>> Error 2
>>>>> make[1]: *** [CMakeFiles/Makefile2:252: CMakeFiles/run.dir/rule] Error
>>>>> 2
>>>>> make: *** [Makefile:196: run] Error 2
>>>>>
>>>>> Thanks,
>>>>> Amit Sharma
>>>>>
>>>>> --
> 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/70804bf4-cefb-44a3-a4a9-915469a867c4n%40googlegroups.com
> <https://groups.google.com/d/msgid/dealii/70804bf4-cefb-44a3-a4a9-915469a867c4n%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/CAM50jEu58Tn%2Bm_DL_oFUyRQvH_eO-qSX0A6D4%3DhnPkpKFHyASg%40mail.gmail.com.

[deal.II] Re: Linking error when compiling examples: error: cannot find -lhdf5-shared

[Simon]

Is there already a solution to this issue?

I have the same problem as Amit Sharm;
hdf5 is loaded.

Best
Simon

amitshar...@gmail.com schrieb am Freitag, 31. März 2023 um 15:05:26 UTC+2:

> Dear Bruno,
>
> Yes, I loaded hdf5(version-1.10.7) and I tried same with latest version 
> available on spack.
>
> Thanks,
> Amit
>
> On Friday, March 31, 2023 at 6:27:13 PM UTC+5:30 bruno.t...@gmail.com 
> wrote:
>
>> Amit,
>>
>> Did you load the hdf5 package? You can check using `spack find --loaded`.
>>
>> Best,
>>
>> Bruno
>>
>> On Friday, March 31, 2023 at 4:51:02 AM UTC-4 amitshar...@gmail.com 
>> wrote:
>>
>>> Hello everyone,
>>>
>>> I installed dealii using spack manager. I started learning dealii using 
>>> examples but I am getting a linking error.
>>>
>>> Scanning dependencies of target step-1
>>> [ 33%] Building CXX object CMakeFiles/step-1.dir/step-1.cc.o
>>> [ 66%] Linking CXX executable step-1
>>> /home/amit/spack/opt/spack/linux-ubuntu20.04-skylake/gcc-9.4.0/binutils-2.38-e2nnae3w7g55p34q7m3tsngmmrol2iba/bin/ld.gold:
>>>  
>>> error: cannot find -lhdf5-shared
>>> collect2: error: ld returned 1 exit status
>>> make[3]: *** [CMakeFiles/step-1.dir/build.make:223: step-1] Error 1
>>> make[2]: *** [CMakeFiles/Makefile2:272: CMakeFiles/step-1.dir/all] Error 
>>> 2
>>> make[1]: *** [CMakeFiles/Makefile2:252: CMakeFiles/run.dir/rule] Error 2
>>> make: *** [Makefile:196: run] Error 2
>>>
>>> Thanks,
>>> Amit Sharma
>>>
>>>

-- 
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/74ca1a35-bc78-441c-8f44-408b61646fdcn%40googlegroups.com.

Re: [deal.II] writing data to a file changes program output although this file is never used

[Simon Wiesheier]

Hello to all,

unfortunately, I have no admin rights and can not re-compile the library
with -DDEAL_II_WITH_TBB=OFF.

But I did
export DEAL_II_NUM_THREADS=1
to make sure that nothing like a race condition is involved.
However, my program is not parallelized explicitedly by myself.
If there is multi-threading, then just because I call
dealii functions which are multi-threaded per default.

Anyway, with DEAL_II_NUM_THREADS=1, valgrind does not produce any error
messages anymore (see valgrind.txt), but
my issue is still there. To give you a better insight, I attached the
output of my program once
with the print statement in my assembly routine
(output_print_NOT_outcommented.txt) and
without the print statement ( output_print_outcommented.txt).
As you can see, the RHS of my linear system after convergence is different
at some load steps.
And as I said, these differences sum up in repeating calls to my program
and, clearly, should not be there -- regardless how small they are.

What I did is to run my program with the address and undefined behavior
sanitizer of clang by passing some flags to cmake:
cmake -DCAMKE_CXX_FLAGS="-fsanitize=undefined" -DCMAKE_EXE_LINKER_FLAGS
="-fsanitize=undefined" -DCAMKE_CXX_FLAGS="-fsanitize=address"
-DCMAKE_EXE_LINKER_FLAGS ="-fsanitize=address"
-DCAMKE_CXX_FLAGS="-fno-optimize-sibling-calls" .
At the very end of my program (probably when the destructor is called or
even later), the sanitizers reported some errors (see
address_sanitizer.txt),
but this may be some false positives. In particular, no error is reported
during the relevant part of my program.
These errors occur with and without the print statement, and also in debug
mode.

If there is a bug in my program, this bug seems to be a tough one (at least
for me).

If someone of you (Wolfgang, Bruno, Daniel,...) were willed to have a look
at my code,
I would reduce the issue to a minimal working example and upload all source
files here or sent it do you directly.
I would highly appreciate that since I do not want to extend my code
further with that bug in it.

Best
Simon

<https://mail.google.com/mail/u/0?ui=2&ik=4a4452916d&attid=0.2&permmsgid=msg-a:r8629661344512179658&view=att&disp=safe&realattid=f_lfwmt5ix1>

Am Fr., 31. März 2023 um 15:06 Uhr schrieb Bruno Turcksin <
bruno.turck...@gmail.com>:

> Simon,
>
> Le ven. 31 mars 2023 à 08:58, Simon Wiesheier 
> a écrit :
>
>>
>>
>> Given that it works fine in debug mode, there are likely no out-of-bound
>> violations. I just use std::vector and Vector as data structures
>> which would be detected in debug mode.
>>
>> That's optimistic :) It's not because you are in debug mode that
> std::vector checks the bounds. The bounds are only checked when using at()
>
>
>> How can I run my program without TBB enabled?
>>
>
> Reconfigure and recompile deal.II with -D DEAL_II_WITH_TBB=OFF
>
> 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 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/CAGVt9eP2PDbJ%2BBFLGJ8qV4Gm54FY_DGcnMw7gyRcXuWHoYUVnQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/dealii/CAGVt9eP2PDbJ%2BBFLGJ8qV4Gm54FY_DGcnMw7gyRcXuWHoYUVnQ%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/CAM50jEug4DCxMKPHz%2Bk4ZFXzXHJj4V4XcBGkx-HdarERqeq3PQ%40mail.gmail.com.
==3313580== Memcheck, a memory error detector
==3313580== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==3313580== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==3313580== Command: ./NeoHooke
==3313580== Parent PID: 3063539
==3313580== 
==3313580== 
==3313580== HEAP SUMMARY:
==3313580== in use at exit: 206,618 bytes in 1,302 blocks
==3313580==   total heap usage: 277,987 allocs, 276,685 frees, 17,751,468 bytes 
allocated
==3313580== 
==3313580== LEAK SUMMARY:
==3313580==definitely lost: 0 bytes in 0 blocks
==3313580==indirectly lost: 0 bytes in 0 bl

Re: [deal.II] writing data to a file changes program output although this file is never used

[Simon Wiesheier]

Hi Bruno,

I do not see my bug in debug mode. So there the print statement has no
effect.

Given that it works fine in debug mode, there are likely no out-of-bound
violations. I just use std::vector and Vector as data structures
which would be detected in debug mode.

How can I run my program without TBB enabled?

Best
Simon

Bruno Turcksin  schrieb am Do., 30. März 2023,
20:18:

> Hello,
>
> Usually when I have this kind of bug, there are two possibilities:
>  1. I am using an un-initialized value
>  2. I am writing out of bound
>
> What I do is using valgrind with my code in Debug mode and without TBB
> enabled otherwise you get difficult to understand backtrace like here.
> However, what I've also encountered is that in Debug mode, the compiler
> would initialize the variable but it wouldn't do it in Release... So make
> sure that all the variables are initialized and when using a std::vector,
> use at() instead of operator[]. Only use at() in Debug mode because it is
> much slower than operator[]. Other than that rerun valgrind without TBB
> enabled, you should get something more meaningful.
>
> Best,
>
> Bruno
>
>
> On Wednesday, March 29, 2023 at 12:41:24 PM UTC-4 Simon wrote:
>
>> Too early pleased -- the issue still persists.
>>
>> As described above, adding the reference symbol & to JxW and global_index
>> makes a difference in my program, but is not the solution.
>>
>> I ran my program in debug mode using
>> valgrind --tool=memcheck --leak-check=full ./my_program
>>
>> The valgrind output associated with
>> void fun(const Tensor<2,3 & F,
>>const double JxW,
>>const unsigned int global_index,
>>std::vector> & sensitivity_matrix)
>> {
>> // use F and JxW to write some values into sensitivity_matrix, which
>> is passed by reference since it is a large matrix
>> if(print_or_not==true)  std::cout<<"print anything here..."<> }
>> is
>> [image: memcheck_NotOutC.png]
>>
>> The valgrind output associated with
>> void fun(const Tensor<2,3 & F,
>>const double JxW,
>>const unsigned int global_index,
>>std::vector> & sensitivity_matrix)
>> {
>> // use F and JxW to write some values into sensitivity_matrix, which
>> is passed by reference since it is a large matrix
>> // if(print_or_not==true)  std::cout<<"print anything
>> here..."<> }
>> [image: memcheck_outC.png]
>>
>> The differences are "only" possibly lost messages, but the backtraces are
>> not really clear to me.
>> Do you see any problems with my code by inspecting the memory check?
>>
>> Based on your experience, I would appreciate your feedback regarding how
>> to debug my problem further.
>> Adding print statements clearly is not really helpful if my program shows
>> undefined behavior and
>> if the print statement itself is what causes differences.
>>
>> Thank you!
>>
>> On Wednesday, March 29, 2023 at 3:02:52 PM UTC+2 Simon wrote:
>>
>> Of course, Approach B is the right way to go if I want to produce
>> reliable results.
>>
>> After plenty of hours of debugging, I found a possible source for the
>> differences:
>> The member function called by my assembly routine has the following
>> signature
>> void fun(const Tensor<2,3 & F,
>>const double JxW,
>>const unsigned int global_index,
>>std::vector> & sensitivity_matrix)
>> {
>> //use F and JxW to write some values into sensitivity_matrix at
>> global_index
>> }
>>
>> To debug my problem, I wrapped the << statement into an if-condition that
>> I controlled via my parameter file:
>> {
>> // use F and JxW to write some values into sensitivity_matrix, which
>> is passed by reference since it is a large matrix
>> if(print_or_not==true)  std::cout<<"print anything here..."<> }
>> Interestingly, setting print_or_not==false or just out-commenting the
>> line changes some results of my program.
>> In other words, the output obtained by
>> {
>> // use F and JxW to write some values into sensitivity_matrix, which
>> is passed by reference since it is a large matrix
>> if(false)  std::cout<<"print anything here..."<> }
>> is different from the output obtained by
>> {
>> // use F and JxW to write some values into sensitivity_matrix, which
>>

Re: [deal.II] writing data to a file changes program output although this file is never used

[Simon Wiesheier]

Of course, Approach B is the right way to go if I want to produce reliable
results.

After plenty of hours of debugging, I found a possible source for the
differences:
The member function called by my assembly routine has the following
signature
void fun(const Tensor<2,3 & F,
   const double JxW,
   const unsigned int global_index,
   std::vector> & sensitivity_matrix)
{
//use F and JxW to write some values into sensitivity_matrix at
global_index
}

To debug my problem, I wrapped the << statement into an if-condition that I
controlled via my parameter file:
{
// use F and JxW to write some values into sensitivity_matrix, which is
passed by reference since it is a large matrix
if(print_or_not==true)  std::cout<<"print anything here..."<> & sensitivity_matrix)
Adding the reference symbol & to JxW and global_index,
the program output is identical, regardless of the number of print
statements -- as it should be the case.
Within the assembly function (which calls fun()), JxW and global_index are
defined as always in a deal.ii program:
const double JxW=fe_values.JxW(k);
std::vector local_dof_indices(...); ->
cell->get_dof_indices(local_dof_indices);
gobal_index = local_dof_indices[i];

Could the missing reference symbol & be an explanation for why I observed
the undefined behavior of my program?
It clearly changes something, but I do not really understand why that might
be the case.

Best
Simon







Am Fr., 24. März 2023 um 22:38 Uhr schrieb Wolfgang Bangerth <
bange...@colostate.edu>:

> On 3/24/23 11:04, Simon wrote:
> >
> > Having all that said, is there any reasonable argument as to what could
> > cause the program output to be different by just adding ...<<...
> statement?
>
> There is no reasonable argument why that should be the case. The
> function you are calling looks like this:
>
> template 
> inline std::ostream &
> operator<<(std::ostream &out, const Tensor &p)
> {
>for (unsigned int i = 0; i < dim; ++i)
>  {
>out << p[i];
>if (i != dim - 1)
>  out << ' ';
>  }
>
>return out;
> }
>
> It *should* have no side effects. If it does, there is something funny
> going on in your program.
>
> That leaves a philosophical question:
>
>  > Admittedly, I do not know how to debug this further, because there is in
>  > theory
>  > nothing to debug if I can trace the differences back to the ...<<...
>  > statement.
>
> Approach A is to say "Well, let me just remove the output statement
> then; I know that my program works in that case". Approach B is to say
> "This situation illustrates that I don't understand something
> fundamental about my program. Let me use the occasion to investigate".
> Everyone who has been following this mailing list for a while will
> suspect that I lean quite heavily towards Approach B. If the state of
> the program changes in ways I do not understand, and that make no sense
> to me, it is not unreasonable to suspect that there is a conceptual bug
> somewhere, however unpleasant it may be to search for it, and that not
> investigating the cause for the issue is really just closing one's eyes
> towards a problem that is clearly there.
>
> In your case, I would start by outputting vastly more intermediate
> results (up to machine precision) to see where the first time is that
> something is different between the program with and the one without the
> << statement. Maybe you can identify which variable it is that first
> changes, and if you know that, it may be easier to also see *why* it
> changes. You could wrap the operator<< statement in some kind of
> if-condition that you can control from outside the program, and then run
> your program twice every time, once with and without the output
> statement. Pipe the output of each run into two files that you can then
> run 'diff' on.
>
>  From experience, this is not likely going to be a bug that is fun to
> chase down. But it might make for a good learning opportunity. It would
> be quite interesting to hear back here if you find out what caused the
> issue!
>
> 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 the Google Groups

[deal.II] writing data to a file changes program output although this file is never used

[Simon]

Dear all,

my deal.ii program is called roughly 300 times from a matlab script for the 
purpose of a parameter identification. In essence, given some parameters, 
the matlab script calls deal.ii to compute a displacement field. I exchange 
the data transfer between deal.ii and matlab by reading from and writing 
into files. In particular, I store the parameters in a file with 13 digits 
after the decimal point since there are finite-difference calculations 
involved.
I double-checked that my simulations are deterministic, i.e. the parameters 
at all 300 calls to deal.ii are identical if I re-run the matlab script 
anew. By identical, I mean that all 13 digits coincide.

My deal.ii program has, besides the standard data structures 
(Triangulation, DoFHandler,...), a pointer to a class as member variable. 
This class has a member function, which is called during assembly of the 
linear system to calculate a stress tensor. Within this member function, I 
created a
std::ofstream out_data("/a/path/file.txt")
object and wrote the calculated stress into this file:
out_data

[deal.II] reference for citing the concept of vector-valued test functions?

[Simon]

Dear all,

is the deal.ii implementation of vector-valued test functions as described 
here 
  
also described in an article, paper, ... or is this a "deal.ii thing"?

I would like to make a reference in a publication where the concept of 
vector-valued test functions is explained in more detail, but do not want 
to cite a webpage.

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/5d15ce9c-1324-41bc-b832-2c578a31f093n%40googlegroups.com.

[deal.II] B-spline basis functions to interpolate nodal values (control points) in 1d

[Simon]

Dear all,

my objective is to do an 1d-approximation 
F(x) = N_i(x) P_i 
where N_i are cubic B-spline basis functions and P_i known nodal values 
(control points). 
To assemble my linear system, I have to compute the first and second 
derivatives of F at the quadrature points of the triangulation. 
Since the number of control points P_i is quite moderate (less than 20), I 
think it is reasonable to evaluate all basis functions N_i in lieu of 
implementing an entire finite element class.

I scanned the dealii manual but could only find a CSpline class 
<https://www.dealii.org/current/doxygen/deal.II/classFunctions_1_1CSpline.html>
.
Just to make sure: 
B-Spline (basis) functions are not implemented in dealii yet, right?

So I probably will have to rely on an external library. 
Can someone make a library recommendation?
I read about tinyspline <https://github.com/msteinbeck/tinyspline> and 
splinelib <https://github.com/mfcats/SplineLib>, but have no knowledge 
regarding their performance, or if they are appropriate for usage in a 
dealii-program.

As I said, I mainly want to 
(i) interpolate control points with B-spline basis functions and
(ii) evaluate first and second derivatives at arbitrary points in the knot 
interval.

Best
Simon 

-- 
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/a26b043d-da5b-4ce6-80d5-c4d46734beefn%40googlegroups.com.

[deal.II] possible to shift a support point (no vertex) of a triangulation?

[Simon]

Dear all,

I am approximating a scalar function F of one single argument by 
discretizing the argument over the interval [lb;ub]. 
Then, I interpolate the nodal values utilizing VectorTools::interpolate.
To generate the triangulation (a line), I call 
GridGenerator::hyber_cube(triangulation, lb, ub) and refine globally up to 
a desired level.
Either FE_Q(1) or FE_Q(2) elements are used. 

The issue is that there is one 'point' p in [lb;ub] for which the function 
must be Zero. 
In case of FE_Q(1) elements, I simply shifted the vertex which is closest 
to p, to p.
For FE_Q(2) elements, the closest point to p is a vertex *or* the support 
point in the center of the element. 
I think it is not possible to 'shift' a support point as the triangulation 
is made up of vertices only, right?

Best
Simon

-- 
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/e4c1dc91-7e1c-4317-93ca-ef8985f1313dn%40googlegroups.com.

Re: [deal.II] collect2 linking error when executing make

[Simon Wiesheier]

deal.II was installed using spack.

Do I have to recompile the whole library with
$ cmake -DDEAL_II_WITH_HDF5=OFF?



Am Do., 5. Jan. 2023 um 17:15 Uhr schrieb Timo Heister :

> How did you install deal.II on your new machine? Note that the HDF5
> configuration is part of deal.II and not your user project.
>
> On Wed, Jan 4, 2023 at 4:48 AM Simon Wiesheier
>  wrote:
> >
> > I called cmake as follows $ cmake -DDEAL_II_WITH_HDF5=OFF . and get the
> additional lines //No help, variable specified on the command line.
> DEAL_II_WITH_HDF5: UNINITIALIZED=OFF in my CMakeCache. txt file. However,
> after $ make ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍
> > ZjQcmQRYFpfptBannerStart
> > This Message Is From an External Sender
> > Use caution when opening links or attachments if you do not recognize
> the sender.
> >
> > ZjQcmQRYFpfptBannerEnd
> > I called cmake as follows
> > $ cmake -DDEAL_II_WITH_HDF5=OFF .
> >
> > and get the additional lines
> >
> > //No help, variable specified on the command line.
> > DEAL_II_WITH_HDF5:UNINITIALIZED=OFF
> >
> > in my CMakeCache.txt file.
> >
> > However, after
> > $ make
> >
> > the error message is unchanged.
> > Best
> > Simon
> >
> >
> > Am Di., 3. Jan. 2023 um 20:55 Uhr schrieb Simon Wiesheier <
> simon.wieshe...@gmail.com>:
> >>
> >> I started from an empty source directory with only a CMakeLists.txt
> file.
> >>
> >> I do not need hdf5.
> >> At least I was not aware that I had it on my old computer.
> >>
> >> Is there a way to work around the issue?
> >>
> >> Best
> >> Simon
> >>
> >>
> >> Timo Heister  schrieb am Di., 3. Jan. 2023, 20:19:
> >>>
> >>> Simon,
> >>>
> >>> Make sure that you do not transfer any temporary files
> >>> (CMakeCache.txt, CMakeFiles/ etc.) but that you start from a fresh
> >>> source directory. The error message hints at the fact that your new
> >>> system does not have hdf5 installed.
> >>>
> >>> On Mon, Jan 2, 2023 at 4:21 AM Simon 
> wrote:
> >>> >
> >>> > Dear all, First of all, I wish you a happy and prosperous new year
> 2023! I transferred my dealii project to a different computer and encounter
> an linking error (command make) after setting up the project (command cmake
> .). ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍
> >>> > ZjQcmQRYFpfptBannerStart
> >>> > This Message Is From an External Sender
> >>> > Use caution when opening links or attachments if you do not
> recognize the sender.
> >>> >
> >>> > ZjQcmQRYFpfptBannerEnd
> >>> > Dear all,
> >>> >
> >>> > First of all, I wish you a happy and prosperous new year 2023!
> >>> >
> >>> > I transferred my dealii project to a different computer and
> >>> > encounter an linking error (command make) after setting up
> >>> > the project (command cmake .).
> >>> > The error message is attached.
> >>> >
> >>> > What is the problem?
> >>> >
> >>> > Best
> >>> > Simon
> >>> >
> >>> > --
> >>> > 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/ca0ce1f2-cba0-42e1-8ee4-2178806540ebn%40googlegroups.com
> .
> >>>
> >>>
> >>>
> >>> --
> >>> Timo Heister
> >>> http://www.math.clemson.edu/~heister/
> >>>
> >>> --
> >>> 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 th

Re: [deal.II] collect2 linking error when executing make

[Simon Wiesheier]

I called cmake as follows
$ cmake -DDEAL_II_WITH_HDF5=OFF .

and get the additional lines

//No help, variable specified on the command line.
DEAL_II_WITH_HDF5:UNINITIALIZED=OFF

in my CMakeCache.txt file.

However, after
$ make

the error message is unchanged.
Best
Simon


Am Di., 3. Jan. 2023 um 20:55 Uhr schrieb Simon Wiesheier <
simon.wieshe...@gmail.com>:

> I started from an empty source directory with only a CMakeLists.txt file.
>
> I do not need hdf5.
> At least I was not aware that I had it on my old computer.
>
> Is there a way to work around the issue?
>
> Best
> Simon
>
>
> Timo Heister  schrieb am Di., 3. Jan. 2023, 20:19:
>
>> Simon,
>>
>> Make sure that you do not transfer any temporary files
>> (CMakeCache.txt, CMakeFiles/ etc.) but that you start from a fresh
>> source directory. The error message hints at the fact that your new
>> system does not have hdf5 installed.
>>
>> On Mon, Jan 2, 2023 at 4:21 AM Simon  wrote:
>> >
>> > Dear all, First of all, I wish you a happy and prosperous new year
>> 2023! I transferred my dealii project to a different computer and encounter
>> an linking error (command make) after setting up the project (command cmake
>> .). ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍
>> > ZjQcmQRYFpfptBannerStart
>> > This Message Is From an External Sender
>> > Use caution when opening links or attachments if you do not recognize
>> the sender.
>> >
>> > ZjQcmQRYFpfptBannerEnd
>> > Dear all,
>> >
>> > First of all, I wish you a happy and prosperous new year 2023!
>> >
>> > I transferred my dealii project to a different computer and
>> > encounter an linking error (command make) after setting up
>> > the project (command cmake .).
>> > The error message is attached.
>> >
>> > What is the problem?
>> >
>> > Best
>> > Simon
>> >
>> > --
>> > 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/ca0ce1f2-cba0-42e1-8ee4-2178806540ebn%40googlegroups.com
>> .
>>
>>
>>
>> --
>> Timo Heister
>> http://www.math.clemson.edu/~heister/
>>
>> --
>> 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/CAMRj59HYLvENRpM7%3Dwy4v%3D8pvbkm7viGjMa4Apr3ytoZKX%3DktQ%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/CAM50jEsJVDPE-6Y1tuviCXU%2BmgPD55%3D1pX%3DyW8JTP5eghM7ZWA%40mail.gmail.com.

Re: [deal.II] collect2 linking error when executing make

[Simon Wiesheier]

I started from an empty source directory with only a CMakeLists.txt file.

I do not need hdf5.
At least I was not aware that I had it on my old computer.

Is there a way to work around the issue?

Best
Simon


Timo Heister  schrieb am Di., 3. Jan. 2023, 20:19:

> Simon,
>
> Make sure that you do not transfer any temporary files
> (CMakeCache.txt, CMakeFiles/ etc.) but that you start from a fresh
> source directory. The error message hints at the fact that your new
> system does not have hdf5 installed.
>
> On Mon, Jan 2, 2023 at 4:21 AM Simon  wrote:
> >
> > Dear all, First of all, I wish you a happy and prosperous new year 2023!
> I transferred my dealii project to a different computer and encounter an
> linking error (command make) after setting up the project (command cmake
> .). ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍
> > ZjQcmQRYFpfptBannerStart
> > This Message Is From an External Sender
> > Use caution when opening links or attachments if you do not recognize
> the sender.
> >
> > ZjQcmQRYFpfptBannerEnd
> > Dear all,
> >
> > First of all, I wish you a happy and prosperous new year 2023!
> >
> > I transferred my dealii project to a different computer and
> > encounter an linking error (command make) after setting up
> > the project (command cmake .).
> > The error message is attached.
> >
> > What is the problem?
> >
> > Best
> > Simon
> >
> > --
> > 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/ca0ce1f2-cba0-42e1-8ee4-2178806540ebn%40googlegroups.com
> .
>
>
>
> --
> Timo Heister
> http://www.math.clemson.edu/~heister/
>
> --
> 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/CAMRj59HYLvENRpM7%3Dwy4v%3D8pvbkm7viGjMa4Apr3ytoZKX%3DktQ%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/CAM50jEviY4LS2TKAp2OKYLBLK%2BUTqozOyWwPqD8GfQvYX0NsWQ%40mail.gmail.com.

[deal.II] collect2 linking error when executing make

[Simon]

Dear all,

First of all, I wish you a happy and prosperous new year 2023!

I transferred my dealii project to a different computer and 
encounter an linking error (command make) after setting up 
the project (command cmake .).
The error message is attached.

What is the problem?

Best
Simon

-- 
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/ca0ce1f2-cba0-42e1-8ee4-2178806540ebn%40googlegroups.com.

Re: [deal.II] large condition number after solving linear systems

[Simon Wiesheier]

Sorry that I come back to this again, but I would appreciate your feedback
to the issue I am confronted with:

" You would generally choose the (normalizes) eigenvectors of the J^T J
you have as the unit directions and the new set of parameters are then
multipliers for these directions. (So far your parameters are
multipliers for the unit vectors e_i in your 8-dimensional parameter
space.) The matrix J^T J using this basis for your parameter space will
then already be diagonal, though still poorly conditioned. "

I tried to implement this for only 3 parameters and the 3x3 Hessian
evaluated at the start vector reads
H = J^T J = [4.91e-121.07e-12   -5.98e-12
   6.50e-13   -1.72e-12
 sym 7.70e-12 ]
The eigenvectors are
EV_1 = [0.58; 0.58; 0.58]
EV_2 = [0.54; -0.80; 0.26]
EV_3 = [-0.61; -0.16; 0.77]
with associated eigenvalues {-8.72e-28, 4.80e-13; 1.28e-11}.
Clearly, I can not scale the eigenvectors by 1/sqrt(eigenvalue) as the
eigenvalues are numerically negative or very small.
Thus, I transformed the
old parameters [50;0;50]
using the transformation matrix [EV_1; EV_2; EV_3] and
obtained the
new parameters [-16778; 206381; 675972].
The set of new parameters is inadmissible in my case as the first and last
parameter have to be greater than the second parameter.
There is probably no straightforward way to incorporate this constraint in
the transformation, is it?

But anyway, it seems that I have to scale my parameters already before I
compute the J^T J.
The best alternative to linearly scale the parameters p_i is to normalize
them according to
-1 < p_i < +1 .
Right?

Best,
Simon

Am Mo., 17. Okt. 2022 um 16:20 Uhr schrieb Wolfgang Bangerth <
bange...@colostate.edu>:

> On 10/17/22 08:12, Simon Wiesheier wrote:
> >
> > I do not plan to do anything else than computing (J^t J)^-1
> > and some matrix multiplications with it.
> > Based on what you said, this should not cause any undue problems, right?
> >
>
> Probably not.
> 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/5ShTkx3dMCU/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/bf533083-5b0f-1627-9582-c73809f0c614%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/CAM50jEtBYuK%2Bps739ZaDeJG51Pm5DjNhOLSbcN9HjxzxUkbjdA%40mail.gmail.com.

Re: [deal.II] Re: measuring cpu and wall time for assembly routine

[Simon Wiesheier]

Sorry, I was wrong. Of course, it is the other way round.
The fast one is 3 times faster.

-Simon

Am So., 23. Okt. 2022 um 10:37 Uhr schrieb Peter Munch <
peterrmue...@gmail.com>:

> Now, I am lost. The fast one is 3 times slower!?
>
> Peter
>
> On Sunday, 23 October 2022 at 10:33:38 UTC+2 Simon wrote:
>
>> Certainly.
>> When using the slow path, i.e. MappingQ in version 9.3.2, the cpu time is
>> about 6.3 seconds.
>> In case of the fast path, i.e. MappingQGeneric in version 9.3.2, the cpu
>> time is about 18.7 seconds.
>> Crudely,  the .reinit function associated with the FEPointEvaluation
>> objects is called about 1.2 million times.
>>
>> Best,
>> Simon
>>
>> Am Sa., 22. Okt. 2022 um 17:09 Uhr schrieb Peter Munch <
>> peterr...@gmail.com>:
>>
>>> Happy about that! May I ask you to post the results here. I am curious
>>> since I never actually compared timings (and only blindly trusted Martin).
>>>
>>> Thanks,
>>> Peter
>>>
>>> On Saturday, 22 October 2022 at 16:46:16 UTC+2 Simon wrote:
>>>
>>>> Yes, the issue is resolved and the computation time decreased
>>>> significantly.
>>>>
>>>> Thank you all!
>>>>
>>>> -Simon
>>>>
>>>> Am Sa., 22. Okt. 2022 um 12:57 Uhr schrieb Peter Munch <
>>>> peterr...@gmail.com>:
>>>>
>>>>> You are right. Release 9.3 uses the slow path for MappingQ. The reason
>>>>> is that here
>>>>> https://github.com/dealii/dealii/blob/ccfaddc2bab172d9d139dabc044d028f65bb480a/include/deal.II/matrix_free/fe_point_evaluation.h#L708-L711
>>>>> we check for MappingQGeneric. At that time MappingQ and MappingQGeneric
>>>>> were different classes. In the meantime, we have merged the classes so 
>>>>> that
>>>>> in release 9.4 and on master this is not an issue anymore. Is there a
>>>>> chance that you update deal.II. Alternatively, you could use
>>>>> MappingQGeneric instead of MappingQ.
>>>>>
>>>>> Hope this resolves this issue!
>>>>>
>>>>> Peter
>>>>>
>>>>> On Friday, 21 October 2022 at 10:59:35 UTC+2 Simon wrote:
>>>>>
>>>>>> I revised the appendix from my last message a little bit and attache
>>>>>> now a minimal working example (just 140 lines) along with a 
>>>>>> CMakeLists.txt.
>>>>>> After checking the profiling results from valgrind, the combination
>>>>>> of MappingQ with FE_Q takes *not* the fast path.
>>>>>>
>>>>>> For info: I use dealii version 9.3.2
>>>>>>
>>>>>> Best,
>>>>>> Simon
>>>>>>
>>>>>> Am Do., 20. Okt. 2022 um 18:11 Uhr schrieb Simon Wiesheier <
>>>>>> simon.w...@gmail.com>:
>>>>>>
>>>>>>> " When you use FEPointEvaluation, you should construct it only once
>>>>>>> and re-use the same object for different points. Furthermore, you should
>>>>>>> also avoid to create "p_dofs" and the "std::vector" near the  I was not
>>>>>>> clear with my original message. Anyway, the problem is the FEValues 
>>>>>>> object
>>>>>>> that gets used. I am confused by your other message that you use FE_Q
>>>>>>> together with MappingQ - that combination should be supported and if it 
>>>>>>> is
>>>>>>> not, we should take a look at a (reduced) code from you. "
>>>>>>>
>>>>>>> I added a snippet of my code (see appendix) in which I describe the
>>>>>>> logic as to what I am doing with FEPointEvaluation.
>>>>>>> In fact, constructing FEPointEvaluation (and the vector p_dofs) once
>>>>>>> and re-using them brings only minor changes as the overall costs are
>>>>>>> dominated by the call to reinit().
>>>>>>> But, of course, it helps at least.
>>>>>>>
>>>>>>> I am surprised too that the fast path is not used. Maybe you can
>>>>>>> identify a problem in my code.
>>>>>>> Thank you!
>>>>>>>
>>>>>>> Best,
>>>>>>> Simon
>>>>>>>
>>>>>>> Am Do., 20. Okt. 2022 um 

Re: [deal.II] Re: measuring cpu and wall time for assembly routine

[Simon Wiesheier]

Certainly.
When using the slow path, i.e. MappingQ in version 9.3.2, the cpu time is
about 6.3 seconds.
In case of the fast path, i.e. MappingQGeneric in version 9.3.2, the cpu
time is about 18.7 seconds.
Crudely,  the .reinit function associated with the FEPointEvaluation
objects is called about 1.2 million times.

Best,
Simon

Am Sa., 22. Okt. 2022 um 17:09 Uhr schrieb Peter Munch <
peterrmue...@gmail.com>:

> Happy about that! May I ask you to post the results here. I am curious
> since I never actually compared timings (and only blindly trusted Martin).
>
> Thanks,
> Peter
>
> On Saturday, 22 October 2022 at 16:46:16 UTC+2 Simon wrote:
>
>> Yes, the issue is resolved and the computation time decreased
>> significantly.
>>
>> Thank you all!
>>
>> -Simon
>>
>> Am Sa., 22. Okt. 2022 um 12:57 Uhr schrieb Peter Munch <
>> peterr...@gmail.com>:
>>
>>> You are right. Release 9.3 uses the slow path for MappingQ. The reason
>>> is that here
>>> https://github.com/dealii/dealii/blob/ccfaddc2bab172d9d139dabc044d028f65bb480a/include/deal.II/matrix_free/fe_point_evaluation.h#L708-L711
>>> we check for MappingQGeneric. At that time MappingQ and MappingQGeneric
>>> were different classes. In the meantime, we have merged the classes so that
>>> in release 9.4 and on master this is not an issue anymore. Is there a
>>> chance that you update deal.II. Alternatively, you could use
>>> MappingQGeneric instead of MappingQ.
>>>
>>> Hope this resolves this issue!
>>>
>>> Peter
>>>
>>> On Friday, 21 October 2022 at 10:59:35 UTC+2 Simon wrote:
>>>
>>>> I revised the appendix from my last message a little bit and attache
>>>> now a minimal working example (just 140 lines) along with a CMakeLists.txt.
>>>> After checking the profiling results from valgrind, the combination of
>>>> MappingQ with FE_Q takes *not* the fast path.
>>>>
>>>> For info: I use dealii version 9.3.2
>>>>
>>>> Best,
>>>> Simon
>>>>
>>>> Am Do., 20. Okt. 2022 um 18:11 Uhr schrieb Simon Wiesheier <
>>>> simon.w...@gmail.com>:
>>>>
>>>>> " When you use FEPointEvaluation, you should construct it only once
>>>>> and re-use the same object for different points. Furthermore, you should
>>>>> also avoid to create "p_dofs" and the "std::vector" near the  I was not
>>>>> clear with my original message. Anyway, the problem is the FEValues object
>>>>> that gets used. I am confused by your other message that you use FE_Q
>>>>> together with MappingQ - that combination should be supported and if it is
>>>>> not, we should take a look at a (reduced) code from you. "
>>>>>
>>>>> I added a snippet of my code (see appendix) in which I describe the
>>>>> logic as to what I am doing with FEPointEvaluation.
>>>>> In fact, constructing FEPointEvaluation (and the vector p_dofs) once
>>>>> and re-using them brings only minor changes as the overall costs are
>>>>> dominated by the call to reinit().
>>>>> But, of course, it helps at least.
>>>>>
>>>>> I am surprised too that the fast path is not used. Maybe you can
>>>>> identify a problem in my code.
>>>>> Thank you!
>>>>>
>>>>> Best,
>>>>> Simon
>>>>>
>>>>> Am Do., 20. Okt. 2022 um 17:02 Uhr schrieb Martin Kronbichler <
>>>>> kronbichl...@gmail.com>:
>>>>>
>>>>>> Dear Simon,
>>>>>>
>>>>>> When you use FEPointEvaluation, you should construct it only once and
>>>>>> re-use the same object for different points. Furthermore, you should also
>>>>>> avoid to create "p_dofs" and the "std::vector" near the  I was not clear
>>>>>> with my original message. Anyway, the problem is the FEValues object that
>>>>>> gets used. I am confused by your other message that you use FE_Q together
>>>>>> with MappingQ - that combination should be supported and if it is not, we
>>>>>> should take a look at a (reduced) code from you.
>>>>>>
>>>>>> Regarding the high timings: There is some parallelization by tasks
>>>>>> that gets done inside the constructor of FEValues. This has good intents
>>>>>> for the case that w

Re: [deal.II] Re: measuring cpu and wall time for assembly routine

[Simon Wiesheier]

Yes, the issue is resolved and the computation time decreased significantly.

Thank you all!

-Simon

Am Sa., 22. Okt. 2022 um 12:57 Uhr schrieb Peter Munch <
peterrmue...@gmail.com>:

> You are right. Release 9.3 uses the slow path for MappingQ. The reason is
> that here
> https://github.com/dealii/dealii/blob/ccfaddc2bab172d9d139dabc044d028f65bb480a/include/deal.II/matrix_free/fe_point_evaluation.h#L708-L711
> we check for MappingQGeneric. At that time MappingQ and MappingQGeneric
> were different classes. In the meantime, we have merged the classes so that
> in release 9.4 and on master this is not an issue anymore. Is there a
> chance that you update deal.II. Alternatively, you could use
> MappingQGeneric instead of MappingQ.
>
> Hope this resolves this issue!
>
> Peter
>
> On Friday, 21 October 2022 at 10:59:35 UTC+2 Simon wrote:
>
>> I revised the appendix from my last message a little bit and attache now
>> a minimal working example (just 140 lines) along with a CMakeLists.txt.
>> After checking the profiling results from valgrind, the combination of
>> MappingQ with FE_Q takes *not* the fast path.
>>
>> For info: I use dealii version 9.3.2
>>
>> Best,
>> Simon
>>
>> Am Do., 20. Okt. 2022 um 18:11 Uhr schrieb Simon Wiesheier <
>> simon.w...@gmail.com>:
>>
>>> " When you use FEPointEvaluation, you should construct it only once and
>>> re-use the same object for different points. Furthermore, you should also
>>> avoid to create "p_dofs" and the "std::vector" near the  I was not clear
>>> with my original message. Anyway, the problem is the FEValues object that
>>> gets used. I am confused by your other message that you use FE_Q together
>>> with MappingQ - that combination should be supported and if it is not, we
>>> should take a look at a (reduced) code from you. "
>>>
>>> I added a snippet of my code (see appendix) in which I describe the
>>> logic as to what I am doing with FEPointEvaluation.
>>> In fact, constructing FEPointEvaluation (and the vector p_dofs) once and
>>> re-using them brings only minor changes as the overall costs are dominated
>>> by the call to reinit().
>>> But, of course, it helps at least.
>>>
>>> I am surprised too that the fast path is not used. Maybe you can
>>> identify a problem in my code.
>>> Thank you!
>>>
>>> Best,
>>> Simon
>>>
>>> Am Do., 20. Okt. 2022 um 17:02 Uhr schrieb Martin Kronbichler <
>>> kronbichl...@gmail.com>:
>>>
>>>> Dear Simon,
>>>>
>>>> When you use FEPointEvaluation, you should construct it only once and
>>>> re-use the same object for different points. Furthermore, you should also
>>>> avoid to create "p_dofs" and the "std::vector" near the  I was not clear
>>>> with my original message. Anyway, the problem is the FEValues object that
>>>> gets used. I am confused by your other message that you use FE_Q together
>>>> with MappingQ - that combination should be supported and if it is not, we
>>>> should take a look at a (reduced) code from you.
>>>>
>>>> Regarding the high timings: There is some parallelization by tasks that
>>>> gets done inside the constructor of FEValues. This has good intents for the
>>>> case that we are in 3D and have a reasonable amount of work to do. However,
>>>> you are in 1D (if I read your code correctly), and then it is having
>>>> adverse effects. The reason is that the constructor of FEValues is very
>>>> likely completely dominated by memory allocation. When we have 1 thread,
>>>> everything is fine, but when we have multiple threads working they will
>>>> start to interfere with each other when the request memory through
>>>> malloc(), which has to be coordinated by the operating system (and thus
>>>> gets slower). In fact, the big gap between compute time and wall time shows
>>>> that there is a lot of time wasted by "system time" that does not do actual
>>>> work on the cores.
>>>>
>>>> I guess the library could have a better measure of when to spawn tasks
>>>> in FEValues in similar context, but it is a lot of work to get this right.
>>>> (This is why I keep avoiding it in critical functions.)
>>>>
>>>> Best,
>>>> Martin
>>>>
>>>>
>>>> On 20.10.22 16:47, Simon Wiesheier wrote:
>>>>
>>>> Update

Re: [deal.II] Re: measuring cpu and wall time for assembly routine

[Simon Wiesheier]

I revised the appendix from my last message a little bit and attache now a
minimal working example (just 140 lines) along with a CMakeLists.txt.
After checking the profiling results from valgrind, the combination of
MappingQ with FE_Q takes *not* the fast path.

For info: I use dealii version 9.3.2

Best,
Simon

Am Do., 20. Okt. 2022 um 18:11 Uhr schrieb Simon Wiesheier <
simon.wieshe...@gmail.com>:

> " When you use FEPointEvaluation, you should construct it only once and
> re-use the same object for different points. Furthermore, you should also
> avoid to create "p_dofs" and the "std::vector" near the  I was not clear
> with my original message. Anyway, the problem is the FEValues object that
> gets used. I am confused by your other message that you use FE_Q together
> with MappingQ - that combination should be supported and if it is not, we
> should take a look at a (reduced) code from you. "
>
> I added a snippet of my code (see appendix) in which I describe the logic
> as to what I am doing with FEPointEvaluation.
> In fact, constructing FEPointEvaluation (and the vector p_dofs) once and
> re-using them brings only minor changes as the overall costs are dominated
> by the call to reinit().
> But, of course, it helps at least.
>
> I am surprised too that the fast path is not used. Maybe you can identify
> a problem in my code.
> Thank you!
>
> Best,
> Simon
>
> Am Do., 20. Okt. 2022 um 17:02 Uhr schrieb Martin Kronbichler <
> kronbichler.mar...@gmail.com>:
>
>> Dear Simon,
>>
>> When you use FEPointEvaluation, you should construct it only once and
>> re-use the same object for different points. Furthermore, you should also
>> avoid to create "p_dofs" and the "std::vector" near the  I was not clear
>> with my original message. Anyway, the problem is the FEValues object that
>> gets used. I am confused by your other message that you use FE_Q together
>> with MappingQ - that combination should be supported and if it is not, we
>> should take a look at a (reduced) code from you.
>>
>> Regarding the high timings: There is some parallelization by tasks that
>> gets done inside the constructor of FEValues. This has good intents for the
>> case that we are in 3D and have a reasonable amount of work to do. However,
>> you are in 1D (if I read your code correctly), and then it is having
>> adverse effects. The reason is that the constructor of FEValues is very
>> likely completely dominated by memory allocation. When we have 1 thread,
>> everything is fine, but when we have multiple threads working they will
>> start to interfere with each other when the request memory through
>> malloc(), which has to be coordinated by the operating system (and thus
>> gets slower). In fact, the big gap between compute time and wall time shows
>> that there is a lot of time wasted by "system time" that does not do actual
>> work on the cores.
>>
>> I guess the library could have a better measure of when to spawn tasks in
>> FEValues in similar context, but it is a lot of work to get this right.
>> (This is why I keep avoiding it in critical functions.)
>>
>> Best,
>> Martin
>>
>>
>> On 20.10.22 16:47, Simon Wiesheier wrote:
>>
>> Update:
>>
>> I profiled my program with valgrind --tool=callgrind and could figure out
>> that
>> FEPointEvaluation creates an FEValues object along with a quadrature
>> object under the hood.
>> Closer inspection revealed that all constructors, destructors,...
>> associated with FEPointEvaluation
>> need roughly 5000 instructions more (per call!).
>> That said, FEValues is indeed the faster approach, at least for FE_Q
>> elements.
>>
>> export DEAL_II_NUM_THREADS=1
>> eliminated the gap between cpu and wall time.
>> Using FEValues directly, I get cpu time 19.8 seconds
>> and in the case of FEPointEvaluation cpu time = 21.9 seconds;
>> Wall times are in the same ballpark.
>> Out of curiosity, why produces multi-threading such high wall times (200
>> seconds) in my case?.
>>
>> These times are far too big given that the solution of the linear system
>> takes only about 13 seconds.
>> But based on what all of you have said, there is probably no other to way
>> to implement my problem.
>>
>> Best
>> Simon
>>
>> Am Do., 20. Okt. 2022 um 11:55 Uhr schrieb Simon Wiesheier <
>> simon.wieshe...@gmail.com>:
>>
>>> Dear Martin and Wolfgang,
>>>
>>> " You seem to be looking for FEPointEvaluation. That class is shown in
>>> step-19 and provid

Re: [deal.II] Re: measuring cpu and wall time for assembly routine

[Simon Wiesheier]

" When you use FEPointEvaluation, you should construct it only once and
re-use the same object for different points. Furthermore, you should also
avoid to create "p_dofs" and the "std::vector" near the  I was not clear
with my original message. Anyway, the problem is the FEValues object that
gets used. I am confused by your other message that you use FE_Q together
with MappingQ - that combination should be supported and if it is not, we
should take a look at a (reduced) code from you. "

I added a snippet of my code (see appendix) in which I describe the logic
as to what I am doing with FEPointEvaluation.
In fact, constructing FEPointEvaluation (and the vector p_dofs) once and
re-using them brings only minor changes as the overall costs are dominated
by the call to reinit().
But, of course, it helps at least.

I am surprised too that the fast path is not used. Maybe you can identify a
problem in my code.
Thank you!

Best,
Simon

Am Do., 20. Okt. 2022 um 17:02 Uhr schrieb Martin Kronbichler <
kronbichler.mar...@gmail.com>:

> Dear Simon,
>
> When you use FEPointEvaluation, you should construct it only once and
> re-use the same object for different points. Furthermore, you should also
> avoid to create "p_dofs" and the "std::vector" near the  I was not clear
> with my original message. Anyway, the problem is the FEValues object that
> gets used. I am confused by your other message that you use FE_Q together
> with MappingQ - that combination should be supported and if it is not, we
> should take a look at a (reduced) code from you.
>
> Regarding the high timings: There is some parallelization by tasks that
> gets done inside the constructor of FEValues. This has good intents for the
> case that we are in 3D and have a reasonable amount of work to do. However,
> you are in 1D (if I read your code correctly), and then it is having
> adverse effects. The reason is that the constructor of FEValues is very
> likely completely dominated by memory allocation. When we have 1 thread,
> everything is fine, but when we have multiple threads working they will
> start to interfere with each other when the request memory through
> malloc(), which has to be coordinated by the operating system (and thus
> gets slower). In fact, the big gap between compute time and wall time shows
> that there is a lot of time wasted by "system time" that does not do actual
> work on the cores.
>
> I guess the library could have a better measure of when to spawn tasks in
> FEValues in similar context, but it is a lot of work to get this right.
> (This is why I keep avoiding it in critical functions.)
>
> Best,
> Martin
>
>
> On 20.10.22 16:47, Simon Wiesheier wrote:
>
> Update:
>
> I profiled my program with valgrind --tool=callgrind and could figure out
> that
> FEPointEvaluation creates an FEValues object along with a quadrature
> object under the hood.
> Closer inspection revealed that all constructors, destructors,...
> associated with FEPointEvaluation
> need roughly 5000 instructions more (per call!).
> That said, FEValues is indeed the faster approach, at least for FE_Q
> elements.
>
> export DEAL_II_NUM_THREADS=1
> eliminated the gap between cpu and wall time.
> Using FEValues directly, I get cpu time 19.8 seconds
> and in the case of FEPointEvaluation cpu time = 21.9 seconds;
> Wall times are in the same ballpark.
> Out of curiosity, why produces multi-threading such high wall times (200
> seconds) in my case?.
>
> These times are far too big given that the solution of the linear system
> takes only about 13 seconds.
> But based on what all of you have said, there is probably no other to way
> to implement my problem.
>
> Best
> Simon
>
> Am Do., 20. Okt. 2022 um 11:55 Uhr schrieb Simon Wiesheier <
> simon.wieshe...@gmail.com>:
>
>> Dear Martin and Wolfgang,
>>
>> " You seem to be looking for FEPointEvaluation. That class is shown in
>> step-19 and provides, for simple FiniteElement types, a much faster way to
>> evaluate solutions at arbitrary points within a cell. Do you want to give
>> it a try? "
>>
>> I implemented the FEPointEvaluation approach like this:
>>
>> FEPointEvaluation<1,1> fe_eval(mapping,
>> FE_Q<1>(1),
>> update_gradients |
>> update_values);
>> fe_eval.reinit(cell,
>> make_array_view(std::vector>{ref_point_energy_vol}));
>> Vector p_dofs(2);
>> cell->get_dof_values(solution_global, p_dofs);
>> fe_eval.evaluate(make_array_view(p_dofs),
>> EvaluationFlags::values |
>> EvaluationFlags::gradient

Re: [deal.II] Re: measuring cpu and wall time for assembly routine

[Simon Wiesheier]

" What type of Mapping are you using? If you take a look at
https://github.com/dealii/dealii/blob/ad13824e599601ee170cb2fd1c7c3099d3d5b0f7/source/matrix_free/fe_point_evaluation.cc#L40-L95
you can see when the fast path of FEPointEvaluation is taken. Indeed, the
slow path is (FEValues). One question: are you running in release or debug
mode? "

I use FE_Q<1>(1) with a MappingQ<1>(1) and
FE_Q<2>(1) with a MappingQ<2>(1).

I am running in release mode.

Best,
Simon

Am Do., 20. Okt. 2022 um 16:53 Uhr schrieb Peter Munch <
peterrmue...@gmail.com>:

> > FEPointEvaluation creates an FEValues object along with a quadrature
> object under the hood.
> Closer inspection revealed that all constructors, destructors,...
> associated with FEPointEvaluation
> need roughly 5000 instructions more (per call!).
> That said, FEValues is indeed the faster approach, at least for FE_Q
> elements.
>
> What type of Mapping are you using? If you take a look at
> https://github.com/dealii/dealii/blob/ad13824e599601ee170cb2fd1c7c3099d3d5b0f7/source/matrix_free/fe_point_evaluation.cc#L40-L95
> you can see when the fast path of FEPointEvaluation is taken. Indeed, the
> slow path is (FEValues). One question: are you running in release or debug
> mode?
>
> Hope this brings us closer to the issue,
> Peter
>
> On Thursday, 20 October 2022 at 16:47:17 UTC+2 Simon wrote:
>
>> Update:
>>
>> I profiled my program with valgrind --tool=callgrind and could figure out
>> that
>> FEPointEvaluation creates an FEValues object along with a quadrature
>> object under the hood.
>> Closer inspection revealed that all constructors, destructors,...
>> associated with FEPointEvaluation
>> need roughly 5000 instructions more (per call!).
>> That said, FEValues is indeed the faster approach, at least for FE_Q
>> elements.
>>
>> export DEAL_II_NUM_THREADS=1
>> eliminated the gap between cpu and wall time.
>> Using FEValues directly, I get cpu time 19.8 seconds
>> and in the case of FEPointEvaluation cpu time = 21.9 seconds;
>> Wall times are in the same ballpark.
>> Out of curiosity, why produces multi-threading such high wall times (200
>> seconds) in my case?.
>>
>> These times are far too big given that the solution of the linear system
>> takes only about 13 seconds.
>> But based on what all of you have said, there is probably no other to way
>> to implement my problem.
>>
>> Best
>> Simon
>>
>> Am Do., 20. Okt. 2022 um 11:55 Uhr schrieb Simon Wiesheier <
>> simon.w...@gmail.com>:
>>
>>> Dear Martin and Wolfgang,
>>>
>>> " You seem to be looking for FEPointEvaluation. That class is shown in
>>> step-19 and provides, for simple FiniteElement types, a much faster way to
>>> evaluate solutions at arbitrary points within a cell. Do you want to give
>>> it a try? "
>>>
>>> I implemented the FEPointEvaluation approach like this:
>>>
>>> FEPointEvaluation<1,1> fe_eval(mapping,
>>> FE_Q<1>(1),
>>> update_gradients |
>>> update_values);
>>> fe_eval.reinit(cell,
>>> make_array_view(std::vector>{ref_point_energy_vol}));
>>> Vector p_dofs(2);
>>> cell->get_dof_values(solution_global, p_dofs);
>>> fe_eval.evaluate(make_array_view(p_dofs),
>>> EvaluationFlags::values |
>>> EvaluationFlags::gradients);
>>> double val = fe_eval.get_value(0);
>>> Tensor<1,1> grad = fe_eval.get_gradient(0);
>>>
>>> I am using FE_Q elements of degree one and a MappingQ object also of
>>> degree one.
>>>
>>> Frankly, I do not really understand the measured computation times.
>>> My program has several loadsteps with nested Newton iterations:
>>> Loadstep 1:
>>> Assembly 1: cpu time 12.8 sec  wall time 268.7 sec
>>> Assembly 2: cpu time 17.7 sec  wall time 275.2 sec
>>> Assembly 3: cpu time 22.3 sec  wall time 272.6 sec
>>> Assembly 4: cpu time 23.8 sec  wall time 271.3sec
>>> Loadstep 2:
>>> Assembly 1: cpu time 14.3 sec  wall time 260.0 sec
>>> Assembly 2: cpu time 16.9 sec  wall time 262.1 sec
>>> Assembly 3: cpu time 18.5 sec  wall time 270.6 sec
>>> Assembly 4: cpu time 17.1 sec  wall time 262.2 sec
>>> ...
>>>
>>> Using FEValues instead of FEPointEvaluation, the results are:
>>> Loadstep 1:
>>> Assembly 1: cpu time 23.9 sec  wall time 171.0 sec
>>> Assembly 

Re: [deal.II] Re: measuring cpu and wall time for assembly routine

[Simon Wiesheier]

Update:

I profiled my program with valgrind --tool=callgrind and could figure out
that
FEPointEvaluation creates an FEValues object along with a quadrature object
under the hood.
Closer inspection revealed that all constructors, destructors,...
associated with FEPointEvaluation
need roughly 5000 instructions more (per call!).
That said, FEValues is indeed the faster approach, at least for FE_Q
elements.

export DEAL_II_NUM_THREADS=1
eliminated the gap between cpu and wall time.
Using FEValues directly, I get cpu time 19.8 seconds
and in the case of FEPointEvaluation cpu time = 21.9 seconds;
Wall times are in the same ballpark.
Out of curiosity, why produces multi-threading such high wall times (200
seconds) in my case?.

These times are far too big given that the solution of the linear system
takes only about 13 seconds.
But based on what all of you have said, there is probably no other to way
to implement my problem.

Best
Simon

Am Do., 20. Okt. 2022 um 11:55 Uhr schrieb Simon Wiesheier <
simon.wieshe...@gmail.com>:

> Dear Martin and Wolfgang,
>
> " You seem to be looking for FEPointEvaluation. That class is shown in
> step-19 and provides, for simple FiniteElement types, a much faster way to
> evaluate solutions at arbitrary points within a cell. Do you want to give
> it a try? "
>
> I implemented the FEPointEvaluation approach like this:
>
> FEPointEvaluation<1,1> fe_eval(mapping,
> FE_Q<1>(1),
> update_gradients | update_values);
> fe_eval.reinit(cell,
> make_array_view(std::vector>{ref_point_energy_vol}));
> Vector p_dofs(2);
> cell->get_dof_values(solution_global, p_dofs);
> fe_eval.evaluate(make_array_view(p_dofs),
> EvaluationFlags::values |
> EvaluationFlags::gradients);
> double val = fe_eval.get_value(0);
> Tensor<1,1> grad = fe_eval.get_gradient(0);
>
> I am using FE_Q elements of degree one and a MappingQ object also of
> degree one.
>
> Frankly, I do not really understand the measured computation times.
> My program has several loadsteps with nested Newton iterations:
> Loadstep 1:
> Assembly 1: cpu time 12.8 sec  wall time 268.7 sec
> Assembly 2: cpu time 17.7 sec  wall time 275.2 sec
> Assembly 3: cpu time 22.3 sec  wall time 272.6 sec
> Assembly 4: cpu time 23.8 sec  wall time 271.3sec
> Loadstep 2:
> Assembly 1: cpu time 14.3 sec  wall time 260.0 sec
> Assembly 2: cpu time 16.9 sec  wall time 262.1 sec
> Assembly 3: cpu time 18.5 sec  wall time 270.6 sec
> Assembly 4: cpu time 17.1 sec  wall time 262.2 sec
> ...
>
> Using FEValues instead of FEPointEvaluation, the results are:
> Loadstep 1:
> Assembly 1: cpu time 23.9 sec  wall time 171.0 sec
> Assembly 2: cpu time 32.5 sec  wall time 168.9 sec
> Assembly 3: cpu time 33.2 sec  wall time 168.0 sec
> Assembly 4: cpu time 32.7 sec  wall time 166.9 sec
> Loadstep 2:
> Assembly 1: cpu time 24.9 sec  wall time 168.0 sec
> Assembly 2: cpu time 34.7 sec  wall time 167.3 sec
> Assembly 3: cpu time 33.9 sec  wall time 167.8 sec
> Assembly 4: cpu time 34.3 sec  wall time 167.7 sec
> ...
>
> Clearly, the fluctuations using FEValues are smaller than in case of
> FEPointEvaluation.
> Anyway, using FEPointEvaluation the cpu time is smaller but the wall time
> substantially bigger.
> If I am not mistaken, the values cpu time 34.3 sec and wall time 167.7 sec
> mean that
> the cpu needs 34.3 sec to execute my assembly routine and has to wait in
> the
> remaining 167.7-34.3 seconds.
> This huge gap between cpu and wall time has to be related to what I do
> with FEValues or FEPointEvaluation
> as cpu and wall time are nearly balanced if I use either neither of them.
> What might be the problem?
>
> Best
> Simon
>
>
>
>
>
> Am Mi., 19. Okt. 2022 um 22:34 Uhr schrieb Wolfgang Bangerth <
> bange...@colostate.edu>:
>
>> On 10/19/22 08:45, Simon Wiesheier wrote:
>> >
>> > What I want to do boils down to the following:
>> > Given the reference co-ordinates of a point 'p', along with the cell on
>> > which 'p' lives,
>> > give me the value and gradient of a finite element function evaluated
>> at
>> > 'p'.
>> >
>> > My idea was to create a quadrature object with 'p' being the only
>> > quadrature point and pass this
>> > quadrature object to the FEValues object and finally do the
>> > .reinit(cell) call (then, of course, get_function_values()...)
>> > 'p' is different for all (2.5 million) quadrature points, which is why
>> I
>> > create the FEValues object so many times.
>>
>&g

Re: [deal.II] Re: measuring cpu and wall time for assembly routine

[Simon Wiesheier]

Dear Martin and Wolfgang,

" You seem to be looking for FEPointEvaluation. That class is shown in
step-19 and provides, for simple FiniteElement types, a much faster way to
evaluate solutions at arbitrary points within a cell. Do you want to give
it a try? "

I implemented the FEPointEvaluation approach like this:

FEPointEvaluation<1,1> fe_eval(mapping,
FE_Q<1>(1),
update_gradients | update_values);
fe_eval.reinit(cell,
make_array_view(std::vector>{ref_point_energy_vol}));
Vector p_dofs(2);
cell->get_dof_values(solution_global, p_dofs);
fe_eval.evaluate(make_array_view(p_dofs),
EvaluationFlags::values |
EvaluationFlags::gradients);
double val = fe_eval.get_value(0);
Tensor<1,1> grad = fe_eval.get_gradient(0);

I am using FE_Q elements of degree one and a MappingQ object also of degree
one.

Frankly, I do not really understand the measured computation times.
My program has several loadsteps with nested Newton iterations:
Loadstep 1:
Assembly 1: cpu time 12.8 sec  wall time 268.7 sec
Assembly 2: cpu time 17.7 sec  wall time 275.2 sec
Assembly 3: cpu time 22.3 sec  wall time 272.6 sec
Assembly 4: cpu time 23.8 sec  wall time 271.3sec
Loadstep 2:
Assembly 1: cpu time 14.3 sec  wall time 260.0 sec
Assembly 2: cpu time 16.9 sec  wall time 262.1 sec
Assembly 3: cpu time 18.5 sec  wall time 270.6 sec
Assembly 4: cpu time 17.1 sec  wall time 262.2 sec
...

Using FEValues instead of FEPointEvaluation, the results are:
Loadstep 1:
Assembly 1: cpu time 23.9 sec  wall time 171.0 sec
Assembly 2: cpu time 32.5 sec  wall time 168.9 sec
Assembly 3: cpu time 33.2 sec  wall time 168.0 sec
Assembly 4: cpu time 32.7 sec  wall time 166.9 sec
Loadstep 2:
Assembly 1: cpu time 24.9 sec  wall time 168.0 sec
Assembly 2: cpu time 34.7 sec  wall time 167.3 sec
Assembly 3: cpu time 33.9 sec  wall time 167.8 sec
Assembly 4: cpu time 34.3 sec  wall time 167.7 sec
...

Clearly, the fluctuations using FEValues are smaller than in case of
FEPointEvaluation.
Anyway, using FEPointEvaluation the cpu time is smaller but the wall time
substantially bigger.
If I am not mistaken, the values cpu time 34.3 sec and wall time 167.7 sec
mean that
the cpu needs 34.3 sec to execute my assembly routine and has to wait in the
remaining 167.7-34.3 seconds.
This huge gap between cpu and wall time has to be related to what I do with
FEValues or FEPointEvaluation
as cpu and wall time are nearly balanced if I use either neither of them.
What might be the problem?

Best
Simon





Am Mi., 19. Okt. 2022 um 22:34 Uhr schrieb Wolfgang Bangerth <
bange...@colostate.edu>:

> On 10/19/22 08:45, Simon Wiesheier wrote:
> >
> > What I want to do boils down to the following:
> > Given the reference co-ordinates of a point 'p', along with the cell on
> > which 'p' lives,
> > give me the value and gradient of a finite element function evaluated at
> > 'p'.
> >
> > My idea was to create a quadrature object with 'p' being the only
> > quadrature point and pass this
> > quadrature object to the FEValues object and finally do the
> > .reinit(cell) call (then, of course, get_function_values()...)
> > 'p' is different for all (2.5 million) quadrature points, which is why I
> > create the FEValues object so many times.
>
> It's worth pointing out that is exactly what VectorTools::point_values()
> does.
>
> (As others have already mentioned, if you want to do that many many
> times over, this is too expensive and you should be using
> FEPointEvaluation instead.)
>
> 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 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/cd1c8fa0-443d-b7bf-b433-f5ab033a247c%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/CAM50jEscu%2BSVwwUd6izNn9F9F1483QR%3DfFiBFbar27ZORDpeqA%40mail.gmail.com.

Re: [deal.II] Re: measuring cpu and wall time for assembly routine

[Simon Wiesheier]

" It's an environment variable. "

I did
$DEAL_II_NUM_THREADS
and the variable is not set.
But if it were set to one, why would this explain the gap between cpu and
wall time?

" My point is the constructor should not be called millions of times. You
are not going to be able to get that function 100 times faster. It's best
to find a way to call it less often. "

What I want to do boils down to the following:
Given the reference co-ordinates of a point 'p', along with the cell on
which 'p' lives,
give me the value and gradient of a finite element function evaluated at
'p'.

My idea was to create a quadrature object with 'p' being the only
quadrature point and pass this
quadrature object to the FEValues object and finally do the .reinit(cell)
call (then, of course, get_function_values()...)
'p' is different for all (2.5 million) quadrature points, which is why I
create the FEValues object so many times.

Do you a different suggestion to solve my problem, ie to evaluate the
finite element field and its derivatives at 'p'?

Best,
Simon


Am Mi., 19. Okt. 2022 um 16:17 Uhr schrieb Bruno Turcksin <
bruno.turck...@gmail.com>:

> Simon,
>
> Le mer. 19 oct. 2022 à 09:33, Simon Wiesheier 
> a écrit :
>
>> Thank you for your answer!
>>
>> " Did you set DEAL_II_NUM_THREADS=1?"
>>
>> How can I double-check that?
>> ccmake .
>> only shows my the variables CMAKE_BUILD_TYPE and deal.II_DIR .
>> But I do  do knot if this is the right place to look for.
>>
> It's an environment variable. If you are using bash, you can do
>
> export DEAL_II_NUM_THREADS=1
>
>
>>
>> " That could explain why CPU and Wall time are different. Finally, if I
>> understand correctly, you are calling the constructor of FEValues about 2.5
>> million times. That means that the call to one FEValues constructor is
>> 100/2.5e6 seconds about 40 microseconds. That doesn't seem too slow. "
>>
>> There was a typo in my post. It should be 160/2.5e6 seconds about 64
>> microsecends.
>>
> My point is the constructor should not be called millions of times. You
> are not going to be able to get that function 100 times faster. It's best
> to find a way to call it less often.
>
> 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 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/CAGVt9eMfVohOUToQOsBD_v%2BqU%3D0Em_XOMiwqFi2SM_0zLoy-sQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/dealii/CAGVt9eMfVohOUToQOsBD_v%2BqU%3D0Em_XOMiwqFi2SM_0zLoy-sQ%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/CAM50jEtyY576riC6yNqqMafXfGGvTXY8mhm%3Di7HMzr-U_LAxbQ%40mail.gmail.com.

Re: [deal.II] Re: measuring cpu and wall time for assembly routine

[Simon Wiesheier]

Thank you for your answer!

" Did you set DEAL_II_NUM_THREADS=1?"

How can I double-check that?
ccmake .
only shows my the variables CMAKE_BUILD_TYPE and deal.II_DIR .
But I do  do knot if this is the right place to look for.

" That could explain why CPU and Wall time are different. Finally, if I
understand correctly, you are calling the constructor of FEValues about 2.5
million times. That means that the call to one FEValues constructor is
100/2.5e6 seconds about 40 microseconds. That doesn't seem too slow. "

There was a typo in my post. It should be 160/2.5e6 seconds about 64
microsecends.

Best,
Simon

Am Mi., 19. Okt. 2022 um 15:08 Uhr schrieb Bruno Turcksin <
bruno.turck...@gmail.com>:

> Simon,
>
> The best way to profile a code is to use a profiler. It can give a lot
> more information than what simple timers can do. You say that your code is
> not parallelized but by default deal.II is multithreaded . Did you set
> DEAL_II_NUM_THREADS=1? That could explain why CPU and Wall time are
> different. Finally, if I understand correctly, you are calling the
> constructor of FEValues about 2.5 million times. That means that the call
> to one FEValues constructor is 100/2.5e6 seconds about 40 microseconds.
> That doesn't seem too slow.
>
> Best,
>
> Bruno
>
> On Wednesday, October 19, 2022 at 7:51:55 AM UTC-4 Simon wrote:
>
>> Dear all,
>>
>> I implemented two different versions to compute a stress for a given
>> strain and want to compare the associated computation times in release mode.
>>
>> version 1: stress = fun1(strain)  cpu time:  4.52  s  wall
>> time:   4.53 s
>> version 2: stress = fun2(strain) cpu time: 32.5s  wall time:
>> 167.5 s
>>
>> fun1 and fun2, respectively, are invoked for all quadrature points
>> (1,286,144 in the above example) defined on the triangulation. My program
>> is not parallelized.
>> In fun2, I call  find_active_cell_around_point
>> <https://www.dealii.org/current/doxygen/deal.II/namespaceGridTools.html#a2e10aeb1c8e76110a84b6945eac3aaf0>
>> twice for two different points on two different (helper) triangulations and
>> initialize two FEValues objects
>> with the points ' ref_point_vol' and 'ref_point_dev'
>> as returned by find_active_cell_around_point
>> <https://www.dealii.org/current/doxygen/deal.II/namespaceGridTools.html#a2e10aeb1c8e76110a84b6945eac3aaf0>
>> .
>> FEValues<1> fe_vol(dof_handler_vol.get_fe(),
>> Quadrature<1>(ref_point_vol),
>> update_gradients |
>> update_values);
>> FEValues<1> fe_values_energy_dev(this->dof_handler_dev.get_fe(),
>> Quadrature<1>(ref_point_dev),
>> update_gradients |
>> update_values);
>>
>> I figured out that the initialization of the two FEValues objects is the
>> biggest portion of the above mentioned times.  In particular, if I comment
>> the initialization out, I have
>> cpu time: 6.54 s wall time: 6.55 s .
>>
>> The triangulations associated with dof_handler_vol and dof_handler_dev
>> are both 1d and store only 4 and 16 elements, respectively. That said, I am
>> wondering why the initialization takes so long (roughly 100 seconds wall
>> time in total) and why this causes a gap between the cpu and wall time.
>> Unfortunately, I have to reinitialize them anew whenever fun2 is called,
>> because  the point 'ref_point_vol' (see Quadrature<1>(ref_point_vol)) is
>> different in each call to fun2.
>>
>> Best
>> Simon
>>
>>
>>
>> --
> 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/uAplhH99yg4/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/d955e8e6-78c8-41f7-9f6c-f5339c22b319n%40googlegroups.com
> <https://groups.google.com/d/msgid/dealii/d955e8e6-78c8-41f7-9f6c-f5339c22b319n%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/CAM50jEs0T02%2BpdBiP%2BP72vz_eoN2Et%2BJ6X6HPL9xdZGXOtnmdA%40mail.gmail.com.

[deal.II] measuring cpu and wall time for assembly routine

[Simon]

Dear all,

I implemented two different versions to compute a stress for a given strain 
and want to compare the associated computation times in release mode.

version 1: stress = fun1(strain)  cpu time:  4.52  s  wall time:   
4.53 s
version 2: stress = fun2(strain) cpu time: 32.5s  wall time: 
167.5 s 

fun1 and fun2, respectively, are invoked for all quadrature points 
(1,286,144 in the above example) defined on the triangulation. My program 
is not parallelized.
In fun2, I call  find_active_cell_around_point 
<https://www.dealii.org/current/doxygen/deal.II/namespaceGridTools.html#a2e10aeb1c8e76110a84b6945eac3aaf0>
 
twice for two different points on two different (helper) triangulations and 
initialize two FEValues objects 
with the points ' ref_point_vol' and 'ref_point_dev' 
as returned by find_active_cell_around_point 
<https://www.dealii.org/current/doxygen/deal.II/namespaceGridTools.html#a2e10aeb1c8e76110a84b6945eac3aaf0>
 
.
FEValues<1> fe_vol(dof_handler_vol.get_fe(), 
Quadrature<1>(ref_point_vol),
update_gradients | update_values); 
   
FEValues<1> fe_values_energy_dev(this->dof_handler_dev.get_fe(), 
Quadrature<1>(ref_point_dev),
update_gradients | update_values); 
  

I figured out that the initialization of the two FEValues objects is the 
biggest portion of the above mentioned times.  In particular, if I comment 
the initialization out, I have 
cpu time: 6.54 s wall time: 6.55 s .

The triangulations associated with dof_handler_vol and dof_handler_dev are 
both 1d and store only 4 and 16 elements, respectively. That said, I am 
wondering why the initialization takes so long (roughly 100 seconds wall 
time in total) and why this causes a gap between the cpu and wall time.
Unfortunately, I have to reinitialize them anew whenever fun2 is called, 
because  the point 'ref_point_vol' (see Quadrature<1>(ref_point_vol)) is 
different in each call to fun2. 

Best
Simon



-- 
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/8f0e7843-c382-44bc-8e24-bbb65818c40cn%40googlegroups.com.

Re: [deal.II] large condition number after solving linear systems

[Simon Wiesheier]

" It always depends on what you want to do with it. If your goal is to show
that
the problem has a few large and a few small singular vectors, you don't
need
to know them accurately. If you want to multiply with the matrix, the
ill-conditioning is likely also not going to hurt very much. If you want to
solve a linear system with it, that might be a different story. "

I do not plan to do anything else than computing (J^t J)^-1
and some matrix multiplications with it.
Based on what you said, this should not cause any undue problems, right?

Best
Simon

Am Mo., 17. Okt. 2022 um 15:47 Uhr schrieb Wolfgang Bangerth <
bange...@colostate.edu>:

> On 10/17/22 00:44, Simon Wiesheier wrote:
> >
> > I plan to work with the correlation matrix (related to the inverse of
> J^t J).
> > If J has condition number about 1e13, do you think I can work on J^t J
> > without getting into numerical problems?
>
> It always depends on what you want to do with it. If your goal is to show
> that
> the problem has a few large and a few small singular vectors, you don't
> need
> to know them accurately. If you want to multiply with the matrix, the
> ill-conditioning is likely also not going to hurt very much. If you want
> to
> solve a linear system with it, that might be a different story.
>
> 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 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/f006a974-f4b7-a829-198b-5e98fe2312cc%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/CAM50jEuAkN20acgdXvnFvpfUJnWEz3qbHtZ4cmMbwuSgjuhs1w%40mail.gmail.com.

Re: [deal.II] large condition number after solving linear systems

[Simon Wiesheier]

One last thing:

" Or you live with the ill-conditionedness. "

I plan to work with the correlation matrix (related to the inverse of J^t
J).
If J has condition number about 1e13, do you think I can work on J^t J
without getting into numerical problems?

Best
Simon


Am Mo., 17. Okt. 2022 um 06:14 Uhr schrieb Wolfgang Bangerth <
bange...@colostate.edu>:

> On 10/15/22 03:15, Simon Wiesheier wrote:
> >
> > This makes sense.
> > So, given the scaled eigenvectors E_1,...,E_8, how can I find the
> coefficients
> > A^*,...,H^* ?
> > Is it just a matrix multiplication
> > P* =  (E_1; ... ; E_8) \times p* ,
> > where P* = (A^*,...,H^*) are the new parameters and p* = (a^*,...,h^*)
> are the
> > old parameters?
>
> Something of the sort. It's the same point in 8-space, you're just
> expressing
> it with regard to different bases.
>
>
> > Assuming that my pde solver still converges for the new parameters, the
> > overall procedure would be as follows:
> > 1. run dealii program to compute J with old parameters p*
> > 2. compute the new basis (EV_i) and the new parameters P*
> > 3. run dealii program to compute the new J with the new parameters P*
> > 4. compute p* =  (E_1; ... ; E_8)^-1  \times P*
> > Repeat 1-4 for all iterations of the optimsation algorithm
> (Levenberg-Marquardt).
> > Is that correct?
>
> Conceptually, this is correct. In practice, it may not be necessary to
> actually do it that way: All you're looking for is a well-conditioned
> basis.
> You don't need the exact vectors E_i. In some applications you can guess
> such
> vectors (like in the model case I drew up), in others you compute them
> once
> for one case and re-use for other cases where maybe they are not exactly
> the
> eigenvalues of the matrix J^T J. Or you live with the ill-conditionedness.
>
>
> > At the end, the ensuing parameters have to be the same, no matter
> > wheter I use the above scaling or not. The sole difference is that
> > the scaled version improves (amongs others) the condition number of J
> and may
> > lead to
> > a better convergence of the optimsation algorithm, right?
> Yes.
>
> 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 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/1e45e679-0528-d64d-e922-0dc6fdaeb471%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/CAM50jEsShwppMZ6zGjQ-HGrrk5Yt16e3VThi%3DzsEZASP-Lgjsg%40mail.gmail.com.

Re: [deal.II] large condition number after solving linear systems

[Simon Wiesheier]

Thanks for taking the time to come back to this!
I will give it a try to implement your suggested scaling.

" The sum you show is only one vector. You need 8 basis vectors.

Think of it this way: You have 8 parameters, which I'm going to call
a,b,c,d,e,f,g,h. The parameter space is 8-dimensional, and the solution
of the parameter estimation problem is a point in this parameter space
which I'm going to call
   x^*
and you choose to represent this point in 8-space via
   x^* = a^* e_a + b^* e_b + ...
where
   e_a=(1,0,0,0,0,0,0,0)
   e_b=(0,1,0,0,0,0,0,0)
   etc.

But you could have chosen to represent x^* as well via
   x^* = A^* E_1 + B^* E_2 + ...
where
   E_1 = \sqrt{lambda_1} ev_1
   E_2 = \sqrt{lambda_2} ev_2
   etc
(or some such) and then you are seeking the coefficient A,B,C, ... "

This makes sense.
So, given the scaled eigenvectors E_1,...,E_8, how can I find the
coefficients A^*,...,H^* ?
Is it just a matrix multiplication
P* =  (E_1; ... ; E_8) \times p* ,
where P* = (A^*,...,H^*) are the new parameters and p* = (a^*,...,h^*) are
the old parameters?

Assuming that my pde solver still converges for the new parameters, the
overall procedure would be as follows:
1. run dealii program to compute J with old parameters p*
2. compute the new basis (EV_i) and the new parameters P*
3. run dealii program to compute the new J with the new parameters P*
4. compute p* =  (E_1; ... ; E_8)^-1  \times P*
Repeat 1-4 for all iterations of the optimsation algorithm
(Levenberg-Marquardt).
Is that correct?

At the end, the ensuing parameters have to be the same, no matter
wheter I use the above scaling or not. The sole difference is that
the scaled version improves (amongs others) the condition number of J and
may lead to
a better convergence of the optimsation algorithm, right?


Best
Simon



Am Fr., 14. Okt. 2022 um 22:27 Uhr schrieb Wolfgang Bangerth <
bange...@colostate.edu>:

>
> Simon:
>
> > If J has full rank, this means that none of the 8 columns is linearly
> > dependent
> > on another column or, equivalently, no parameter is linearly dependent
> > on another parameter.
>
> Yes.
>
>
> > " You would generally choose the (normalizes) eigenvectors of the J^T J
> > you have as the unit directions and the new set of parameters are then
> > multipliers for these directions. "
> >
> > Is it reasonable to choose \sum_{i=1}^8 ev_i(ev_i are the normalized
> > eigenvectors)
> > as the new set of parameters?
>
> The sum you show is only one vector. You need 8 basis vectors.
>
> Think of it this way: You have 8 parameters, which I'm going to call
> a,b,c,d,e,f,g,h. The parameter space is 8-dimensional, and the solution
> of the parameter estimation problem is a point in this parameter space
> which I'm going to call
>x^*
> and you choose to represent this point in 8-space via
>x^* = a^* e_a + b^* e_b + ...
> where
>e_a=(1,0,0,0,0,0,0,0)
>e_b=(0,1,0,0,0,0,0,0)
>etc.
>
> But you could have chosen to represent x^* as well via
>x^* = A^* E_1 + B^* E_2 + ...
> where
>E_1 = \sqrt{lambda_1} ev_1
>E_2 = \sqrt{lambda_2} ev_2
>etc
> (or some such) and then you are seeking the coefficient A,B,C, ...
>
>
> > " Of course, all of this requires computing the eigenvalues and
> > eigenvectors of the current J^T J once."
> >
> > If I get the gist correctly, I first run my dealii program to compute J
> > like I do it right now,
> > thence compute the eigenvectors, and based on them the new set of
> > parameters.
> > Finally, I run my dealii program again to compute the new J with the new
> > parameters.
> > Correct?
>
> Yes, something like this.
>
>
> > I did not read about such a scaling technique in the context of
> > parameter estimation so far.
> > Do you have any reference where the procedure is described?
>
> Sorry, I don't. But I have a test problem for you: Try to minimize the
> function
>f(x,y) = 1*(x-y)^2 + (x+y)^2
> It has a unique minimum, but the x,y-values along the valley of this
> function are highly correlated and so a steepest descent method will be
> very ill-conditioned. The eigenvectors of the Hessian of this function
> give you the uncorrelated coordinate directions:
>ev_1 = 1/sqrt(2) [1 1]
>ev_2 = 1/sqrt(2) [1 -1]
> If you introduce variables
>A = (x-y)*sqrt(1)
>B = (x+y)*sqrt(1)
> your objective function will become
>f(A,B) = A^2 + B^2
> which is much easier to minimize. Once you have the solution A^*, B^*,
> you can back out to x^*, y^*.
>
> Best
>   W.
> --
> 
> Wolfgang Bangerth  email:

Re: [deal.II] large condition number after solving linear systems

[Simon Wiesheier]

" No, that is definitely not true. The correlations are expressed by the
eigenvectors associated with the eigenvalues. J^T J is symmetric and
positive definite, so all of the eigenvectors are mutually orthogonal.
But they will generally not lie along the coordinate axes, and so
express correlations between the parameters."

I see. My point pertains to the following:
If J has full rank, this means that none of the 8 columns is linearly
dependent
on another column or, equivalently, no parameter is linearly dependent on
another parameter.

" You would generally choose the (normalizes) eigenvectors of the J^T J
you have as the unit directions and the new set of parameters are then
multipliers for these directions. "

Is it reasonable to choose \sum_{i=1}^8 ev_i (ev_i are the normalized
eigenvectors)
as the new set of parameters?

" Of course, all of this requires computing the eigenvalues and
eigenvectors of the current J^T J once. "

If I get the gist correctly, I first run my dealii program to compute J
like I do it right now,
thence compute the eigenvectors, and based on them the new set of
parameters.
Finally, I run my dealii program again to compute the new J with the new
parameters.
Correct?
I did not read about such a scaling technique in the context of parameter
estimation so far.
Do you have any reference where the procedure is described?

I have to check whether the above scaling works for my problem or not:
For instance, if there are three old parameters {0, 20,000, 300,000} and
your proposed method
produces the new set of parameters {5,000, 40,000, 90,000},
it may happen that my pde solver does not converge anymore.
Also, the old ranking (0 < 20,000 < 300,000) has to be retained during
scaling.


Best
Simon

Am Do., 13. Okt. 2022 um 22:03 Uhr schrieb Wolfgang Bangerth <
bange...@colostate.edu>:

> On 10/13/22 11:55, Simon Wiesheier wrote:
> >
> > " and if it is poorly
> > conditioned, you need to choose the 8 parameters differently, for
> > example (i) scaled in a different way, and (ii) as linear combinations
> > of what you use right now. "
> >
> > I double-checked that my J has full rank.
> > If I interpret this correctly, there are no correlation between my
> > parameters
> > and what describe as your point (ii) is not neccessary in my case.
>
> No, that is definitely not true. The correlations are expressed by the
> eigenvectors associated with the eigenvalues. J^T J is symmetric and
> positive definite, so all of the eigenvectors are mutually orthogonal.
> But they will generally not lie along the coordinate axes, and so
> express correlations between the parameters.
>
>
> > I definitely have to scale my paramters somehow.
> > Do you have a recommendation how to scale the parameters?
>
> You would generally choose the (normalizes) eigenvectors of the J^T J
> you have as the unit directions and the new set of parameters are then
> multipliers for these directions. (So far your parameters are
> multipliers for the unit vectors e_i in your 8-dimensional parameter
> space.) The matrix J^T J using this basis for your parameter space will
> then already be diagonal, though still poorly conditioned. But if you
> scale the eigenvectors by something like the square root of the
> eigenvalues, you'll get J^T J to be the identity matrix.
>
> Of course, all of this requires computing the eigenvalues and
> eigenvectors of the current J^T J once.
>
> 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 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/779dc304-26df-1733-83a0-e171ecb524b1%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/CAM50jEtXEgvVHQ%3DuvK7-acYZHAzX2A%2BnkjQedh-E_A9n4WGwsA%40mail.gmail.com.

Re: [deal.II] large condition number after solving linear systems

[Simon Wiesheier]

Thank you for your reply!

" I might be missing something, but how do you define the condition number
of a non-square matrix? "

In the matlab documentation is stated:
cond(J) is the 2-norm condition number for inversion,
equal to the ratio of the largest singular value of J to the smallest.

" The condition number of J is determined by your choice of parameters. If
I understand things right, your J^T J is 8x8,"

Correct, J^T J is 8x8.

" and if it is poorly
conditioned, you need to choose the 8 parameters differently, for
example (i) scaled in a different way, and (ii) as linear combinations
of what you use right now. "

I double-checked that my J has full rank.
If I interpret this correctly, there are no correlation between my
parameters
and what describe as your point (ii) is not neccessary in my case.

I definitely have to scale my paramters somehow.
Do you have a recommendation how to scale the parameters?


Best
Simon


Am Do., 13. Okt. 2022 um 18:38 Uhr schrieb Wolfgang Bangerth <
bange...@colostate.edu>:

> Hi Simon,
>
> > To this end, I am solving n linear systems, where n is the number of
> > parameters:
> > K * sensitivity[i] = rhs[i]i=1,...,n
> > K is the (symmetric) tangent matrix which I already use to solve for the
> > solution of my pde, that is,
> > I just assemble the rhs vectors anew.
> > The result is the Jacobian matrix
> > J = [ sensitivity[1] ;...; sensitivity[n] )
> > which has as many rows as my pde has degrees of freedom.
> > J has dimensions 320x8, that is,
> > my pde has 320 dofs and I want to optimise 8 parameters.
> > The solution of my pde (the dofs) are in the interval [0 to 1] and the
> > parameters are in the interval [0 to 1e5] , i.e., the entries of J are
> > rather small per nature (1e-6 to 1e-10).
> > I evaluated the condition number of J in matlab: cond(J) = 1e13, which
> > is too large given that the optimization algorithm works on J^t*J.
>
> I might be missing something, but how do you define the condition number
> of a non-square matrix?
>
> Separately, though: what is the relationship between the condition
> number of J and solving linear systems with K? If I understand you right...
>
> > Currently, I solve the above n linear systems using the direct solver
> > UMFPACK. I know that there is no such thing like a preconditioner for
> > direct solvers.
> > Thus, I solved the linear systems using the iterative SolverCG with a
> > preconditioner:
> >  const int solver_its = 1000
> >  const double tol_sol = 1e-15
> >  SolverControl solver_control(solver_its, tol_sol);
> >  GrowingVectorMemory > GVM;
> >  SolverCG > solver_CG(solver_control, GVM);
> >  PreconditionSSOR<> preconditioner;
> >  preconditioner.initialize(tangent_matrix, 1.2);
> >  //solve the linear systems...
> > However, the condition number of J is still around 1e13.
>
>
> ...then this is the code you use to solve with K. K being whatever it
> is, the preconditioner you use only affects *how* you solve the linear
> systems with K, but it has no effect on the *solution* of the linear
> systems, and so this piece of code has no influence on J: J is what it
> is, and the condition number of J is what it is independent of the code
> you use to *solve for J*.
>
> > My idea was to push the condition number of J at least some order of
> > magnitudes when applying a preconditioner to my tangent matrix.
> > Is this consideration reasonable?
>
> The condition number of J is determined by your choice of parameters. If
> I understand things right, your J^T J is 8x8, and if it is poorly
> conditioned, you need to choose the 8 parameters differently, for
> example (i) scaled in a different way, and (ii) as linear combinations
> of what you use right now.
>
> 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/5ShTkx3dMCU/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/deali

[deal.II] large condition number after solving linear systems

[Simon]

Dear all,

I am optimising parameters which are part of the pde I am working on.

To this end, I am solving n linear systems, where n is the number of 
parameters:
K * sensitivity[i] = rhs[i]i=1,...,n 
K is the (symmetric) tangent matrix which I already use to solve for the 
solution of my pde, that is, 
I just assemble the rhs vectors anew. 
The result is the Jacobian matrix 
J = [ sensitivity[1] ;...; sensitivity[n] ) 
which has as many rows as my pde has degrees of freedom. 
J has dimensions 320x8, that is, 
my pde has 320 dofs and I want to optimise 8 parameters. 
The solution of my pde (the dofs) are in the interval [0 to 1] and the 
parameters are in the interval [0 to 1e5] , i.e., the entries of J are 
rather small per nature (1e-6 to 1e-10). 
I evaluated the condition number of J in matlab: cond(J) = 1e13, which is 
too large given that the optimization algorithm works on J^t*J. 

Currently, I solve the above n linear systems using the direct solver 
UMFPACK. I know that there is no such thing like a preconditioner for 
direct solvers.
Thus, I solved the linear systems using the iterative SolverCG with a 
preconditioner:
const int solver_its = 1000
const double tol_sol = 1e-15
SolverControl solver_control(solver_its, tol_sol);
GrowingVectorMemory > GVM;
SolverCG > solver_CG(solver_control, GVM);
PreconditionSSOR<> preconditioner;
preconditioner.initialize(tangent_matrix, 1.2);
//solve the linear systems...
However, the condition number of J is still around 1e13. 

My idea was to push the condition number of J at least some order of 
magnitudes when applying a preconditioner to my tangent matrix. 
Is this consideration reasonable?

Best
Simon

-- 
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/96c541fb-c5d2-4f90-8d9b-2a1f603d3430n%40googlegroups.com.

Re: [deal.II] automatic differentiation of pde solution wrt design variables in dealii

[Simon Wiesheier]

My problem is nonlinear but steady-state and I formulated the residual r
associated with the pde as r = r(u(E), E).
After the last Newton-iteration, the residual is nearly 0 and the chain
rule gives
0 = dr/dU * dU/dE + dr/dE
0 = K*dU/dE + dr/dE
dU/dE = -K^-1 * dr/dE (--> evaluate after the last iteration)

In my case, dr/dE is quite simple and I do not need AD to compute it.
My motivation to use AD is to check if the approach
dU/dE = -K^-1 * dr/dE
is correct at all.

But as you said, it is easier to circumvent the differentiation of the
matrix iterative process.
(The SolverCG class, for instance, is not templatized anyway to work with
AD).


Best
Simon


Am Do., 1. Sept. 2022 um 06:36 Uhr schrieb Praveen C :

> It depends on what kind of problem you have, linear or nonlinear,
> steady-state or transient.
>
> For example, in case of a linear BVP you may have
>
>
> A(E) U(E) = b(E)
>
> then
>
> A(E) U’(E) = b’(E) - A’(E) U(E)
>
> Use AD to compute b’(E), A’(E) which involves applying AD to the assemble
> process, that is used in some of the tutorial examples, and solve the
> matrix problem using the same solver you use for the original problem. This
> way you dont have to differentiate the matrix iterative process itself.
>
> Best
> praveen
>
>
> On 01-Sep-2022, at 1:01 AM, Simon  wrote:
>
> Dear all,
>
>
> I want to differentiate my pde solution U with respect to some design
> variables E, that is, computing the Jacobian dU/dE.
> I already implemented the Jacobian analytically, however, I would like to
> double check it using AD.
>
> " (In theory an entire program could be made differentiable. This could be
> useful in, for example, the sensitivity analysis of solutions with respect
> to input parameters. However, to date this has not been tested.)"
>
> I found this information in the AD module.
> Also the relevant tuturials -- step33, step 70, step 71 -- do not cover
> the topic sensitivity analysis, but only AD at cell- and quadrature point
> level.
>
> That said, is it possible (with reasonable efforts) to make the entire
> dealii program AD differentiable, or is it recommendable to use other open
> source tools for that purpose?
> My biggest concern is the solution of the linear system because the solver
> classes require in most cases a Vector and, consequently, the
> dependency u(E) can not be encoded.
>
>
> Best
> Simon
>
> --
> 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/f9f35931-c2b1-4e49-9910-e142b7684804n%40googlegroups.com
> <https://groups.google.com/d/msgid/dealii/f9f35931-c2b1-4e49-9910-e142b7684804n%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/ur_89avE81k/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/B6CA18BA-CC94-4E56-97CD-9DC3ECAA0D68%40gmx.net
> <https://groups.google.com/d/msgid/dealii/B6CA18BA-CC94-4E56-97CD-9DC3ECAA0D68%40gmx.net?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/CAM50jEtWxvYvhrq_GGpOGAPhjMfWcO2_LRVKkms7Bk0s6NOpwg%40mail.gmail.com.

[deal.II] automatic differentiation of pde solution wrt design variables in dealii

[Simon]

Dear all, 


I want to differentiate my pde solution U with respect to some design 
variables E, that is, computing the Jacobian dU/dE. 
I already implemented the Jacobian analytically, however, I would like to 
double check it using AD. 

" (In theory an entire program could be made differentiable. This could be 
useful in, for example, the sensitivity analysis of solutions with respect 
to input parameters. However, to date this has not been tested.)"

I found this information in the AD module. 
Also the relevant tuturials -- step33, step 70, step 71 -- do not cover the 
topic sensitivity analysis, but only AD at cell- and quadrature point 
level. 

That said, is it possible (with reasonable efforts) to make the entire 
dealii program AD differentiable, or is it recommendable to use other open 
source tools for that purpose?
My biggest concern is the solution of the linear system because the solver 
classes require in most cases a Vector and, consequently, the 
dependency u(E) can not be encoded.


Best
Simon

-- 
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/f9f35931-c2b1-4e49-9910-e142b7684804n%40googlegroups.com.

Re: [deal.II] visualizing a finite element field: different piecewise constant values within cells

[Simon Wiesheier]

 "I am pretty sure that is no longer correct. Can you check in step-19 or
one of the other particle programs?"

You are right. In step 19, for instance, also the properties assigned to
the particles are written to a .vtu file.

" In that case, may I
suggest that you create a ParticleHandler with particles located at
quadrature points (for which there is already a generator function)."

I think you are referring to the function
Particles::Generators::quadrature_points(...).
I think there is no version of this function for non-parallel programs,
i.e., where you do not have to pass
const std::vector< std::vector< BoundingBox
<https://www.dealii.org/current/doxygen/deal.II/classBoundingBox.html><
spacedim > > > & ,
is it?

Best
Simon



Am Fr., 26. Aug. 2022 um 14:39 Uhr schrieb Wolfgang Bangerth <
bange...@colostate.edu>:

> On 8/26/22 15:37, Simon Wiesheier wrote:
> >
> > My idea was to actually plot the data at quarters of the elements (this
> > includes the quadrature point, of course, but looks nicer that just a
> > scatter plot -- in my opinion).
> > I have to check how the output looks like when using particles::DataOut
> > class. I just scanned the documentation of that class, which says:
> > 'This class currently only supports witing the particle position and
> > their ID and does not allow to write the properties attached to the
> > particles'.
> >
> > Given that, I can not write the properties (thus the qp values) to
> > file, can I?
>
> I am pretty sure that is no longer correct. Can you check in step-19 or
> one of the other particle programs?
>
> 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 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/bbe96645-c161-8f5d-d872-eeb4d66acc42%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/CAM50jEvN1X_yYbOyRO3z5f4ZBEzcV7KbvrjZdfNEVakFyVJitA%40mail.gmail.com.

Re: [deal.II] visualizing a finite element field: different piecewise constant values within cells

[Simon Wiesheier]

"I *assume* that your goal is to visualize the data at the actual
quadrature points, not on quarters of the elements. In that case, may I
suggest that you create a ParticleHandler with particles located at
quadrature points (for which there is already a generator function).
Each particle would then carry one "property" and you'd just have to
assign that property the value of your solution at that point (or
whatever other quantity you want visualized at this point). The final
step is to use the particles::DataOut class to output the information at
the particle locations."

My idea was to actually plot the data at quarters of the elements (this
includes the quadrature point, of course, but looks nicer that just a
scatter plot -- in my opinion).
I have to check how the output looks like when using particles::DataOut
class. I just scanned the documentation of that class, which says:
'This class currently only supports witing the particle position and their
ID and does not allow to write the properties attached to the particles'.

Given that, I can not write the properties (thus the qp values) to  file,
can I?

Best
Simon

Wolfgang Bangerth  schrieb am Fr., 26. Aug. 2022,
22:09:

> On 8/26/22 10:31, Simon wrote:
> >
> >
> > To this end, I think I need a finite element with piecewise constant
> > shape functions. Each shape function is '1' at one quarter of the
> > reference domain and '0' at the remaining three quarters.
> > Or is there an easier way to do this?
> > If not, I probably would have to write my own finite element class,
> > given that such an element does not exist in dealii?
>
> It is possible to implement such an element, but like Daniel already
> said, it's maybe more work than you want to do.
>
> I *assume* that your goal is to visualize the data at the actual
> quadrature points, not on quarters of the elements. In that case, may I
> suggest that you create a ParticleHandler with particles located at
> quadrature points (for which there is already a generator function).
> Each particle would then carry one "property" and you'd just have to
> assign that property the value of your solution at that point (or
> whatever other quantity you want visualized at this point). The final
> step is to use the particles::DataOut class to output the information at
> the particle locations.
>
> 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 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/2ede856e-6144-caba-4858-7525b03d55cc%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/CAM50jEvi1C3Ykzm2B41zFn76UJ51LmgbSY6xKkwXtQpNHxGSxg%40mail.gmail.com.

[deal.II] visualizing a finite element field: different piecewise constant values within cells

[Simon]

Dear all,


my triangulation is two-dimensional and consists of quadrilaterals, i.e. 
four vertices per cell. Each cell has four quadrature points (qp's).

I visualize the data at the quadrature points (in paraview) by producing a 
discontinuous finite element field which has as many DoFs as my 
triangulation has qp's, that is, the qp values are somehow assigned to the 
nodes. 
In paraview (or other visualization programs) I would like to see four 
piecewice constant "colors" on every element: Sloppy speaking, each cell is 
divided into four subcells, and each of the subcells shows only one color 
which corresponds to the nodal value belonging to that subcell.

To this end, I think I need a finite element with piecewise constant shape 
functions. Each shape function is '1' at one quarter of the reference 
domain and '0' at the remaining three quarters. 
Or is there an easier way to do this?
If not, I probably would have to write my own finite element class, given 
that such an element does not exist in dealii?


Thank you,
Simon

-- 
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/0206f2a1-85cb-4970-9da8-d78de0bf6cc7n%40googlegroups.com.

Re: [deal.II] get the partition of the system matrix A associated with the unconstrained dofs

[Simon Wiesheier]

Thanks for your input.
In the meantime, I replaced the matrix multiplication
res = A^_{-1}*B
by solving 'p' linear systems
A*res[p] = B[p],
where p is the number of columns of the matrix B.

" That's one way to go. FullMatrix::gauss_jordan() also computes the
inverse of a matrix."

As stated, what I tried is to use the operator= according to
LAPACKFullMatrix new_matrix = my_system_matrix .
However, there is an error message
"error: conversion from ‘dealii::SparseMatrix’ to non-scalar type
‘dealii::LAPACKFullMatrix’ requested
   LAPACKFullMatrix new_matrix = tangent_matrix"

How can I fix this?

Best
Simon


Am Mo., 22. Aug. 2022 um 08:45 Uhr schrieb Wolfgang Bangerth <
bange...@colostate.edu>:

> On 8/19/22 13:14, Simon Wiesheier wrote:
> >
> > I also need the system matrix A for a second purpose, namely
> > to compute a matrix multiplication:
> > res = A^{-1} * B ,
> > where B is another matrix.
> > -To be more precise, I need the inverse of the 19x19 submatrix
> > corresponding to the unconstrained DoFs only -- not the inverse of the
> > full system matrix..
>
> Right. But the inverse of the 19x19 matrix is the 19x19 subblock of the
> 20x20 big matrix. That's because after zeroing out the row and column,
> you have a block diagonal matrix where the inverse of the matrix
> consists of the inverses of the individual blocks.
>
> > I could not find a function which computes the inverse of a sparse
> > matrix directly (without solving a linear system).
> > What I tried is,
> > LAPACKFullMatrix new_matrix = my_system_matrix ,
> > thence calling the invert function.
> > But I am not sure if this is the right way to go.
>
> That's one way to go. FullMatrix::gauss_jordan() also computes the
> inverse of a matrix.
>
>
> > -Also, after calling constraints.distribute_local_to_global(),
> > does it make sense at all to compute an inverse matrix, given that some
> > rows and columns were set to zero?
>
> Yes -- as mentioned above, you should consider the resulting matrix as
> block diagonal.
>
> 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/4Swu5xeNU3U/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/593cd135-fa19-1572-23a9-53bcfb34aad9%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/CAM50jEtTnxmS5Wwnr9QMcL95uEx%2BJqQmbRuXFyLYb5bQrrZh2Q%40mail.gmail.com.

Re: [deal.II] get the partition of the system matrix A associated with the unconstrained dofs

[Simon Wiesheier]

" When you solve a new linear system with
the matrix, that linear system knows nothing about what happened when you
first built the matrix and the original right hand side."

Yes, but I have to call constraints.distribute_local_to_global (...)
also when building the new linear system. But I observed that there is also
a constraints.distribute_local_to_global () function which writes only into
the global matrix.

I also need the system matrix A for a second purpose, namely
to compute a matrix multiplication:
res = A^{-1} * B ,
where B is another matrix.
-To be more precise, I need the inverse of the 19x19 submatrix
corresponding to the unconstrained DoFs only -- not the inverse of the full
system matrix..
I could not find a function which computes the inverse of a sparse matrix
directly (without solving a linear system).
What I tried is,
LAPACKFullMatrix new_matrix = my_system_matrix ,
thence calling the invert function.
But I am not sure if this is the right way to go.
-Also, after calling constraints.distribute_local_to_global(),
does it make sense at all to compute an inverse matrix, given that some
rows and columns were set to zero?

Thank you again!

Best
Simon



Am Fr., 19. Aug. 2022 um 09:59 Uhr schrieb Wolfgang Bangerth <
bange...@colostate.edu>:

> On 8/19/22 05:46, Simon Wiesheier wrote:
> >
> > This system boilds down to a 2x2 system for x1 and x2 with x0=0.
> > This is exactly what I want to compute, but without having -c*K10
> substracted.
> > (Because the new rhs comes from a different problem and has nothing to
> do with
> > the constrainted dofs - I just need the 2x2 portion from the original
> problem)
>
> Right. But c*K10 is subtracted from the right hand side when you call
>constraints.distribute_local_to_global (...)
> It is not magically stored somewhere. When you solve a new linear system
> with
> the matrix, that linear system knows nothing about what happened when you
> first built the matrix and the original right hand side.
>
> 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 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/66de0c9f-8dce-48a3-a7fb-6a047bc4f1c7%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/CAM50jEspLNDrgcjfZwyKPUmMq8YWi4oZyxvQJHPjw%2BRQ4rSxxg%40mail.gmail.com.

Re: [deal.II] get the partition of the system matrix A associated with the unconstrained dofs

[Simon Wiesheier]

" But the easier approach may be to use the same 20x20 matrix and just copy
the
new rhs you want to solve with into a vector with size 20, leaving the
entries
of the rhs vector that correspond to constrained DoFs zero (or, in fact,
whatever you want -- the value there doesn't matter). By zeroing out rows
and
columns, you are in essence solving a linear system with only the 19x19
matrix. You then copy the 19 DoFs you care about out of the solution vector
into an output vector."

I will assemble the new rhs as vector with size 20.
If the values of the new rhs correspondong to constrained DoFs are
irrlevant,
I do not have to modify the new rhs as well as the 20x20 system matrix at
all.

But let me make a short example with the following linear 3x3 linear system
A*x = b:

A =
[K00   K01 0  ;
 K10   K11   K12;
   0 K21   K22;]

x=[x0; x1; x2]
b=[b1, b2; b3]

Say x0=c=const.

The linear system looks like this after the assembly routine:

A =
[K00 00  ;
   0 K11   K12;
   0 K21   K22;]

x=[0 ; x1; x2]
b=[0 ; b2-c*K10; b3]

This system boilds down to a 2x2 system for x1 and x2 with x0=0.
This is exactly what I want to compute, but without having -c*K10
substracted.
(Because the new rhs comes from a different problem and has nothing to do
with the constrainted dofs - I just need the 2x2 portion from the original
problem)

Currently I only deal with homogeneous constraints (x0=0).
In this case constraints.distribute(...) does not change the unconstrained
entries of the rhs, right?

But I will also have to deal with inhomogeneous constraints, in which case
it makes a difference.
That said, is there a way to leave the components of the rhs corresponding
to unconstrained DoFs unchanged?

Best
Simon

Am Fr., 19. Aug. 2022 um 01:41 Uhr schrieb Wolfgang Bangerth <
bange...@colostate.edu>:

> On 8/18/22 10:38, Simon wrote:
> > Say, I have in total 20 dofs and the dof with global dof index Zero is
> > constrained.
> > As a consequence, the first component of the rhs b is set to Zero as
> well as
> > the first row and column of the system matrix A (except the diagonal
> value).
> > In a postprecessing step, I have to solve another linear system,
> however, with
> > the system matrix being only the 19x19 matrix associated with the 19
> > unconstrained dofs; I do not need the rhs anymore.
> >
> > Is there a way to get this portion of the system matrix based on the
> existing
> > system matrix (sparsity pattern)?
>
> Both the sparsity pattern and the sparse matrix have iterators that allow
> you
> to iterate over all entries of a matrix. You can do that and just filter
> out
> those rows and columns you're not interested in, and then copy the rest
> into
> output objects with translated indices.
>
> But the easier approach may be to use the same 20x20 matrix and just copy
> the
> new rhs you want to solve with into a vector with size 20, leaving the
> entries
> of the rhs vector that correspond to constrained DoFs zero (or, in fact,
> whatever you want -- the value there doesn't matter). By zeroing out rows
> and
> columns, you are in essence solving a linear system with only the 19x19
> matrix. You then copy the 19 DoFs you care about out of the solution
> vector
> into an output vector.
>
> 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 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/17c15884-e251-1c38-f563-16bec6ad37a7%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/CAM50jEuP777mMbgKsxwU%3DsJhMzAMYm2vYzUNPY1JzMV69U1FQw%40mail.gmail.com.

[deal.II] get the partition of the system matrix A associated with the unconstrained dofs

[Simon]

Dear all,


some degrees of freedom of my solution vector are constrained. 
When solsing the linear system A*x=b, I use the first approach as described 
in "Constraints on degrees of freedom". 
That is, I call
constraints.distribute_local_to_global(...,false)
and, after solving the linear system,
constraints.distribute(...). 

My question pertains to the following:
Say, I have in total 20 dofs and the dof with global dof index Zero is 
constrained. 
As a consequence, the first component of the rhs b is set to Zero as well as
the first row and column of the system matrix A (except the diagonal 
value). 
In a postprecessing step, I have to solve another linear system, however, 
with the system matrix being only the 19x19 matrix associated with the 19 
unconstrained dofs; I do not need the rhs anymore.

Is there a way to get this portion of the system matrix based on the 
existing system matrix (sparsity pattern)?


Thank you,
Simon

-- 
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/219e5a2e-06f3-400e-a3db-6e022020587an%40googlegroups.com.

Re: [deal.II] interface between dealii and matlab for data transfer (using mex files?)

[Simon Wiesheier]

Hi Andreas, Hi Simon,

your approaches work for me.
Thank you for pointing out!

Best regards
Simon

Am Di., 16. Aug. 2022 um 11:10 Uhr schrieb 'Andreas Hegendörfer' via
deal.II User Group :

> Hi Simon,
> maybe you can solve your problem with Matlab's C++ interface (
> https://de.mathworks.com/help/matlab/matlab_external/call-matlab-functions-from-c-1.html
> ).
> The interface allows you to access Matlab's command line via C++ code,
> and, thus, you can use the full capabilities of Matlab within your C++
> code.
>
> You could do the following:
>
> call function res = fun(p,y) in C++
> transfer vector p from matlab to C++
> run deal.ii calculation in C++
> res = s - y;
> end
>
> BR Andreas
>
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>  Virenfrei.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> <#m_4874777905485958703_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> Am Mo., 15. Aug. 2022 um 02:22 Uhr schrieb Simon <
> simon.wieshe...@gmail.com>:
>
>> Dear all,
>>
>> my question is specific and regards the data transfer between Matlab and
>> a dealii program. In a nutshell, I have to call my dealii program from
>> Matlab with a Matlab vector as argument (my dealii program needs the values
>> in the vector). I figured out that Mex files are one way to transfer data
>> to a c++ program.
>>
>>
>> Here is a snippet of my Matlab script:
>>
>> function res = fun(p,y)
>> s = call_my_dealii_program_passing_the_vector_p
>> res = s - y;
>> end
>>
>> My issue is *how to pass the vector 'p' to the dealii program*.
>>
>> There are MEX files which provide an interface between Matlab and C++
>> programs. A standard MEX file looks like this:
>>
>> //file mymex.cpp
>> #include "mex.h"
>> //include some more header files from c++ or dealii
>> //write here the whole class definition and implemenation
>>
>> void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray
>> *prhs[])
>> {
>> //this is the interface function to Matlab where also 'p' is passed
>> //in here, I will also create the instance of my dealii program to run
>> the typical member //functions ike make_grid(), system_setup(),...
>> }
>>
>> The above mex file is compiled within the Matlab gui using a c++ compiler
>> (mex mymex.cpp).
>>
>> If I do not include any dealii headers in  mymex.cpp , the compilation
>> works.
>> However, including dealii headers results in a bunch of error messages
>> when I compile the program in Matlab (mex mymex.cpp), because environment
>> variables are not known to Matlab,...
>> Usually, I just call 'spack load dealii' followed by 'make run' to run my
>> dealii programs, but I do not know how to 'forward' all this information to
>> the Matlab compilation process.
>>
>> All that said, has someone already worked with Mex files together with
>> dealii?
>>
>> I also appreciate other approaches to manage the data transfer between
>> Matlab and dealii.
>>
>>
>> Best
>> Simon
>>
>> --
>> 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/b047d35d-b3e3-465b-88d8-c708343086bfn%40googlegroups.com
>> <https://groups.google.com/d/msgid/dealii/b047d35d-b3e3-465b-88d8-c708343086bfn%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/CAF_nQ7DepQDY1AjpP81K1Dza73-fTmNnpCyum6SqhvJPMR3CKw%40mail.gmail.com
> <https://groups.google.com/d/msgid/dealii/CAF_nQ7DepQDY1AjpP81K1Dza73-fTmNnpCyum6SqhvJPMR3CKw%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/CAM50jEuY-pOJhfbwNOG5cRSPdKbeOhGX8oajaW%3DNTk9hFByrGQ%40mail.gmail.com.

Re: [deal.II] Re: interface between dealii and matlab for data transfer (using mex files?)

[Simon Sticko]

Hi,

I have done the mex-coupling with dealii before. As Bruno said, it is easiest 
to mex with cmake. Example in attached zip. Hope it helps.


Best,
Simon Sticko

On 15/08/2022 15:05, Bruno Turcksin wrote:

Simon

Le lun. 15 août 2022 à 08:52, Simon Wiesheier mailto:simon.wieshe...@gmail.com>> a écrit :


I also thought about transferring the data by reading from/writing to a 
file.
But I was looking for a more general approach without having to create 
files.

Writing files is no less general than coupling directly Matlab and deal.II The 
main advantage of coupling the two codes directly is that it is faster but it 
should only matter if you have to transfer a very large amount of data or if 
you do it very often.

I was also pondering if it is possible to compile the mex file like a 
normal dealii program (by adding a few Matlab macros to the files generated by 
cmake).
But I can not say how much is involved to do this due to my modest 
knowledge about cmake.
If it were possible and someone wanted to guide me through that process, I 
would be willed to try that out; otherwise I go with the easier approach and 
work with files.

The way you probably want to do that is to start from a CMakeLists.txt similar to the one that 
you are using to compile your deal.II code and use 
https://cmake.org/cmake/help/latest/module/FindMatlab.html 
<https://cmake.org/cmake/help/latest/module/FindMatlab.html> to compile the mex file. I 
have never done it so I don't know if it "just works" or if it is more involved.

Best,

Bruno

--
The deal.II project is located at http://www.dealii.org/ 
<http://www.dealii.org/>
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en 
<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 
<mailto:dealii+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/CAGVt9eMM_kwCXbSHZONL2p8icdeiwDF%3DQrvQ-qbyQFYxqEPL4g%40mail.gmail.com
 
<https://groups.google.com/d/msgid/dealii/CAGVt9eMM_kwCXbSHZONL2p8icdeiwDF%3DQrvQ-qbyQFYxqEPL4g%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/ad0f6fad-39f8-db0d-d5f2-bd849504dcbb%40gmail.com.
<>

Re: [deal.II] Re: interface between dealii and matlab for data transfer (using mex files?)

[Simon Wiesheier]

Dear Bruno,


I also thought about transferring the data by reading from/writing to a
file.
But I was looking for a more general approach without having to create
files.

I was also pondering if it is possible to compile the mex file like a
normal dealii program (by adding a few Matlab macros to the files generated
by cmake).
But I can not say how much is involved to do this due to my modest
knowledge about cmake.
If it were possible and someone wanted to guide me through that process, I
would be willed to try that out; otherwise I go with the easier approach
and work with files.


Best
Simon

Bruno Turcksin  schrieb am Mo., 15. Aug. 2022,
14:24:

> Simon,
>
> You could just write/read files to transfer the data and you can launch
> your deal.II code from Matlab using
> https://www.mathworks.com/help/matlab/ref/system.html This way Matlab
> does not need to know anything about deal.II. You just write and read
> files, and you execute a bash command.
>
> Best,
>
> Bruno
>
> On Sunday, August 14, 2022 at 8:22:30 PM UTC-4 Simon wrote:
>
>> Dear all,
>>
>> my question is specific and regards the data transfer between Matlab and
>> a dealii program. In a nutshell, I have to call my dealii program from
>> Matlab with a Matlab vector as argument (my dealii program needs the values
>> in the vector). I figured out that Mex files are one way to transfer data
>> to a c++ program.
>>
>>
>> Here is a snippet of my Matlab script:
>>
>> function res = fun(p,y)
>> s = call_my_dealii_program_passing_the_vector_p
>> res = s - y;
>> end
>>
>> My issue is *how to pass the vector 'p' to the dealii program*.
>>
>> There are MEX files which provide an interface between Matlab and C++
>> programs. A standard MEX file looks like this:
>>
>> //file mymex.cpp
>> #include "mex.h"
>> //include some more header files from c++ or dealii
>> //write here the whole class definition and implemenation
>>
>> void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray
>> *prhs[])
>> {
>> //this is the interface function to Matlab where also 'p' is passed
>> //in here, I will also create the instance of my dealii program to run
>> the typical member //functions ike make_grid(), system_setup(),...
>> }
>>
>> The above mex file is compiled within the Matlab gui using a c++ compiler
>> (mex mymex.cpp).
>>
>> If I do not include any dealii headers in  mymex.cpp , the compilation
>> works.
>> However, including dealii headers results in a bunch of error messages
>> when I compile the program in Matlab (mex mymex.cpp), because environment
>> variables are not known to Matlab,...
>> Usually, I just call 'spack load dealii' followed by 'make run' to run my
>> dealii programs, but I do not know how to 'forward' all this information to
>> the Matlab compilation process.
>>
>> All that said, has someone already worked with Mex files together with
>> dealii?
>>
>> I also appreciate other approaches to manage the data transfer between
>> Matlab and dealii.
>>
>>
>> Best
>> Simon
>>
> --
> 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/beTOBvu5ko4/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/f7904da5-4e91-408a-a8c3-c512db95cb8dn%40googlegroups.com
> <https://groups.google.com/d/msgid/dealii/f7904da5-4e91-408a-a8c3-c512db95cb8dn%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/CAM50jEvsU1i7aa_9M%2B9Mqtp3z9Ztdx%3D7%3DeL3twodN8-mdZL_EA%40mail.gmail.com.

[deal.II] interface between dealii and matlab for data transfer (using mex files?)

[Simon]

Dear all,

my question is specific and regards the data transfer between Matlab and a 
dealii program. In a nutshell, I have to call my dealii program from Matlab 
with a Matlab vector as argument (my dealii program needs the values in the 
vector). I figured out that Mex files are one way to transfer data to a c++ 
program.


Here is a snippet of my Matlab script:

function res = fun(p,y)
s = call_my_dealii_program_passing_the_vector_p
res = s - y;
end

My issue is *how to pass the vector 'p' to the dealii program*.

There are MEX files which provide an interface between Matlab and C++ 
programs. A standard MEX file looks like this:

//file mymex.cpp
#include "mex.h"
//include some more header files from c++ or dealii
//write here the whole class definition and implemenation

void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
{
//this is the interface function to Matlab where also 'p' is passed
//in here, I will also create the instance of my dealii program to run the 
typical member //functions ike make_grid(), system_setup(),...
}

The above mex file is compiled within the Matlab gui using a c++ compiler 
(mex mymex.cpp). 

If I do not include any dealii headers in  mymex.cpp , the compilation 
works. 
However, including dealii headers results in a bunch of error messages when 
I compile the program in Matlab (mex mymex.cpp), because environment 
variables are not known to Matlab,...
Usually, I just call 'spack load dealii' followed by 'make run' to run my 
dealii programs, but I do not know how to 'forward' all this information to 
the Matlab compilation process.

All that said, has someone already worked with Mex files together with 
dealii?

I also appreciate other approaches to manage the data transfer between 
Matlab and dealii. 


Best
Simon

-- 
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/b047d35d-b3e3-465b-88d8-c708343086bfn%40googlegroups.com.

Re: [deal.II] FEInterfaceValues and hp::FECollection

[Simon Sticko]

Hi,

Unfortunately no-one has implemented FEInterfaceValues for hp yet (I think it 
would be great if someone did). The only workaround I know is to NOT use 
FEInterfaceValues and instead:

1. Use 2 hp::FEFaceValues objects, one initialized with cell 0 and one 
initialized with cell 1.

2. Split the jump term in 4 terms: [u][v] = u_0*v_0 - u0*v_1 - u_1*v_0 + u_1*v_1

3. Assemble each term in a separate local matrix (A_00, A_01, A_10, A_11), where

   A_01 - Rows correspond to local dofs on cell 0, columns to local dofs on 
cell 1.

4. Use global_dof_indices of cell 0 and cell 1 to map each local matrix to the 
global matrix.

Best,
Simon



On 09/08/2022 00:58, Marco Feder wrote:

Dear all,

I'm using an hp::FECollection object to describe different FE spaces in my 
grid. In particular, I'm in the following scenario:

x- - - - - -x
|             |
|     0      |
|             |
x - - F - -x
|             |
|     1      |
|             |
x- - - - - -x

On cell number 0 I have a FESystem with FE_Q(1) and FE_Q(1), which corresponds 
to fe_collection[0].
On cell number 1, I have again a FESystem with FE_Q(1) and FE_Nothing, 
corresponding to fe_collection[1].

I need to compute the jump [d_n u_h]_F, being F the face shared by the two 
cells. Unfortunately, I can't find a proper way to initialize FEInterfaceValues 
so that it understands that I need the jump of the first components only. 
Indeed, if I use fe_collection[0] (or fe_collection[1]) as first argument in 
the constructor, I have a runtime error in reinit(cell) saying (as expected):

/    The FiniteElement you provided to FEValues and the FiniteElement that
     belongs to the DoFHandler that provided the cell iterator do not
     match./
/
/
since we have different spaces on cell0 and cell1. Is there a possible 
workaround to this?

Best,
Marco

--
The deal.II project is located at http://www.dealii.org/ 
<http://www.dealii.org/>
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en 
<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 
<mailto:dealii+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/2d71b802-132c-4f8a-a20d-03542939036an%40googlegroups.com
 
<https://groups.google.com/d/msgid/dealii/2d71b802-132c-4f8a-a20d-03542939036an%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/23e81ebd-cf4e-60ad-ea66-ad825581b533%40gmail.com.

Re: [deal.II] fourth-order referential deviatoric tensor Dev_P: why is 'S' used in the definition?

[Simon Wiesheier]

[image: grafik.png]
[image: grafik.png]
The only place I use Dev_P is to compute the above double contractions ('P'
in the above is what dealii returns as Dev_P)
As you can see, the fourth order tangent C_bar consists of outer products
of second order symmetric tensors:
boldsymbol 'I' is the second order unit tensor, C_bar is a symmetric second
order tensor, and blackboard 'I' is the general fourth order unit tensor,
the deltas are just scalars.

In my opinion, the double contractions 'P : outer_product(C_bar, C_bar)'
and 'P : I' produce different results if the fourth order symmetric unit
tensor 'S' is used to define 'P' .
The same holds also for doing the double contractions with P_T.
Correct?

Best
Simon

Am Mo., 8. Aug. 2022 um 12:54 Uhr schrieb Wolfgang Bangerth <
bange...@colostate.edu>:

> On 8/7/22 06:00, Simon wrote:
> >
> > the fourth-order referential deviatoric tensor as returned by
> > Physics::Elasticity::StandardTensors
> > <
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.dealii.org%2Fcurrent%2Fdoxygen%2Fdeal.II%2FclassPhysics_1_1Elasticity_1_1StandardTensors.html&data=05%7C01%7CWolfgang.Bangerth%40colostate.edu%7Cc7d0b41aa97a4f5bbf6a08da786c79b6%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637954704552090273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=u9Z1RfLeZdT2vdeD7%2BNYIXWA8h%2Bkvtdre4KIewAI0ws%3D&reserved=0><
>
> > dim >::Dev_P
> > includes the fourth-order referential/spatial unit *symmetric* tensor
> > Physics::Elasticity::StandardTensors
> > <
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.dealii.org%2Fcurrent%2Fdoxygen%2Fdeal.II%2FclassPhysics_1_1Elasticity_1_1StandardTensors.html&data=05%7C01%7CWolfgang.Bangerth%40colostate.edu%7Cc7d0b41aa97a4f5bbf6a08da786c79b6%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637954704552090273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=u9Z1RfLeZdT2vdeD7%2BNYIXWA8h%2Bkvtdre4KIewAI0ws%3D&reserved=0><
>
> > dim >::S = identity_tensor
> > <
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.dealii.org%2Fcurrent%2Fdoxygen%2Fdeal.II%2Fsymmetric__tensor_8h.html%23ab3e890348aa219805e84f7d367e098c3&data=05%7C01%7CWolfgang.Bangerth%40colostate.edu%7Cc7d0b41aa97a4f5bbf6a08da786c79b6%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637954704552090273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3bQQR2Em7YyxuQuohp19IsBWntxKehAhRzin%2F0GFlBs%3D&reserved=0
> >().
> >
> > In the literature, for instance G. A. Holzapfel: "Nonlinear solid
> mechanics. A
> > Continuum Approach for Engineering" (2007),
> > however, the general fourth-order unit tensor
> > I_{ijkl} = delta_{ik} delta_{jl} is used to compute Dev_P.
> >
> > I implemented a hyperelastic material model with a volumetric /
> isochoric
> > split of the strain energy function and it only converges when using 'S'
> - as
> > dealii does it. Using the  general fourth-order unit tensor to define
> Dev_P,
> > my solver does not converge at all.
> >
> > Is it neccessary to use 'S' due to the way dealii stores and accesses
> the
> > elements of symmetric tensors?
>
> The question is what you apply I or S to. If you apply them to symmetric
> rank-2 tensors, then they are the same. If you apply them to non-symmetric
> tensors, then they are not.
>
> 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/tHMjlrUqMYI/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/9c3d5b70-7fe0-9684-0f7e-c608baf72c50%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/CAM50jEvvyDyDO3aQepDSgkNdgm1qfH7xYgRJx1qJZmU4298CUQ%40mail.gmail.com.

[deal.II] fourth-order referential deviatoric tensor Dev_P: why is 'S' used in the definition?

[Simon]

Dear all,


the fourth-order referential deviatoric tensor as returned by 
Physics::Elasticity::StandardTensors 
<https://www.dealii.org/current/doxygen/deal.II/classPhysics_1_1Elasticity_1_1StandardTensors.html><
 
dim >::Dev_P 
includes the fourth-order referential/spatial unit *symmetric* tensor 
Physics::Elasticity::StandardTensors 
<https://www.dealii.org/current/doxygen/deal.II/classPhysics_1_1Elasticity_1_1StandardTensors.html><
 
dim >::S = identity_tensor 
<https://www.dealii.org/current/doxygen/deal.II/symmetric__tensor_8h.html#ab3e890348aa219805e84f7d367e098c3>
().

In the literature, for instance G. A. Holzapfel: "Nonlinear solid 
mechanics. A Continuum Approach for Engineering" (2007), 
however, the general fourth-order unit tensor 
I_{ijkl} = delta_{ik} delta_{jl} is used to compute Dev_P. 

I implemented a hyperelastic material model with a volumetric / isochoric 
split of the strain energy function and it only converges when using 'S' - 
as dealii does it. Using the  general fourth-order unit tensor to define 
Dev_P,  my solver does not converge at all.  

Is it neccessary to use 'S' due to the way dealii stores and accesses the 
elements of symmetric tensors? 


Best
Simon


-- 
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/cc73ad68-f056-421d-b717-1bfcf1be9d4cn%40googlegroups.com.

Re: [deal.II] automatic differentiation:

[Simon Wiesheier]

Hi Jean-Paul,

thanks for pointing that out.

However, I believe there has been a misunderstanding:
I am working here with a FE discretized energy on a seperate triangulation,
say, 'triangulation_energy', with the coordinates being the first and third
invariant of 'C'; The corresponding nodal energy values are stored in the
vector 'solution_energy' and are computed once based on a analytical energy
function.
So for each quadrature point in my geometry (first triangulation) I am
computing 'C=F^T*F', thence the first and third invariant of 'C' and store
them in a Point<2> object denoted as 'invariant_point'.
Then, I employ
'GridTools::find_active_cell_around_point(triangulation_energy,
invariant_point)' to finally create a second FEValues object with the only
purpose to compute the gradient of the energy ('solution_energy') at
'invariant_point'.
'get_function_gradients(solution_energy, grad_energy_at_ref_point ) gives
me the gradient of 'solution_energy' with respect to the first and third
invariant of 'C' because the real coordinates on the associated
triangulation are the first and third invariant of 'C'.
Now, I have all the quantities to compute the stress tensor as
S_ad = 2*(grad_energy_at_ref_point[0][0]*invariant1_wrt_C_ad
+
grad_energy_at_ref_point[0][1]*invariant3_wrt_C_ad);

My goal is to compute the 4th order tangent \frac{\partial S_ad}{\partial
C_ad}.

All that said, is it not correct to start like this?:
SymmetricTensor<2,dim> C = symmetrize(F^t *F);
ad_helper.register_independent_variable(C, C_dofs);
const SymmetricTensor<2, dim, ADNumberType> C_ad =
ad_helper.get_sensitive_variables(C_dofs);

Best,
Simon



Am Mo., 18. Juli 2022 um 22:46 Uhr schrieb Jean-Paul Pelteret <
jppelte...@gmail.com>:

> Hi Simon,
>
> Unfortunately I don’t have the time at this moment to give you a full
> explanation as to why the logic of your code is wrong, but in essence you
> have the sequence of operations inverted. You need to compute your energy
> based on the “sensitive” DoF values that would come from the reinit’d
> FEValues operation. You cannot compute something like C_ad ahead of time,
> like it appears that you have.
>
> Take a look at these lines in the (unfinished) tutorial that will
> illustrate the steps required to linearise an energy functional. This
> should hopefully help steer you in the right direction.
>
> https://github.com/dealii/dealii/pull/10394/files#diff-fc8b83d1370bfd7eb558ea76175bfc0e8d6305023d54b17ec9cccb0fba9b1e02R1758-R1831
>
> Best,
> Jean-Paul
>
> On 18. Jul 2022, at 19:46, Simon  wrote:
>
> Dear all,
>
> I want to retrieve a tangent at quadrature point level using AD - attached
> is a snippet of my code:
>
> The computation of the dependent variable 'S_ad' in line 36 involves the
> call
> get_function_gradients (solution_energy, grad_energy_at_ref_point),
> see line 35.
> 'solution_energy' is a scalar function which depends on the independent
> variable 'C_ad' as can be seen in the derivations from line 8 on.
> My issue is that I see no way to pass the NumberTypes type
> (=Differentiation::AD::NumberTypes::sacado_dfad_dfad) to the corrosponding
> FEValues object, and, as a consequence, the AD framework is not aware that
> 'solution_energy' is a function of 'C_ad'.
> In particular, 'grad_energy_at_ref_point' will be treated as a constant
> with respect to 'C_ad' in line 36f.
>
> How can I incorporate this dependency in the AD framework?
>
> Thank you,
> Simon
>
> --
> 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/990f7f7f-37a2-4f9d-b6c2-bbf7dda21e8dn%40googlegroups.com
> <https://groups.google.com/d/msgid/dealii/990f7f7f-37a2-4f9d-b6c2-bbf7dda21e8dn%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

Re: [deal.II] shape function gradient at arbitrary points in the element

[Simon Wiesheier]

Just to make sure that I chose a reasonable approach:

//create FEValues object whenever I need it, that is,
'number_of_cells*number_of_qps_per_cell' times
FEValues<2> fe_values(dof_handler.get_fe(),

Quadrature<2>(my_point_in_ref_coords),
   update_gradients);
fe_values.reinit(cell);

//evaluate, say, the gradient of the second shape function in real coords
at "my_point_in_ref_coords"
Tensor<1,2> shape_gradient_real_second = fe_values.shape_grad(1, 0);

Without measuring the time but based on your intuition - the approach using
FEPointEvaluation would not be much faster, would it?

Best
Simon



Am Do., 7. Juli 2022 um 03:45 Uhr schrieb Wolfgang Bangerth <
bange...@colostate.edu>:

> On 7/5/22 09:28, Simon Wiesheier wrote:
> >
> > What is the approach to achieve this?
> > My only idea is to create a new FEValues object for each quadrature
> point and
> > pass an appropriate Quadrature object. But seems to be very inefficient.
>
> This is basically what the VectorTools::point_value() and
> VectorTools::point_gradient() functions do. You might want to read through
> their implementations to see how this is done.
>
> The only other approach is with classes like FEPointEvaluation. If you
> read
> through their implementation, you might be able to understand how they can
> also be used to evaluate just a single shape function. In the end, the
> values
> and gradients of a single shape function correspond to the values and
> gradients of a finite element field that corresponds to a solution vector
> with
> one 1.0 and the rest of the elements set to zero.
>
> 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 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/6527dccb-aebc-f424-5217-1c19a9b8b3c2%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/CAM50jEsJh_oDF%3DzZFvnq69rVbcn5GQmBvji8u2oLyeU8SbfK6A%40mail.gmail.com.

Re: [deal.II] discretization of a analytical function on a second triangulation

[Simon Wiesheier]

Dear Daniel,


yes, I defined a class derived from deal::Function and it seems to work for
me.

Basically, my motivation to call VectorTools::interpolate is to compute the
nodal values (scalar field --> DOFs) in the triangulation based on the
formula implemented in the just derived class.
During the assembly routine, I access some interpolated values at
quadrature points,...

With this in mind, is this an appropriate way?


Best
Simon

Am Di., 5. Juli 2022 um 09:16 Uhr schrieb Daniel Arndt <
d.arndt.m...@gmail.com>:

> Simon,
>
> defining a class derived from dealii::Function sounds sensible.
> Whether calling VectorTools::interpolate makes sense, depends on what you
> want to do with the interpolated function. In may cases, it's enough to
> just evaluate it locally during assembly using functionality like
> FEValues::get_function_values.
>
> Best,
> Daniel
>
> On Mon, Jul 4, 2022 at 10:26 AM Simon  wrote:
>
>> Dear all:
>>
>>
>> I am solving a nonlinear PDE on a Triangulation T_1.
>>
>> I know the analytical representation of a scalar function of two
>> variables (no space co-ordinates, but two invariants of a quantity)
>> and my goal is to find a discretized version of the analytical function
>> (on a second, two-dimensional triangulation T_2).
>> The nodal values of T_2 should be the exact values corresponding to the
>> analytical solution.
>> As for the values between the nodes, I want to start with a bilinear
>> interpolation.
>>
>> The coupling to my original PDE works as follows:
>> For each quadrature point defined on T_1, I compute the two input
>> variables of the above function based on my solution vector, find the
>> corresponding cell of T_2 and want to retrieve the interpolated nodal
>> values.
>>
>> My idea is to use the function
>> VectorTools::interpolate ,
>> but I do not know a suitable Function object to hand over.
>>
>> Is this an appropriate approach at all?
>>
>>
>> Thank you,
>> Simon
>>
>> --
>> 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/14b1d8f6-f902-4414-a5c6-348ae3f5003en%40googlegroups.com
>> <https://groups.google.com/d/msgid/dealii/14b1d8f6-f902-4414-a5c6-348ae3f5003en%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/CAOYDWbKNTV%3D8Bipyq_gzbMoLvxdvv-%2BmHLipn27DbOcK-eWL_A%40mail.gmail.com
> <https://groups.google.com/d/msgid/dealii/CAOYDWbKNTV%3D8Bipyq_gzbMoLvxdvv-%2BmHLipn27DbOcK-eWL_A%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/CAM50jEsXcMsvZzq0-EFgQwWn%3Dr%3D6yBw8yVrMnQ5met_LK0zHew%40mail.gmail.com.

Re: [deal.II] shape function gradient at arbitrary points in the element

[Simon Wiesheier]

Dear Martin,

thanks for pointing out to the FEPointEvaluation class.
However, my intent is to compute the gradients of shape functions in real
coordinates.

" so in that case the recommendation would be to use FEValues, despite that
being terribly inefficient."

What is the approach to achieve this?
My only idea is to create a new FEValues object for each quadrature point
and pass an appropriate Quadrature object. But seems to be very inefficient.
Is there an alternative way in combination with FEValues?

Best,
Simon


Am Di., 5. Juli 2022 um 08:16 Uhr schrieb Martin Kronbichler <
kronbichler.mar...@gmail.com>:

> Dear Simon,
>
> We have the class FEPointEvalation,
> https://dealii.org/developer/doxygen/deal.II/classFEPointEvaluation.html
> , which implements the operation of evaluating a solution at arbitrary
> points (as handed in as an array to points in unit coordinates). To do this
> for positions in real coordinates, you typically need to invert the
> mapping, Mapping::transform_real_to_unit_cell or
> Mapping::transform_points_real_to_unit_cell, see
> https://dealii.org/developer/doxygen/deal.II/classMapping.html , always
> assuming that you have located the correct points. Most tasks can be
> reduced to this setup.
>
> If your intent is not just the solution interpolation but the value of
> shape functions, e.g. because you want to assemble a local matrix,
> FEPointEvaluation is not directly providing that info, so in that case the
> recommendation would be to use FEValues, despite that being terribly
> inefficient. We could possibly integrate such functionality into
> FEPointEvaluation if you have interest in that direction, so let us know
> what your needs are.
>
> Best,
> Martin
> On 05.07.22 15:56, Simon wrote:
>
> Dear all:
>
> I have to compute the gradient with respect to real space co-ordinates of
> the shape functions belonging to a FE_Q element at arbitrary points in the
> element, that is, not only at quadrature points.
>
> What is the way to do this in dealii?
> FEValues provides shape function values, gradients,... only at quadrature
> points.
>
> Thank you,
> Simon
> --
> 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/16afc8fa-bcfe-4a81-9ade-040c18f85596n%40googlegroups.com
> <https://groups.google.com/d/msgid/dealii/16afc8fa-bcfe-4a81-9ade-040c18f85596n%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/34843cd0-22a6-d4b5-7cb8-f530715a6108%40gmail.com
> <https://groups.google.com/d/msgid/dealii/34843cd0-22a6-d4b5-7cb8-f530715a6108%40gmail.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/CAM50jEteHa8vhryPshNi4SGP3jhm%3DsEj_A8K6wq1TSX-aamKmQ%40mail.gmail.com.

[deal.II] shape function gradient at arbitrary points in the element

[Simon]

Dear all:

I have to compute the gradient with respect to real space co-ordinates of 
the shape functions belonging to a FE_Q element at arbitrary points in the 
element, that is, not only at quadrature points. 

What is the way to do this in dealii?
FEValues provides shape function values, gradients,... only at quadrature 
points. 

Thank you,
Simon

-- 
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/16afc8fa-bcfe-4a81-9ade-040c18f85596n%40googlegroups.com.

[deal.II] discretization of a analytical function on a second triangulation

[Simon]

Dear all:


I am solving a nonlinear PDE on a Triangulation T_1.

I know the analytical representation of a scalar function of two variables 
(no space co-ordinates, but two invariants of a quantity) 
and my goal is to find a discretized version of the analytical function (on 
a second, two-dimensional triangulation T_2).
The nodal values of T_2 should be the exact values corresponding to the 
analytical solution.
As for the values between the nodes, I want to start with a bilinear 
interpolation.

The coupling to my original PDE works as follows:
For each quadrature point defined on T_1, I compute the two input variables 
of the above function based on my solution vector, find the corresponding 
cell of T_2 and want to retrieve the interpolated nodal values. 

My idea is to use the function
VectorTools::interpolate ,
but I do not know a suitable Function object to hand over. 

Is this an appropriate approach at all?


Thank you,
Simon

-- 
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/14b1d8f6-f902-4414-a5c6-348ae3f5003en%40googlegroups.com.

Re: [deal.II] mesh_generator

[Simon Sticko]

Hi,

Did you call

triangulation.execute_coarsening_and_refinement();

after setting the refinement flag?

Best,
Simon

On 23/06/2022 17:22, LY XXXiao wrote:

Hi there,

Has anyone experienced this issue in mesh refinement:

I have already a basic mesh with 120 cells, and I only want to refine one 
element among them, so I set a refine_flag for this element. But the refinement 
does not happen ?? Is there anything else that I missed? I learned step 1 and 
step 6 for meshing problem.

Best regards,
Longying


--
The deal.II project is located at http://www.dealii.org/ 
<http://www.dealii.org/>
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en 
<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 
<mailto:dealii+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/0cfddd51-4380-4cd3-81af-9259046b2c8en%40googlegroups.com
 
<https://groups.google.com/d/msgid/dealii/0cfddd51-4380-4cd3-81af-9259046b2c8en%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/49efb643-4ca8-f2a6-c9a7-c7c20fa12ee8%40gmail.com.

Re: [deal.II] How to add degrees of freedom to a specified node

[Simon Sticko]

Hi,

Since several XFEM papers formulate this as a Heaviside enrichment around the 
crack, you might find this class useful:

https://www.dealii.org/current/doxygen/deal.II/classFE__Enriched.html

Relating to Wolfgangs answer, note in particular the section "Using enriched and 
non-enriched FEs together".

Best,
Simon


On 18/06/2022 07:43, Wolfgang Bangerth wrote:


Wang Yuan,


  I am using extended finite element method to do crack expansion. I have a 
question, can I increase the degree of freedom for the nodes designated around 
the crack in Deal?


Not easily. deal.II enumerates degrees of freedom based on the finite element 
used on a cell, so if you want to have extra degrees of freedom, you need to 
describe that by using a different element on that cell (using the 
hp-framework, in the same way as step-46 for example).


Meanwhile, another question is can I assign different numbers of Gaussian 
integral points to different elements? Thank you for your help!


Yes! You can use a hp::QCollection together with hp::FEValues. Or you can do it 
by hand: You create multiple quadrature rules and corresponding FEValues 
objects, and then you choose which one is appropriate when you are on a 
concrete cell.

Best
  W.



--
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/56f2ee5e-9bba-fd46-7499-7b925aa3353d%40gmail.com.

Re: [deal.II] Integral over part of domain.

[Simon Sticko]

Hi,

This type of integral can be computed with the tools presented in the Step-85 
tutorial:

https://www.dealii.org/developer/doxygen/deal.II/step_85.html

which you can use if you install the master branch of deal.II (or wait for the 
soon-released 9.4 version).

In particular, take a look at the assemble_system() function in Step-85 and the 
NonMatching::FEValues class:

https://www.dealii.org/developer/doxygen/deal.II/classNonMatching_1_1FEValues.html

Best,
Simon


On 13/06/2022 15:17, Oleg Kmechak wrote:

Hello there,

Facing such a problem.
Want to evaluate integral over circle (see picture below). Integral has such a 
form:
I = Integral[ solution_value(x, y) * my_func(x, y) * dx dy,  over circle].

Currently I am using the simplest way to evaluate such integral - rectangular 
approximation. And most time cost part - is using 
Functions::FEFieldFunction to get solution_value(x, y). Solving FEM is 
faster than evaluation of such integrals.

Also, my_func(x, y) has hidden parameter 'order'. Basically, I am using 
integral to expand field around tip (in the center of circle) into series. And 
also with higher order, accuracy of series parameter (result of integration) is 
poorer.

So maybe once again. How to evaluate fast and accurately integral over such 
circle (not whole domain)?

Also, maybe I can introduce a function which is equal to 1 inside of circle and 
0 - outside. And then integrate over whole domain.
Also, maybe I can adopt The deal.II Library: Integrators (dealii.org) 
<https://www.dealii.org/current/doxygen/deal.II/group__Integrators.html> to fit 
my function but not sure how I can do it.

Best regards,
Oleg Kmechak

Inkedinit_river_with_boundary_cond_LI.jpg

--
The deal.II project is located at http://www.dealii.org/ 
<http://www.dealii.org/>
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en 
<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 
<mailto:dealii+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/e02ebf7a-c4f2-4202-8cd2-057900260914n%40googlegroups.com
 
<https://groups.google.com/d/msgid/dealii/e02ebf7a-c4f2-4202-8cd2-057900260914n%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/79693521-76dc-ece1-e0eb-32fb0bf7c36c%40gmail.com.

Re: [deal.II] Facing problem while installation deal.ii

[Simon Sticko]

Hi,

Just to elaborate slightly on what Chen said: If your installation stops at 52%, it is NOT because 
of "dependencies not satisfied". This is not an error. Can you post the error you get 
from calling make in the terminal? E.g. copy the output you get from cmake and "make" to 
a txt-file and attach that.

Best,
Simon

On 10/06/2022 10:05, 陈敏 wrote:

Dear Abhishek Nath Thakur

These are many examples showing how to use deal.ii, these are corresponding documents on 
the official website <https://dealii.org/developer/doxygen/deal.II/Tutorial.html>. 
But some of these need external packages 
<https://dealii.org/developer/readme.html#:~:text=bit%2Dindices.-,Optional%20interfaces%20to%20other%20software%20packages,-When%20configuring%20interfacing>
 not bundled in the deal.ii. you need to install them yourself. Finally, you don't need to 
install all of the external packages, only the necessary packages are needed according to 
your applications.

Best
Chen

Abhishek Nath Thakur mailto:abhisheknaththa...@gmail.com>> 于2022年6月10日周五 15:57写道：

Dear deal.ii users,

I tried to install deal.ii 9.2.0 several times but every time i'm getting 
"dependencies not satisfied" (*image attached below*) due to which my 
installation stops at 52% everytime. I'm not sure if its an error or something else. So 
any help is appreciated

Thank you in advance


-- 
The deal.II project is located at http://www.dealii.org/ <http://www.dealii.org/>

For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en 
<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 
<mailto:dealii+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/5483bfa8-a269-4503-8624-557e8aa015edn%40googlegroups.com
 
<https://groups.google.com/d/msgid/dealii/5483bfa8-a269-4503-8624-557e8aa015edn%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
The deal.II project is located at http://www.dealii.org/ 
<http://www.dealii.org/>
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en 
<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 
<mailto:dealii+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/CADr3OdL74ZJdfrwXhe1M%2BB0sZ4%2BwtNBBhV4bGUCqv1vspUvEqg%40mail.gmail.com
 
<https://groups.google.com/d/msgid/dealii/CADr3OdL74ZJdfrwXhe1M%2BB0sZ4%2BwtNBBhV4bGUCqv1vspUvEqg%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/1bb4cf10-c237-938f-666a-7b87e175d13d%40gmail.com.

Re: [deal.II] Encountering error in installation of deal.ii

[Simon Sticko]

Hi,

From the error message, it looks like you don't have C++ compiler installed.
If you are using ubuntu, try

sudo apt-get install g++

and rerun cmake.

Best,
Simon

On 08/06/2022 16:32, Abhishek Nath Thakur wrote:

Respected deal.ii users,

I'm trying to install deal.ii 9.2.0 version but keep getting the error(*error 
image attached below*). I'm very new to this so i can really use someone's help 
to find me the way out of this.

Thank you very much in advance


--
The deal.II project is located at http://www.dealii.org/ 
<http://www.dealii.org/>
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en 
<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 
<mailto:dealii+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/e5dd7aeb-ade5-4c4a-9774-6ce10535b3b3n%40googlegroups.com
 
<https://groups.google.com/d/msgid/dealii/e5dd7aeb-ade5-4c4a-9774-6ce10535b3b3n%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/6e38f5a1-4032-47c5-e31c-0036353adc35%40gmail.com.

Re: [deal.II] How to use create_mass_matrix tools with FESystem

[Simon Sticko]

Hi,

In the stacktrace it looks like the error does not come from create_mass_matrix 
but from VectorTools::project. It complains that the passed Function has 1 
component when it should have dim components.

If you are projecting your own function, you need to make sure you set the 
number of components in the constructor, e.g. as for the body-force in step-18:

https://github.com/dealii/dealii/blob/39e29ba7e1cb8c7f711df6b89d19a76394b16f6a/examples/step-18/step-18.cc#L552

Best,
Simon



On 10/04/2022 01:51, Matthew Rich wrote:

Hi all,

I am trying to use the helper tools to assemble a system for a vector valued 
problem.

I am looking to have 2 or 3 displacement DoFs.

So I use

FESystem fe;

and initialize with

fe(FE_Q 
<https://www.dealii.org/current/doxygen/deal.II/classFE__Q.html>(1), dim)

So my code compiles, but when I try and run I get the following


An error occurred in line <182> of file 

 in function
     void dealii::VectorTools::internal::project_matrix_free(const dealii::Mapping&, const dealii::DoFHandler&, 
const dealii::AffineConstraints&, const dealii::Quadrature&, const dealii::Function::value_type>&, dealii::LinearAlgebra::distributed::Vector&, bool, const 
dealii::Quadrature<(dim - 1)>&, bool) [with int components = 2; int fe_degree = 1; int dim = 2; Number = double; int spacedim = 2; typename 
dealii::LinearAlgebra::distributed::Vector::value_type = double]
The violated condition was:
     dof.get_fe(0).n_components() == function.n_components
Additional information:
     Dimension 2 not equal to 1.

Stacktrace:
---
#0  /usr/lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0: void dealii::VectorTools::internal::project_matrix_free<2, 1, 2, double, 2>(dealii::Mapping<2, 
2> const&, dealii::DoFHandler<2, 2> const&, dealii::AffineConstraints const&, dealii::Quadrature<2> const&, 
dealii::Function<2, dealii::LinearAlgebra::distributed::Vector::value_type> const&, 
dealii::LinearAlgebra::distributed::Vector&, bool, dealii::Quadrature<(2)-(1)> const&, bool)
#1  /usr/lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0: void dealii::VectorTools::internal::project_matrix_free_degree<2, 2, double, 2>(dealii::Mapping<2, 
2> const&, dealii::DoFHandler<2, 2> const&, dealii::AffineConstraints const&, dealii::Quadrature<2> const&, 
dealii::Function<2, dealii::LinearAlgebra::distributed::Vector::value_type> const&, 
dealii::LinearAlgebra::distributed::Vector&, bool, dealii::Quadrature<(2)-(1)> const&, bool)
#2  /usr/lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0: void dealii::VectorTools::internal::project_matrix_free_component<2, double, 2>(dealii::Mapping<2, 
2> const&, dealii::DoFHandler<2, 2> const&, dealii::AffineConstraints const&, dealii::Quadrature<2> const&, 
dealii::Function<2, dealii::LinearAlgebra::distributed::Vector::value_type> const&, 
dealii::LinearAlgebra::distributed::Vector&, bool, dealii::Quadrature<(2)-(1)> const&, bool)
#3  /usr/lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0: void dealii::VectorTools::internal::project_matrix_free_copy_vector<2, dealii::Vector, 
2>(dealii::Mapping<2, 2> const&, dealii::DoFHandler<2, 2> const&, dealii::AffineConstraints::value_type> 
const&, dealii::Quadrature<2> const&, dealii::Function<2, dealii::Vector::value_type> const&, dealii::Vector&, bool, 
dealii::Quadrature<(2)-(1)> const&, bool)
#4  /usr/lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0: void dealii::VectorTools::internal::project, 2>(dealii::Mapping<2, 2> 
const&, dealii::DoFHandler<2, 2> const&, dealii::AffineConstraints::value_type> const&, dealii::Quadrature<2> 
const&, dealii::Function<2, dealii::Vector::value_type> const&, dealii::Vector&, bool, dealii::Quadrature<(2)-(1)> 
const&, bool)
#5  /usr/lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0: void dealii::VectorTools::project<2, dealii::Vector, 2>(dealii::Mapping<2, 2> const&, 
dealii::DoFHandler<2, 2> const&, dealii::AffineConstraints::value_type> const&, dealii::Quadrature<2> const&, 
dealii::Function<2, dealii::Vector::value_type> const&, dealii::Vector&, bool, dealii::Quadrature<(2)-(1)> const&, bool)
#6  /usr/lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0: void dealii::VectorTools::project<2, dealii::Vector, 2>(dealii::DoFHandler<2, 2> 
const&, dealii::AffineConstraints::value_type> const&, dealii::Quadrature<2> const&, dealii::Function<2, 
dealii::Vector::value_type> const&, dealii::Vector&, bool, dealii::Quadrature<(2)-(1)> const&, bool)
#7  ./final_proj: final_proj::WaveEquation<2>::run(

[deal.II] MPI: Evaluating several distributed functions on each node

[Konrad Simon]

Dear all,

I am facing a little challenge: Suppose I have several objects myFunction 
of a certain class MyFunction derived from a Function object on 
each process in my MPI universe. The number of MyFunction objects may vary 
from process to process.
I am trying to evaluate each object at certain points p that live on a 
distributed::Triangualtion. The evaluation points are different for 
each MyFunction object. A point may be contained in a cell owned by another 
process whose id is known, so I know where to send it to to ask a 
MyFunction object on that specific process to evaluate it for me and send 
the value back.

Now my question: How do I deal with several MyFunction objects on one 
process (I can identify these by a hash). Is it a good idea to have a class 
with a set of static variables and methods on each node to manage the 
communication and distribute necessary information within the process using 
the specific MyFunction hash? Does that make sense?

Let me stress again, the difficulty here is that I have several objects 
that may ask for values one by one or even in a (shared memory) parallel 
manner that may or may not trigger communication (sort of some_to_some 
style as implemented in Deal.II). 

Thanks in advance :-)

Best,
Konrad

-- 
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/4fb6b294-aa7f-4dc2-b823-e42247bf2302n%40googlegroups.com.

[deal.II] Re: range-based loop over cells

[simon...@gmail.com]

No, sorry... All cells. Just starting at level 0. Got confused by this line:

Triangulation 
<https://www.dealii.org/developer/doxygen/deal.II/classTriangulation.html>< 
dim, spacedim >::cell_iterator 
<https://www.dealii.org/developer/doxygen/deal.II/group__Iterators.html#ga997d61ac7cdc2be3ae934b1f7cdb>
 
Triangulation 
<https://www.dealii.org/developer/doxygen/deal.II/classTriangulation.html>< 
dim, spacedim >::begin ( const unsigned int 
<https://www.dealii.org/developer/doxygen/deal.II/classint.html>  *level* = 
0) const

/Simon

On Thursday, March 24, 2022 at 2:10:39 PM UTC+1 simon...@gmail.com wrote:

> You will iterate from begin() to end() on the object after the colon. On 
> Triangulation this is the cells on level 0.
>
> Best,
> Simon
>
> On Thursday, March 24, 2022 at 1:57:29 PM UTC+1 Niklas Fehn wrote:
>
>> thanks. I think it is nevertheless possible to write "cell : 
>> triangulation", and I wondered what this means exactly?
>>
>> bruno.t...@gmail.com schrieb am Donnerstag, 24. März 2022 um 13:35:41 
>> UTC+1:
>>
>>> Niklas,
>>>
>>> If you want cell_iterators, you write for(auto cell : 
>>> triangulation.cell_iterators 
>>> ()) If you want active_cell_iterators, you write for(auto cell : 
>>> triangulation.active_cell_iterators ()) The documentation is here 
>>> <https://dealii.org/current/doxygen/deal.II/group__CPP11.html#gaef378969994082255fbc64366511a7d1>
>>> .
>>>
>>> Best,
>>>
>>> Bruno
>>> On Thursday, March 24, 2022 at 8:21:42 AM UTC-4 Niklas Fehn wrote:
>>>
>>>> Dear dealii,
>>>>
>>>> when writing
>>>>
>>>> for(auto cell : triangulation){} 
>>>>
>>>> which type of cell iterator is used (cell_iterators(), 
>>>> active_cell_iterators())? and where do I find this information in the 
>>>> documentation?
>>>>
>>>> Many thanks and 
>>>>
>>>> Best
>>>> Niklas
>>>>
>>>

-- 
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/8403cace-6ba4-4240-8d83-7d36b1832348n%40googlegroups.com.

[deal.II] Re: range-based loop over cells

[simon...@gmail.com]

You will iterate from begin() to end() on the object after the colon. On 
Triangulation this is the cells on level 0.

Best,
Simon

On Thursday, March 24, 2022 at 1:57:29 PM UTC+1 Niklas Fehn wrote:

> thanks. I think it is nevertheless possible to write "cell : 
> triangulation", and I wondered what this means exactly?
>
> bruno.t...@gmail.com schrieb am Donnerstag, 24. März 2022 um 13:35:41 
> UTC+1:
>
>> Niklas,
>>
>> If you want cell_iterators, you write for(auto cell : 
>> triangulation.cell_iterators 
>> ()) If you want active_cell_iterators, you write for(auto cell : 
>> triangulation.active_cell_iterators ()) The documentation is here 
>> <https://dealii.org/current/doxygen/deal.II/group__CPP11.html#gaef378969994082255fbc64366511a7d1>
>> .
>>
>> Best,
>>
>> Bruno
>> On Thursday, March 24, 2022 at 8:21:42 AM UTC-4 Niklas Fehn wrote:
>>
>>> Dear dealii,
>>>
>>> when writing
>>>
>>> for(auto cell : triangulation){} 
>>>
>>> which type of cell iterator is used (cell_iterators(), 
>>> active_cell_iterators())? and where do I find this information in the 
>>> documentation?
>>>
>>> Many thanks and 
>>>
>>> Best
>>> Niklas
>>>
>>

-- 
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/c3238c4b-d16d-4102-a10d-6f66db511ff7n%40googlegroups.com.

[deal.II] Triangulation from lower-dimensional object

[Konrad Simon]

Dear all,

I was recently looking for a solution to the following problem:

I have a triangulation, e.g., of a unit cube. I need to solve a 
lower-dimensional (FEM-like) problem on all faces with BCs on edges and for 
each face I need to solve a problem on all edges with BCs at vertices.

Can I somehow extract a Triangulation form a Triangulation by 
providing, for example, the boundary id on the Triangulation level?

Best,
Konrad

-- 
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/ae0eae00-a572-4036-b20e-31f45dd70892n%40googlegroups.com.

[deal.II] Elasticity Preconditioner

[Konrad Simon]

Dear all, 

A student and me are trying to deal with (parallel, static) linearized 
elasticity similar to step-8.
However, the problem is slightly different since the Lame parameters are 
functions instead of constants. 
Can anyone recommend good solvers & preconditioners for the resulting 
system? Our boundary conditions fix all degrees of freedom in the kernel.

Best,
Konrad

-- 
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/eba0cc0f-6028-4fde-9cee-307e09f8d2ban%40googlegroups.com.

[deal.II] cite specific content of dealii documentation

[Simon]

Dear all,

I wrote a thesis where my source code is based on dealii.

As described here,
https://www.dealii.org/publications.html,
I inserted the given bibtex entry in my document.
However, I also use specific content of
the documentation of the project function inside 
the vector tools namespace,
https://www.dealii.org/current/doxygen/deal.II/namespaceVectorTools.html#ac6b404bf03cb2a742b290421cc2789fe,
in particular, the notes on the quadrature formula for the "mass matrix".

How do I cite this correctly? Simply listing all authors of the bibtex 
entry from above + the url?

Best
Simon

-- 
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/c6d23852-e7c2-4d27-a93a-75d6621225b7n%40googlegroups.com.

[deal.II] Re: Munmap_chunk(): invalid pointer

[simon...@gmail.com]

Hi,
Good that you solved you problem.

Address sanitizer is great for finding this type of bugs, but note that you 
don't want to use it when you run the actual simulation. 
In general, memory usage increases (by a  factor ~2 to ~3) and the code 
runs slower (by a factor ~2 to ~5).

Best,
Simon

On Monday, September 13, 2021 at 3:03:04 PM UTC+2 simon...@gmail.com wrote:

> Hi,
> "Invalid pointer" suggest that this is some bug related to memory. One way 
> to find such errors is to turn on the adress sanitizer. If you use gcc or 
> clang, this can be done by configuring cmake this:
>
> cmake -DCMAKE_BUILD_TYPE="Debug" -DCMAKE_CXX_FLAGS="-fsanitize=address" 
> -DCMAKE_EXE_LINKER_FLAGS="-fsanitize=address" ..
>
> and then recompiling. If you now run your program, it will crash with 
> something like this:
>
> =
> ==29575==ERROR: AddressSanitizer: heap-buffer-overflow on address 
> 0x60207a34 at pc 0x55a3f14c9cb4 bp 0x7ffd346a5f40 sp 0x7ffd346a5f30
> WRITE of size 4 at 0x60207a34 thread T0
> #0 0x55a3f14c9cb3 in Poro::Poroelasticity<2>::assemble_system() 
> /home/simon/workspace/sandbox/example.cc:249
> #1 0x55a3f14c110f in Poro::Poroelasticity<2>::run() 
> /home/simon/workspace/sandbox/example.cc:394
> #2 0x55a3f14b517a in main /home/simon/workspace/sandbox/example.cc:411
> #3 0x7fea8d0a80b2 in __libc_start_main 
> (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
> #4 0x55a3f14b4f5d in _start 
> (/home/simon/workspace/sandbox/build/example+0x76f5d)
>
>
> At the top entry #0, you can see that the code crashed at line 249,  which 
> corresponds to the line:
>
> freq[j]=j+1;
>
> Here, freq had length 1 and you by mistake tried to access the j=1 entry.
>
> Best,
> Simon
>
> On Monday, September 13, 2021 at 10:49:41 AM UTC+2 masia...@gmail.com 
> wrote:
>
>> Hello everyone, 
>> I am trying to run the following script, but getting the error: 
>> 'munmap_chunk(): invalid pointer'. The eclipse debugger doesn't help me 
>> realize, where exactly the error occurs. 
>> In case you have an idea, how to correct it, please, let me know. I would 
>> be very gratefull!
>>
>> Kind regards,
>> Mariia 
>>
>>
>>
>>
>> #include 
>> #include 
>> #include 
>>
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>>
>> #include 
>> #include 
>>
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>>
>> #include 
>> #include 
>>
>> //#include 
>>
>> #include 
>> #include 
>> #include 
>> #include 
>>
>> #include 
>>
>> namespace Poroelasticity
>> {
>>   using namespace dealii;
>>
>>   template 
>>   SymmetricTensor<4, dim, std::complex> 
>> get_stress_strain_tensor(const std::complex lambda,
>>const std::complex mu)
>>   {
>>   const std::complex nothing(0.0,0.0);
>>   SymmetricTensor<4, dim, std::complex> stress_strain_tensor;
>>   for (unsigned int i=0; i< dim; ++i)
>>   for (unsigned int j=0; j< dim; ++j)
>>   for (unsigned int k=0; k< dim; ++k)
>>   for (unsigned int l=0; l< dim; ++l)
>>   stress_strain_tensor[i][j][k][l]= (((i==k) && (j==l) ? mu : nothing) +
>>   ((i==l) && (j==k) ? mu : nothing) +
>> ((i==j) && (k==l) ? lambda : nothing));
>>   return stress_strain_tensor;
>>   }
>>
>>   template 
>>   inline SymmetricTensor<2, dim> get_strain(const FEValues 
>> &fe_values,
>>   const unsigned int shape_func,
>> const unsigned int q_point)
>>   {
>>   SymmetricTensor<2, dim> strain_tensor;
>>   for (unsigned int i=0; i< dim; ++i)
>>   strain_tensor[i][i] = fe_values.shape_grad_component(shape_func, 
>> q_point, i)[i];
>>
>>   for (unsigned int i=0; i< dim; ++i)
>>   for (unsigned int j=i+1; j< dim; ++j)
>>   strain_tensor[i][j] =
>>   (fe_values.shape_grad_component(shape_func, q_point, i)[j] +
>>fe_values.shape_grad_component(shape_func, q_point, j)[i]) /
>>2;
>>   return strain_tensor;
>>   }
>>
>>
>>   template 
>>   class Poroelasticity
>>   {
>>   public:
>> Poroelasticity(const unsigned int degree);
>> void run();
>>
>>   private:
>>

[deal.II] Re: Munmap_chunk(): invalid pointer

[simon...@gmail.com]

Hi,
"Invalid pointer" suggest that this is some bug related to memory. One way 
to find such errors is to turn on the adress sanitizer. If you use gcc or 
clang, this can be done by configuring cmake this:

cmake -DCMAKE_BUILD_TYPE="Debug" -DCMAKE_CXX_FLAGS="-fsanitize=address" 
-DCMAKE_EXE_LINKER_FLAGS="-fsanitize=address" ..

and then recompiling. If you now run your program, it will crash with 
something like this:

=
==29575==ERROR: AddressSanitizer: heap-buffer-overflow on address 
0x60207a34 at pc 0x55a3f14c9cb4 bp 0x7ffd346a5f40 sp 0x7ffd346a5f30
WRITE of size 4 at 0x60207a34 thread T0
#0 0x55a3f14c9cb3 in Poro::Poroelasticity<2>::assemble_system() 
/home/simon/workspace/sandbox/example.cc:249
#1 0x55a3f14c110f in Poro::Poroelasticity<2>::run() 
/home/simon/workspace/sandbox/example.cc:394
#2 0x55a3f14b517a in main /home/simon/workspace/sandbox/example.cc:411
#3 0x7fea8d0a80b2 in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
#4 0x55a3f14b4f5d in _start 
(/home/simon/workspace/sandbox/build/example+0x76f5d)


At the top entry #0, you can see that the code crashed at line 249,  which 
corresponds to the line:

freq[j]=j+1;

Here, freq had length 1 and you by mistake tried to access the j=1 entry.

Best,
Simon

On Monday, September 13, 2021 at 10:49:41 AM UTC+2 masia...@gmail.com wrote:

> Hello everyone, 
> I am trying to run the following script, but getting the error: 
> 'munmap_chunk(): invalid pointer'. The eclipse debugger doesn't help me 
> realize, where exactly the error occurs. 
> In case you have an idea, how to correct it, please, let me know. I would 
> be very gratefull!
>
> Kind regards,
> Mariia 
>
>
>
>
> #include 
> #include 
> #include 
>
> #include 
> #include 
> #include 
> #include 
> #include 
>
> #include 
> #include 
>
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
>
> #include 
> #include 
>
> //#include 
>
> #include 
> #include 
> #include 
> #include 
>
> #include 
>
> namespace Poroelasticity
> {
>   using namespace dealii;
>
>   template 
>   SymmetricTensor<4, dim, std::complex> 
> get_stress_strain_tensor(const std::complex lambda,
>const std::complex mu)
>   {
>   const std::complex nothing(0.0,0.0);
>   SymmetricTensor<4, dim, std::complex> stress_strain_tensor;
>   for (unsigned int i=0; i< dim; ++i)
>   for (unsigned int j=0; j< dim; ++j)
>   for (unsigned int k=0; k< dim; ++k)
>   for (unsigned int l=0; l< dim; ++l)
>   stress_strain_tensor[i][j][k][l]= (((i==k) && (j==l) ? mu : nothing) +
>   ((i==l) && (j==k) ? mu : nothing) +
> ((i==j) && (k==l) ? lambda : nothing));
>   return stress_strain_tensor;
>   }
>
>   template 
>   inline SymmetricTensor<2, dim> get_strain(const FEValues &fe_values,
>   const unsigned int shape_func,
> const unsigned int q_point)
>   {
>   SymmetricTensor<2, dim> strain_tensor;
>   for (unsigned int i=0; i< dim; ++i)
>   strain_tensor[i][i] = fe_values.shape_grad_component(shape_func, 
> q_point, i)[i];
>
>   for (unsigned int i=0; i< dim; ++i)
>   for (unsigned int j=i+1; j< dim; ++j)
>   strain_tensor[i][j] =
>   (fe_values.shape_grad_component(shape_func, q_point, i)[j] +
>fe_values.shape_grad_component(shape_func, q_point, j)[i]) /
>2;
>   return strain_tensor;
>   }
>
>
>   template 
>   class Poroelasticity
>   {
>   public:
> Poroelasticity(const unsigned int degree);
> void run();
>
>   private:
> void make_grid_and_dofs();
> void assemble_system();
> void solve();
> void output_results() const;
>
> const unsigned int degree;
>
> Triangulation triangulation;
> FESystem  fe;
> DoFHandlerdof_handler;
>
> BlockSparsityPattern  sparsity_pattern;
> BlockSparseMatrix> system_matrix;
> BlockVector> solution;
> BlockVector> system_rhs;
>
> static const SymmetricTensor<4, dim> stress_strain_tensor;
>
> static constexpr unsigned int start_freq=0;
> static constexpr unsigned int end_freq=2; //[Hz]
>   };
>
> template
>   class RightHandSide : public Function
>   {
>   public:
>   RightHandSide()
>   : Function(1)
>   {}
>
>   virtual double value(const Point &p,
>  const unsigned int component = 0) const override;
>   
>   };
>
>   template 
>   double RightHandSide::value

[deal.II] Re: shift-invert transformation problem with slepc

[simon...@gmail.com]

Hi,

I think you need to set both which eigen pair and the target value. For 
example, if you look for the eigenvalue closest in magnitude to 0, you need 
to set the following

const double target_eigenvalue = 0;
eigensolver.set_which_eigenpairs(EPS_TARGET_MAGNITUDE);
eigensolver.set_target_eigenvalue(target_eigenvalue);

Depending on slepc version it might be that you can only choose 
EPS_TARGET_MAGNITUDE. See question 8 here:

https://slepc.upv.es/documentation/faq.htm

Best,
Simon

On Tuesday, August 24, 2021 at 3:39:29 AM UTC+2 anton.i...@gmail.com wrote:

> Dear All,
>
> I am trying to use a shift-invert transformation in step-36. I did minimal 
> changes in the solve function adding the following code that describes what 
> spectral transformation I need to do:
>
> SolverControl solver_control (dof_handler.n_dofs(), 1e-9);
> SLEPcWrappers::SolverKrylovSchur eigensolver(solver_control);
> eigensolver.set_which_eigenpairs (EPS_SMALLEST_REAL);
> eigensolver.set_problem_type (EPS_GHEP);
>
> double eigen_shift = 1.0e-4;
> SLEPcWrappers::TransformationShiftInvert::AdditionalData 
> additional_data(eigen_shift);
> SLEPcWrappers::TransformationShiftInvert shift (MPI_COMM_WORLD, 
> additional_data);
> eigensolver.set_transformation (shift);
>
> eigensolver.solve(stiffness_matrix,
>   mass_matrix,
>   eigenvalues,
>   eigenfunctions,
>   eigenfunctions.size());
>
> and it gives me the following error: 
>
> [0]PETSC ERROR: Shift-and-invert requires a target 'which' (see 
> EPSSetWhichEigenpairs), for instance -st_type sinvert -eps_target 0 
> -eps_target_magnitude
>
> Any help to resolve this error is greatly appreciated. I also attached the 
> full code of modified step-36.
>
> Thank you,
> Anton.
>

-- 
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/ada0420b-83b5-4af0-a77c-d71c9af63dd6n%40googlegroups.com.