[deal.II] Re: What is the path to the dealii installation directory in a containerized version?

[Jhon Uribe]

*This is the problem:*

*I have the following files (in the directory 
/home/dealii/documents/examples_backup/step-1):*

dealii@9b28e44a5519:~/documents/examples_backup/step-1$ ls 
CMakeLists.txt  doc  step-1.cc

*Then I write the following command:*

dealii@9b28e44a5519:~/documents/examples_backup/step-1$ cmake .

*And the following error is printed:*

CMake Error at CMakeLists.txt:30 (MESSAGE):
  

  *** Could not locate a (sufficiently recent) version of deal.II.  ***

  

  You may want to either pass a flag -DDEAL_II_DIR=/path/to/deal.II to cmake

  or set an environment variable "DEAL_II_DIR" that contains this path.


-- Configuring incomplete, errors occurred!


El martes, 30 de julio de 2019, 15:48:47 (UTC-5), Jhon Uribe escribió:
>
> Hello
>
> I am using a container from the image 
> v9.1.1-gcc-mpi-fulldepsspack-debugrelease, but when I try to use the 
> command "cmake -DDEAL_II_DIR=/path/to/installed/deal.II .", I don't know 
> what to replace the string "/path/to/installed/deal.II" for.
>
> Thank you for your attention
>
>

-- 
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/823289e9-5753-4e12-ae63-f420586559af%40googlegroups.com.

Re: [deal.II] Step 31: Preconditioner correspondence

[Wolfgang Bangerth]

On 7/30/19 9:47 AM, Franco Milicchio wrote:
> Dear all,
> 
> As I am moving towards understanding the wrappers, I am facing a problem 
> in making Step 31 converge. My previous question is answered, and it 
> compiles. Yet, I am still wondering what kind of "pure deal.II" 
> preconditioner I could use in that tutorial.
> 
> Specifically, there are two in the tutorial (using Trilinos).
> 
>   * PreconditionAMG is an algebraic multigrid using a Chebyshev
> smoother, used to solve the stokes problem.
>   * PreconditionIC is an incomplete Cholesky, used to retrieve the
> temperature.
> 
> Now my implementation runs (with results), but I am aware my choices are 
> not the best ones. Please note that I am using just deal.II without 
> PETSc now as I am unable to run codes that require MPI (so, no Hypre). 
> I've chosen to use:
> 
>   * SparseILU for the stokes problem.
>   * IdentityPreconditioner for the temperature.
> 
> Do you have any suggestions? I could also use PETSc, but MPI is not an 
> option.

Preconditioner design is hard -- which is why I've recorded 4 or so 
lectures on the topic ;-)

The Stokes problem is symmetric, so you can probably gain a bit by using 
an incomplete Cholesky decomposition for it instead of the ILU.

The temperature equation is, I believe, symmetric in step-31 as well 
(the advection is treated explicitly IIRC) and so a sparse IC would work 
again. (If we decided to treat advection implicitly -- I just don't 
recall --, then an ILU would again be the correct choice.)

But in reality, neither ILU nor IC are particularly good 
preconditioners. They're expensive to compute and, unless you have very 
good strategies for deciding which fill-in you want to allow (which we 
don't have in deal.II), then they're not all that much better than an 
SSOR or SOR preconditioner -- which you can of course also try. The 
strategies used in the tutorial are chosen well, but require 
implementations of algorithms that just aren't available in deal.II.

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/50f64a97-2f3c-5bff-01f4-bc83ad58e478%40colostate.edu.

[deal.II] What is the path to the dealii installation directory in a containerized version?

[Jhon Uribe]

Hello

I am using a container from the image 
v9.1.1-gcc-mpi-fulldepsspack-debugrelease, but when I try to use the 
command "cmake -DDEAL_II_DIR=/path/to/installed/deal.II .", I don't know 
what to replace the string "/path/to/installed/deal.II" for.

Thank you for your attention

-- 
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/080a5675-bb2b-4e4f-896d-f8a1f01db0ce%40googlegroups.com.

Re: [deal.II] Number of Lines in the Deal.ii Library

[Wolfgang Bangerth]

On 7/30/19 2:30 PM, Jean-Paul Pelteret wrote:
> 
> Thanks for sharing! Those numbers are certainly thought provoking. It 
> would appear that we (being the collective community) have been putting 
> in a few minutes here and there to write this FEM library :-D

We might have :-)


