Re: [deal.II] step-1 Error

2020-09-18 Thread Wolfgang Bangerth

On 9/18/20 3:37 PM, Scott Ziegler wrote:
Thanks for the response! I might be misunderstanding, but in my directory for 
step-1 I tried running the command exactly as "module load dealii" and I just 
get "bash: module: command not found" in return. What am I doing wrong?


Oh, it doesn't know the 'module' command. It's not that it doesn't know the 
module it's trying to load. Can you check how one would install the 'module' 
command?


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/7adff14b-5bff-9978-1b5d-a3c7b38924d4%40colostate.edu.


Re: [deal.II] Re: Initialization of PETSc::MPI::BlockSparseMatrix

2020-09-17 Thread Wolfgang Bangerth

On 9/17/20 9:07 AM, Gabriel Stankiewicz wrote:
I created IndexSets by using the function 
DoFTools::locally_owned_dofs_per_component() and then gathering all indices 
corresponding to displacement DoFs (three instances of IndexSet) into one 
IndexSet using IndexSet::add_indices() and the fourth instance correponded to 
electric potential DoFs. However, the function 
DoFTools::locally_owned_dofs_per_component() wasn't returning only locally 
owned DoFs but also the locally not owned ones.


No, that isn't right. This is a function that is so widely used that it is 
hard to believe that it would be wrong. If you think that it returns something 
wrong, I believe that your *understanding* of what this function returns is 
wrong, and that might lead to further confusion downstream when you are 
thinking how to initialize matrices.


There are quite a number of tutorial programs that build parallel block 
matrices. I know that step-32 does this for Trilinos, but I think that the 
parallel Navier-Stokes solver does it for PETSc. It would be useful to just 
compare your code with how these programs do it.


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/7456c0c4-d042-2455-50bc-659ddaf9de16%40colostate.edu.


Re: [deal.II] Separated domains in load balanding

2020-09-15 Thread Wolfgang Bangerth

On 9/14/20 7:29 PM, shahab.g...@gmail.com wrote:
I am using load balancing and I noticed after load balancing, that the cells 
owned by each processor are sometimes separated from each other. In other 
words, some processors may own cell domains that are not connected to each other.
As this increases the computational cost in my case, I was wondering whether 
it would be possible to limit the load balancing to define only adjacent cells?


Not with parallel::distributed::Triangulation. That class uses a partitioning 
algorithm that optimizes for the data structures used in storing 
triangulations, sometimes at the expense of creating these kinds of 
disconnected sub-domains. In practice, however, this has relatively little 
effect on the performance of programs to the best of our knowledge: Yes, it is 
not *optimal*, but it is good enough to not be a major problem in most cases. 
You state that it increases the computational cost -- that's true, but do you 
have evidence that that creates a bottleneck?


If you do need a different partitioning algorithm, you can use 
parallel::shared::Triangulation or, since deal.II 9.2, the 
parallel::fullydistributed::Triangulation class.


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/e8d17b06-a23c-c00a-1d8c-c3cc11464bb4%40colostate.edu.


Re: [deal.II] Reading in higher order meshes from GMSH

2020-09-15 Thread Wolfgang Bangerth

On 9/15/20 9:26 AM, Sepehr Moalemi wrote:


I am currently looking to see if Dealii has support for reading in higher 
order meshes.


Other than what Peter already mentioned, you must have a description of the 
geometry from which gmsh created the mesh. If that is available in a CAD 
format, you can also read that in. step-54 shows how to do that.


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/2fa0ccea-de26-4227-46fe-09b45bc2bc95%40colostate.edu.


Re: [deal.II] Problems with the two-phase flow problem calculated on a hyperball (Step.21)

2020-09-09 Thread Wolfgang Bangerth



Simon,

visit.pngThank you for your respone. Sorry, I did not think about the 
meaning of the modification in step.21. It was naive. But in my work, I solve 
only the Darcy equation (v velocity, p pressure) on a more complicated mesh, 
whichis similar to a Hyper_Ball. I have the same problems. So I tried to find 
a “simple case” with the same behavior to understandthe problem.


For example I solve the Darcy equation on a "HyperCube" with constant 
Dirichlet condition for the pressure (p=p_D on partial Omega). Then I get the 
trivial solution v = 0, p = p_D (=2000).
But if I use a “Hyper_Shell” or “Hyper_Ball” instead of a “Hyper_Cube”, then 
there are problems(see attachments) and I don't get the trivial solution. Why?


The question is: How exactly do you prescribe the boundary values? There are 
several steps associated with getting boundary values right:

* You need to generate a geometry
* If you have curved boundaries, you also need to make sure that the different 
parts of the boundary have the appropriate manifold objects associated with 
them to ensure that the mesh is refined in the correct way
* You need to associate different boundary indicators to different parts of 
the boundary
* You need to write a function that for a given points returns the appropriate 
boundary value.


I don't know how you implement all of these steps, but you should double check.

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/9672f2da-afca-5552-7f2d-e55c363b8fe4%40colostate.edu.


Re: [deal.II] Issue with unstructured hex mesh

2020-09-09 Thread Wolfgang Bangerth

On 9/9/20 12:31 PM, Paras Kumar wrote:


This does not say anything about the *absolute level of accuracy*. I would
not
be surprised if for a mesh like the one you show (in which pretty much every
hexahedron is poorly shaped), the solution is less than for the 
corresponding
tetrahedal mesh. But if you refine it a couple of times, you should get a
more
accurate solution. Is this not the case?

We also tried with a refined mesh (resulting in 360K elements as compared to 
120K elements for the mesh in pic-2.png), but the irregularities still remain 
as  can be seen in pic-4.png.Considering that fact that we wish to model 
multi-particle systems, such large number of elements would render such a 
mehsing approach computationally infeasible.


Right. But it helps illuminate where the problem may be.

From the look of it, the solution is at least smoother. That might suggest 
that the issue is not a bug in the code, but that the solution really does 
converge, though maybe slowly. Do you have the resources to do one more 
refinement, just to see whether the solution continues to get better? That's 
not going to be a production run, but a one-time computation that might take a 
day or two if necessary.




The quality of meshes matters for the absolute level of error. The hex 
meshes
you get by subdividing tets are generally quite poor, though I know of 
people
who are using these routinely and report that they nevertheless get good
accuracy. A better approach is certainly to see if you can find ways to
*directly* create hex meshes. gmsh can do this to some degree. For the 
sphere
you show, deal.II can also generate a high-quality mesh itself.

We have already tried several options available in GMSH, but it did not seem 
to work. Could you please suggest some tool for automatic "direct" Hex mesh 
generation.


I'm no expert in using gmsh, so if you say that you couldn't get it to work, 
then I have no other suggestion either.



Is it not a good idea to use the tet-to-hex approach for generating Hex 
meshes, since this appears to be the only feasible option with GMSH 
considering the complexity of the geometry.
The actual geometry in the current case comprises a spherical particle of 
material-2 embedded in a cube of material-1 (later, it could be 50 such 
particles embedded in the matrix). I went through the grid generation 
functions of deal.II but could not find any possibilities of  doing an 
"intersection" between triangulations as would be necessary for the matrix 
material. Did I miss something?


If it's just one sphere in a ball, then take a look at the various functions 
in namespace GridGenerator that build geometries with holes. If you take a 
look at these functions and how they are implemented, you will probably 
understand how you can generate a mesh for a single hole in a cube, and then 
combine it with a mesh for the spherical hole via GridGenerator::hyper_sphere.


That won't work if you have many inclusions. We generally deal with many 
inclusions by just using a regular mesh for the domain and at each quadrature 
point asking whether it is inside an inclusion or in the background material. 
Here is an example of how this could be done:

https://github.com/geodynamics/aspect/blob/master/benchmarks/nsinker/nsinker.cc
The value() returns the coefficient at a particular point. The mesh does not 
actually to to mesh these inclusions, we just leave it to each quadrature 
point. The benchmark this file implements is like this:

https://geodynamics.org/cig/news/research-highlights/november-2019/
You can find more information about this "nsinker" benchmark here:
https://tigerprints.clemson.edu/cgi/viewcontent.cgi?article=3528=all_dissertations

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/1239a949-4dc5-09c3-4dc7-7f455028f9cc%40colostate.edu.


Re: [deal.II] Issue with unstructured hex mesh

2020-09-08 Thread Wolfgang Bangerth



Paras,

I am working on homogenization of particulate nano-composites and thus have to 
solve the finite deformation quasistatics problem on different 
microstructures, such as one shown in the attachment pic-1.png.


In order to automate the generation of (2D & 3D) meshes for microstructures 
comprising of randomly distributed filler particles of arbitrary radius, we 
employ a self-written python code using GMSH for mesh generation. The setup 
works well for 2D but for 3D, the resulting mesh (left) culminates in 
irregularities in the stress contour as compared to that obtained with a 
structured mesh (right) as can be seen from the attachment pic-2.png. Due to 
the random spatial distribution and arbitrary size of particles, unstructured 
mesh appeared as the feasible option.


In order to verify that the cause of such irregularities is the mesh and not 
our solver (based on deal.ii), we tested the mesh in Abaqus and similar 
irregularities were observed, cf. pic-3.png. Refining the mesh does not help 
either.


That suggests that you are doing something wrong. I don't know what exactly 
the problem is, and in particular how you assign material properties to cells, 
but we know from theory that the finite element solution must converge to the 
exact solution if you just refine the mesh often enough. If it doesn't for 
you, then something is amiss.


This does not say anything about the *absolute level of accuracy*. I would not 
be surprised if for a mesh like the one you show (in which pretty much every 
hexahedron is poorly shaped), the solution is less than for the corresponding 
tetrahedal mesh. But if you refine it a couple of times, you should get a more 
accurate solution. Is this not the case?



Has anyone else working with unstructured Hex meshes, observed similar issues? 
Any clues on how to deal with this issue or on other tools (preferably open 
source) which one could use for generating better meshes in 3D would be of 
great help.


The quality of meshes matters for the absolute level of error. The hex meshes 
you get by subdividing tets are generally quite poor, though I know of people 
who are using these routinely and report that they nevertheless get good 
accuracy. A better approach is certainly to see if you can find ways to 
*directly* create hex meshes. gmsh can do this to some degree. For the sphere 
you show, deal.II can also generate a high-quality mesh itself.


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/814bb2bb-94d2-0dbc-43cc-4e4a1151518c%40colostate.edu.


Re: [deal.II] Periodic boundary conditions in Newton's method

2020-09-07 Thread Wolfgang Bangerth

On 9/7/20 6:40 PM, Jimmy Ho wrote:


I have a general question regarding the application of periodic boundary 
conditions in Newton's method when solving nonlinear equations. Should the 
periodic constraint be applied to the incremental Newton update, or directly 
to the total solution vector?


Periodicity constraints are not too different from the way you would deal with 
Dirichlet boundary conditions. step-15 discusses this in great length, and the 
solution is to make sure that your first iteration satisfies the periodicity 
constraints and that all updates do as well -- which ensures that all iterates 
do so, too.


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/dc4d35f1-98e9-25ed-f46f-22c990291083%40colostate.edu.


Re: [deal.II] What is the first and second index of the gradient tensor

2020-09-07 Thread Wolfgang Bangerth

On 9/7/20 6:21 PM, yuesu jin wrote:
   I want to contract the gradient tensor with another vector, such as 
T_ij*n_j, the gradient tensor is d_j u_i (d is the partial differential 
operator). I am wondering what is the first index of gradient tensor, i or j? 


I believe it is
  T_ij = d_j u_i
I know I documented this somewhere (maybe in FEValues::gradient() or 
FEValuesView::Vector::gradient) but if you can't find it, it would be nice if 
you could just try out and maybe suggest a place where this should be documented.


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/5074e87b-889e-5c44-77e6-62fcfc1be1da%40colostate.edu.


Re: [deal.II] Question about fe_value.divergence

2020-09-03 Thread Wolfgang Bangerth

On 9/3/20 4:50 PM, yuesu jin wrote:
   I read the step.20 again. It solves my question. I didn't understand what 
the non-primitive element talks about, now I know the necessity of that. Thank 
you!


Glad to hear!
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/e3574f42-2793-3f0e-e965-c2eac05ad244%40colostate.edu.


Re: [deal.II] Question about fe_value.divergence

2020-09-03 Thread Wolfgang Bangerth

On 9/3/20 1:28 PM, yuesu jin wrote:
   I am working on vector value finite element modeling. I read the pages 
https://www.dealii.org/current/doxygen/deal.II/group__vector__valued.html 
<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.dealii.org%2Fcurrent%2Fdoxygen%2Fdeal.II%2Fgroup__vector__valued.html=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7Cb30f39009c8c49c8fc8108d8503f8631%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637347581059635256=w%2BABjRZ1fzUdFfCQvw49JwLF7Inl3iEG4XR78VwlgoA%3D=0> which 
uses the fe_values.divergence and fe_value.grad, but I cannot find these two 
member functions in the FEValues\FESystem\FEValueBase categories. Could you 
give me the documentation page about these two functions?


These functions only exist in FEValuesViews::Vector and FEValuesViews::Tensor. 
You get that if you have something like


  FEValuesExtractors::Vector velocities(0);
  fe_values[velocities].divergence (...);

step-22 shows how this works in practice.

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/79b2e60e-86e5-b310-9b28-c5c96c3eb364%40colostate.edu.


Re: [deal.II] extract_dofs() extremely slow in for single-thread run?

2020-09-03 Thread Wolfgang Bangerth

On 9/3/20 1:16 AM, 'Maxi Miller' via deal.II User Group wrote:


Again, extract_dofs takes most of the time here. Is there an alternative 
approach for that, too?


There is a variation of extract_dofs() that returns its results in the form of 
a std::vector (as one of the arguments) instead of an IndexSet. Could 
you try and see whether that is substantially faster?


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/e4b9665c-7423-ff8c-10ec-951c18085c32%40colostate.edu.


Re: [deal.II] PETScWrappers::MPI::BlockVector with Direct Solver

2020-09-02 Thread Wolfgang Bangerth

On 9/2/20 8:49 AM, mau@gmail.com wrote:


I have read the documentation but I didn't find anything related to using 
BlockVector from PETScWrappers with a Direct Solver, for instance 
SolverPreOnly should work as a Direct Solver with PETScWrappers::PreconditionLU.


In my serial code I used SparseDirectUMFPACK, but it is incompatible with a 
PETScWrappers::MPI::BlockVector.


Is there any way to use a Direct Solver with PETScWrappers::MPI::BlockVector ?


No. You have to use non-blocked matrices and vectors if you want to use one of 
the PETSc direct solvers.


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/a58850e7-9651-e744-58d9-9ba88989bc3f%40colostate.edu.


Re: [deal.II] ABOUT OPERATING PETScWrappers::MPI::SparseMatrix

2020-08-30 Thread Wolfgang Bangerth

On 8/30/20 12:20 AM, xs...@berkeley.edu wrote:
Hi, I declared two same scale matrix A and B using 
PETScWrappers::MPI::SparseMatrix and assign values on these two matrixes. I 
want to do some operation on them to get another matrix C which equals h*A+B. 
How should I get the matrix C? Thank you very much.


This should work:

C = B;
C.add (h, A);

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/b049bd31-33fa-416a-9fbf-0a2a85353788%40colostate.edu.


Re: [deal.II] Problems with the two-phase flow problem calculated on a hyperball (Step.21)

2020-08-26 Thread Wolfgang Bangerth

