[deal.II] Little question about constructor

2019-09-03 Thread yuesu jin 
Hi all,

  I have a question about the constructor initialization list. In some
tutorials, we initialize the dof_handler in the constructor with parameter
triangulation, however, the triangulation is initialized in some member
function within this class, which means when we initialize the class, we
have not had the triangulation yet, I don't know why this method works?

Best regards,
Yuesu

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

Re: [deal.II] Difference between BlockDynamicSparsityPattern and TrilinosWrappers::BlockSparsityPattern

2019-09-03 Thread Wolfgang Bangerth 


Bruno,

> Is there a different between how DynamicSparsityPatterns and 
> BlockDynamicSparsityPatterns behave?

The latter is just an array of the former. Under the hood, every block 
is simply a DynamicSparsityPattern that can be initialized in the same 
way one always does.


> When you look at step-40, which is the first "MPI" step, the way the 
> sparsity pattern is made is 
> (https://dealii.org/current/doxygen/deal.II/step_40.html#LaplaceProblemsetup_system)
> |
> DynamicSparsityPattern 
> dsp(locally_relevant_dofs);
> DoFTools::make_sparsity_pattern 
> (dof_handler,dsp,constraints,false);
> SparsityTools::distribute_sparsity_pattern 
> (
>     dsp,
>     dof_handler.n_locally_owned_dofs_per_processor(),
>     mpi_communicator,
>     locally_relevant_dofs);
> |
> 
> My understanding was that you were only making the sparsity pattern for 
> your own locally relevants dofs and the distribution step would make 
> sure that everything was coherent.

Correct.


> However, the sparsity pattern is made 
> in a completely different way in step-32 
> (https://dealii.org/current/doxygen/deal.II/step_32.html) and the 
> TrilinosWrappers:BlockSparsityPattern is used.

Correct. In step-40, we use PETSc, which has no sparsity pattern data 
structure of its own, and so we need to initialize the PETSc matrices 
with our own. In contrast, Trilinos has its own sparsity pattern 
classes, and so to initialize a Trilinos matrix, we need to build one of 
their sparsity patterns. (Or block patterns, as it may be -- which again 
is just an array of patterns.)


> Consequently, I was a bit confused as to the difference between these 
> approaches. It seems like the second one is necessary for Block matrices?
> I will take a deeper look into this, but I must say my understanding of 
> that point right now is relatively poor :(

The difference has nothing to do with blocks and everything with whether 
you base your linear algebra on PETSc or Trilinos.

Does this help?

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/daeb73c6-cee8-8a0f-2abe-074c44d30a59%40colostate.edu.

[deal.II] Extracting volume data to the boundary

2019-09-03 Thread Alberto Salvadori 
Dear community

I am trying to find a good way to deal with the following problem.

I am interested in a Laplace-Beltrami simulation (say with unknown scalar 
field c) on a surface that advects (with displacement field u) enclosesing 
a volume of say elastic material.
The two problems are per se uncoupled, but for the geometrical evolution. 
In this regard, one may solve separately for displacements in the volume 
and for c on the surface, once the latter is informed on the displacement 
field (and related gradients) on the surface nodes (and Gauss points). 
Extracting the surface mesh from the volume is quite simple. Which is 
though the best way to extract (project) the displacement solution on the 
boundary? Any suggestion/ hint?

Many thanks,
Alberto

-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155 


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

Re: [deal.II] Getting RHS values at nodes with DBC

2019-09-03 Thread Daniel Arndt 
Giorgos,

You can find a discussion for how constraints are handled in deal.II in
https://www.dealii.org/developer/doxygen/deal.II/group__constraints.html.

Thank you for your feedback.
> I'll try to explain what I try to calculate with the help of a standard
> FEM textbook:
>
> [...]
>
> In the book the global system is partitioned so that the first row
> contains the known U1 dofs and the second row the unknown the dofs U2.
> They solve the system for the U2 and then they calculate F1.
>

In short: we normally don't condense the linear system but use a diagonal
matrix for the constrained rows instead (and modify the right-hand side
accordingly).


> I think that the F1 vector  contains, among others, the fluxes from the
> imposed BCs.
>
In case you only have Dirichlet boundary conditions, K11 is diagonal, K12
is zero and F1 contains the (possibly scaled) Dirichlet boundary values.

Could you clarify in mathematical terms what you mean by "fluxes"? Maybe,
we are just using different terms fo the same thing.

In case you are interested in n\cdot In u at the boundary, you can use
FEValues::get_function_gradients() and FEValues::get_normal_vectors() with
a quadrature formel that contains
the points you are interested in on a cell in reference coordinates. This
is the approach VectorTools::point_gradient() is using for returning the
gradient for a single point in real coordinates.

Best,
Daniel

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

Re: [deal.II] Getting RHS values at nodes with DBC

2019-09-03 Thread Giorgos Kourakos 
Thank you for your feedback.
I'll try to explain what I try to calculate with the help of a standard FEM 
textbook:

[image: CaptureFEMbook.PNG]

In the book the global system is partitioned so that the first row contains 
the known U1 dofs and the second row the unknown the dofs U2.
They solve the system for the U2 and then they calculate F1.

I think that the F1 vector  contains, among others, the fluxes from the 
imposed BCs.

Does this make sense?

Can I achieve something like that with deal.ii?

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

Re: [deal.II] Distributing objects on cluster nodes according to distributed triangulation (MPI)

2019-09-03 Thread Wolfgang Bangerth 
On 9/3/19 2:40 AM, Konrad wrote:
> 
> I have a little technical question though: Can I attach the mpi_communicators 
> that you use in the deal.ii tutorials also somehow to a 
> boost::mpi::communicator?
> 
> https://www.boost.org/doc/libs/1_48_0/doc/html/boost/mpi/communicator.html
> 
> Never tried it but according to the documentation it seems possible.

Yes, boost::mpi is a wrapper around MPI, and so the communicators can be 
converted to each other.

boost::mpi is a nice idea in principle, but it's not particularly well 
designed and few people use it. Some reasons are listed here:
 
https://scicomp.stackexchange.com/questions/3019/boostmpi-or-c-mpi-for-high-performance-scientific-applications

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/ea8558d7-6ce8-53b5-d75c-d71225bb9aea%40colostate.edu.

[deal.II] Re: triangulation.add_periodicity takes an enormous amount of time

2019-09-03 Thread Andreas Rupp 
Dear Daniel,
Thank you very much for your reply! You are absolutely right. I used the 
Debug mode where this issue occurs. In Release mode, the problem is gone.
Best,
Andreas

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

Re: [deal.II] Distributing objects on cluster nodes according to distributed triangulation (MPI)

2019-09-03 Thread Konrad 
Thank you, Wolfgang, problem solved. But in a much simpler way. My basis 
object is not easily serializable so I have to recreate it and destroy the 
old one anyway (for now) once cells are moved to other nodes. So I do not 
send send them but rather create them and work with them on each node (if 
the corresponding cell is locally owned) and just collect some serializable 
information on a master process with mpi_gather.

I have a little technical question though: Can I attach the 
mpi_communicators that you use in the deal.ii tutorials also somehow to a 
boost::mpi::communicator?

https://www.boost.org/doc/libs/1_48_0/doc/html/boost/mpi/communicator.html

Never tried it but according to the documentation it seems possible.

Best,
Konrad

On Friday, August 23, 2019 at 6:35:18 PM UTC+2, Wolfgang Bangerth wrote:
>
> On 8/23/19 7:33 AM, Konrad wrote: 
> > 
> > Thanks, I see this class makes it possible to identify cells globally in 
> a 
> > distributed triangulation. I don't see though how the objects in the 
> std::map 
> > are distributed among cluster nodes as the cells are. Am I missing 
> something here? 
>
> Yes, the data transfer is difficult because you need to figure out who 
> owns a 
> cell for which you have an entry in your local map after 
> refinement/rebalancing. Then you need to pack the data, send it to the new 
> owner, and possibly receive information about other cells you now own 
> after 
> refinement/rebalancing. 
>
> You might want to look at how other classes do this that store non-trivial 
> data on each cell. An example is ContinuousQuadratureDataTransfer. 
>
> Best 
>   W. 
>
> -- 
>  
> Wolfgang Bangerth  email: bang...@colostate.edu 
>  
> www: http://www.math.colostate.edu/~bangerth/ 
>
>

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