> The “bundled” folder includes third party libraries, so I think that it 
> would be disingenuous for one to include those contributions in such an 
> assessment of the size of the code base. But if you want to get the most 
> representative figures for the library itself, then the having a line 
> count for the “cmake”, “doc”, “include”, “examples” and “source” would 
> give the most accurate representation of the size of the functional part 
> of the library. We already know that there are on the order of 1 
> unit tests, so having an individual assessment of the “tests” folder 
> would be interesting. If you’re willing to re-run your analysis while 
> taking my comments into consideration, then I’d certainly be interested 
> to see the new results!

There is actually a script in contrib/utilities/count_lines.sh that 
counts lines and also shows how to visualize the data. It would be 
interesting to use cloc for that script :-)

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/bfd762e4-2dad-626e-5228-afb601786bc0%40colostate.edu.

Re: [deal.II] How to efficiently add / remove cells (maybe with hp::DoFHandler)

[Mathias Anselmann]

Dear Professor Bangerth,

thanks for your reply, I hope I can answer your questions:

I can see that this doesn't look right. But do you understand *why* 
> things go wrong? I can't tell from the pictures, but I've often found 
> that when trying to solve a problem for which I know that there is a bug 
> somewhere, then it's worthwhile investing the time to *understand* why 
> it is wrong, rather than trying to come up with completely different 
> ways of doing this. 
>

Oh yes, I actually did not assume my current way of doing things to work.
After the static case was running, it was just a one liner (calling 
set_fe_indices() again in each timestep) which was a really naive way of 
doing things.
The problem at the moment is, that I just change the fe_index from pure 
FE_Nothing to my actual FE_System without updating my sparsity pattern, and 
re-initializing my matrices / vectors.
To be honest I didn't even think, that this code runs in debug mode but 
throws an assertion, but it didn't...

So the two option 1 and 2 are the things, that I see, which can "fix" my 
problem.


No, I would venture the guess that the cost of assembling and solving 
> linear systems is still the dominant factor. 
>
That's definitely right. Nevertheless I guess transferring old solutions 
with no degrees of freedom on an ancient FE_Nothing cell to an updated 
version where this cell has degrees of freedom might become tricky.

The problem with the second way is that just not using FE_Nothing but 
instead my normal FE_System and setting all degrees of freedom to "0" on 
the former FE_Nothing cells will not help either, since I use continuous 
elements and don't want my interior ("0"-solid-solution) to interchange 
with my outer (flow)-solution on the "cut-cells". I guess one way to 
overcome this issue is to set all DoF on a "former FE_Nothing cell" to "0" 
besides the DoFs that also belong to a cut-cell neighbor?

Greetings,

Mathias

-- 
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/1efec3ae-5713-42da-ad3e-6b0874e225e9%40googlegroups.com.

Re: [deal.II] Number of Lines in the Deal.ii Library

[Jean-Paul Pelteret]

Hi Jason,

Sorry, replying to your message has been on my TODO list for quite some time.

Thanks for sharing! Those numbers are certainly thought provoking. It would 
appear that we (being the collective community) have been putting in a few 
minutes here and there to write this FEM library :-D

The “bundled” folder includes third party libraries, so I think that it would 
be disingenuous for one to include those contributions in such an assessment of 
the size of the code base. But if you want to get the most representative 
figures for the library itself, then the having a line count for the “cmake”, 
“doc”, “include”, “examples” and “source” would give the most accurate 
representation of the size of the functional part of the library. We already 
know that there are on the order of 1 unit tests, so having an individual 
assessment of the “tests” folder would be interesting. If you’re willing to 
re-run your analysis while taking my comments into consideration, then I’d 
certainly be interested to see the new results!

Best regards,
Jean-Paul

> On 06 Jun 2019, at 06:42, 'Jason Nicholson' via deal.II User Group 
>  wrote:
> 
> I did a quick look at how many lines are in the Deal.ii library using "cloc". 
> I thought I would share.
> 
> [jnicholson@jhnlt001 dealii-master]$ ls
> bundled  CMakeLists.txt  CONTRIBUTING.mddoc   include  LICENSE.md 
>  source  VERSION
> cmakecontrib CTestConfig.cmake  examples  Jenkinsfile  README.md  
>  tests
> [jnicholson@jhnlt001 dealii-master]$ cloc .
>10523 text files.
>10118 unique files.  
> 1045 files ignored.
> 
> github.com/AlDanial/cloc v 1.74  T=27.75 s (341.6 files/s, 81345.2 lines/s)
> ---
> Language files  blankcomment  
>  code
> ---
> C/C++ Header  8467 242546 397541  
>   1194279
> C++633  54291  70135  
>248811
> CMake  232   2491   7289  
> 10324
> HTML28888  5  
>  5984
> CUDA14673   1023  
>  3283
> C6366444  
>  2010
> Python  16441976  
>  1812
> Assembly12173392  
>   939
> MATLAB  17292716  
>   927
> Fortran 77   2338   1309  
>   773
> Markdown10209  0  
>   748
> Windows Module Definition1  0  0  
>   718
> Perl11179379  
>   689
> make 4 84 69  
>   612
> Bourne Shell10132355  
>   467
> XML  4  9  8  
>   437
> CSS  2 68 22  
>   340
> Bourne Again Shell   8 74233  
>   281
> TeX  2 34 18  
>60
> DTD  1  0  6  
>15
> JavaScript   1  0  1  
>14
> ---
> SUM:  9481 303288 480921  
>   1473523
> ---
> 
> -- 
> 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/e56fddfc-13ac-4588-bf25-e4e0041ee867%40googlegroups.com
>  
> 