On 8/26/20 7:05 AM, 'simon doersam' via deal.II User Group wrote:
In Step.21 (The two phase flow problem) I replaced the domain "Hyper_cube" 
with "Hyper_ball".
The numerical solution is unrealistic and appears to be numerical problems at 
all points,
where the boundary intersects with one of the following planes: E1: = {x \ in 
R ^ 3, x1 = x2}, E2: = {x \ in R ^ 3, x1 = x3}, E3: = {x \ in R ^ 3, x2 = x3}.


The pressure and the viscosity are partially negative at these points.

Can someone help me and explain why this is happening?


You also need to change the definition of boundary values:

  template 
  class SaturationBoundaryValues : public Function
  {
  public:
SaturationBoundaryValues()
  : Function(1)
{}

virtual double value(const Point ,
 const unsigned int /*component*/ = 0) const override
{
  if (p[0] == 0)
return 1;
  else
return 0;
}
  };

This simply doesn't make any sense with the geometry you are now using.

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/72cd864c-5a53-7fff-a7c0-9d9eb6b97b66%40colostate.edu.


Re: [deal.II] deal.ii Installation : expand_instantiations Error

2020-08-24 Thread Wolfgang Bangerth

On 8/24/20 3:40 PM, Aaditya Lakshmanan wrote:


I am not sure what the above means. I contacted support at NERSC for help and 
he responded as follows :

-
The problem is that somewhere in the cmake files it's missing:
```
find_library(ATP_SIGHANDLER_LIBRARY NAMES AtpSigHandler)
```
and then you need to add
```
target_link_libraries( ${ATP_SIGHANDLER_LIBRARY})
```
to the file that specifies the link step for `libdeal_II.g.so`

I had a look at the cmake files, but it's a pretty complex setup. I think it 
might be best to reach out to the developers again, and get them to 
incorporate those changes for cray systems.

-



Aaditya -- that would help, but the question is why that is necessary. What 
does this library do, and why do we need to link with it? If this kind of 
change is necessary for *every* project you want to install there, then the 
system setup is somehow broken -- so I suspect that there is a reason why the 
compiler requires linking with this project, but I don't know why. Can you ask 
you system support why this is necessary and why the compiler doesn't link 
these libraries in itself?


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/5e22e4bc-f6dc-12f4-5c46-c79f0f8b5edb%40colostate.edu.


Re: [deal.II] mmult memory leak with petsc

2020-08-18 Thread Wolfgang Bangerth



Hi Richard,


I do have approx. the same numbers, but on 4 cores (see screenshot).

Fortunately, I was able to adapt our little program here with success
- which I append here just for the sake of completeness, since I went on 
github and tried my best to propose that change, see
https://github.com/dealii/dealii/pull/10838 
<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdealii%2Fdealii%2Fpull%2F10838=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7Cda1531178e7b4705abac08d843a89035%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637333738540558308=1VdEvclgxPPonuEzf1nrSpc0TGmge9QTTXlkJ1snjPk%3D=0>

I hope that worked out, but I used git for the first time.


It's the first time at some time for everyone -- but we hope it won't be your 
last patch!




Nonetheless, some concerns of mine remain:
(i) if I allow in my application-code to actually change the row scaling of 
the right matrix in the product (assuming the vector has all nonzero entries),
I will actually get away with only 1 additional matrix being the product 
instead of 2 including the product and a temporary one (which was the one not 
destroyed)

by the cost of scaling and rescaling the right matrix in the product.


Right. You might not actually need this function, but it's still worth fixing 
:-)


(ii) The documentation says, that both Trilinos and PETSc actually rebuilding 
the sparsity pattern of the product,
so using compute_mmult_pattern in the setup of the product would be of no use, 
right?


For the moment that's correct. But the PETSc documentation provides a way how 
one could re-use a previously computed sparsity pattern. One could add a flag 
to the mmult function that switches between either telling PETSc to create a 
new sparsity pattern, or re-using the existing one.


If you only call the function once, I have no doubt that there is not much of 
a difference between using the deal.II and PETSc ways of creating sparsity 
patterns. It's a different story if you plan on calling this function multiple 
times using the same sparsity pattern.


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/cb2f1e20-d80f-e104-7d51-66f3ca05b4da%40colostate.edu.


Re: [deal.II] METIS Issue during Installation Process

2020-08-18 Thread Wolfgang Bangerth

On 8/18/20 11:44 AM, Ed Read wrote:
It does not even make it in the Build target obj_grid_debug and crashes with 
the METIS error as before. I will try and do 'make clean' with a serial build 
and see if that might help solve the problem.


That would surprise me, but give it a try. I'll come back to my original 
question: What version of METIS is this, and how did you install it?


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/85c75dc9-3498-e9ff-3aa5-52b1a966dd99%40colostate.edu.


Re: [deal.II] METIS Issue during Installation Process

2020-08-18 Thread Wolfgang Bangerth

On 8/18/20 10:37 AM, Ed Read wrote:


[ 76%] Built target obj_grid_debug
Makefile:149: recipe for target 'all' failed


The error is somewhere higher up. Run 'make -j1' and see what it gives you.

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/d3afde50-a707-a790-acd1-83a4990242bf%40colostate.edu.


Re: [deal.II] mmult memory leak with petsc

2020-08-18 Thread Wolfgang Bangerth



I took a look at the modified mwe you sent -- immediately noticing that you 
read though the whole thing,

which is amazing, considering that this is a google group!
So, thanks again for your time and effort, it is really appreciated!


:-)



I have been busy doing the following with our little toy problem:
(i)  Upgraded to deal.ii v9.2.0 with candi, together with PETSc 3.13.1 (and 
Trilinos 12.18.1).
(ii) Further stripped down the mwe and deleted unnecessary parts and moved all 
but the mmult() out of the 'main loop'.


So, I still observe the following:
using Trilinos, all is fine.

and using PETSc, using the call
leftMatrix.mmult(result, rightMatrix)
seems fine, whereas calling
leftMatrix.mmult(result, rightMatrix, vector)
still results in a memory leak for me.

Could you verify that again for me please?


I'm running this program and watching memory consumption in 'top', looking at 
the 'virt' and 'res' columns. It's growing very slowly: after 3.5 minutes, I'm 
now at about 2GB and 1GB, respectively. Is this about as much as you get as well?


Looking at the code in question, we end up in this function:
https://github.com/dealii/dealii/blob/master/source/lac/petsc_matrix_base.cc#L494-L561

Interestingly, I believe that your case specifically goes into line 539 
(please confirm), which then calls MatDuplicate. But we never delete that 
object again -- one could suspect that there needs to be a MatDestroy at the 
end of that block. Would you be interested in trying that out?


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/d02757ea-653d-87cd-6c32-f6a4f8ba56c0%40colostate.edu.


Re: [deal.II] METIS Issue during Installation Process

2020-08-18 Thread Wolfgang Bangerth

On 8/17/20 7:14 PM, Edward Read wrote:


I am trying to install Deal.ii on my new cluster, from the build screen output 
it looks there is a problem in finding METIS (which is installed). I am not 
exactly sure what is going on? Is there a way to hard code the METIS Path 
during the make process? I have attached the screen out from the CMAKE. Any 
thoughts or suggestions would greatly be appreciated.


Which version of METIS is this, and how did you install it? The error messages 
are all about a (presumed macro) METIS_EXPORT, but the version I have locally 
doesn't have that macro at all.


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/15be8907-77fc-cc93-5e04-bd5a1c538941%40colostate.edu.


Re: [deal.II] PETSc iteration does not converge

2020-08-17 Thread Wolfgang Bangerth

On 8/17/20 6:01 PM, yuesu jin wrote:
     I did nothing to verify those properties. because the single thread CG 
solver converged well. I used  different preconditioners in parallel version 
and single thread version. In the parallel version I used block Jacobi and in 
the single thread version I used Jacobi. How can I check if the parallel 
blocked sparse matrix is/ isn't symmetrical and positive definite?


Think of tests such as this:
* run on 1 processor, multiply a vector w of all 1s from the right, and output 
the resulting vector v=Aw on all processors

* run on >1 processors and repeat
Are the vectors the same for both cases? The matrix should be the same 
regardless of partitioning, but is it?


* repeat the same with Tvmult (multiplication from the left)

You can probably come up with many similar tests that check properties of the 
matrix, comparing between the single-processor and multiple-processor cases. 
The point is that you may not know the exact answer, but you know that the two 
cases should result in the same output.


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/1c573208-1579-e2c9-672d-f6463630eead%40colostate.edu.


Re: [deal.II] PETSc iteration does not converge

2020-08-17 Thread Wolfgang Bangerth




    I tried both, first I tried 1e-4*system_rhs.l2_norm(), it failed.


Then either the matrix is not symmetric/positive definite/whatever other 
property your iterative solver requires, or your preconditioner is unsuitable. 
What have you don to verify that your matrix has the necessary properties?



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/b87ee936-8e48-6f21-8d5c-5403e4dadb73%40colostate.edu.


Re: [deal.II] mmult memory leak with petsc

2020-08-17 Thread Wolfgang Bangerth


Richard,

I am working on incompressible flow problems and stumbled upon an issue when 
calling PETScWrappers::SparseMatrix::mmult(),
but before I describe the problem in more detail, let me comment on the basic 
building blocks of the MWE:


(i) parallel::distributed::Triangulation & either PETSc or Trilinos linear 
algebra packages
(ii) dim-dimensional vector-valued FE space for velocity components & 
scalar-valued FE space for pressure,

simply constructed via:
FESystem fe (FE_Q(vel_degree), dim,
                          FE_Q(press_degree), 1);

So, after integrating the weak form -- or just filling the matrices with some 
entries -- we end up with a block system

A u + B p = f
C u + D p = g.
To construct some preconditioners, we have to perform some matrix-matrix 
products:
either for the Schur complement
(a) S = D - C inv(diag(A)) B
or some A_gamma
(b) A_gamma = A + gamma * B inv(diag(Mp)) C.

Comletely ignoring now, why that might be necessary or not
(I know that there is the possibility of assembling a grad-div term and using a
Laplacian on the pressure space to account for the reaction term,
but that is not really an option in the stabilized case),
we need those matrix products, and here comes the problem:

using either PETSc or Trilinos I get identical matrix-products when calling 
mmult(), BUT
when using PETSc, the RAM is slowly but steadily filled (up to 500GB on our 
local cluster)


I came up with the MWE attached, which does nothing else than initializing the 
system

and then constructs the matrix product 1000 times in a row.


Nice! Can I ask you to play with this some more? I think you can make that 
code even more minimal:
* Remove all of the commented out stuff -- for the purposes of reproducing the 
problem it shouldn't matter.
* Move the matrix initialization code out of the main loop. You want to show 
that it's the mmult that is the problem, but you're having a lot of other code 
in there as well that could in principle be the issue. If you move the 
initialization of the individual factors out of the loop and only leave 
whatever is absolutely necessary for the mmult in the loop, then you've 
reduced the number of places where one needs to look.

* I bet you could trim down the list of #includes by a good bit :-)

You seem to be using a pretty old version of deal.II. There are a number of 
header files that no longer exist, and some code that doesn't compile for me. 
For your reference, attached is a version that compiles on the current master 
branch (though with a number of warnings). That said, it seems like the memory 
doesn't explode for me -- which raises the question of which version of 
deal.II and PETSc you use. For me, this is deal.II dev and PETSc 3.7.5.




Am I doing anything wrong or is this supposed to be used differently?
I am using dealii v.9.0.1 installed via candi, so maybe the old version is the 
reason.


Possible -- no need to chase an old bug that has already been fixed if you can 
simply upgrade.




Bonus question:
Is there a way similar to hand the sparsity patterns over to the mmult function?
(For the dealii::SparseMatrix there is, which is why I am asking)


DynamicSparsityPattern has compute_mmult_pattern, which should give you a 
sparsity pattern you can then use to initialize the resulting PETSc matrix.


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/fa4bb1b7-6540-2c19-7d33-08f5871f7c25%40colostate.edu.
/*
  This code is licensed under the "GNU GPL version 2 or later". See
  license.txt or https://www.gnu.org/licenses/gpl-2.0.html

  Copyright 2019: Richard Schussnig
*/

// Include files
#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 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
// #include 

#include 
#include 
#include 

// (Block-)LinearOperator and operations among those for the sub-solvers.
#include 
#include 
#include 

// Parameter handler for input-file processing at runtime.
#include 

namespace L

Re: [deal.II] Re: Anistropic refinement DG - saddle point problem

2020-08-17 Thread Wolfgang Bangerth

On 8/17/20 6:02 AM, jfgir...@gmail.com wrote:


I would like to open again the topic with another question. Is there any way 
to use the Meshworker to solve the DG formulation but using block matrix and 
vectors?   I couldn't find a proper way to do it with the Meshworker because I 
have to choose the component of the shape function when I am using the blocks 
matrix.


Ignore MeshWorker and instead build on the underlying MeshWorker::mesh_loop() 
functions. This is what the current versions of step-12 and step-47 do, for 
example. They don't care what matrix and vector type you use.


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/0ca0575b-41d2-cc78-66a5-052a15aa77c9%40colostate.edu.


Re: [deal.II] Question about complex value finite element

2020-08-16 Thread Wolfgang Bangerth

On 8/16/20 6:38 PM, yuesu jin wrote:
    Thank you very much! I found step-62 yesterday and I have compared the 
difference between them.  I want to write two versions and compare their CPU 
time to get an exact result.


That would be interesting to hear about -- please let us know what you find!
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/83a6c82a-925e-d121-bc29-3e05f1e6b918%40colostate.edu.


Re: [deal.II] PETSc iteration does not converge

2020-08-16 Thread Wolfgang Bangerth

On 8/14/20 9:20 PM, yuesu jin wrote:
I tried a few levels of the tolerance, 1e-3, 1e-4 ,1e-6 and 1e-8. 1e-3 
converged because that is in the same level with the solution. Error occurs 
below 1e-4.  I have tried the Jacobi preconditioner instead of SSOR in the 
single thread CG version, it converged as well.


Is this 1e-4 * system_rhs.l2_norm(), or just 1e-4? If the latter, what is the 
size of system_rhs.l2_norm()? You should choose a tolerance that is 
proportional to the norm of the 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/0cd8b66f-b168-c725-200f-b2bb6ff727d5%40colostate.edu.


Re: [deal.II] Question about complex value finite element

2020-08-16 Thread Wolfgang Bangerth

Yuesu,

   I am adding an absorbing boundary condition like step-24 did in the 
frequency domain, in which the time derivative gives a complex term.  I also 
found the complex acoustic wave problem step-29 which splits the complex wave 
function into two real parts.
   What I want to know is what if I directly set up the matrix and rhs vector 
as complex ? Why does step-29 says "/it is often more convenient to 
split complex valued functions into their real and imaginary parts and use 
separate scalar finite element fields for discretizing each one of them/" ?


The problem is that we don't have iterative solvers for problems in which the 
matrix and vectors store complex values. We can, however, use PETSc's 
complex-valued solvers as well as the SparseDirectUMFPACK solver. I think you 
probably want to look at step-62 and step-58 for other options.


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/168267e0-9fbd-fc96-e780-f697856b5572%40colostate.edu.


Re: [deal.II] PETSc iteration does not converge

2020-08-14 Thread Wolfgang Bangerth

On 8/14/20 5:53 PM, yuesu jin wrote:


I also wrote a single thread CG version, which converges well. The 
preconditioner in the parallel version is blockJacobi but the single thread 
version I used is SSOR. Does it matter to the convergence? Thank you!


Yes, in exactly the ways the error message shows: If you are using a different 
preconditioner, you should expect different convergence behavior.


Whether you should expect one or the other method to work (or fail) depends on 
the properties of the matrix you are trying to solve. I'd also check whether 
the residual 0.00295038 is large or small compared to the initial residual. 
What is the tolerance you are using in the SolverControl object?


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/91ed065a-a39b-c7ba-978a-704485da3387%40colostate.edu.


Re: [deal.II] Hanging nodes of a read-in mesh

2020-08-10 Thread Wolfgang Bangerth

On 8/9/20 10:10 PM, Feimi Yu wrote:
I'm solving for a SUPG stabilized slightly compressible Navier-Stokes 
equation, with a Schur complement type preconditioner.


I don't see why hanging nodes would make any kind of difference for this 
combination (in fact, for any equation). If I were you, I'd try to dig a bit 
further to come up with concrete evidence that the hanging nodes are your 
problem (I suspect that the problem is actually elsewhere) and then see how to 
address this. Having used hanging nodes for 23 years now, your hypothesis 
sounds unlikely to me.


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/e2611cf5-f3b2-b1c8-6f70-9930e2b99b73%40colostate.edu.


Re: [deal.II] Hanging nodes of a read-in mesh

2020-08-09 Thread Wolfgang Bangerth

On 8/9/20 7:22 PM, Feimi Yu wrote:


I realized something after I posted my question, so I removed it after a 
while. Sorry that my original post is not shown in the thread. After checking 
the output block IDs in ParaView I found that it was not
the unbalanced load that caused the slow computation, but somehow the hanging 
nodes themselves, which caused the change of condition number in the system 
matrix.


No, that too isn't your problem. Hanging nodes don't make the condition number 
significantly worse. What's the equation you're solving, and what's your 
solver and preconditioner?


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/8b2fa2ba-08a9-d5f2-fa65-54166a35ab9e%40colostate.edu.


Re: [deal.II] Output multiple fields with different discretization

2020-08-09 Thread Wolfgang Bangerth



>dataOutDisp.add_data_vector(solution.block(0), [...]
> ...
A probable solution could be to create a new DOfHandler during each output 
call for both the displacement as well as the phase-field and attach the 
respective solution blocks to their DofHandlers. Not sure this would work 
since the mapping which would be used for the phase-field would be based on a 
different DoFHandler. Also, this would probably be computationally expensive 
(not sure?)


Just output the whole vector (not just one block). If you don't want to 
visualize the fields that are in the other blocks, just don't visualize them 
even though they are in the output file :-)


Cheers
 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/bdff9525-81bc-2e00-19f9-8aafa75d3928%40colostate.edu.


Re: [deal.II] Hanging nodes of a read-in mesh

2020-08-09 Thread Wolfgang Bangerth

On 8/9/20 1:58 PM, Feimi Yu wrote:


I am doing a grid study of a 2D mesh. At first I simply applied a local 
refinement in the code for a specific region,
but it turns out this caused the load to be unbalanced among the ranks (the 
rank carrying the refined mesh is much more loaded than others)

and the computation became very slow.


Are you partitioning the mesh yourself, or are doing different things on 
different parts of the domain? I'm assuming that you are using 
parallel::distributed::Triangulation, which automatically partitions the mesh 
so that every process has roughly the same number of cells.



Then I tried refine the mesh and output 
it as a file, then read it in as regular mesh.
This time it seems that the hanging nodes are not properly treated. 


Yes. That's because the mesh format does not record which cells neighbor which 
cells. The only way to re-construct this kind of neighborship relationship is 
by checking which cells share a common face -- which refined children do not 
with their parent's neighbor.




(DoFTools::make_hanging_node_constraints() only search for cells
that have children, which is lost after the I/O I did). Is there any way to 
resolve this problem, by either re-balance the
computation load after local refinement or make the solver realize the hanging 
nodes?


Writing out and reading in will not work. The question is why your mesh is not 
load balanced.


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/a66b9374-6612-d30b-e1b4-1eb6ee9ea505%40colostate.edu.


Re: [deal.II] Output multiple fields with different discretization

2020-08-07 Thread Wolfgang Bangerth

On 8/7/20 11:20 AM, Paras Kumar wrote:


I have a query regarding writing the solution to a VTK file for visualization 
with PARAVIEW.  If one wanted to do this via a mapping based on the 
displacement field, then one could simply follow the output_results() function 
of step-44.
My question is that, Is it possible to write to the same vtk file, fields 
based on different MappingQEulerian 
<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.dealii.org%2F9.0.0%2Fdoxygen%2Fdeal.II%2FclassMappingQEulerian.html=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7Ccbd1a9a17b8540f0018708d83af62a7b%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637324176247361942=0fDQN1511kXggwdxcB8jf%2FO05Wn8ghyd3QzReWpRrqc%3D=0> 
objects and with different values of n_subdivsions for the 
data_out.build_patches 
<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.dealii.org%2F9.0.0%2Fdoxygen%2Fdeal.II%2FclassDataOut.html%23a5eb51872b8736849bb7e8d2007fae086=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7Ccbd1a9a17b8540f0018708d83af62a7b%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637324176247371938=d1P5xlbOdyblD2C38dcCkBaFpm2sCqSI8HWRFvKNYtw%3D=0>() 
function?


Paras:
No, you can't. But there is nothing that prevents you from creating two .vtu 
files that contain different things, and visualizing the at the same time. 
Both paraview and visit allow you to open several .vtu files at the same time 
and showing their contents in the same window.


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/33bc0633-a14d-5084-abef-cf27c14f7a4b%40colostate.edu.


Re: [deal.II] error: cannot declare field ‘CoupledTH<3>::triangulation’ to be of abstract type ‘dealii::parallel::distributed::Triangulation<3, 3>’

2020-08-07 Thread Wolfgang Bangerth
  const Point& p, const unsigned int /*component*/) const {
                        ^
In file included from /home/shyaan/thm/src/main.cc:6:0:
/home/shyaan/thm/./include/sourceterm.h: In instantiation of ‘double 
EquationData::PressureSourceTerm::value(const dealii::Point&, 
unsigned int) const [with int dim = 3]’:

/home/shyaan/thm/src/main.cc:84:1:   required from here
/home/shyaan/thm/./include/sourceterm.h:35:16: warning: unused variable ‘time’ 
[-Wunused-variable]

    const double time = this->get_time();  // get time
                 ^~~~
/home/shyaan/thm/./include/sourceterm.h:30:57: warning: unused parameter ‘p’ 
[-Wunused-parameter]

  double PressureSourceTerm::value(const Point& p,
                                                          ^
In file included from /home/shyaan/thm/src/main.cc:1:0:
/home/shyaan/thm/./include/boundaryvalues.h: In instantiation of ‘double 
EquationData::TemperatureDirichletBoundaryValues::value(const 
dealii::Point&, unsigned int) const [with int dim = 3]’:

/home/shyaan/thm/src/main.cc:84:1:   required from here
/home/shyaan/thm/./include/boundaryvalues.h:81:16: warning: unused variable 
‘time’ [-Wunused-variabl]

    const double time = this->get_time();
                 ^~~~
/home/shyaan/thm/./include/boundaryvalues.h: In instantiation of ‘double 
EquationData::PressureDirichletBoundaryValues::value(const 
dealii::Point&, unsigned int) const [with int dim = 3]’:

/home/shyaan/thm/src/main.cc:84:1:   required from here
/home/shyaan/thm/./include/boundaryvalues.h:40:16: warning: unused variable 
‘time’ [-Wunused-variabl]

    const double time = this->get_time();  // get time
                 ^~~~
In file included from /home/shyaan/thm/src/main.cc:6:0:
/home/shyaan/thm/./include/sourceterm.h: In member function ‘double 
EquationData::PressureSourceTerm::value(const dealii::Point&, 
unsigned int) const [with int dim = 3]’:
/home/shyaan/thm/./include/sourceterm.h:44:1: warning: control reaches end of 
non-void function [-Wreturn-type]

  }
  ^
In file included from /home/shyaan/thm/src/main.cc:1:0:
/home/shyaan/thm/./include/boundaryvalues.h: In member function ‘double 
EquationData::PressureNeumanBoundaryValues::value(const 
dealii::Point&, unsigned int) const [with int dim = 3]’:
/home/shyaan/thm/./include/boundaryvalues.h:137:1: warning: control reaches 
end of non-void function [-Wreturn-type]

  }
  ^
/home/shyaan/thm/./include/boundaryvalues.h: In member function ‘double 
EquationData::TemperatureNeumanBoundaryValues::value(const 
dealii::Point&, unsigned int) const [with int dim = 3]’:
/home/shyaan/thm/./include/boundaryvalues.h:174:1: warning: control reaches 
end of non-void function [-Wreturn-type]

  }
  ^
/home/shyaan/thm/./include/boundaryvalues.h: In member function ‘double 
EquationData::PressureDirichletBoundaryValues::value(const 
dealii::Point&, unsigned int) const [with int dim = 3]’:
/home/shyaan/thm/./include/boundaryvalues.h:53:1: warning: control reaches end 
of non-void function -Wreturn-type]

  }
  ^
/home/shyaan/thm/./include/boundaryvalues.h: In member function ‘double 
EquationData::TemperatureDirichletBoundaryValues::value(const 
dealii::Point&, unsigned int) const [with int dim = 3]’:
/home/shyaan/thm/./include/boundaryvalues.h:98:1: warning: control reaches end 
of non-void function -Wreturn-type]

  }
  ^
CMakeFiles/thm.dir/build.make:62: recipe for target 
'CMakeFiles/thm.dir/src/main.cc.o' failed

make[2]: *** [CMakeFiles/thm.dir/src/main.cc.o] Error 1
CMakeFiles/Makefile2:163: recipe for target 'CMakeFiles/thm.dir/all' failed
make[1]: *** [CMakeFiles/thm.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

On Friday, 7 August 2020 08:10:10 UTC-7, Wolfgang Bangerth wrote:


 > Thank you for your reply. The complete code can be found on GitHub and
we also
 > have the instruction for compiling the code on TACC in UTA. This code
is in
 > the branch thm_seg_distributed. You may like to download it and build it.
 >
 > https://github.com/cb-geo/thm/tree/thm_seg_distributed

<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcb-geo%2Fthm%2Ftree%2Fthm_seg_distributed=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7Cb0e1ddaef91d4f79ecf308d83afc6cd0%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637324203116115798=4hDFUzAdKHSL0kF83cwsiHjbvGcq%2BPJr59%2FD2wQfdng%3D=0>

 >

<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcb-geo%2Fthm%2Ftree%2Fthm_seg_distributed=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7C27086d193c0142af7bd808d8399db8bc%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637322696859927190=Q40LdQEQ0g6X8dv%2BFnn%2BF44xtnrlGGiVg%2Fnp1rDaaL8%3D=0

<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcb-geo%2Fthm%2Ftree%2Fthm_seg_distributed=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7Cb0e1ddaef91d4f79ecf308

Re: [deal.II] error: cannot declare field ‘CoupledTH<3>::triangulation’ to be of abstract type ‘dealii::parallel::distributed::Triangulation<3, 3>’

2020-08-07 Thread Wolfgang Bangerth



Thank you for your reply. The complete code can be found on GitHub and we also 
have the instruction for compiling the code on TACC in UTA. This code is in 
the branch thm_seg_distributed. You may like to download it and build it.


https://github.com/cb-geo/thm/tree/thm_seg_distributed 
<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcb-geo%2Fthm%2Ftree%2Fthm_seg_distributed=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7C27086d193c0142af7bd808d8399db8bc%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637322696859927190=Q40LdQEQ0g6X8dv%2BFnn%2BF44xtnrlGGiVg%2Fnp1rDaaL8%3D=0>


Xiang,
this compiles fine for me. Can you show me the exact and complete error 
message you get with the version on github?


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/61921057-9ae5-acdf-56df-a2247bcc134e%40colostate.edu.


Re: [deal.II] Re: deal.II discussion group: Feedback and guidelines

2020-08-06 Thread Wolfgang Bangerth


Kaleem -- please use a subject for your email that indicates the concrete 
question you have.



The following error shown in step-49 during make run.
Exception on processing:


An error occurred in line <1430> of file 
 
in function
     void dealii::GridIn::read_msh(std::istream&) [with int dim 
= 2; int spacedim = 2; std::istream = std::basic_istream]

The violated condition was:
     in
Additional information:


Yes, thanks for reporting this. It's a bug in the library :-(

The problem is that two files that should be in this directory are not, in 
fact. If you take the two files attached to this email, and put them into the 
step-49/ directory, everything should work!


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/af3b3ed5-f17f-b714-7c9f-63352fb77090%40colostate.edu.
cl1 = 1;

Point(1) = {-1, 0.3, 0, 1};
Point(2) = {0.5, 0.3, 0, 1};
Point(3) = {-1, -0.5, 0, 1};
Point(4) = {0.5, -0.5, 0, 1};

Point(7) = {-0.3, -0.1, 0, 1};
Point(8) = {-0.2, -0.1, 0, 1};
Point(9) = {-0.3, 0.1, -0, 1};
Point(10) = {-0.4, -0.1, 0, 1};
Point(11) = {-0.3, -0.3, 0, 1};

Point(12) = {0.1, -0.1, 0, 1};
Point(13) = {0.2, 0.0, 0, 1};
Point(14) = {0.3, -0.1, 0, 1};

// lines of the outer box:
Line(1) = {1, 2};
Line(2) = {4, 2};
Line(3) = {1, 3};
Line(4) = {3, 4};

// the first cutout:
Ellipse(5) = {8, 7, 11, 9};
Ellipse(6) = {9, 7, 11, 10};
Ellipse(7) = {8, 7, 10, 11};
Ellipse(8) = {11, 7, 8, 10};

// the second cutout:
Line(9) = {12, 13};
Line(10) = {13, 14};
Line(11) = {14, 12};

// loops of the outside and the two cutouts
Line Loop(12) = {1, -2, -4, -3};
Line Loop(14) = {5, 6, -8, -7};
Line Loop(15) = {9,10,11};

// these define the boundary indicators in deal.II:
Physical Line(0) = {1, 2, 4, 3};
Physical Line(1) = {6, 5, 8, 7};
Physical Line(2) = {9, 10, 11};


// you need the physical surface, because that is what deal.II reads in
Plane Surface(16) = {12, 14, 15};
Physical Surface(17) = {16};

// some parameters for the meshing:
Mesh.Algorithm = 8;
Mesh.RecombineAll = 1;
Mesh.CharacteristicLengthFactor = 0.09;
Mesh.SubdivisionAlgorithm = 1;
Mesh.Smoothing = 20;
Show "*";


example.msh
Description: Mesh model


Re: [deal.II] Output of Gauss point stress tensor

2020-08-05 Thread Wolfgang Bangerth



  Thanks for the guidance. I tried 
replacing the " source/particles/particle_handler.cc 
<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdealii%2Fdealii%2Fpull%2F10589%2Ffiles%23diff-df7869b8ff6741c5bba620988f7bd995=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7Cd00ea92f27a5466d8a5e08d8395d0f41%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637322419138637595=CQSVVYYrHp5wMfy3INtkJBdS%2BNjFzBqLAdPwVHI1r%2FU%3D=0>" 
file with the one present in 
"https://github.com/dealii/dealii/pull/10589/files;. Also 
include/deal.II/particles/particle_accessor.h 
<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdealii%2Fdealii%2Fpull%2F10319%2Ffiles%23diff-ba98c140727c3e55b479f34172de381b=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7Cd00ea92f27a5466d8a5e08d8395d0f41%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637322419138637595=Y9F5eICnrFT8jNpnmg03tO3gb%2BWO%2B8xEqt9%2F9fucTBQ%3D=0> 
and source/particles/particle_accessor.cc 
<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdealii%2Fdealii%2Fpull%2F10319%2Ffiles%23diff-0b2cb32ab20618cd2a77e2ddfda9eddd=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7Cd00ea92f27a5466d8a5e08d8395d0f41%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637322419138647592=7ZHhT3M4M%2Bu2FaPwpR2qwSkJevjIip4d7%2BvaQrqmsG0%3D=0> 
from "https://github.com/dealii/dealii/pull/10319/files;. Then compiled again 
my deal.ii 9.2.0 but it gives error during compilation.


Yes -- we put about 10 changes every day into deal.II. You can't just replace 
individual files in 9.2 with the current development sources :-)



