Re: [deal.II] DataOut class only offers 6 digit output for double type?

[Wolfgang Bangerth]

As the theme side, i gives a vector to a  DataOut object, the type of the 
vector entry is double, with 15 effective digit. But there is only 6 digit 
when write to a file (vtk or gpl). My vector is around  1647.99932, the 
result write into the file is 1648. How can i improve the presion of the 
result in file?


You probably just need to call
  output_file_stream.precision(12);
before calling
  data_out.write_vtk(output_file_stream);
This should make sure that output is written with 12 digits rather than C++'s 
default of 6 digits.


That said, do you really need this many digits of accuracy? It is very 
difficult to solve PDEs to more than, say, 4 digits of accuracy. As a 
consequence, it would surprise me if you actually need more accuracy than just 
the default 6 digits in your output files.


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/d5502550-b6a5-aa17-41d6-06781a5c758d%40colostate.edu.

Re: [deal.II] DataOut class only offers 6 digit output for double type?

[Timo Heister]

huyanzhuo,

We compute and then output data inside DataOut as float (32 bit
floating point) and not as double (64bit). Float has an accuracy of
approximately 7 decimal digits, so your number would be roughly
1647.999 but it happens to be rounded up to 1648.000.
I am afraid there is no easy way to change this because this is
hard-coded inside DataOut. It is in the Patch class if you are
curious:
https://www.dealii.org/developer/doxygen/deal.II/structDataOutBase_1_1Patch.html#a366bf92bcc2b667586d630455953d911

Normally, this should be enough for visualization.

On Tue, Feb 8, 2022 at 4:58 PM huyanzhuo  wrote:
>
> I'm using the 8.5.1 version.
> As the theme side, i gives a vector to a  DataOut object, the type of 
> the vector entry is double, with 15 effective digit. But there is only 6 
> digit when write to a file (vtk or gpl). My vector is around  1647.99932, 
> the result write into the file is 1648. How can i improve the presion of the 
> result in file?
>
> --
> 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/db91c18b-7e9b-4aa0-9a81-3e93e1f3df2an%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/CAMRj59GUHB9ZqmwjuScjrfuyb8XSuz%2BCg-ZbX24i22cGUdLURA%40mail.gmail.com.

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

[Timo Heister]

> *L_operator(local_dof_indices[i],local_dof_indices[j]) =
cell_matrix(i,j);*

*This looks incorrect, because global pairs of indices will happen more
than once in a normal assembly (with a continuous finite element). You have
to add the contribution using +=.*


On Tue, Feb 8, 2022, 16:52 Hermes Sampedro  wrote:

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

-- 
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/CAMRj59Eu0BiPXZ7EeGjv6Zsc2ppbkstaUc5SYXzCfRrNFqbyOw%40mail.gmail.com.

[deal.II] DataOut class only offers 6 digit output for double type?

[huyanzhuo]

I'm using the 8.5.1 version. 
As the theme side, i gives a vector to a  DataOut object, the type of 
the vector entry is double, with 15 effective digit. But there is only 6 
digit when write to a file (vtk or gpl). My vector is around  
1647.99932, the result write into the file is 1648. How can i improve 
the presion of the result in file?

-- 
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/db91c18b-7e9b-4aa0-9a81-3e93e1f3df2an%40googlegroups.com.

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

[Hermes Sampedro]

Dear Wolfgang, 

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

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


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

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


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

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

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

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/0b63fba4-0c3f-4727-9ce2-18ddc897aba9n%40googlegroups.com.

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

[Wolfgang Bangerth]

On 2/8/22 09:06, Hermes Sampedro wrote:


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


No functions in deal.II touch your linear system unless you specifically 
call a function that takes a matrix or vector as argument. So, if you 
have the distribute_local_to_global() call for one type of matrix, you 
need to call it for the other kind of matrix as well. But these 
functions do not internally store some kind of magic pointer to the 
matrix and right hand side so that at some later point, when you're not 
watching, they do something nefarious to your matrix :-)