Re: [deal.II] Different solution with different software

[Jean-Paul Pelteret]

Hi Felix,

> Okay. When I read you e-mail I sincerely hoped it wasn't the problem. But it 
> was. Now the results match.

That’s great that this was an easy fix! I’m glad that you can now move along 
with your problem :-)

> I feel so so stupid. Such a rookie mistake. I already made this mistake 3 
> years ago and forgot about it.

Well now, I bet each one of us has who has been in the C++ game for a while 
carries around a list of “obvious” mistakes that they first look for when 
evaluating their own or someone else’s code. Don’t be too upset about this. I’d 
be embarrassed to admit how many times I’ve been tripped up by (what turn out 
to be) trivial errors. The important thing is to learn from it and try your 
hardest not to do it again!

> Thank you very much for taking the time to look through this part of the 
> code. I own you big time.
> 
> Thank you also Daniel for helping me. I will still try a manufactured 
> solution to learn about this process. 

You’re very welcome. I only had a couple of minutes to help, so its entirely 
coincidental that my contribution happened to be the one that assisted you the 
most. I pass the owed favour over to Daniel, who spent a lot more brain power 
thinking about your problem than I did. And I think that there’s certainly 
something to be learned about implementing a manufactured solution, so go for  
it!

> Thanks also to everyone that contributed to dealii.

Its always a delight for us to hear that the users of the library are happy 
with it. Thank you for your nice compliment! We hope that in the future you’ll 
also be on the contributors list, with either a little patch or hopefully 
something more!

> Its the perfect library for people that are not as stupid as me.

Seriously, don’t be too hard on yourself. We’ve all made (and will continue to 
make) these sorts of mistakes from time to time :-)

Best,
Jean-Paul