Therefore as a second option, I have created a simplified code which 
represents my problem. Kindly receive the files attached. Looking forward for 
your guiding response!


The code in question looks like this:

  Particles::Particle new_particle;
  new_particle.set_location(location);
  new_particle.set_reference_location(
  mapping.transform_real_to_unit_cell(cell, location));
  new_particle.set_id(next_unused_particle_id);

  SymmetricTensor<2, dim> strain; strain = 0;
  new_particle.set_properties(make_array_view(strain));

  particle_handler.insert_particle(new_particle, cell);

It is correct that set_properties() throws an exception here, because there 
really is no property pool associated with this particle. If you write it like 
this:


  auto inserted_particle
= particle_handler.insert_particle(new_particle, cell);
  inserted_particle->set_properties(make_array_view(strain));

then things will work if you also change the number of properties stored by 
the ParticleHandler object to dim*(dim+1)/2=6 (it is currently 'dim').


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/bc3f6ab2-bf49-1dc1-44fd-7e3b4e101a08%40colostate.edu.


Re: [deal.II] error: cannot declare field ‘CoupledTH<3>::triangulation’ to be of abstract type ‘dealii::parallel::distributed::Triangulation<3, 3>’

2020-08-05 Thread Wolfgang Bangerth

On 8/5/20 10:42 AM, 孙翔 wrote:


Please see the attached file, which is the head file that used the library. 
Thank you very much.


That's not enough -- you're using a file "interpolation.h" that I don't have, 
and parts of the rest of that file depend on this. You need to give me 
something that's sufficiently complete for me to try and compile this to 
obtain the error you see.


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/636a9090-e6ee-6afa-d1c8-13d6ced82885%40colostate.edu.


Re: [deal.II] error: cannot declare field ‘CoupledTH<3>::triangulation’ to be of abstract type ‘dealii::parallel::distributed::Triangulation<3, 3>’

2020-08-05 Thread Wolfgang Bangerth

On 8/5/20 10:13 AM, 孙翔 wrote:


I have included it actually, and also the distributed/grid_refinement.h was 
also included. Because I want to import the outside mesh to build up the 
triangulation, I also used Gridin to work on the triangulation, which is like 
as the following:


Then I have no other idea -- send us the file that produces the error, I think 
that's the only way we can help :-)


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/e24b8708-e9c3-7c24-ab46-318338e21bdb%40colostate.edu.


Re: [deal.II] error: cannot declare field ‘CoupledTH<3>::triangulation’ to be of abstract type ‘dealii::parallel::distributed::Triangulation<3, 3>’

2020-08-05 Thread Wolfgang Bangerth

On 8/5/20 3:01 AM, 孙翔 wrote:


error: cannot declare field ‘CoupledTH<3>::triangulation’ to be of abstract 
type ‘dealii::parallel::distributed::Triangulation<3, 3>’


I suspect that you forgot in
  #include 

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/cd47ef94-8ede-114e-6859-b604ef262cf4%40colostate.edu.


Re: [deal.II] Connecting UMFPACK in deal.II to Trilinos's Amesos solver

2020-08-04 Thread Wolfgang Bangerth

On 8/4/20 3:56 PM, Jimmy Ho wrote:


So, what should I do to properly connect UMFPACK in deal.II to Trilinos? Any 
suggestions are highly appreciated!


It's not going to work this way, I'm afraid. Trilinos wants a link to an 
external installation of UMFPACK (or SparseSuite, of which it is part of these 
days). deal.II doesn't actually create such an installation and instead just 
links everything into the deal.II libraries.


So what you want to do is to download UMFPACK, install it on your system, and 
point Trilinos to the installation.


(UMFPACK is still going to be part of the deal.II libraries, but that 
shouldn't create any problems.)


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/049d38a5-63f9-ce9f-fe6c-b37482130f10%40colostate.edu.


Re: [deal.II] catching SolverControl::NoConvergence

2020-08-03 Thread Wolfgang Bangerth

On 7/31/20 3:44 AM, Alberto Salvadori wrote:
By the way, I noticed that there is no Trilinos wrapper for GMRES, yet the 
implementation of LA::MPI::SolverGMRES provides no error when
the trilinos flag is set. Is there any redirection to another solver? Is this 
a potential source of the unexpected behavior mentioned above?


Good question. Can you create a minimal test case for that as well?

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/365d58c8-9912-0ef1-961e-2dce77bd42e3%40colostate.edu.


Re: [deal.II] ERROR WHEN RUNNING THE CODE ON MULTIPLE NODES OF HPC

2020-08-03 Thread Wolfgang Bangerth

On 8/2/20 11:26 PM, 孙翔 wrote:


Yes, it cannot run on a cluster. Both of them run in release mode. I'm also 
curious about the error. I debug the code by outputting some specific values.


If you see any error, the first step always should be to run in debug mode 
instead. Make sure that that works, and only then is it worth your time to 
think about release mode!


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/be9258d4-07a7-bb8f-5620-d002eb5c71f0%40colostate.edu.


Re: [deal.II] ERROR WHEN RUNNING THE CODE ON MULTIPLE NODES OF HPC

2020-08-02 Thread Wolfgang Bangerth

On 8/2/20 1:50 AM, 孙翔 wrote:
Hi, I run my parallelized code which is similar to step-18 on HPC. When I run 
it in multiple mpi processes on a single node. It can give me a good solution. 
However, when I run it on multiple nodes of HPC and each node has one mpi 
process, it reported an error as follows.


Are you saying that the same number of MPI processes works when you run 
locally, but doesn't when run on a cluster? That doesn't make any sense -- 
nothing in the code depends on *where* these MPI processes run.


Are you running in debug mode in both cases?

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/3b096ae3-11a9-1149-543f-2e728f83a4d9%40colostate.edu.


Re: [deal.II] Output of Gauss point stress tensor

2020-07-31 Thread Wolfgang Bangerth

On 7/30/20 5:26 PM, Muhammad Mashhood wrote:


_But it gives the following error on running:_

/An error occurred in line <298> of file 
 in function
     void dealii::Particles::Particle::set_properties(const 
dealii::ArrayView&) [with int dim = 3; int spacedim = 3]

The violated condition was:
     property_pool != nullptr
Additional information:
[...]


I explored the mailing list and found someone from the community already had 
similar problem of assigning the properties to the particles where it was 
suggested to use following way of assigning the properties:


I believe that this is a bug that I fixed a while back:
https://github.com/dealii/dealii/pull/10589
https://github.com/dealii/dealii/issues/10590
Unfortunately, this happened after the 9.2 release. Are you in a position to 
work with the current development sources?


If this doesn't solve the problem, can you come up with a simplified piece of 
code that illustrates 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 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/ff615e6a-2422-0294-6de2-2fee5c6677c0%40colostate.edu.


Re: [deal.II] Unexpected behavior when using GridGenerator::subdivided_hyper_rectangle in parallel

2020-07-30 Thread Wolfgang Bangerth

On 7/30/20 10:11 AM, Jimmy Ho wrote:


As a follow-up question, upon calling compress(), will the local copy of the 
system matrix on a specific processor get updated to contain information from 
all other processors? In other words, if I print out the system matrix from a 
particular processor after calling compress(), is that the same global system 
matrix that the linear solver is solving?


Each processor only stores a subset of the rows of the matrix. During 
assembly, each processor computes a number of matrix entries, but it can not 
compute all entries for the rows of the matrix it owns -- some need 
contributions from other processes. The call to compress() makes sure the 
contributions from these other processes are sent to the one that owns these 
rows of the matrix.


In any case, after compress(), the rows each processor owns are correct -- but 
each processor doesn't know anything about the rows of the matrix it doesn't own.


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/9a27440e-2864-afb2-d21c-cecdcc229305%40colostate.edu.


Re: [deal.II] Installation didn't give any errors but when I tried make test, it failed all tests

2020-07-30 Thread Wolfgang Bangerth

On 7/30/20 3:59 AM, kaleem iqbal wrote:
I want to simulate FSI with elastic walls in bifurcation carotid arteries in 
2D. is it possible to use that geometry?


It is possible to use this geometry, but you need to generate a mesh for it. 
(See step-49 for mesh generation.)


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/6935fa53-0f02-121f-53dc-3489962b762f%40colostate.edu.


Re: [deal.II] Re: Memory loss in system solver

2020-07-29 Thread Wolfgang Bangerth

On 7/29/20 1:12 PM, Richard Schussnig wrote:


Great to hear that you were able to construct a minimal working example & 
pinpoint the error location,

that is already of great help, but please do share the MWE you have constructed!
I can also confirm, that this behaviour described in the previous posts does 
not(!) occur when running step-18

(I am running v.9.0.1, which is why I did not want to bother the mailing list).

If we have step-18 and your MWE, we simply compare and see, where the error 
might come from, right?

-Unfortunately though, I am not overly skilled when it comes to C++,
so maybe someone else might be kind enough to help us out on that one?


All help would definitely be appreciated! (Hi Richard :-)

Having the minimal example would be a great first step!.
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/1f1974a2-896c-0906-2f37-15c373339b50%40colostate.edu.


Re: [deal.II] catching SolverControl::NoConvergence

2020-07-29 Thread Wolfgang Bangerth

On 7/29/20 5:37 AM, Alberto Salvadori wrote:


try
{
iterate_on_tolerance = false ;
this->pcout << " AMG - Bicgstab " << std::flush ;

bicgstab.solve (this->system_matrix, distributed_incremental_displacement, 
this->system_rhs, preconditioner);

solver_control_last_step = bicgstab_solver_control.last_step();
}

catch ( SolverControl::NoConvergence )
{
iterate_on_tolerance = true ;
try
{
   ... whatever ...
}

My idea is: whenever  bicgstab.solve fails, for instance because the accuracy 
is higher than the tolerance, I want to catch the exception 
SolverControl::NoConvergence  and do something else. I am insecure if the 
above code is fine for this purpose, could you please address me  to a broader 
explanation ?


Yes, this is the equivalent code of what we have here in ASPECT:
https://github.com/geodynamics/aspect/blob/master/source/simulator/solver.cc#L502-L520
or more tailored to your situation:
https://github.com/geodynamics/aspect/blob/master/source/simulator/solver.cc#L838-L913


At any rate, it turns out that the code above works OK for PETSc, but not for 
trilinos - I do would like to use trilinos for the sake of memory leaks. 
Apparently , errors of kind


aztec00 error code #

take the lead with trilinos and the exception is not caught properly. I must 
have done something wrong.
Interesting. Can you again construct a small test case so we can see how to 
fix this?


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/7e852110-5dfe-4d1e-ef50-8fadd7a1e839%40colostate.edu.


Re: [deal.II] Output of Gauss point stress tensor

2020-07-29 Thread Wolfgang Bangerth

On 7/28/20 11:05 AM, Muhammad Mashhood wrote:


/.~/working_dir/step-42$ /step-42 p1_chinese.prm
Segmentation fault (core dumped)/

I tried to comment out the line "  , particle_handler(triangulation, mapping, 
/*n_properties=*/dim) " and by doing so the code starts running normally.


I have tried to run it in the debug mode but over there the program exits with 
following error:


/(gdb) r
Starting program: ~/working_dir/step-42/step-42
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
*** Call this program as <./step-42 input.prm>


You need to run the executable with
  r p1_chinese.prm
to make sure it loads the appropriate input file, or you will not see the 
segmentation fault in the debugger.




[Inferior 1 (process 5082) exited with code 01]/

Can there be a possible problem in using the " 
/particle_handler(triangulation, mapping, /*n_properties=*/dim) /" ? Thank you!


I don't know. Can you get a backtrace in the debugger?

It's something that ought to work. If you can't figure out what is happening, 
send me the exact .cc file you're trying to run and I'll take a look!


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/9d6e7acb-3b71-ee27-c819-062e7c77e4aa%40colostate.edu.


Re: [deal.II] HOW TO OUTPUT SYSTEM MATRIX IN A FILE

2020-07-29 Thread Wolfgang Bangerth

On 7/29/20 1:31 PM, Daniel Arndt wrote:
Of course, there is also 
PETScWrappers::MatrixBase::print(https://www.dealii.org/current/doxygen/deal.II/classPETScWrappers_1_1MatrixBase.html#a7515e640202d1ad50bd9baa13c404cb1 
<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.dealii.org%2Fcurrent%2Fdoxygen%2Fdeal.II%2FclassPETScWrappers_1_1MatrixBase.html%23a7515e640202d1ad50bd9baa13c404cb1=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7C741ab88a0bde4381989208d833f5fe8c%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637316478913030640=sOoVCUSnTWzX10j0pVHnVUHeafeQV4DWkEYAkjrqZAo%3D=0>) 
that should work.


Ah, yes, that's much better!
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/409e71cd-e027-1537-91de-af8726280cfd%40colostate.edu.


Re: [deal.II] HOW TO OUTPUT SYSTEM MATRIX IN A FILE

2020-07-29 Thread Wolfgang Bangerth

On 7/28/20 12:11 PM, 孙翔 wrote:
Hi, I followed step-17 and build a system matrix of which type 
is PETScWrappers::MPI::SparseMatrix. I want to output it after assembling. How 
should I do it? Thank you very much.


If performance doesn't matter, just loop over all indices i and j and output 
the value of the matrix. If you're running in parallel, you need to restrict 
the loop over i to the locally owned range.


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/879a7ef3-7c13-8142-d970-773e3a57e470%40colostate.edu.


Re: [deal.II] Unexpected behavior when using GridGenerator::subdivided_hyper_rectangle in parallel

2020-07-29 Thread Wolfgang Bangerth



Jimmy,

A minimum example to reproduce this is attached. When the mesh is built using 
GridGenerator::hyper_cube or GridGenerator::subdivided_hyper_rectangle with 
subsequent refinement, the program works as expected. When the same mesh is 
generated using GridGenerator::subdivided_hyper_rectangle without any 
subsequent refinement, some entries in the global stiffness matrix (the nodes 
on the right hand side of the mesh, in this case, using 2 processors) do not 
get updated. The example output of stiffness matrices when using one and two 
processors are also attached for reference.


So my question is, is this the expected behavior of the function? If so, why 
is that the case?


There is still a lot of stuff in the program that could be remove, including 
all of the comments, to make it substantially smaller and easier to understand.


I don't know whether there is a bug, but here is a suggestion: The finite 
element solution u_h(x) that results from the linear system should be the same 
independent of the partitioning. But the order of degrees of freedom may be 
different, and consequently the matrix may not be the same -- it should only 
be the same up to some column and row permutation. Have you verified that the 
*solution function* (not the solution vector) that results is the same 
independent of the number of processors?


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/8ae2f688-280f-9e71-414c-e519ffeaad82%40colostate.edu.


Re: [deal.II] Output cell variables as cell arrays in vtu files

2020-07-27 Thread Wolfgang Bangerth

On 7/27/20 2:47 PM, Jimmy Ho wrote:


data_out.add_data_vector( cellData , "Name" , data_out.type_cell_data );

to force deal.ii to recognize that "cellData" should be interpreted as a 
cell-based data. When I read the vtu files generated by this program via 
ParaView, I found that although cellData looks like it is cell-based in the 
visualization (i.e., it is discontinuous over the cells), the data array 
itself is stored as a point array, so I couldn't use the 
Cell_Data_to_Point_Data filter to get a smoothed and continuous visualization. 
So, is there a way to write a cell-based data into cell arrays in vtu files?


No, all data produced by DataOut is point data. For cell-wise constants, it is 
just written in a way that makes point data look piecewise constant.


You will have to find a different way to achieve what that filter does. What 
does it do? Maybe we can suggest a way to achieve the same from within 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/76ca040e-1369-93b2-6247-958fdb83b931%40colostate.edu.


Re: [deal.II] Complex-valued distributed matrices in dealii

2020-07-26 Thread Wolfgang Bangerth



Pascal,

Originally, I only knew Trilinos because I used the distributed matrices and 
vectors in my application. I also knew that there is a configuration of 
trilinos to make complex numbers available in all packages that support it.
However, from what I can tell, that only effects Tpetra datatypes, not Epetra. 
From what I have seen in the dealwrappers, they only use Epetra. An 
interesting detail about this is the Komplex-Package, which is described as an 
Epetra based solver for complex systems, which wraps Epetra matrices and 
stores the real and imaginary parts as blocks. (see here: 
https://docs.trilinos.org/dev/packages/komplex/doc/html/index.html 
<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.trilinos.org%2Fdev%2Fpackages%2Fkomplex%2Fdoc%2Fhtml%2Findex.html=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7Ca8809251f22f473d86cc08d83141f358%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637313506615095299=m%2BNl78twnMHlf3ByWf3OlsYX7WDK%2ByHz6ogeMVuKUBA%3D=0> )
At GitHub I can see that project 4 deals with adding Tpetra support which 
would make complex numbers in Tpetra usable in deal if the interface is built 
to support them)