My suggestion would be to make sure that before the solve, the two 
matrices and corresponding right hand sides are the same. This is often 
awkward if the objects are large, but you can test this by outputting 
the norm of these objects.


Then check that the solution is also the same. My guess is that for some 
reason, either the matrix or the rhs are different.


Best
 W.

--

Wolfgang Bangerth  email: 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/0756a340-f64e-2ca6-e769-cc60834d681b%40colostate.edu.

Re: [deal.II] Help with step-7 Neumann boundary conditions

[Wolfgang Bangerth]

On 2/8/22 09:12, Ali Seddiq wrote:
This is while if I change the pressure, naming it as U2 to another 
scalar field variable , naming it as U1, it works, though I get zero 
iteration for U1, and in fact it does not solve for U1.

For example if I write:

fe_face_values[U1].value(i, q_point) *...    (U1: second scalar variable)

It leads to the error, but if I write:
fe_face_values[U1].value(i, q_point) *... (U1: first scalar variable)

does  a number of iterations for U1 , and 0 iteration (probably also 
meaning no solution) for U2.


Ali -- we don't know what your code looks like (and even if we did, we 
would not have the time to debug it), but the paragraph above suggests 
to me that you do not actually understand what the various parts of your 
code are doing.


My suggestion to you is to make sure you have the simplest possible case 
that fails. That means that you find out what the difference between U1 
and U2 is, and why one fails and the other does not. In general, I find 
that copying the current version of a program to a safe place, and then 
slashing everything from it that is not necessary to show the bug is a 
valid strategy for debugging. Make the program as small as you can, 
since this reduces the number of places where the bug can be.


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/af8b61af-423b-7355-e9ae-4269367a074a%40colostate.edu.

[deal.II] deal.II Newsletter #200

['Rene Gassmoeller' via deal.II User Group]

Hello everyone!

This is deal.II newsletter #200.
It automatically reports recently merged features and discussions about the 
deal.II finite element library.


## Below you find a list of recently proposed or merged features:

#13344: Fix boundary IDs for `pipe_junction`. (proposed by marcfehling; merged) 
https://github.com/dealii/dealii/pull/13344

#13343: Add MGSmootherPrecondition::initialize_matrices() (proposed by 
peterrum) https://github.com/dealii/dealii/pull/13343

#13342: Fix name of change-log entry (proposed by peterrum; merged) 
https://github.com/dealii/dealii/pull/13342

#13341: Make FEEval more consistent with FEValues (proposed by peterrum) 
https://github.com/dealii/dealii/pull/13341

#13340: Fix assert message for empty vector (proposed by peterrum; merged) 
https://github.com/dealii/dealii/pull/13340

#13339: Save a few cycles for single-character output. (proposed by bangerth; 
merged) https://github.com/dealii/dealii/pull/13339

#13338: correcting some notations (proposed by pengfej; merged) 
https://github.com/dealii/dealii/pull/13338

#13337: Fix deduction matrix free (proposed by drwells; merged) 
https://github.com/dealii/dealii/pull/13337

#13336: VTU: put closing XML on separate line (proposed by tjhei; merged) 
https://github.com/dealii/dealii/pull/13336

#13335: SolverControl: make constructors explicit (proposed by tjhei; merged) 
https://github.com/dealii/dealii/pull/13335

#13334: documentation fixes (proposed by tjhei; merged) 
https://github.com/dealii/dealii/pull/13334

#1: PreconditionIdentity: move implementation out of declaration (proposed 
by tjhei; merged) https://github.com/dealii/dealii/pull/1

#13332: fix a formula (proposed by zjiaqi2018; merged) 
https://github.com/dealii/dealii/pull/13332

#13331: remove two wrong file comments (proposed by tjhei; merged) 
https://github.com/dealii/dealii/pull/13331