> On Thursday, July 25, 2019 at 7:28:13 PM UTC+2, Jean-Paul Pelteret wrote:
> Dear Felix,
> 
> I don’t claim to have read through your comprehensive documentation of your 
> issue in any detail, but one observation of your code is that you have a 
> couple of suspect terms in your local matrix assembly. In particular, the 
> terms of this form
>> 1/2/phiscale*(u_j_y-v_j_x)
> do not compute to what you think they do. The compiler will read this from 
> left to right, and the first operation it sees is an integer divided by an 
> integer. Integer division in C++ will return the value of the quotient 
> rounded down (towards zero, if positive). There’s a more detailed explanation 
> here:
> https://stackoverflow.com/a/3602857 
> So these terms always compute zero! Here’s a short example if you need 
> further proof (looks at the debug output in the central column):
> https://godbolt.org/z/XJZ59h 
> 
> So what you need to do to fix this is to use operator precedence to make sure 
> that you’re always performing division with floating point numbers, or (IMO 
> the preferable solution) explicitly specify the factor 1/2 as a floating 
> point value, either by writing it as 1.0/2.0 or just 0.5.
> 
> I’ve got no idea if this is the only source of error in your code, but its 
> certainly not helping you :-) Good luck in sorting this out!
> 
> Best,
> Jean-Paul
> 
>> On 25 Jul 2019, at 16:10, Félix Bunel gmail.com 
>> > wrote:
>> 
>> One final remark for today, if I remove the two asymmetrical terms in my 
>> equation so it becomes :
>> 
>> 
>> 
>> Then all three codes gives back the same solution...
>> 
>> So I thought it would come from my assembly of this part of the system but I 
>> have checked and checked again... It should not come from my weak 
>> formulation since the fenics and dealii have the same one. 
>> Something to do with the matrix no longer being symmetrical ? But I used 
>> UMFPack as a solver so it should not be an issue...
>> 
>> Here is my assembly process for the stokes problem in case you see something 
>> wrong
>> void Elfe::stokes_assemble_system ()
>> {   //Fonction qui assemble le problème de Stokes
>> 
>> std::cout << BLUE << "Assemblage Stokes" << RESET
>>   << std::endl;
>> 
>> //On réinitialise la matrice et le rhs
>> stokes_system_matrix = 0;
>> stokes_system_rhs = 0;
>> 
>> //On charge de quoi extraire les valeurs
>> QGauss<2>  quadrature_formula(4);
>> const unsigned int   dofs_per_cell = stokes_fe.dofs_per_cell;
>> const unsigned int   n_q_points= quadrature_formula.size();
>> 
>> std::vector local_dof_indices (dofs_per_cell);
>> 
>> FullMatrix   local_matrix (dofs_per_cell, dofs_per_cell);
>> Vector   local_rhs (dofs_per_cell);
>> 
>> //Stokes values
>> FEValues<2> stokes_fe_values(stokes_fe, quadrature_formula,
>>  update_values | update_gradients | 
>> update_JxW_values);
>> 
>> double u_i, v_i;
>> double u_i_x, u_i_y, 

Re: [deal.II] Collapse vertex and apply constraint

[Wolfgang Bangerth]

On 7/30/19 1:28 PM, Daniel Garcia-Sanchez wrote:
> 
> I did 3 test which gave the same solution:
> 
>   * Original mesh. determinant(system_matrix) = 6.6e10
>   * Move vertex and do not apply constraint. determinant(system_matrix)
> = 6e11
>   * Move vert and apply constraint. det(system_matrix) = 1.2e12

You can't compute the determinant for anything but quite small matrices. 
It's not a numerically stable operation. The only way to determine 
whether a matrix is singular is to compute all eigenvalues and see 
whether one or more are "small" compared to the size of the other 
eigenvalues.

Can you do that for the matrices you have, and plot the eigenvalues in 
the same plot? Is there a qualitative difference?

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/7afaba23-6a4d-8254-cee8-8401c3a8eec2%40colostate.edu.

[deal.II] Re: Collapse vertex and apply constraint

[Daniel Garcia-Sanchez]

Hi,
I realized that the mesh is not clear in the solution images. Below you can 
find the meshes: with and without a vertex collapse.

Thanks!
Daniel

[image: solution_1.png]

[image: solution_2.png]



On Tuesday, July 30, 2019 at 9:28:47 PM UTC+2, Daniel Garcia-Sanchez wrote:
>
> Hi,
>
> I'm doing 3D electromagnetic simulations with Nelelec and NedelecSZ 
> elements. I would like to collapse some vertices in other to follow the 
> geometry.
>
> The matrix should be singular if you collapse a vertex but according 
> to Luca Heltai:
>
> You can get away with it if you add enough constraints to your system so 
> that each collapsed degree of freedom is identical (you can do this by 
> using the ConstraintMatrix class). This should be enough to remove the 
> singularity from the matrix (and it is often used as a trick to deal with 
> singular integrals).
>
> https://groups.google.com/forum/#!searchin/dealii/degenerate%7Csort:relevance/dealii/VLXWrUVh_18/ohiblJOlCtUJ
>
> I gave it a try with a simple simulation (step-6) with 25 dofs and a 
> rectangular mesh.
>
> I used add_line() and add_entry() from AffineConstraints
>
> If I collapse the vertex and don't apply the constraint, I still get the 
> right solution and the determinant is non zero. I expected the determinant 
> to be zero for this particular case. The matrix should be singular.
>
> I did 3 test which gave the same solution:
>
>- Original mesh. determinant(system_matrix) = 6.6e10
>- Move vertex and do not apply constraint. determinant(system_matrix) 
>= 6e11
>- Move vert and apply constraint. det(system_matrix) = 1.2e12
>
> Below you can find the simulations as you can see I always get the right 
> solution for all the cases.
>
> Why the determinant when I collapse the vertex and don't apply the 
> constraint is non-zero? The matrix should be singular.
>
> How do I find the dof asociated to a vertex? I just did try and error for 
> this particular test.
>
> Can I do the same trick in 3D for the Nedelec and NedelecSZ elements?
>
> How do I check the quality of a mesh and that the matrix is not singular? 
> I can't do the determinant for a large matrix.
>
> Thanks!
> Daniel
>
> [image: solution_1.png]
>
> [image: solution_2.png]
>
>

-- 
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/81c4a9cc-43d5-4b27-b683-6b9165eb5bf3%40googlegroups.com.

[deal.II] Collapse vertex and apply constraint

[Daniel Garcia-Sanchez]

Hi,

I'm doing 3D electromagnetic simulations with Nelelec and NedelecSZ 
elements. I would like to collapse some vertices in other to follow the 
geometry.

The matrix should be singular if you collapse a vertex but according 
to Luca Heltai:

You can get away with it if you add enough constraints to your system so 
that each collapsed degree of freedom is identical (you can do this by 
using the ConstraintMatrix class). This should be enough to remove the 
singularity from the matrix (and it is often used as a trick to deal with 
singular integrals).
https://groups.google.com/forum/#!searchin/dealii/degenerate%7Csort:relevance/dealii/VLXWrUVh_18/ohiblJOlCtUJ

I gave it a try with a simple simulation (step-6) with 25 dofs and a 
rectangular mesh.

I used add_line() and add_entry() from AffineConstraints

If I collapse the vertex and don't apply the constraint, I still get the 
right solution and the determinant is non zero. I expected the determinant 
to be zero for this particular case. The matrix should be singular.

I did 3 test which gave the same solution:

   - Original mesh. determinant(system_matrix) = 6.6e10
   - Move vertex and do not apply constraint. determinant(system_matrix) = 
   6e11
   - Move vert and apply constraint. det(system_matrix) = 1.2e12

Below you can find the simulations as you can see I always get the right 
solution for all the cases.

Why the determinant when I collapse the vertex and don't apply the 
constraint is non-zero? The matrix should be singular.

How do I find the dof asociated to a vertex? I just did try and error for 
this particular test.

Can I do the same trick in 3D for the Nedelec and NedelecSZ elements?

How do I check the quality of a mesh and that the matrix is not singular? I 
can't do the determinant for a large matrix.

Thanks!
Daniel

[image: solution_1.png]

[image: solution_2.png]

-- 
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/e8812f11-3d99-4ab3-847e-4e949262e501%40googlegroups.com.

Re: [deal.II] How to efficiently add / remove cells (maybe with hp::DoFHandler)

[Wolfgang Bangerth]

Mathias,

> I want to simulate how a solid moves in a fluid with a fixed mesh using 
> Cut-FEM. I implemented this using the hp-framework and set all the DoFs 
> where just the solid is to FE_Nothing. You can see this in (attached) 
> two pictures: overlay_0 shows a solid circle lying in a fluid. On 
> no_overlay_0 the overlay is removed and you see the the underlying 
> "solution" behind the cut and the 4 complete solid cells (the FE_Nothing 
> cells).
> 
> This works well, but the idea has always been to move now the solid in 
> the fluid. This works until the solid gets out of the starting 
> FE_Nothing cells. What I do in a naive way every timestep is I check 
> where the solid is and set the active FE index accordingly but this is 
> not enough, and the solution gets distorted. You see this in overlay_1 
> (distorsion top left of the solid should not be there) and in 
> no_overlay_1 you see that see that see just activated cells are not 
> continuous (and they should be, since I use continuous elements).

I can see that this doesn't look right. But do you understand *why* 
things go wrong? I can't tell from the pictures, but I've often found 
that when trying to solve a problem for which I know that there is a bug 
somewhere, then it's worthwhile investing the time to *understand* why 
it is wrong, rather than trying to come up with completely different 
ways of doing this.

This is because I may want to use the technique that doesn't work again 
at a later time, and it's useful to actually understand how to make it 
work. It's also possible that the bug is not in fact where one thinks it 
is, and then using a different approach isn't actually going to solve 
anything.


> So now I'm thinking of a proper and computationally cheap way to achieve 
> my goal and have two ideas in mind:
> 
> 1.) Using the hp-framework and FE_Nothing:
> After setting the right FE_Index I have call distribute_dofs(), update 
> my constraints and reinit all my matrices and vectors. I further have to 
> somehow transfer the old solution to the new "grid". I guess these 
> things make this option computationally expensive.