Yes, Tpetra is the way to go in the long run. deal.II actually has Tpetra 
wrappers already, in namespace LinearAlgebra::TpetraWrappers. It is definitely 
our long-term goal to move from the Epetra interfaces to the Tpetra 
interfaces. The issue -- for several years already -- is that not all of the 
packages we use in Trilinos (for example for solvers, preconditioners, etc) 
support Tpetra. In other words, at least every time we looked, we could not 
replace our Epetra interfaces without losing functionality.


That said, it is definitely true that there are Trilinos packages for solvers 
and preconditioners that do support Tpetra, and for which we don't (yet) have 
any interfaces. So, if you are willing to help out with this situation, one 
approach worth pursuing would be to explore what Trilinos functionality you 
need, and then ask here or on github which pieces are already available and 
which still need to be written. None of the interfaces are very large, and 
writing more interfaces is not a very difficult task because there are already 
good examples to start from. We would certainly appreciate any help!



About GMRES: I will be using PETSc GMRES to solve my system, but if possible I 
will try to also solve it with dealii::SolverGMRES and let you know what happens.


Yes, feedback is welcome!

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/967f3eea-3051-6f58-3447-52d1bdba784a%40colostate.edu.


Re: [deal.II] Complex-valued distributed matrices in dealii

2020-07-25 Thread Wolfgang Bangerth

On 7/23/20 10:42 AM, Pascal Kraft wrote:


I have Trillions compiled with support for complex numbers and also searched 
through the LinearAlgebra documentation.


I don't think I knew that one can compile Trilinos with complex numbers. How 
do you do that?


It does not greatly surprise me that we use TrilinosScalar and double 
interchangeably. If Trilinos can indeed be compiled with complex numbers, then 
we ought to find a way to (i) make TrilinosScalar dependent on whatever 
Trilinos was compiled for, (ii) ensure that all of the places that currently 
don't compile because we use double in place of TrilinosScalar are fixed.


Patches are, as always, very welcome!


I require GMRES as a solver (which should be possible, because the GMRES 
Versions all use a templated Vector which can take complex components) and MPI 
distribution of a sparse system. I have so far only seen FullMatrix to accept 
complex numbers.


I believe that GMRES could indeed be made to work for complex-valued problems, 
but I'm not sure any of us have every tried. When writing step-58, I toyed 
with the idea of looking up in the literature what one would need for a 
complex GMRES, but in the end decided to just make SparseDirectUMFPACK work 
instead. The issue is that for every matrix-vector and vector-vector operation 
that happens inside GMRES, you have to think about whether one or the other 
operand needs to be complex-conjugated. I'm certain that is possible, but 
would require an audit of a few hundred lines. It would probably be simpler to 
just use PETSc's (or Trilinos') GMRES implementation.


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/0a11242b-16e1-7c2b-681e-398602d2c60c%40colostate.edu.


Re: [deal.II] Memory loss in system solver

2020-07-24 Thread Wolfgang Bangerth

On 7/24/20 3:32 AM, Alberto Salvadori wrote:


It turns out that this code produces a memory loss, quite significant since I 
am solving my system thousands of times, eventually inducing the run to fail. 
I am not sure what is causing this issue and how to solve it, maybe more 
experienced users than myself can catch the problem with a snap of fingers.


I have verified the issue on my mac (Catalina) as well as on linux ubuntu 
(4.15.0), using deal.ii 9.1.1.
Apparently the issue reveals only when mpi is invoked with more than one 
processor, whereas it does not emerge when running in serial or by mpirun -np 1.


Alberto -- I've taken a look at the SolverBicgstab class and don't see 
anything glaringly obvious that would suggest where the memory is lost. It's 
also funny that that would only happen with more than one processor because 
the memory handling of PETSc vectors shouldn't be any different for one or 
more processors.


Do you think you could come up with a simple test case that illustrates the 
problem? In your case, I'd start with the code you have and remove basically 
everything you do: replace the assembly by a function that just fills the 
matrix with the identity matrix (or something similarly simple), remove 
everything that does anything useful with the solution, remove graphical 
output, etc. The only thing that should remain is the loop that repeatedly 
solves a linear system and illustrates the memory leak, but the program no 
longer has to do anything useful (in fact, it probably shouldn't -- it should 
only exercise the one part you suspect of causing the memory leak).


I think that would make finding the root cause substantially simpler!

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/5a63f6c5-48b7-a40a-36c8-5e0ef5bed327%40colostate.edu.


Re: [deal.II] Location for Boundary Condition Application

2020-07-24 Thread Wolfgang Bangerth

On 7/23/20 11:47 AM, Daniel Arndt wrote:

McKenzie,

I'm interested in applying a non-homogeneous Dirichlet boundary condition
to a specific edge. However, I'm unsure how to identify or specify a
particular edge or face to add the boundary condition to. Could you help
clear this up for me?


What do you know about that particular edge? You can always ask faces or 
edges, e.g., about their midpoints. Have a look at 
https://www.dealii.org/current/doxygen/deal.II/step_6.html#Abettermesh 
<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.dealii.org%2Fcurrent%2Fdoxygen%2Fdeal.II%2Fstep_6.html%23Abettermesh=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7C89baeb6e175e40c6c58b08d82f306f84%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637311232357310913=1Jamkij%2BSaxretqshK2UkkMRsRIDxzHVgFQIP5i1mFw%3D=0>.


And here:
https://github.com/bangerth/dealii/blob/66/examples/step-19/step-19.cc#L303-L317
for an example where I'm setting different boundary indicators depending on 
the location of a face. These boundary conditions are then used when 
interpolating different boundary conditions here:

https://github.com/bangerth/dealii/blob/66/examples/step-19/step-19.cc#L340-L354
This is eventually going to become step-19.

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/8c48a006-dff5-4333-fc96-2c3a0a28d4e3%40colostate.edu.


Re: [deal.II] Accessing nodal values of a FEM solution

2020-07-24 Thread Wolfgang Bangerth

On 7/23/20 12:07 PM, Xuefeng Li wrote:


Well, the above function calculates the gradients of a finite element at the 
quadrature points of a cell, not at the nodal points of a cell.

Such a need arises in the following situation.

for ( x in vector_of_nodal_points )
   v(x) = g(x, u(x), grad u(x))


It's worth pointing out, however, that for the common FE_Q elements, the 
function values u(x) are continuous and so it doesn't matter how exactly you 
compute u(x) at node points. On the other hand, grad u(x) is in general 
discontinuous and so trying to evaluate it at node points is not actually 
possible: You will either get the values from one adjacent cell or the value 
from another.


In other words, if you want to compute a function that depends on 'grad u', 
you need to think about what exactly you mean by that. In the formulation 
above, v(x) will in general be a discontinuous function, and you need to think 
about whether using FE_Q (a continuous finite element space) is really what 
you want to do.


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/d2d54493-3b73-2f2f-8002-c3f9ef317177%40colostate.edu.


[deal.II] Denis Davydov stepping down as Principal Developer

2020-07-19 Thread Wolfgang Bangerth



All,
Denis Davydov, who has been one of the Principal Developers of deal.II since 
2015, has decided to step down from this role after leaving academia last 
year. I would like to take the opportunities to say a few words about him.


Denis is an applied mathematician with a focus on mechanics problems, and more 
specifically on quantum mechanical models of materials. He originally was a 
user of deal.II, like most on this mailing list, but eventually started 
contributing code and, after some time, becoming a principal developer. Going 
through the changelogs of the last few versions turns up quite a long list of 
functionality Denis has contributed -- I find it difficult to summarize 
because his work is really all over the library, but a short summary would 
have to include the following topics:

* A lot of Denis' work had a relationship to eigenvalue problems, and that led
 to substantial improvements of deal.II's support of complex-valued problems,
 new and improved interfaces to eigenvalue solvers ARPACK and SLEPc, as well
 as to the LAPACK and ScaLAPACK packages.
* He has also done a lot of work related to hp functionality, including
 classes that estimate the smoothness of a solution and can be used to
 decide between h and p refinement.
* There are also the parallel::shared::Triangulation class, the BFGS solver
 and line search functionality that are almost entirely his alone.

Projects like deal.II are technical in some sense, and it's easy to forget 
that those involved are people as well. One of the things I enjoy most about 
deal.II is the collective, that the people who run it get along well and are 
all also friends. Denis is Russian by origin, living in Germany. I don't think 
I've met him more than 3 or 4 times, but have always enjoyed his humor and 
humanity. I personally look forward to staying friends with him. As a project, 
we all owe him for both for his technical work as well as the personal touch 
and mentorship he has brought to his approach to leadership!


Thanks you Denis, and good luck on your future endeavors!
  Wolfgang, & all of the other Principal Developers

--
----
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/1639e56c-c470-cfee-dd1e-06a73bcc8f0f%40colostate.edu.


Re: [deal.II] Accessing nodal values of a FEM solution

2020-07-19 Thread Wolfgang Bangerth

On 7/19/20 6:28 PM, Daniel Arndt wrote:


The tutorial examples show only how to access values of the solution at
the quadrature points within each cell.

https://github.com/dealii/dealii/wiki/Frequently-Asked-Questions#how-to-get-the-mapped-position-of-support-points-of-my-element 
<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdealii%2Fdealii%2Fwiki%2FFrequently-Asked-Questions%23how-to-get-the-mapped-position-of-support-points-of-my-element=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7Cc61491e1703e46c5be0f08d82c43defe%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637308017305040965=TM3AYA4IqcrckUMqRTWfCJWUz3MGrUx%2FRFGvRrsg40Y%3D=0> 
might also be helpful.


You might also be interested in looking at the do_half_phase_step() function 
of step-58:


https://dealii.org/developer/doxygen/deal.II/step_58.html#ImplementingtheStrangsplittingsteps

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/e41d69b2-bfcd-5001-7559-876226768dce%40colostate.edu.


Re: [deal.II] [deal.ii]mesh import problem

2020-07-16 Thread Wolfgang Bangerth



Chen,


I want to import the mesh file exported by gmsh.
[...]

*Could anyone let me known how to import mesh ?*