#13330: remove forward declarations of MappingQ (proposed by nfehn; merged) 
https://github.com/dealii/dealii/pull/13330

#13328: Add MatrixFree::initialize_cell_data_vector()  (proposed by peterrum; 
merged) https://github.com/dealii/dealii/pull/13328

#13327: FEEval::reinit(std::array): use MappingDataOnTheFly (proposed by 
peterrum; merged) https://github.com/dealii/dealii/pull/13327

#13326: Use the new CA interface instead of using AnonymousProcess. (proposed 
by bangerth) https://github.com/dealii/dealii/pull/13326

#13325: CMake: Modernize DEAL_II_PACKAGE_HANDLE macro and clean up Find*.cmake 
files (proposed by tamiko; merged) https://github.com/dealii/dealii/pull/13325

#13324: Fix warning regarding unused parameter (proposed by kronbichler; 
merged) https://github.com/dealii/dealii/pull/13324

#13323: Micro simplication. (proposed by bangerth; merged) 
https://github.com/dealii/dealii/pull/13323

#13322: Deal with empty function objects in CA algorithms. (proposed by 
bangerth; merged) https://github.com/dealii/dealii/pull/13322

#13320: Replace is_detected (type) by is_supported_operation (variable). 
(proposed by bangerth; merged) https://github.com/dealii/dealii/pull/13320

#13319: CMake: call CMake's FindHDF5 instead of trying to find everything by 
hand (proposed by tamiko; merged) https://github.com/dealii/dealii/pull/13319

#13316: MatrixFreeTools::compute_diagonal(): do not initialize vector (proposed 
by peterrum; merged) https://github.com/dealii/dealii/pull/13316

#13315: `MatrixFreeTools::compute_diagonal`: introduce template parameter 
`VectorType` (proposed by mschreter; merged) 
https://github.com/dealii/dealii/pull/13315


## And this is a list of recently opened or closed discussions:

#13348: Test fe_nedelec_sz_hessian_divergence_theorem.debug times out (opened) 
https://github.com/dealii/dealii/issues/13348

#13347: GMSH quad mesh with some cells with negative weight (opened) 
https://github.com/dealii/dealii/issues/13347

#13346: Negative det in MappingFE on some simplex mesh (opened) 
https://github.com/dealii/dealii/issues/13346

#13345: DataOut hdf5 does not support large files (opened) 
https://github.com/dealii/dealii/issues/13345

#13329: Link to wrong header file in Docu of MappingQ? (opened and closed) 
https://github.com/dealii/dealii/issues/13329

#13321: Replace std::pow with integer exponent (opened) 
https://github.com/dealii/dealii/issues/13321

#13295: Follow-ups to the introduction of `is_detected` (closed) 
https://github.com/dealii/dealii/issues/13295

#10561: Improve support of cell-data vectors in MatrixFree (closed) 
https://github.com/dealii/dealii/issues/10561

#8957: deal.II does not see the HDF5 package on Ubuntu 18.04 (closed) 
https://github.com/dealii/dealii/issues/8957


A list of all major changes since the last release can be found at 
https://www.dealii.org/developer/doxygen/deal.II/recent_changes.html.


Thanks for being part of the community!


Let us know about questions, problems, bugs or just share your experience by 
writing to dealii@googlegroups.com, or by opening issues or pull 

Re: [deal.II] Help with step-7 Neumann boundary conditions

[Ali Seddiq]

Dear Wolfgang,

Sorry to raise this topic again. But when I add the boundary term to the to 
cell_rhs on assembly_system, I receive the following message, based on 
which most likely this addition leads to an invertible matrix:


An error occurred in line <457> of file 
 in function
void dealii::SolverCG::solve(const MatrixType&, 
VectorType&, const VectorType&, const PreconditionerType&) [with MatrixType 
= dealii::SparseMatrix; PreconditionerType = 
dealii::PreconditionIdentity; VectorType = dealii::Vector]
The violated condition was: 
false
Additional information: 
Iterative method reported convergence failure in step 25. The residual in 
the last step was 1.55891e-08.