No, I would venture the guess that the cost of assembling and solving 
linear systems is still the dominant factor.


> 2.) Not using FE_Nothing:
> Just using the fluid FE everywhere on the mesh and set the DoF where the 
> solid is to "0" (by using constraints?). Since I use a relatively 
> complex block matrix (in parallel) with some non-quadratic blocks I 
> guess this probably means fiddling around with the corresponding matrix 
> entries to make the resulting matrix not singular?

You should be able to put these constraints into an AffineMatrix object 
for the whole DoFHandler. This will ensure that all rows and columns of 
the matrix are correct.

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/5837bcc6-5298-df87-6993-9ce76896d03b%40colostate.edu.

Re: [deal.II] Error on runnig the examples

[Wolfgang Bangerth]

On 7/30/19 5:41 AM, Javad Hashemi wrote:
> All files exist and accessible. 

But it doesn't seem to be available when you run cmake. Can you show us 
what you get when you do
   ls -l /root/math/dealii-9.1.1/lib/
? I will note that in general, it's a bad idea to run things as root. 
You should be running your programs as a regular user.

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/4abe20d1-d7a8-4b24-4660-3498d3993a87%40colostate.edu.

[deal.II] Step 31: Preconditioner correspondence

[Franco Milicchio]

Dear all,

As I am moving towards understanding the wrappers, I am facing a problem in 
making Step 31 converge. My previous question is answered, and it compiles. 
Yet, I am still wondering what kind of "pure deal.II" preconditioner I 
could use in that tutorial.