First, our apologies for not replying to this issue earlier. These 
interactions with other programs are really thorny :-(


I've taken a look at your input VTK file. The first issue is that our reader 
in GridIn expects (maybe unreasonably so) that cells are listed before lines 
in the CELLS section. This is relatively easy to fix by swapping the lines and 
cells in the CELLS and CELL_TYPES section of your input file.


But the more relevant part is that one then runs into the following error:
...
An error occurred in line <2690> of file 
 in function
static void 
dealii::internal::TriangulationImplementation::Implementation::create_triangulation(const 
std::vector >&, const std::vector >&, 
const dealii::SubCellData&, dealii::Triangulation<2, spacedim>&) [with int 
spacedim = 2]

The violated condition was:
line->boundary_id() != numbers::internal_face_boundary_id
Additional information:
The input data for creating a triangulation contained information about a 
line with indices 1 and 49 that is described to have boundary indicator 0. 
However, this is an internal line not located on the boundary. You cannot 
assign a boundary indicator to it.


If this happened at a place where you call 
Triangulation::create_triangulation() yourself, you need to check the 
SubCellData object you pass to this function.


If this happened in a place where you are reading a mesh from a file, then you 
need to investigate why such a line ended up in the input file. A typical case 
is a geometry that consisted of multiple parts and for which the mesh 
generator program assumes that the interface between two parts is a boundary 
when that isn't supposed to be the case, or where the mesh generator simply 
assigns 'geometry indicators' to lines at the perimeter of a part that are not 
supposed to be interpreted as 'boundary indicators'.

...

The description of the error message already suggests the problem. You need to 
somehow convince gmsh to not output information about line segments at all.


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/2b99a9fc-aaac-13fd-6da0-01dbfd212816%40colostate.edu.


Re: [deal.II] Output of Gauss point stress tensor

2020-07-16 Thread Wolfgang Bangerth

On 7/16/20 9:15 AM, Muhammad Mashhood wrote:
So far it would be enough if I have the Gauss point values only at the points 
rather than having complete field. I like to access these point values of 
stress and strain tensors in .vtk file or .pvtu file through ParaView (same as 
I am accessing the results currently).
I would be grateful if you or any other user has experience in this regard or 
know about relevant deal.ii tutorial dealing with same feature.


deal.II has functionality to output data on individual points if that data is 
associated with particles. I don't know how much work you want to invest in 
getting this to work for you, but here are two options:


* Easy: Create a ParticleHandler object, loop over all of your quadrature 
points, and for each quadrature point you create a particle. You can then 
associate "properties" with each particle, and use Particles::DataOut to 
output these properties in the same way as you would use DataOut for field 
data. You can probably figure out how this works by looking at the draft 
step-19 tutorial program:

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

* More work, but more elegant: You could write a class, let's say 
QuadraturePointData::DataOut or something similar, to which you could describe 
the information of location + values without the detour of particles. I'm sure 
we'd be happy to walk you through the process of doing so if you wanted to go 
for that, and it would be a very nice addition to deal.II if you wanted to get 
it merged.


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/852a3e77-e242-4f9e-4182-2635e418b6bd%40colostate.edu.


Re: [deal.II] parallel::distributed::SolutionTransfer for FE_FaceQ element

2020-07-15 Thread Wolfgang Bangerth

On 7/13/20 2:48 PM, Yu Leng wrote:


What I really need is the solution in the interior (FE_DGQ).

I am trying to separate (FE_DGQ, FE_FaceQ) into (FE_DGQ, FE_Nothing) and 
(FE_Nothing, FE_FaceQ)  and hope in this way I can only transfer solution on 
FE_DGQ. But I have no luck yet.


What specifically happens?


On the other hand, can you recommend any reference on how to transfer the 
solution by hand.


You should be able to define a DoFHandler that *only* has the FE_DGQ, copy the 
solution into a vector associated with that DoFHandler, and transfer that from 
one mesh to another. Then reverse the process once you're on the other mesh.


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/1dfa1721-35db-dc44-faec-d45c6c6423d8%40colostate.edu.


Re: [deal.II] Output of Gauss point stress tensor

2020-07-15 Thread Wolfgang Bangerth

On 7/15/20 11:05 AM, Muhammad Mashhood wrote:


My question is that along with this, can I also export the stress and strain 
tensors data of quadrature points i.e. 
"local_history_strain_values_at_qpoints[i][j]" directly to the output file 
(.pvtu or .vtu etc.) i.e. without mapping or averaging etc. on the node. In 
this way I want to directly visualize the quadrature point values of stress 
and strain in Paraview.


The question is more a philosophical one than one of how you can achieve this. 
Typically, when we output information in finite element contexts, we output 
them as "fields", i.e., functions of space. This allows us to show them as 
surfaces, with color gradients, etc. The strategy you have found of taking 
values defined in (quadrature) points and converting them to fields is a way 
to make that happen.


If you want to output the stress/strain information, you have two options:

* You actually do show them as values defined only at individual points,
  rather than as fields. In this scheme, the stress/strain really only exists
  at the quadrature points, but not anywhere in between. You can't create
  surface plots, you can't create isocontour plots, etc.
* You create a field that somehow approximates these point values. There are
  different ways of doing that, and the approach you are currently using is
  one way for this.

So the question is mostly: What's your goal with this? Do you want to show 
these quantities as fields, or as data to be visualized at individual points?


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/5760fe79-fd66-044f-5dc7-0a45e851ac5c%40colostate.edu.


Re: [deal.II] parallel::distributed::SolutionTransfer for FE_FaceQ element

2020-07-13 Thread Wolfgang Bangerth

On 7/12/20 5:06 PM, Yu Leng wrote:


I am encountered with this error while using adaptive mesh refinement in 
parallel.


virtual const FullMatrix ::FiniteElement<2, 
2>::get_prolongation_matrix(const unsigned int, const RefinementCase &) const

The violated condition was:
     prolongation[refinement_case - 1][child].n() == this->dofs_per_cell
Additional information:
   You are trying to access the matrices that describe how to embed a finite 
element function on one cell into the finite element space on one of its 
children (i.e., the 'embedding' or 'prolongation' matrices). However, the 
current finite element can either not define this sort of operation, or it has 
not yet been implemented.


Yu -- could you try to come up with a minimal example that demonstrates the 
error? It doesn't have to do anything useful -- just set up the FE, a 
DoFHandler, call SolutionTransfer. This way, it would be much simpler for us 
to reproduce the error.


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/326584c7-ba13-6591-32d4-bdaa5b88101a%40colostate.edu.


Re: [deal.II] step-7 remarks on superconvergence and quadrature

2020-07-13 Thread Wolfgang Bangerth

On 7/13/20 7:38 AM, Praveen C wrote:

You were right, this happens for degree >= 2

See the discussion in Section 1.2 here

https://www.math.purdue.edu/~zhan1966/research/paper/superconvergence.pdf 
<https://nam01.safelinks.protection.outlook.com/?url=https:%2F%2Fwww.math.purdue.edu%2F~zhan1966%2Fresearch%2Fpaper%2Fsuperconvergence.pdf=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7C48c31868f9844d7e6e5c08d827321e75%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C1%7C637302443507240168=VqrErQTBylXc7ceblfcvciT2FQOKFRoFOkHIIJGGXLA%3D=0>



and it gives many references.

Nice, I didnt know this.


Neither did I know the requirement k>=2. Thanks a lot for figuring this out -- 
I've extended the discussion in step-7 here

  https://github.com/dealii/dealii/pull/10703
and in particular added the reference you found!

Thanks for following this question and helping us improve the documentation! 
Thanks also for allowing me to learn something new!


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/e3dd42a6-bbfb-3800-229a-d7305172e6df%40colostate.edu.


Re: [deal.II] step-7 remarks on superconvergence and quadrature

2020-07-10 Thread Wolfgang Bangerth



Praveen,

https://github.com/cpraveen/fembook/blob/master/deal.II/ex04/demo.cc 
<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcpraveen%2Ffembook%2Fblob%2Fmaster%2Fdeal.II%2Fex04%2Fdemo.cc=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7C64e1553a3ee443da7b0c08d8222ff1ad%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637296936604213536=2KnxkD9r19uV5h41HYbakCAmD2PzuPddCZN0tv%2B%2BAE4%3D=0>

(Change quadrature rules in this code as indicated below)

degree=1
assembly using QGauss(2)
error computed using QGauss(2)

cells   dofs        L2         H1seminorm
   1024   1089 1.606e-03    - 2.517e-01    -
   4096   4225 4.015e-04 2.00 1.259e-01 1.00
  16384  16641 1.004e-04 2.00 6.295e-02 1.00
  65536  66049 2.510e-05 2.00 3.148e-02 1.00
262144 263169 6.275e-06 2.00 1.574e-02 1.00

We just observe the standard convergence rates, does not indicate 
superconvergence.


The following two also yield standard convergence rates

degree=1
assembly using QGauss(2)
error computed using QGaussLobatto(2)

degree=1
assembly using QGaussLobatto(2)
error computed using QGaussLobatto(2)

This indicates there is no superconvergence at the mesh vertices.

(In all cases above, the matrix is exactly assembled.)


Interesting.

But then, was I completely wrong that something like superconvergence points 
exist? Or does the concept only apply when we solve the Laplace equation (the 
Poisson equation with f=0)? What is your recollection of superconvergence?


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/72887e82-dd58-b21f-e0a9-08b2ede981e6%40colostate.edu.


Re: [deal.II] Mesh-induced elastic anisotropy and distorting the quad. points as a way to palliate it

2020-07-10 Thread Wolfgang Bangerth

On 7/10/20 9:15 AM, David F wrote:
I have a 2D system for which I create the stiffness tensor of an isotropic 
material, but for each finite element I create it with a different shear 
modulus. The shear modulus is random for each element (I use an exponential 
distribution, but any distribution leads to the same behavior as long as the 
std is high), with no structure such as layers or anything else. In this case, 
the system should clearly be macroscopically isotropic (up to statistical 
fluctuations due to the random properties) for symmetry reasons.


At least in the limit h->0 I agree. For finite mesh sizes, I would expect that 
the material has a degree of anisotropy that goes to zero as you make the mesh 
smaller. It is true that the axes of anisotropy should be oriented in random 
ways for different realizations of the same experiment on the same mesh. When 
you do your computations, have you checked (for different realizations of the 
random process):
(i) whether the orientation of anisotropy is always the same, and always 
related to the principal directions of the mesh?

(ii) how the magnitude of anisotropy behaves as you refine the mesh?

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/0aba5a00-6c41-bb39-9570-b77c3e297567%40colostate.edu.


Re: [deal.II] step-11 boundary element

2020-07-10 Thread Wolfgang Bangerth

On 7/9/20 8:50 PM, Alex wrote:
Thank you. Do you have any recommendation for reference notes or books which 
explains the math behind mapping? I can see some in Mapping< dim, spacedim > 
Class Template Reference.


I'm not good with what FE book talks about which, but most FE books will have 
sections that cover the idea of "mapping" shape functions. Higher order 
mappings are often discussed with keywords such as "isoparametric mappings".


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/76ff5470-08e2-e3ed-22c1-3b086eb17cc2%40colostate.edu.


Re: [deal.II] Interest in a step-12-like DG tutorial but for the advection-diffusion equation?

2020-07-10 Thread Wolfgang Bangerth



Bruno,

I really enjoy the way step-12 is written, especially because of the use of 
the FEInterfaceValue class. In my opinion it makes low level stuff very easily 
accessible, yet it is relatively easy to understand.
However, I am under the impression that there are no similar test for elliptic 
equations in which you need to use Nitsche method + Symmetric Interior Penalty 
for the boundary + inner faces respectively. I know of step-39, but it does 
not use the same "low-levelish" features.


There is also step-47, which probably comes closest to what you're looking for 
(even though written for a different equation).



I have written such a code for my own pleasure for the laplace equation and I 
am currently working on its advection-diffusion version (mostly following 
Larson Chapter 14).


Would it be interesting to turn such a case into a deal.II step (that would 
follow in step-12 footstep) or does the community feel that the existing steps 
for DG sufficiently cover the ground?


Always!
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/af4b4c25-7761-fe80-2c6e-3fe85fbb03e8%40colostate.edu.


Re: [deal.II] step-11 boundary element

2020-07-09 Thread Wolfgang Bangerth

On 7/9/20 1:18 AM, Alex wrote:
I am new to dealii. I have a question on step-11. For a domain with a curved 
boundary such as step-11 with fe(1), is the boundary element still a bilinear 
one if mapping order>1? i.e. always 4 dofs on a boundary element? Thanks


You need to distinguish between the element and the mapping. The element's 
shape functions are defined on the reference cell, and for a Q1 element 
(=fe(1)), there are always 4 shape functions in 2d.


The *mapping* on the other hand is used to describe how shape functions are 
transformed from the reference cell to the real cell. This mapping is more 
complicated when you have a curved boundary than if you have a straight 
boundary, but it does not affect *how many* shape functions there are.


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/220be353-f7e3-968f-4fe9-978fa5b00d84%40colostate.edu.


Re: [deal.II] Mesh-induced elastic anisotropy and distorting the quad. points as a way to palliate it

2020-07-08 Thread Wolfgang Bangerth

On 7/2/20 10:06 PM, David F wrote:


*_Q2_:* why the system behaves as anisotropic if its local inhomogeneous 
elastic properties are isotropic? If you have any comment or suggestion about 
the problem of mesh-induced elastic anistropy in FEM, I would like to know it.


I don't know how exactly you choose your coefficient, but if you alternate 
layers of isotropic materials, then you get an anisotropic material. Think 
about layering styrofoam plates with steel plates -- the resulting stack of 
layers is essentially incompressible under loads from the side (because the 
steel plates provide the stiffness), but is quite compressible if you load it 
from top and bottom (because the styrofoam layers will simply collapse).


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/7969cc0d-7ff6-61e3-884c-d184fb6c9c66%40colostate.edu.


Re: [deal.II] error: no member named 'quadrature_point_indices' in 'dealii::FEValues<2, 2>'

2020-07-07 Thread Wolfgang Bangerth

On 7/7/20 10:54 AM, hkch...@gmail.com wrote:


I don't understand which index in the sentence: 'Index 1 is not in the 
half-open range [0,1).' refer to.


It's apparently one of the indices passed to cell->vertex_dof_index(...).

Have you tried to run the program in a debugger? This will tell you exactly 
what is happening, where, and why. Learning how to use a debugger is really a 
fantastically useful skill!


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/a6db467a-2a20-ff04-7808-4462f1367c8e%40colostate.edu.


Re: [deal.II] error: no member named 'quadrature_point_indices' in 'dealii::FEValues<2, 2>'

2020-07-07 Thread Wolfgang Bangerth

On 7/6/20 11:25 PM, hkch...@gmail.com wrote:

my platform is macOS Mojave 10.14.6 Beta, the deal.ii vesion is 9.1.0


The functions you're trying to call (FEValues::quadrature_point_indices() and 
FEValues::dof_indices()) were only introduced in deal.II 9.2. You either need 
to upgrade to that version, or rely on functions that were already present in 9.1.


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/afef8ae8-eeb2-ea27-4468-7fd2702893a8%40colostate.edu.


Re: [deal.II] particle parallelization

2020-07-06 Thread Wolfgang Bangerth



I have a few questions on the parallelization aspects of a system containing 
particles and I would appreciate it if someone could answer them.
The first one is: Let's say I'm using 2 CPUs for a simulation. If I change a 
property of a ghost particle (located in a ghost cell for CPU0), will the 
property of the real particle on the other CPU change?


Shahab,
the question has already been answered, but I thought I'd also put that into 
the documentation:

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

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/788cae53-2cd5-3ba2-84e9-d3eee6310092%40colostate.edu.


Re: [deal.II] step-7 remarks on superconvergence and quadrature

2020-07-06 Thread Wolfgang Bangerth




In step-7

https://www.dealii.org/current/doxygen/deal.II/step_7.html 
<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.dealii.org%2Fcurrent%2Fdoxygen%2Fdeal.II%2Fstep_7.html=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7C95a7523f571844a4dbc308d8209dbf1a%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637295209184273315=PbscIaF1YgoA6TOFydENsrn79iERjXLdAeV9g7b5u94%3D=0>


under section on "Verification of correctness”, there is this statement

*(e.g., for linear elements, do not use the QGauss(2) quadrature formula)*

because solution may exhibit superconvergence at the QGauss(2) points.

If we solve

-u’’ = 16*pi^2*sin(4*pi*x) in (0,1)
u(0) = 0, u(1) = 1

using 8 linear elements and QGauss(2) for quadrature.

The error is very small at the vertices of the mesh, not at the QGauss(2) 
points.

Can you look into this issue, is the comment in the documentation wrong, 
perhaps it should say *do not use QGaussLobatto(2)* ? Or is there some issue I 
am missing here ?


Ah, very interesting question! You're right that in some situations -- the 
Laplace equation in 1d specifically -- the superconvergence points are in fact 
the vertices of the cells.


But that's not true in 2d/3d. There, at least the recollection I have from 
when I learned about this many years ago, the superconvergence points are 
indeed the Gauss points. Want to try that out as well in a small experiment? 
Say take a 16x16 mesh, and plot both solution and discrete solution in a part 
of the domain well away from the boundary, and see where the two seem to 
intersect.


(As always, we're always happy to improve the documentation. Clearly, what I 
said in step-7 is not the complete truth and ought to be improved, but I'd 
rather we check what we say before coming up with a better description :-) )


Cheers
 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/d07ed649-dc11-53e4-7e48-3f348f97caf2%40colostate.edu.


Re: [deal.II] Hanging node constraints for one component of a vector system

2020-07-06 Thread Wolfgang Bangerth

On 7/3/20 11:20 AM, Stephen wrote:
I have an FE system object made of FE_TraceQ and FE_FaceQ and would like to 
apply hanging node (and zero boundary) constraints to only the first 
component. This is easy with zero boundary since the function 
DoFTools::make_zero_boundary_constraints can take a component mask as an 
argument but I see no such variant for 
DofTools::make_hanging_node_constraints; what would be the easiest way to do 
this practically?