This error message can indicate that you have simply not allowed a 
sufficiently large number of iterations for your iterative solver to 
converge. This often happens when you increase the size of your problem. In 
such cases, the last residual will likely still be very small, and you can 
make the error go away by increasing the allowed number of iterations when 
setting up the SolverControl object that determines the maximal number of 
iterations you allow.

The other situation where this error may occur is when your matrix is not 
invertible (e.g., your matrix has a null-space), or if you try to apply the 
wrong solver to a matrix (e.g., using CG for a matrix that is not symmetric 
or not positive definite). In these cases, the residual in the last 
iteration is likely going to be large.


This is while if I change the pressure, naming it as U2 to another scalar 
field variable , naming it as U1, it works, though I get zero iteration for 
U1, and in fact it does not solve for U1.
For example if I write:

fe_face_values[U1].value(i, q_point) *...(U1: second scalar variable)

It leads to the error, but if I write:
fe_face_values[U1].value(i, q_point) *... (U1: first scalar variable)

does  a number of iterations for U1 , and 0 iteration (probably also 
meaning no solution) for U2.

As a bit of further information, my weak form simply ends up to:

dt(M+A)*U1 + A'* U2 = dt*(F_{U1^n-1}) + F_U2   

U1 and U2 as two scalar unknowns.


And, the boundary term in matrix-vector form supposed to be my F_U2.
I considered the following block matrices and vectors in forming the linear 
system (and solver):

(M+A): system_matrix.block(0,0)
A': system_matrix.block(1,1)
U1: solution.block(0)
U2: solution.block(1)
F_U1: system_rhs.block(0)
F_U2: system_rhs.block(1)

F_U1 would be integration over the domain with  phi_i_U1* U1^(n_1)
F_U2 would be integration over the boundary with phi_i_U2*neumann_value

cell_rhs(i) += time_step* phi_i_U1 * old_solution_values * 
fe_values.JxW(q_point)  ///as  (F_U1)

and there after boundary term is added as:

cell_rhs(i) += neumann_value *fe_face_values[U2].value(i, q_point)  * 
fe_values.JxW(q_point)  /// as (F_U2)


and the solve function which could be one of the problems is as the 
following:

{
 tmp += system_rhs.block(0);

 SolverControlsolver_control(solution.block 
(0).size(), 1e-8 * system_rhs.l2_norm());
 SolverCG> cg (solver_control);
 cg.solve(system_matrix.block(0, 0), solution.block (0), 
tmp, PreconditionIdentity());

 std::cout << " " << solver_control.last_step() << " CG 
iterations for U1." << std::endl;
 }

 {
 tmp2 += system_rhs.block(1);

 SolverControlsolver_control2(solution.block 
(1).size(), 1e-8 * system_rhs.l2_norm());
 SolverCG> cg (solver_control2);
 cg.solve(system_matrix.block(1, 1), solution.block (1), 
tmp2, PreconditionIdentity());

 std::cout << " " << solver_control2.last_step() << " 
CG iterations for U2." << std::endl;

 }

I did quite a number of changes in the code to see the outcome but it seems 
I got stuck on an apparently obvious problem and unfortunately haven't been 
able to figure it out yet.
I am also not sure if simply addition of boundary term to cell_rhs leads to 
the correct recognition as system_rhs.block(1) in the solve?
Would you or anyone else please help me with this problem?

Thanks very much,
Ali















On Monday, January 31, 2022 at 8:08:18 PM UTC+1 Wolfgang Bangerth wrote:

> On 1/31/22 11:41, Ali Seddiq wrote:
> > 
> > Thanks for a quick reply, and sorry for ambiguity. To be more precise 
> > (trying to be) I should say the lines I modified with the aim of 
> > creating a so-called "view" do not do that for my intended variable. My 
> > question mainly was that if using the [ ] operator (that I added) does 
> > the job of identifying the desired field on the faces? Is the usage 
> correct?
>
> Yes. The call in your example code considers the first vector component 
> of the i'th shape function at quadrature point q_point.
>
>
> > I am also a bit confused as fe.system_to_component_index 
> > <
> 

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