Specifically, there are two in the tutorial (using Trilinos).

   - PreconditionAMG is an algebraic multigrid using a Chebyshev smoother, 
   used to solve the stokes problem. 
   - PreconditionIC is an incomplete Cholesky, used to retrieve the 
   temperature.
   
Now my implementation runs (with results), but I am aware my choices are 
not the best ones. Please note that I am using just deal.II without PETSc 
now as I am unable to run codes that require MPI (so, no Hypre). I've 
chosen to use:

   - SparseILU for the stokes problem.
   - IdentityPreconditioner for the temperature.

Do you have any suggestions? I could also use PETSc, but MPI is not an 
option.

Thanks for your help!
Franco

-- 
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/1e6d7aac-8015-4369-851b-c4d3a168d7a3%40googlegroups.com.

Re: [deal.II] petsc & trilinos blocksparsematrix reinit with zero locally owned components

[Daniel Arndt]

Richard,

[...]
> The very last part (reinit) is working only iff every processor owns parts
> of fluid AND solid domain (which is so far not ensured).
> This behaviour can be seen running exactly the same problem with mpirun -n
> 2 or -n 3, which is attached.
>
> THE QUESTION IS NOW:
> How may one reinit the blocks in a BlockSparseMatrix, if not every
> subdomain has locally_owned_dofs in all blocks?
> Or what is the point I am missing here?
>
> I added a chunk of code at the end, that shows, that the
> block(block_row,block_col).reinit(...) fails, if the locally_owned indexset
> is empty.
>

This assertion was removed in https://github.com/dealii/dealii/pull/6106.
Either use a recent release or simply remove it in your copy of the deal.II
source files.

Best,
Daniel

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

[deal.II] petsc & trilinos blocksparsematrix reinit with zero locally owned components

[richard.schuss...@gmx.at]

Hello everyone,

(question formulated at the bottom, for further info read this)

I am working on an ALE-FSI code in deal.ii available here:
http://www.thomaswick.org/gallery_engl.html 
The nice feature of this specific method is, that with pulling back the 
fluid into the 
Lagrangian/undeformed/reference configuration 
(see. e.g. in publications from Wick, Richter, Jodlbauer, Langer etc)
one can use globally defined function spaces for (vector-valued) velocity 
and
displacement fields and for the scalar pressure.
Globally herein means, in solid and fluid domain, i.e., we can use the 
following:

FESystem fe;
fe (FE_Q(pressDegree+1), dim,  // velocities
 FE_Q(pressDegree+1), dim,  // displacements
 FE_DGP(pressDegree), 1),   // pressure

Now, as we want to efficiently solve this system using the preconditioners 
for 
each block independently, we use a LDU-decomposition ( Jodlbauer et al., 
2019, IJNME).
Therefore, we sort degrees of freedom via the cell->material_id(), which 
shall 
indicate fluid or solid subdomain. So, we get from
[vel ; def ; press] to [ vel_fluid ; def_fluid ; press_fluid ; vel_solid ; 
def_solid ; press_solid].

The setup() so far looks something like this [see setup.txt]:
---
1.) dist dofs.
2.) renumbering: Cuthill_McKee, component_wise & finally depending on 
material_id().
3.) count sizes of blocks (which gives correct numbers).
4.) create indexsets for locally owned & relevant dofs.
5.) setup constraints.
6.) create bdsp:

BlockDynamicSparsityPattern dsp (6,6);
std::vector  n_dof_per_block(6);
n_dof_per_block[0] = n_v_f;
n_dof_per_block[1] = n_u_f;
n_dof_per_block[2] = n_p_f;
n_dof_per_block[3] = n_v_s;
n_dof_per_block[4] = n_u_s;
n_dof_per_block[5] = n_p_s;