Right. That's because make_hanging_node_constraints() in essence just enforces 
a property of the finite element space, namely specific continuity 
constraints. These properties are described by the finite element class.


If I understand you right, then you want an FE_FaceQ that does not require 
continuity from a large face to its child faces -- in other words, you want it 
to be discontinuous. I am curious why you need this? That's because the 
continuity between cells of the same size is implicitly provided. Why do you 
want to treat faces with hanging nodes differently?


(If that's what you really want, you need to come up with a different way to 
describe the finite element space -- using a different class derived from 
FiniteElement -- and I'm happy to walk you through the process. But I 
don't understand why you would want to do that, and so am curious about the 
underlying reason first.)


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/dffb5991-4499-33dc-f3b3-747be71652c2%40colostate.edu.


Re: [deal.II] Error while installing

2020-07-01 Thread Wolfgang Bangerth



     Someone help me solving this issue, here I'm attaching snapshots of that 
error message. And also the installation files was not created after running 
'make install' command.


The error message says
  cannot create directory /home/dealii/share/deal.II/scripts
I believe that you are working in the directory
  /home/prakash/Documents/dealii-9.2.0/build

In other words, I believe that the directory /home/dealii does not actually 
exist and that you can't create it because only the superuser is allowed to 
create new directories under /home. The question is why you want to install 
into this directory to begin with? The usual recommendation is to install into 
a subdirectory of your home directory. A good choice would be

  /home/prakash/dealii

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/1ec77890-1cb3-f2a4-d7a5-47d8a9af40cf%40colostate.edu.


Re: [deal.II] GMesh 1D mesh input error

2020-06-30 Thread Wolfgang Bangerth

On 6/26/20 11:05 AM, Victoria W. wrote:
This fixed my problem in 2d, but I'm still having issues in 3d.  Any other 
suggestions for getting a .msh file read in when it's a 2d mesh in 3d space?  
Posting the mesh I want to use here, with the type 15 elements removed.  I've 
also tried other software and file formats, running into the same issue 
previously posted about .unv files produced with Salome, so I appreciate any 
suggestions on reading in a mesh!


Victoria,
I assume that you are talking about the following error:

 

An error occurred in line <2674> of file 
 in function
static void 
dealii::internal::TriangulationImplementation::Implementation::create_triangulation(const 
std::vector >&, const std::vector >&, 
const dealii::SubCellData&, dealii::Triangulation<2, spacedim>&) [with int 
spacedim = 3]

The violated condition was:
line->boundary_id() != numbers::internal_face_boundary_id
Additional information:
The input data for creating a triangulation contained information about a 
line with indices 9 and 33 that is described to have boundary indicator 0. 
However, this is an internal line not located on the boundary. You cannot 
assign a boundary indicator to it.


If this happened at a place where you call 
Triangulation::create_triangulation() yourself, you need to check the 
SubCellData object you pass to this function.


If this happened in a place where you are reading a mesh from a file, then you 
need to investigate why such a line ended up in the input file. A typical case 
is a geometry that consisted of multiple parts and for which the mesh 
generator program assumes that the interface between two parts is a boundary 
when that isn't supposed to be the case, or where the mesh generator simply 
assigns 'geometry indicators' to lines at the perimeter of a part that are not 
supposed to be interpreted as 'boundary indicators'.




The issue here is similar to the previous one, just that now you have a *line* 
in the interior of a 2d mesh (where previously you had a vertex interior to a 
1d mesh) for which the input file specifies boundary values -- even though 
that line is not actually at the boundary. These lines are now "type 1" 
entities in the language of the GMSH and look like this:

  33 1 0 1 2 10 34
(GMSH numbers vertices starting at 1, whereas deal.II uses 0, so this is the 
line that the error message above complains about: the one with vertices 9 and 
33.)


In your file, there are 208 such lines (listed under the "$ELM" line, and 
numbered 33 to 240). If you remove these lines and adjust the number under 
$ELM from 802 to 594, the file can be read successfully and looks like the one 
attached.


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/78882fe6-ff7e-87e1-0c46-a40c25b50a86%40colostate.edu.


Re: [deal.II] Is there an advantage/disadvantage/difference to using FEInterfaceValues (tutorial step 12) instead of the MeshWorker framework (tutorial step 12b) when it comes to DG?

2020-06-30 Thread Wolfgang Bangerth



I would like to implement a DG solver that would solve the 
convection-diffusion equation and later implement another code to solve the 
incompressible NS equation using DG as well. Tutorials 12 and 12b use 
different approaches to solve the pure convection equation, and so I was 
wondering which of these two approaches is better suited for my problem?
The two approaches were developed for different purposes: FEInterfaceValues as 
an approach to compute jump terms for DG methods in the same way as use 
FEValues and FEFaceValues for evaluating the shape functions on cells and 
faces. On the other hand, MeshWorker was meant as a framework that would make 
the assembly of linear and bilinear forms over cells and interfaces easier. If 
FEInterfaceValues had been around at the time MeshWorker was written, it would 
have been one of the building blocks used there.


So there is no real equivalency between the two. The equivalence is more 
between MeshWorker framework and the MeshWorker::mesh_loop() method used in 
step-12 and step-47: As has been expressed many times on this mailing list, 
MeshWorker has a good underlying idea, but it is not well documented or tested 
and none of the people who frequently answer on the mailing list know it well. 
In other words, its higher level functionality is in essence unmaintained. On 
the other hand, MeshWorker::mesh_loop() *is* well documented and supported, 
and has an interface that is relatively widely understood here. My preference 
would have been to just remove step-12b when the previous version was 
rewritten into what step-12 is now, rather than renaming it step-12b. (And do 
the same for step-16b.) I consider step-12b and step-16b as obsolete.


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/cf5ffbb2-485e-7deb-f5f7-8633af2c1c35%40colostate.edu.


Re: [deal.II] Step-22 with more than 20 million DOFs

2020-06-26 Thread Wolfgang Bangerth



Alex,

I am solving the Stokes flow problem in three dimensions using OpenFCST 
<https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.openfcst.mece.ualberta.ca%2F=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7Ccd3182fe6dfc4066e6b208d81897e47a%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C1%7C637286387952996923=5F%2BU95iUemz1oaDHrEaZ8C3xevwIzmoSqrI3UMU%2F2%2FA%3D=0>, 
which is an open-source platform for fuel cell simulations and it is based on 
deal.II v8.4.1. The code that I use is mostly based on the code in Step-22, 
and I have noticed that my simulations fail when my mesh has more than 20 
million DOFs. In order to check if the problem comes from deal.ii and not from 
OpenFCST, I did the following:


1. Modified slightly the code in step-22 (see file "step-22.cc" attached)  to 
consider a domain in 3D that is of size 100x100x50 and it has 50 divisions per 
direction.

2. Applied the same boundary conditions that are applied in step-22
4. Ran the simulation both in deal.II v8.4.1 and v.9.0.1 with less than 20 
million DOFs, and I was able to obtain a solution (see file "DealII_test.png" 
attached).
5. Ran the simulation in deal.II v8.4.1 -> it resulted in a "Segmentation 
fault" error (see file "output_v8_4_1.out").
5. Ran the simulation in deal.II v9.0.1 -> it resulted in a "nan residual" 
error (see file "output_v9_0_1.out").


I was wondering if someone could please tell me why this issue is appearing 
when I consider a mesh with more than 20 million DOFs, and if there is a 
solution to this.


20 million unknowns is quite a large number, especially if you are using the 
solver used in step-22. My suspicion is that in both cases, the error message 
really just points out that you're run out of memory.


It would be interesting to see how your program's memory use increases as you 
go from smaller to large problems. I suspect that you will see that for 20 
million unknowns on a single machine, you will need ~100GB of memory and that 
that exceeds what the operating system is willing to give you.


20 million unknowns is solidly in the region where you need (i) a parallel 
machine, and (ii) a better linear solver than the one used in step-22. Both 
exist in deal.II: a better linear solver is discussed in the "Possibilities 
for extensions" of step-22, and is implemented in a parallel fashion in 
step-32 among others.


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/9e44c157-833a-2cba-a2f9-373d8d9f9bfc%40colostate.edu.


Re: [deal.II] Understanding slightly cryptic warnings from modified Step-52 code

2020-06-24 Thread Wolfgang Bangerth

On 6/24/20 3:14 PM, Krishnakumar Gopalakrishnan wrote:

Hi,

I am solving the basic diffusion equation using the direct method (based on 
Step-52).


I have made the following changes from Step-52 tutorial

1. The domain is now 1D (as opposed to 2D in step-52)
2. We have Neumann BCs on both ends (left NeumannBC = 0.5, right NeumannBC= 0)
3. Removes the code for MMS validation (i.e. no source term S(t)) so that we 
solve for the unknown field variable, instead of verifying whether the 
pre-formulated analytical solution is retrieved)

4. Sets the absorpotion coefficient, Sigma_a = 0
5. Sets a non-zero initial condition (but a spatially constant value).

The C++ source code & Cmakelists.txt files are attached herewith. The solution 
is indeed correct and is as expected, and I have visualised this in Paraview. 
However, I'd like to understand the compilation warnings.


Some of them have to do with "unused variables", which are somewhat 
straightforward to get rid of. But the other warnings which all have the 
string  "required from here" is not so clear to me.


Read the error/warning message in its entirety. For example, the first one says

/home/bangerth/p/deal.II/1/install/examples/step-1/step-1.cc: In instantiation 
of ‘void DiffusionEqn::SolidDiffusion::run() [with int dim = 1]’:
/home/bangerth/p/deal.II/1/install/examples/step-1/step-1.cc:441:26: 
required from here
/home/bangerth/p/deal.II/1/install/examples/step-1/step-1.cc:420:24: warning: 
variable ‘n_steps’ set but not used [-Wunused-but-set-variable]

 unsigned int   n_steps  = 0;
^~~

If you strip the details, it says:

   In instantiation of function b() // i.e., while compiling a()
   required from here   // i.e., we got to a() while compiling b()
   warning: variable unused