[Hermes Sampedro]

Dear all, 

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

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

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

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


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

[image: result.png]

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

Thank you very much for your help. Regards, 



-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/03437f5b-5d49-4b84-8367-7e9d34f382e8n%40googlegroups.com.

Re: [deal.II] Re: Cluster installation error with symengine library

[Timo Heister]

Stephanie,

I think you likely don't need some fine, am i right? Just comment out the
line for it in the candi.cfg and rerun the setup (you might need to delete
the tmp directory).


On Tue, Feb 8, 2022, 10:01 Raghunandan Pratoori  wrote:

> Hi Stephanie,
>
> I use a singularity container with deal.ii on my university cluster. I
> found it to be much simpler and working on any other cluster tried without
> any problems. I suggest you try that as it is a more reliable solution.
> Also, if needed, I can give you access to the singularity container I
> built on Ubuntu 20.04 with deal.ii v9.3.0
>
> Best,
> Raghunandan.
>
> On Tuesday, February 8, 2022 at 8:30:33 AM UTC-6 sasp...@asu.edu wrote:
>
>> Hello,
>>
>> I am trying to install deal.ii on my university cluster and have been
>> successful up to this point; however, when I attempt to run examples I get
>> the following error:
>>
>> ./step-1: error while loading shared libraries: libsymengine.so.0.7:
>> cannot open shared object file: No such file or directory
>>
>> I found an entry in the FAQ regarding similar problems with linking PETSc
>> and attempted to use that fix but I'm still running into the same issue.
>>
>> Any help would be greatly appreciated.
>>
>> Thanks,
>> Stephanie
>>
> --
> 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/61bc9eb6-a392-4b3a-836e-37764a389b0an%40googlegroups.com
> 
> .
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this 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/CAMRj59E8A%3DfRSBodEL%2BswcpSmzQ61SFpVNOOvAnFCdDaufQGqg%40mail.gmail.com.

[deal.II] Re: Cluster installation error with symengine library

[Raghunandan Pratoori]

Hi Stephanie,

I use a singularity container with deal.ii on my university cluster. I 
found it to be much simpler and working on any other cluster tried without 
any problems. I suggest you try that as it is a more reliable solution.
Also, if needed, I can give you access to the singularity container I built 
on Ubuntu 20.04 with deal.ii v9.3.0

Best,
Raghunandan.

On Tuesday, February 8, 2022 at 8:30:33 AM UTC-6 sasp...@asu.edu wrote:

> Hello,
>
> I am trying to install deal.ii on my university cluster and have been 
> successful up to this point; however, when I attempt to run examples I get 
> the following error:
>
> ./step-1: error while loading shared libraries: libsymengine.so.0.7: 
> cannot open shared object file: No such file or directory
>
> I found an entry in the FAQ regarding similar problems with linking PETSc 
> and attempted to use that fix but I'm still running into the same issue.
>
> Any help would be greatly appreciated.
>
> Thanks,
> Stephanie
>

-- 
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/61bc9eb6-a392-4b3a-836e-37764a389b0an%40googlegroups.com.

Re: [deal.II] Periodic bc for dim=1

[Marc Fehling]

Hello Praveen,

the parallel::distributed::Triangulation class is not instantiated for 
dim=1, only for dim>1. The reason behind it is that p4est does not allow to 
create 1D domains. With any other Triangulation class you should be fine.

Marc

On Tuesday, February 8, 2022 at 1:01:02 AM UTC-7 Praveen C wrote:

> I am getting compilation error
>
> [100%] Linking CXX executable main
> Undefined symbols for architecture arm64:
> "void 
> dealii::GridTools::collect_periodic_faces  
> 1> >(dealii::parallel::distributed::Triangulation<1, 1> const&, unsigned 
> int, unsigned int, int, 
> std::__1::vector  
> 1>::cell_iterator>, 
> std::__1::allocator  
> 1>::cell_iterator> > >&, dealii::Tensor<1, 
> dealii::parallel::distributed::Triangulation<1, 1>::space_dimension, 
> double> const&, dealii::FullMatrix const&)", referenced from:
> CGSEM<1>::setup_box_grid() in cgsem.cc.o
> ld: symbol(s) not found for architecture arm64
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
>
> Maybe I am doing something wrong.
>
> Thanks
> praveen
>
> > On 08-Feb-2022, at 1:19 PM, Peter Munch  wrote:
> > 
> > What do you mean by "does not work for 1D"? In hyper.deal (
> https://github.com/hyperdeal/hyperdeal), we also have PBC in "1D".
> > 
> > Peter
> > 
> > On Tuesday, 8 February 2022 at 06:34:42 UTC+1 Praveen C wrote:
> > Dear all 
> > 
> > I was trying to write a code that works for 1/2/3d navier stokes. 
> > 
> > But it seems like collect_periodic_faces does not work for 1d ? Is this 
> the case, and is there any other way to deal with this situation ? 
> > 
> > Thanks 
> > praveen
> > 
> > -- 
> > The deal.II project is located at http://www.dealii.org/
> > For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups "deal.II User Group" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to dealii+un...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dealii/3dec29d1-bb19-4f58-8c8f-35568ceaf754n%40googlegroups.com
> .
>
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this 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/d41c8fa9-ac3d-4a84-9a33-b1e250556976n%40googlegroups.com.

[deal.II] Cluster installation error with symengine library

[Stephanie Sparks]

Hello,

I am trying to install deal.ii on my university cluster and have been 
successful up to this point; however, when I attempt to run examples I get 
the following error:

./step-1: error while loading shared libraries: libsymengine.so.0.7: cannot 
open shared object file: No such file or directory

I found an entry in the FAQ regarding similar problems with linking PETSc 
and attempted to use that fix but I'm still running into the same issue.

Any help would be greatly appreciated.

Thanks,
Stephanie

-- 
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/7f89d9d5-edb5-4efb-a99d-e0727aaa228fn%40googlegroups.com.

Re: [deal.II] Periodic bc for dim=1

[Praveen C]

I am getting compilation error

[100%] Linking CXX executable main
Undefined symbols for architecture arm64:
  "void 
dealii::GridTools::collect_periodic_faces >(dealii::parallel::distributed::Triangulation<1, 1> const&, unsigned int, 
unsigned int, int, 
std::__1::vector::cell_iterator>, 
std::__1::allocator::cell_iterator> > >&, dealii::Tensor<1, 
dealii::parallel::distributed::Triangulation<1, 1>::space_dimension, double> 
const&, dealii::FullMatrix const&)", referenced from:
  CGSEM<1>::setup_box_grid() in cgsem.cc.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Maybe I am doing something wrong.

Thanks
praveen

> On 08-Feb-2022, at 1:19 PM, Peter Munch  wrote:
> 
> What do you mean by "does not work for 1D"? In hyper.deal 
> (https://github.com/hyperdeal/hyperdeal), we also have PBC in "1D".
> 
> Peter
> 
> On Tuesday, 8 February 2022 at 06:34:42 UTC+1 Praveen C wrote:
> Dear all 
> 
> I was trying to write a code that works for 1/2/3d navier stokes. 
> 
> But it seems like collect_periodic_faces does not work for 1d ? Is this the 
> case, and is there any other way to deal with this situation ? 
> 
> Thanks 
> praveen
> 
> -- 
> 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/3dec29d1-bb19-4f58-8c8f-35568ceaf754n%40googlegroups.com.

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this 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/14A465D2-B15A-4ADD-A7EA-99C8C7037857%40gmx.net.