for (int i=0; i<6; i++)
for (int j=0; j<6; j++)
if (true) //n_dof_per_block[i] > 0 && n_dof_per_block[j] > 0)
dsp.block(i,j).reinit(n_dof_per_block[i], n_dof_per_block[j]);

dsp.compress();
dsp.collect_sizes();

DoFTools::make_sparsity_pattern (dof_handler, dsp,
constraints, false,
Utilities::MPI::this_mpi_process(mpi_communicator));

SparsityTools::distribute_sparsity_pattern (dsp,

dof_handler.locally_owned_dofs_per_processor(),
mpi_communicator,
locally_relevant_dofs);

7.) Now use bdsp to initialize system_matrix (LA::MPI::BlockSparseMatrix):

system_matrix.reinit (locally_owned_partitioning,
  locally_owned_partitioning,
  dsp,
  mpi_communicator);


The very last part (reinit) is working only iff every processor owns parts 
of fluid AND solid domain (which is so far not ensured).
This behaviour can be seen running exactly the same problem with mpirun -n 
2 or -n 3, which is attached.

THE QUESTION IS NOW:
How may one reinit the blocks in a BlockSparseMatrix, if not every 
subdomain has locally_owned_dofs in all blocks? 
Or what is the point I am missing here?

I added a chunk of code at the end, that shows, that the 
block(block_row,block_col).reinit(...) fails, if the locally_owned indexset 
is empty.

Thanks for any help in advance, 
Richard