In other words, the compiler isn't just telling you where (in which function 
and line of code) the problem happened, but also *why* it is compiling this 
function (because it's called from some other place) and with which template 
arguments.


Best
 W.



Can someone please explain what these warnings mean, and what is the best 
practice for refactoring it to avoid such warnings.


Thanks!
Krishna

--
The deal.II project is located at http://www.dealii.org/ 
<https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.dealii.org%2F=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7Cfd8a27c47f9a45cc323908d818838c1f%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637286300568833692=D5TEoM8Dk11JtvV6qM7o79260F%2BztbJpQw5M%2FVghgaU%3D=0>
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en 
<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fforum%2Fdealii%3Fhl%3Den=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7Cfd8a27c47f9a45cc323908d818838c1f%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637286300568843686=XWXhcdeMs1Poa%2BSLIqCZH73Wh1wqlvqLyz%2BTXB%2FMvBo%3D=0>

---
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/d6aaa13b-5325-4f4a-9493-23859a5bcb9co%40googlegroups.com 
<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fdealii%2Fd6aaa13b-5325-4f4a-9493-23859a5bcb9co%2540googlegroups.com%3Futm_medium%3Demail%26utm_source%3Dfooter=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7Cfd8a27c47f9a45cc323908d818838c1f%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637286300568843686=4eiKv3%2FUh9%2Bx5zjYczkUfN%2F%2Fwn8M8zpGx%2Fvccf%2FIhjs%3D=0>.



--
----
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/3d8d3b4d-0fd9-83e0-5457-34dc7e9c612f%40colostate.edu.


Re: [deal.II] GMesh 1D mesh input error

2020-06-24 Thread Wolfgang Bangerth



Victoria,

That was the file I wanted to use - I also tried this 2D mesh in 3D space 
attached.  What is a type 15 entity and why did it cause an error?  The same 
error appeared to be in this .msh file as well.


As mentioned before, it may be possible to remove the "physical entity" things 
in gmsh to avoid the problem.


As for the type 15: If you open the mesh file, it has a section that looks 
like this:


$ELM
58
1 15 0 1 1 1
2 15 0 2 1 2
3 15 0 3 1 3
4 15 0 4 1 4
5 15 0 6 1 5
6 15 0 7 1 6
7 15 0 8 1 7
8 15 0 9 1 8
9 15 0 10 1 9
10 15 0 11 1 10
11 1 0 1 2 10 11
12 1 0 1 2 11 12
13 1 0 1 2 12 13
14 1 0 1 2 13 5
...

The first column is just a counter, the second column is the "type" of the 
object being described. 15 represents individual points, 1 are lines. The 
problem is with these 15s, for which we can't figure out what gmsh wants to 
tell us with these entries. I suspect that if you remove these 10 lines and 
reduce the 58 at the top to 48, that it might actually work. That could give 
you a way forward.


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/9a447045-9e1e-3482-90d1-3cef168be74b%40colostate.edu.


Re: [deal.II] GMesh 1D mesh input error

2020-06-24 Thread Wolfgang Bangerth

On 6/24/20 6:53 AM, Victoria W. wrote:


Thank you for getting back to me.  I've tried with a .inp mesh produced by 
both gmsh and freeCAD, but I get the same error with my .inp gmsh export and 
when I use the FreeCAD export I have to use the read_abaqus() read in method 
which has been giving me a bad_alloc error message.
That too sounds like a bug. If you give me the file, I'll investigate that as 
well.


Was the file you sent earlier the one you're trying to read, or was that just 
an example? We know what the offending parts of that file are (all of the type 
15 entities) and we can strip those out by hand.


Best
 W.

--

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

--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to 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/e4938619-dd3f-a5e5-ff0e-23c5be26daeb%40colostate.edu.


Re: [deal.II] Help with ParticleHandler

2020-06-23 Thread Wolfgang Bangerth

On 6/18/20 9:42 AM, Andrew Davis wrote:
Thanks for you reply. Here is a minimal example that does 3 three things: (i) 
interpolate a solution (some simple function in this case, but would actually 
be the result of solving a PDE) onto the DOFs of a mesh, (ii) interpolate the 
solution onto randomly placed particles, and (iii) try to associated the 
interpolated solution with particle properties.  For me, this code compiles 
but does not run. Do you know why?


Yes, this is a bug. I've opened
  https://github.com/dealii/dealii/issues/10584
Let's take the discussion of the failure there. I think I've got a fix.


(i) In the code below I could replace the counter part with iter->get_id(). Is 
this the intended use of the ID or would we expect this to fail in more 
complicated examples where particles may be added/removed or distributed 
across processors?


It depends on what you want to do. Your counter goes over the locally owned 
particles and takes their index *within the locally owned particles*. 
iter->get_id() returns an id that is intended to be globally unique across all 
processors.



(ii) Is it necessary to copy the particle properties into an std::vector or 
can we just give each particle an iterator the the 
interolatedParticleQuantities vector? The copy step seems unnecessary and 
potentially slow/burdensome if there are lots of particles.


You mean in this part of the code?

  for( auto iter=particleHandler.begin(); iter!=particleHandler.end();
   ++iter, ++part ) {
std::vector quantities(ncomponents);
for( unsigned int i=0; iset_properties(quantities);
  }

Yes, this was an oversight that I fixed a while ago already (but post 9.2): 
ParticleAccessor::set_properties() did not have an overload for ArrayView. 
With the current development version, you can write this as follows:


  for( auto iter=particleHandler.begin(); iter!=particleHandler.end(); 
++iter, ++part )

iter->set_properties
  (make_array_view(interpolatedParticleQuantities.begin()+
   part*ncomponents,
   interpolatedParticleQuantities.begin()+
   part*ncomponents + ncomponents));

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/e834c1ce-89d1-c6f7-0720-2df18a503b59%40colostate.edu.


[deal.II] Re: Questions on parallel linear solver

2020-06-20 Thread Wolfgang Bangerth

Jane,
let me take this to the deal.II mailing list, since that is the place where 
these kinds of questions should be asked:



I recently finished an SUPG based incompressible unsteady Navier-Stokes solver.
The test case is the flow over cylinder problem. I parallized the code. 
Everything works well with the linear code. But when I switch to parallel with 
an iterative linear solver (SolverFGMRES). It performs 10x slower than the 
direct solver(SparseDirectUMFPACK) I used in the linear code. The iterative 
solver typically takes 5-6 gmres iterations to solve the system.


Out of curiosity, what is your preconditioner?


I tried to use the parallel direct solver SparseDirectMUMPS, but it was not 
able to solve the system.


What exactly happens?


I am wondering if this is expected? Given the test case has a system that is 
small ( 2D code with 10,000 dof). And is there any other parallel 
direct solver I can try?


As a rule of thumb, direct solvers are typically faster than iterative solvers 
for problems with less than around 100,000 unknowns. Your problem is so small 
that it's not worth bothering with iterative solvers. It's probably also so 
small that it's not worth bothering with parallelization: parallelization only 
works well if you have more than around 50,000 unknowns per processor. You're 
still far away from that.


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/ab5915b7-d5a2-1c55-1efe-846247ffc0bc%40colostate.edu.


Re: [deal.II] Geometric Conservation Law

2020-06-16 Thread Wolfgang Bangerth



Alexander,

I am wondering if anybody has also found that the inverse of the Jacobian from 
FE Values, with MappingQGeneric does not satisfy the Geometric Conservation 
Law (GCL), in the sense of:


Kopriva, David A. "Metric identities and the discontinuous spectral element 
method on curvilinear meshes." /Journal of Scientific Computing/ 26.3 (2006): 301.


on curvilinear elements/manifolds in 3D.
That is:
\frac{\partial }{\partial \hat{x}_1} *det(J)* \frac{\partial \hat{x}_1 
}{\partial x_1} + \frac{\partial }{\partial \hat{x}_2} *det(J)* \frac{\partial 
\hat{x}_2}{\partial x} + \frac{\partial }{\partial \hat{x}_3} * 
det(J)*\frac{\partial \hat{x}_3 }{\partial x_1} != 0 (GCL says it should =0, 
similarly for x_2 and x_3)


If so or if not, also, has anybody found a remedy to have the inverse of the 
Jacobian from FE Values with MappingQGeneric to satisfy the GCL.


I'm not sure any of us have ever thought about it. (I haven't -- but I really 
shouldn't speak for anyone else.) Can you explain what this equality 
represents? Why should it hold?


I'm also unsure whether we've ever checked whether it holds (exactly or 
approximately). Can you create a small test program that illustrates the 
behavior you are seeing?


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/d8421b9f-0fa9-9769-b63c-281500879687%40colostate.edu.


Re: [deal.II] Help with ParticleHandler

2020-06-16 Thread Wolfgang Bangerth

On 6/16/20 1:46 PM, Andrew Davis wrote:


and I have gotten what I expect.  I have also tried attaching the particle 
properties using:


unsigned int npart = 0;
for( auto iter=particleHandler.begin(); iter!=particleHandler.end(); ++iter, 
++part ) {
   dealii::ArrayView data(interpolatedParticleQuantities.begin() + 
part*ncomponents, ncomponents);

   iter->set_properties(data);
}

but I get the compiler error:

*error: *cannot convert ‘*dealii::ArrayView*’ to ‘*const 
std::vector >&*’


353 | iter->set_properties(*data*);


Does anyone know what I am doing wrong? Or is there is a better way to do 
this? I'm sure this is a dumb question, but I couldn't find anything in the 
tutorials/examples.


You've already solved this one problem by converting the ArrayView to a 
std::vector by hand in your next mail.



> The violated condition was:
>
> property_pool != nullptr
>
> Additional information:
>
> This exception -- which is used in many places in the library -- usually

That's more complicated. The exception happens in the line
  iter->set_properties(...)
and tells you that the particle 'iter' points to isn't associated with a 
PropertyPool, i.e., the object that stores particle properties. I'm not sure 
why that is so. I believe that from your code, you set up the ParticleHandler 
to hold properties, but I can't see where the ParticleHandler's PropertyPool 
would be propagated to the newly added particles.


Can you create a minimal program that shows the issue? It doesn't have to do 
anything useful, just illustrate the error.


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/6dbfba6d-fa26-eb8b-93b8-3ed836dab451%40colostate.edu.


Re: [deal.II] Re: Binding Step-6 class with Boost.Python gives an compilation error: "use of deleted function"

2020-06-14 Thread Wolfgang Bangerth

On 6/14/20 7:09 PM, Oleg Kmechak wrote:

 Solver(Model *model):
 dof_handler(triangulation)
 {
 model = model;


Oleg,
I have not tried too carefully to look at what you're doing, but this line 
doesn't look right. It is equivalent to

  this->model = this->model;
which I don't think is what you want to do.

I should not that we occasionally use the following style in constructors:

 Solver (Model *model)
 :  model (model)
 { ... }

which is initializing this->model with the given argument 'model'. But that 
only works in the initializer list of a class.


You are correct that the error messages you see result from the fact that 
somewhere in the Python interfaces, it is trying to create a copy 
operator/constructor for the Model class, but that that doesn't exist because 
the copy operations for Triangulation and DoFHandler are not allowed. That has 
nothing to do with the issue above.


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/36b4fbb9-9b0a-9ff6-850e-2ba967ceca52%40colostate.edu.


Re: [deal.II] Finite Element Software deal.II Version 9.2.0 released

2020-06-11 Thread Wolfgang Bangerth

On 6/10/20 9:19 PM, Matthias Maier wrote:

Version 9.2.0 of deal.II, the object-oriented finite element library
awarded the J. H. Wilkinson Prize for Numerical Software, has been
released. It is available for free under an Open Source license from the
deal.II homepage at [...]


All,
the link to it is somewhere further down in the announcement, but I'd like to
highlight as always the paper in which we summarize the major improvements in
this version:
  https://www.dealii.org/deal92-preprint.pdf
You may find it interesting.

As always, many many people have contributed to this release. In
addition to the 17 authors of the paper above, section 4 lists another 79
people, also listed below. I think that's an awesome number, and we owe all of 
them for all of their contributions -- thank you!


Best
 Wolfgang & the rest of the principal developers


Pasquale Africa,
Ashna Aggarwal,
Giovanni Alzetta,
Mathias Anselmann,
Kirana Bergstrom,
Manaswinee Bezbaruah,
Benjamin Brands,
Yong-Yong Cai,
Fabian Castelli,
Joshua Christopher,
Ester Comellas,
Katherine Cosburn,
Denis Davydov,
Elias Dejene,
Stefano Dominici,
Brett Dong,
Luel Emishaw,
Niklas Fehn,
Rebecca Fildes,
Menno Fraters,
Andres Galindo,
Daniel Garcia-Sanchez,
Rene Gassmoeller,
Melanie Gerault,
Nicola Giuliani,
Brandon Gleeson,
Anne Glerum,
Krishnakumar Gopalakrishnan,
Graham Harper,
Mohammed Hassan,
Nicole Hayes,
Bang He,
Johannes Heinz,
Jiuhua Hu,
Lise-Marie Imbert-Gerard,
Manu Jayadharan,
Daniel Jodlbauer,
Marie Kajan,
Guido Kanschat,
Alexander Knieps,
Uwe K{\"o}cher,
Paras Kumar,
Konstantin Ladutenko,
Charu Lata,
Adam Lee,
Wenyu Lei,
Katrin Mang,
Mae Markowski,
Franco Milicchio,
Adriana Morales Miranda,
Bob Myhill,
Emily Novak,
Omotayo Omosebi,
Alexey Ozeritskiy,
Rebecca Pereira,
Geneva Porter,
Laura Prieto Saavedra,
Roland Richter,
Jonathan Robey,
Irabiel Romero,
Matthew Russell,
Tonatiuh Sanchez-Vizuet,
Natasha S. Sharma,
Doug Shi-Dong,
Konrad Simon,
Stephanie Sparks,
Sebastian Stark,
Simon Sticko,
Jan Philipp Thiele,
Jihuan Tian,
Sara Tro,
Ferdinand Vanmaele,
Michal Wichrowski,
Julius Witte,
Winnifried Wollner,
Ming Yang,
Mario Zepeda Aguilar,
Wenjuan Zhang,
Victor Zheng.

--

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/11670773-1861-0dc0-e583-d4a799f9743f%40colostate.edu.


Re: [deal.II] Particle Class Implementation

2020-06-10 Thread Wolfgang Bangerth

On 6/9/20 9:05 PM, Bruno Blais wrote:


In additional to what Jean-Paul suggested, you can look at the preliminary 
version of step-68 which does exactly what you would like to achieve with 
particles.
The code is available on the following pull request. Rene and I have put some 
work into it and it works quite well in its current state:
https://github.com/dealii/dealii/pull/10308 
<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdealii%2Fdealii%2Fpull%2F10308=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7Ccdf3c3dffb0c40530d6808d80ceb3094%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637273551562853584=Uyq0AcKtNcjWdg2t7%2FBFz3S%2Fw9fiy%2FrNQc8fIhE8hNo%3D=0>


And finally, there is a third tutorial program currently in the making:
  https://github.com/dealii/dealii/pull/10301
It is the most basic of them and primarily explains how to create particles 
and move them along.


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/c5473c72-d86e-0e8b-e891-b245915bbebf%40colostate.edu.


Re: [deal.II] Re: Broadcasting packed objects

2020-06-09 Thread Wolfgang Bangerth

On 6/9/20 2:53 PM, Maurice Rohracker wrote:

Thanks, Peter, that helped so far!

Another question would be, how would then the serialize function look like if 
one has another class as a member of a class. So, in this case, how would the 
serialize function look like if one has a class House and two of its member 
are of the type Room?

A serializing of nested objects so to speak.


The pack()/unpack() functions make use of the fact that many of the deal.II 
classes have save()/load() functions (sometimes combined into a serialize() 
function) that recursively save/load/serialize the member variables of these 
classes. Here is an example:

https://github.com/dealii/dealii/blob/master/include/deal.II/grid/tria.h#L4030-L4062

In these functions, operator& is used to serialize variables into/out of the 
given stream. If these variables are themselves classes, then that just calls 
these classes' respective save/load/serialize functions.


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/f38c8e99-6394-923f-6efc-c7be12056bc7%40colostate.edu.


Re: [deal.II] How to apply a spatially variable non-zero initial condition in step-52?

2020-06-08 Thread Wolfgang Bangerth



Krishna,

I tried using the VectorTools::project idea from step-25. However, my code 
fails to compile, and I could not decipher the errors and do not know how to 
fix this problem (have been stuck for a while).


The attached code tries to implement Step-52 (but for 1D), with homogenous 
dirichelet BC  at the left edge and homogenous Neumann BC at the right edge, 
with an initial value of 4/5*x*(1 - x/5) (a simple quadratic function). I am 
also attaching the CMakeLists.txt (adapted from Step-52 suitably).


I'd appreciate help (from you and others here on the forum) to solve this issue.


You really need to learn how to read error messages because this is really a 
rather simple case. The error you get is this:


/home/bangerth/p/deal.II/1/install/examples/step-1/step-1.cc:362:26: error: 
‘Step52::InitialValues’ is not a template

  InitialValues<1>(1, time),
  ^
/home/bangerth/p/deal.II/1/install/examples/step-1/step-1.cc:362:50: error: no 
matching function for call to ‘Step52::InitialValues::InitialValues(int, 
time_t (&)(time_t*) throw ())’

  InitialValues<1>(1, time),
  ^

So you already know exactly what the line in question may be. There aren't all 
that many possibilities for what could be wrong. The issue in your case is 
that the 'time' variable doesn't exist in the function where you have the code 
in question. The obscurity of the actual error message comes from the fact 
that there is a global time() function. But in the end, this is a case where 
you could have found the solution yourself.


So just replace time->0 if you want the initial values and everything should 
work.

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/86f05575-28b3-80f3-cfa2-4dc89247f923%40colostate.edu.


Re: [deal.II] Strategy to snap the boundary of a triangulation to a manifold

2020-06-08 Thread Wolfgang Bangerth

On 6/8/20 10:22 AM, Bruno Blais wrote:



Would any of you have a suggestion on how best to achieve the deformation of 
the nodes to match the manifold?


I suspect that this depends a lot on how exactly your manifold is given. You 
need some projection onto the manifold. If you used IGES CAD files, such 
projections are built-in with OpenCASCADE. For constructive solid geometry 
cases, it may be possible to build the project from known normal vectors. I 
expect that the situation becomes complicated in the "creases" where two 
boundary patches come together.


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/c2693a9d-ac2e-a18e-f629-11f7a89217dc%40colostate.edu.


Re: [deal.II] triangulation save not working for 1D domain

2020-06-07 Thread Wolfgang Bangerth

On 6/7/20 9:12 AM, Amaresh B wrote:
Thank you Luca for your reply. I can avoid 
parallel::distributed::Triangulation and use serial code. Can you suggest a 
method to save the solutions along with the triangulation which can be used 
for restarting code? Also please let me know if any example code is available.


step-69 does checkpoint restart.

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/2b66e0d9-5b10-2c3d-a9a4-733cd0bfcc3b%40colostate.edu.


Re: [deal.II] step 70 9.2 version

2020-06-05 Thread Wolfgang Bangerth

On 6/5/20 10:19 AM, luca.heltai wrote:

Wolfgang, it seems that indeed the default parameter file in 9.2 still contains 
`set Output directory = results`.:(


Want to move that to the 9.2.x branch in case we create a .1 release?

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/2b049651-fe11-0be9-d096-4dc87c53190c%40colostate.edu.


Re: [deal.II] preconditioner for three block matrix

2020-06-02 Thread Wolfgang Bangerth

On 6/2/20 2:58 AM, hussan zeb wrote:
Dear Wolfgang Thanks for your reply , i want to solve for viscoelastic fluid 


Zeb,
you'll have to be more specific. How about you show us the equations you want 
to solve, what others in the literature are doing, how you think that the 
solver/preconditioner step-57 might relate to your system, etc.


This is a site where we are happy to help, but we can't read your mind and you 
can't expect us to take a one-line question, do several hours of research to 
think about how one might solve your problem, and then report back. You can 
ask questions, but you need to do your job in doing the work.


Best
 Wolfgang


--

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/0e0d89a1-41c2-a520-befc-248d80a8e239%40colostate.edu.


Re: [deal.II] preconditioner for three block matrix

2020-06-01 Thread Wolfgang Bangerth

On 6/1/20 8:24 AM, hussan zeb wrote:


  how can solve preconditioner for 3x3 matrix inn step57


Hussan -- can you be more specific about your question? step-57 has a rather 
lengthy discussion of how exactly the system is solved:

https://dealii.org/developer/doxygen/deal.II/step_57.html#TheSolverandPreconditioner
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/7a7481f0-4b62-6a00-5e5f-286d09906bc8%40colostate.edu.


  1   2   3   4   5   6   7   8   9   10   >