-- 
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/f49d70e0-407f-4220-92ec-82905ff6dde1%40googlegroups.com.
  timer.enter_section("Setup system.");

  system_matrix.clear ();
  dof_handler.distribute_dofs (fe);  
  DoFRenumbering::Cuthill_McKee (dof_handler);

  // We are dealing with dim+dim+1 components for this
  // dim-dimensional fluid-structure interacion problem
  // Precisely, we use:
  // velocities:0
  // structure displacement:1
  // scalar pressure field: 2
  std::vector block_component (dim+dim+1,0); // velocity
  for (unsigned int i=0; i dofs_per_block (3);
  DoFTools::count_dofs_per_block (dof_handler, dofs_per_block, 
block_component);  
  const unsigned int n_v = dofs_per_block[0],
 n_u = dofs_per_block[1],
 n_p = dofs_per_block[2];

  // Now sort DoFs based on material_id, i.e., sort all DoFs NOT corresponding
  // to material_id == 0 (fluid) back and count material hits per block.
  unsigned int n_v_f = 0, n_u_f = 0, n_p_f = 0,
   n_v_s = 0, n_u_s = 0, n_p_s = 0;

  {
  std::vector  sort_back_material (dof_handler.n_dofs(), false);
  const unsigned int 

Re: [deal.II] Re: Porting tutorials to PETSc from Trilinos

[Franco Milicchio]

Thanks Daniel, now it runs.

Of course it won't converge, lacking preconditiones, but this is for 
another question.

Thank you!
Franco

-- 
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/f26d4349-7889-41d6-8349-71a33fa31f71%40googlegroups.com.

Re: [deal.II] Error on runnig the examples

[Javad Hashemi]

All files exist and accessible. Also, Cmake files are generated in the 
step-1 folder. But, I do not know why it does not work. I hope to get a 
suggestion for solving the problem.

Thanks, 

Javad
 

On Monday, July 29, 2019 at 9:13:21 AM UTC-4, Daniel Arndt wrote:
>
> Javad,
>
> I installed Dealii-9.1.1 successfully. So, I wanted to run step-1 and 
>> followed the command lines based on README instruction. But, I have faced 
>> an error that you can see as follow:
>>
>> root@Lenovo-PC:~/math/dealii-9.1.1/examples/step-1# cmake 
>> -DDEAL_II_DIR=/root/bin/dealii-9.1.1/ .
>> [...]
>> root@Lenovo-PC:~/math/dealii-9.1.1/examples/step-1# make
>> Scanning dependencies of target step-1
>> [ 50%] Building CXX object CMakeFiles/step-1.dir/step-1.cc.o
>> make[2]: *** No rule to make target 
>> '/root/math/dealii-9.1.1/lib/libdeal_II.g.so.9.1.1', needed by 'step-1'.  
>> Stop.
>> [...]
>>
>
> It looks like /root/math/dealii-9.1.1/lib/libdeal_II.g.so.9.1.1 is not 
> accessible. Does this file exist? Is it readable?
> Anyway, you should just install deal.II anew and make sure that the file 
> exists in the installation directory.
>
> Best,
> Daniel
>
>

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

Re: [deal.II] Re: merging meshes step 18

[Stephanie Rocha]

Thanks Sebastian!

I will look into it :)

On Tue, Jul 30, 2019 at 4:23 PM 'Sebastian Stark' via deal.II User Group <
dealii@googlegroups.com> wrote:

> Stephanie,
>
> To me it seems that your meshes of the cubes and the cylinders are
> completely unrelated. However the merge_triangulations() function will only
> merge coincident nodes of the respective meshes. So, in your case no nodes
> will be merged. If you want to make your example work with non-coincident
> meshes, you will have to implement constraints tying the relevant dofs
> together manually (which is quite awkward). But for your example I think
> it's more reasonable to make sure that the relevant nodes of your parts
> coincide. If it was just one cylinder shell (or 4 of them) I would say you
> can make up something combining GridGenerator::cylinder(),
> GridGenerator::cylinder_shell() and
> GridGenerator::hyper_cube_with_cylindrical_hole(). But as there are three
> cylinder shells it's probably easiest to use an external grid generator
> like gmsh to mesh the whole thing at once and import the mesh afterwards.
> As a starting point I guess tutorial step 49 might be very helpful for you:
> https://www.dealii.org/current/doxygen/deal.II/step_49.html
>
> I hope that gives you an idea.
>
> Regards, Sebastian
>
>
> On Tuesday, July 30, 2019 at 7:04:19 AM UTC+2, Stephanie Rocha wrote:
>>
>> Hello everyone,
>>
>> I am a masters student currently using deal.ii for the first time
>>
>> I am trying to modify the shape of step 18 into a top and bottom cubes
>> (who were supposed to be cylinders but that's a different story) with three
>> cylinder shells in between. My issue is that the geometry does not seem to
>> merge together. I am not sure if this is a node issue or if there is a
>> certain way to connect each shape face to face. It seems to only distribute
>> the stress to the top part and not throughout the entire geometry I
>> created.
>>
>> I attached the code and a picture to better visualize my predicament.
>>
>> Thanks to anyone willing to take a look.
>>
>> -Stephanie Rocha
>>
> --
> 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/f0216c17-7b0b-4e60-b0a0-de33d31522ba%40googlegroups.com
> 
> .
>


-- 
Respectfully,
-Stephanie Rocha

Student and class representative of MSS19 at ISU - International Space
University. Strasbourg, FR
Mechanical Engineer - University of New Mexico, USA

-- 
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/CAMTzkOsJ%2Bmq6oQWQ8Of1SsVBW03Lbrthj8iTeXDS3MjYhVS%3D8w%40mail.gmail.com.

[deal.II] Re: merging meshes step 18

['Sebastian Stark' via deal.II User Group]

Stephanie,

To me it seems that your meshes of the cubes and the cylinders are 
completely unrelated. However the merge_triangulations() function will only 
merge coincident nodes of the respective meshes. So, in your case no nodes 
will be merged. If you want to make your example work with non-coincident 
meshes, you will have to implement constraints tying the relevant dofs 
together manually (which is quite awkward). But for your example I think 
it's more reasonable to make sure that the relevant nodes of your parts 
coincide. If it was just one cylinder shell (or 4 of them) I would say you 
can make up something combining GridGenerator::cylinder(), 
GridGenerator::cylinder_shell() and 
GridGenerator::hyper_cube_with_cylindrical_hole(). But as there are three 
cylinder shells it's probably easiest to use an external grid generator 
like gmsh to mesh the whole thing at once and import the mesh afterwards. 
As a starting point I guess tutorial step 49 might be very helpful for you: 
https://www.dealii.org/current/doxygen/deal.II/step_49.html

I hope that gives you an idea.

Regards, Sebastian


On Tuesday, July 30, 2019 at 7:04:19 AM UTC+2, Stephanie Rocha wrote:
>
> Hello everyone, 
>
> I am a masters student currently using deal.ii for the first time 
>
> I am trying to modify the shape of step 18 into a top and bottom cubes 
> (who were supposed to be cylinders but that's a different story) with three 
> cylinder shells in between. My issue is that the geometry does not seem to 
> merge together. I am not sure if this is a node issue or if there is a 
> certain way to connect each shape face to face. It seems to only distribute 
> the stress to the top part and not throughout the entire geometry I 
> created. 
>
> I attached the code and a picture to better visualize my predicament. 
>
> Thanks to anyone willing to take a look. 
>
> -Stephanie Rocha  
>

-- 
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/f0216c17-7b0b-4e60-b0a0-de33d31522ba%40googlegroups.com.