[deal.II] Re: Using the solution from one problem as a boundary condition in another problem with matching mesh on the boundary

[krei]

Thanks for the response. I think this is worth a try. However, as the 
electric field calculation is entirely decoupled from the nonlinear 
currents & heating part, which need to be solved by newton's method, then 
wouldn't it be effective to just once calculate the field and then start 
the newton iterations for only temperature and currents (probably the 
performance can be made the same, but perhaps code readability decreases)? 
And the second thing is that I want a modular code, where you can choose if 
you want to only calculate electric fields and disregard currents & heating 
or calculate both, in this case it would also be good to keep the codes 
separate. So it would be really convenient to have a some kind a fast 
function like "evaluate_gradient_in_quadrature_point(int index)" or 
something similar.

On Saturday, July 30, 2016 at 1:38:06 PM UTC+3, Daniel Arndt wrote:
>
> krei,
>
> If you want to solve different PDEs on different domains that can be 
> discretized by a common mesh, the preferred approach is to use a hp-vector 
> finite element.
> This means that on each of your subdomains all blocks of your finite 
> element but one are of type FENothing.
> You might want to have a look into step-46 for how to do this.
>
> 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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Floquet periodic conditions and complex valued algebra

[Daniel Garcia]

Dear Daniel,

Thanks a lot for your answer. I will start to use deal.ii and I will come 
back with more specific questions.

Best,
Daniel

On Saturday, July 30, 2016 at 2:15:37 PM UTC+2, Daniel Arndt wrote:
>
> Daniel,
>
> 1.) You can use complex valued algebra if you split your problem into two 
> equations. Apart from that most of the algebra objects can be used with 
> std::complex.
> At the moment, this is not true for constraints given by a 
> ConstraintMatrix object, but this is WIP (
> https://github.com/dealii/dealii/issues/1760).
> 2.) Using SLEPc it should be able to compute eigenvalues for a complex 
> valued system
> 3.) As already mentioned at the moment you can't use std::complex in a 
> ConstraintMatrix. If however, you are able to formulate your problem as a 
> system of real valued problems 
> you can use whatever (linear) boundary condition you want. You can use 
> make_periodicity_constraints to setup the DoFs you want to constraint and 
> modify the inhomogeneity afterwards suitably.
> 4.) If you can formulate your problem as PDE (in not more than 3D) you can 
> likely use deal.II for solving it numerically.
>
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: A question about velocity correction in Step-35

[Jiaqi ZHANG]

Hello Daniel,

Thanks for your help again. So the weakly divergence-free velocity is not

computed in Step-35.


Best,
Jiaqi

2016-07-30 6:12 GMT-04:00 Daniel Arndt :

> Jiaqi,
>
> the algorithm in step-35 is the one that is proposed in
> "L. Timmermans, P. Minev, and F. Van De Vosse, “An approximate projec-
> tion scheme for incompressible flow using spectral elements”, International
> journal for numerical methods in fluids, vol. 22, no. 7, pp. 673–688,
> 1996."
>
> The velocity that is solved for is the auxiliary one. You can recover the
> "true"
> weakly divergence-free velocity by the correction you mentioned.
> Notice that the divergence-free velocity is eliminated from the equation
> for the
> auxiliary velocity.
>
> 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.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Jiaqi Zhang
Graduate student
Department of Mathematics
Virginia Tech

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

Re: [deal.II] Re: A question about velocity correction in Step-35

[Daniel Arndt]

Wolfgang,

Interesting that this isn't even mentioned in the introduction to that 
> program, or anywhere else, for that matter. How did you find out? 
>
A major part of my PhD thesis is based on these projection methods.
Reading the literature this seems to be the first paper in which the 
rotational incremental
form has been considered.
 

> It's probably worthwhile adding this reference somewhere. I can do that if 
> you 
> want me to. 
>
I will create a PR next week including some more references to the analysis 
for that scheme.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: Memory usage using MPI/PETSc on single processor

[Pete Griffin]

Hello, Wolfgang.

I looked at the memory consumption of the system_matrix, the system_rhs and 
solution vectors. The difference appears, as Timo suggested, in 
the system_matrix.

The difference may be that the NEW version uses a DynamicSparsityPattern 
while the OLD only guesses on the size 
with, dof_handler.max_couplings_between_dofs(). Apparently with 3d problems 
the function overestimates. Presently DynamicSparsityPattern is used in 
step-8, but, not in step-17.

Thanks

Pete Griffin

=

NEW Code

Cycle 4:
   Number of active cells:   7484
dof_handler.n_dofs() 29277
solution.size() 29277
system_rhs.size() 29277
system_rhs.local_size() 29277
system_matrix.memory_consumption() 18320628 -> 18 MB
   Number of degrees of freedom: 29277 (by partition: 29277)
   Solver converged in 48 iterations.
   Peak virtual memory: 832 MB, Peak resident memory: 102 MB

=

OLD Code

Cycle 4:
   Number of active cells:   7484
n_local_dofs 29277
solution.local_size() 29277
dof_handler.n_dofs() 29277
solution.size() 29277
system_rhs.size() 29277
system_rhs.local_size() 29277
system_matrix.memory_consumption() 361866548 -> 361 MB
   Number of degrees of freedom: 29277 (by partition: 29277)
   Solver converged in 48 iterations.
   Peak virtual memory: 1142 MB, Peak resident memory: 414 MB


On Sunday, July 31, 2016 at 12:52:11 AM UTC-4, bangerth wrote:
>
> On 07/30/2016 05:08 AM, Pete Griffin wrote: 
> > I used the methodology of step-18 for step-17 which showed memory usage 
> > improvements. I have attached a new version of step-17 that allow 
> selecting 
> > between the NEW and OLD. I also attached the results from both and 
> another 
> > plot. I don't know whether this version will work with more than one 
> processor 
> > I run only on 1. It might be helpful if someone would try to run it and 
> report 
> > success or failure. 
>
> Pete -- the two versions are quite different. Have you found out what 
> *exactly* it is that makes the difference in memory consumption? I would 
> like 
> to add a comment to this effect to the program. 
>
> Best 
>   W. 
>
> -- 
>  
> Wolfgang Bangerth   email:bang...@math.tamu.edu 
>  
>  www: http://www.math.tamu.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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] HP with parallel::shared::Triangulation

[Pete Griffin]

Hi, All.

I get an error from an assertion in the call to:
   dof_handler.distribute_dofs (fe_collection);
The triangulation is a parallel::shared::Triangulation.

My C++ is not as good as it needs to be. It appears as if the exception 
(below) means that HP is not implemented for a 
parallel::shared::Triangulation. Is my interpretation correct ?

Is parallel::distributed::Triangulation implemented ?

Thanks, beforehand.

Pete Griffin

=


Exception on processing: 


An error occurred in line <2733> of file 

 
in function
void dealii::hp::DoFHandler::distribute_dofs(const 
dealii::hp::FECollection&) [with int dim = 3; int spacedim = 
3]
The violated condition was: 
false
The name and call sequence of the exception was:
ExcNotImplemented()

=

 The code related to the  assertion at line <2733> of file dof_handler.cc, 
is as follows:

  template
  void DoFHandler::distribute_dofs (const 
hp::FECollection &ff)
  {
.
.
.
if (dynamic_cast*>
(&this->get_triangulation())
== 0)
  {
number_cache.locally_owned_dofs
  = IndexSet (number_cache.n_global_dofs);
number_cache.locally_owned_dofs.add_range (0,
  
 number_cache.n_global_dofs);
Assert (number_cache.n_global_dofs < std::numeric_limits::max (),
ExcMessage ("Global number of degrees of freedom is too 
large."));
number_cache.n_locally_owned_dofs_per_processor
  = std::vector (1,
  (types::global_dof_index) 
number_cache.n_global_dofs);
  }
else
  {
AssertThrow(false, ExcNotImplemented() );
//number_cache.locally_owned_dofs = 
dealii::DoFTools::locally_owned_dofs_with_subdomain(this,tria->locally_owned_subdomain()
 
);
//TODO: update n_locally_owned_dofs_per_processor as well
  }
.
.
.
  }

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

Re: [deal.II] Re: Memory usage using MPI/PETSc on single processor

[Martin Kronbichler]

Hi Pete,


The difference may be that the NEW version uses 
a DynamicSparsityPattern while the OLD only guesses on the size 
with, dof_handler.max_couplings_between_dofs(). Apparently with 3d 
problems the function overestimates. Presently DynamicSparsityPattern 
is used in step-8, but, not in step-17.
I definitely agree that you should NEVER use 
max_couplings_between_dofs() in 3D. As you see, it overestimates by a 
factor of 20 which is also my experience. I actually think we should put 
an assertion into this function in 3D that forbids its use in 3D. People 
should use dynamic sparsity patterns.


Best,
Martin

--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups "deal.II User Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: A question about velocity correction in Step-35

[Wolfgang Bangerth]

On 07/31/2016 05:16 AM, Daniel Arndt wrote:


I will create a PR next week including some more references to the analysis
for that scheme.


That would be much appreciated! Thanks!
W.


--

Wolfgang Bangerth   email:bange...@math.tamu.edu
www: http://www.math.tamu.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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] HP with parallel::shared::Triangulation

[Wolfgang Bangerth]

On 07/31/2016 12:06 PM, Pete Griffin wrote:


I get an error from an assertion in the call to:
   dof_handler.distribute_dofs (fe_collection);
The triangulation is a parallel::shared::Triangulation.

My C++ is not as good as it needs to be. It appears as if the exception
(below) means that HP is not implemented for a
parallel::shared::Triangulation. Is my interpretation correct ?

Is parallel::distributed::Triangulation implemented ?


Pete -- correct, hp finite elements are not implemented for either of the two 
parallel triangulations. I.e., they can currently only be used for sequential 
computations. This is pretty high on our list to get implemented in parallel.


Best
 W.


--

Wolfgang Bangerth   email:bange...@math.tamu.edu
www: http://www.math.tamu.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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] HP with parallel::shared::Triangulation

[Pete Griffin]

Thanks, Wolfgang

Pete Griffin

On Sunday, July 31, 2016 at 2:53:03 PM UTC-4, bangerth wrote:
>
> On 07/31/2016 12:06 PM, Pete Griffin wrote: 
> > 
> > I get an error from an assertion in the call to: 
> >dof_handler.distribute_dofs (fe_collection); 
> > The triangulation is a parallel::shared::Triangulation. 
> > 
> > My C++ is not as good as it needs to be. It appears as if the exception 
> > (below) means that HP is not implemented for a 
> > parallel::shared::Triangulation. Is my interpretation correct ? 
> > 
> > Is parallel::distributed::Triangulation implemented ? 
>
> Pete -- correct, hp finite elements are not implemented for either of the 
> two 
> parallel triangulations. I.e., they can currently only be used for 
> sequential 
> computations. This is pretty high on our list to get implemented in 
> parallel. 
>
> Best 
>   W. 
>
>
> -- 
>  
> Wolfgang Bangerth   email:bang...@math.tamu.edu 
>  
>  www: http://www.math.tamu.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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] time-dependent boundary conditions for distributed computations

[Marek Čapek]

Hello,
is it possible to compute in distributed manner like in Step-40
and to impose different boundary condition in each time step.
In the step-40 the constraint matrix is set in front

constraints.clear 

 
();
constraints.reinit 

 
(locally_relevant_dofs);
DoFTools::make_hanging_node_constraints 

 
(dof_handler, constraints);
VectorTools::interpolate_boundary_values 

 
(dof_handler,
0, ZeroFunction 
(), 
constraints);
constraints.close 

 
();

and the modification of the assembled matrices and right hand sides is
done, for me, somehow behind the curtain in the call
...
cell->get_dof_indices (local_dof_indices); 
constraints.distribute_local_to_global 

 
(cell_matrix,cell_rhs,local_dof_indices,system_matrix,system_rhs);
...
Is there an alternative way how to apply BC's in each time step and still 
conserve the possibility of
distributed computations?

Thank You

Marek

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

[deal.II] Re: time-dependent boundary conditions for distributed computations

[Daniel Arndt]

Marek,

You would just set up your ConstraintMatrix anew. This is also the way it 
is done in step-44.

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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Development activity over the past year

[Wolfgang Bangerth]

All,
I'm writing my annual report to the NSF and wanted to share a few statistics I 
thought were interesting:


* 40,000 new lines of code in deal.II (excluding testsuite) over the past year
* 77 new testcases
* 4 new tutorial programs
* 1540 emails to dealii@googlegroups.com between January to July alone
* 725 people are subscribed to the mailing list (+190 compared to last year)

What this shows to me is that this is a vibrant community that is doing 
awesome things and helping each other! Thanks to you all for participating in 
the many ways in which you contribute!


Best
 Wolfgang

PS: If you haven't actively participated so far, we would love to have you be 
a more active part of this project! Here are a few ideas:

  https://github.com/dealii/dealii/blob/master/CONTRIBUTING.md
  https://www.dealii.org/participate.html

--

Wolfgang Bangerth   email:bange...@math.tamu.edu
www: http://www.math.tamu.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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Development activity over the past year

[Wolfgang Bangerth]

I'm writing my annual report to the NSF and wanted to share a few statistics I
thought were interesting:

* 40,000 new lines of code in deal.II (excluding testsuite) over the past year
* 77 new testcases
* 4 new tutorial programs
* 1540 emails to dealii@googlegroups.com between January to July alone
* 725 people are subscribed to the mailing list (+190 compared to last year)


I could also add this:
* On average, more than 1,000 downloads per month (excluding those who work
  directly from the github repository)
* We merged 3.4 pull request per day on average, weekday or weekend.
* 54 distinct people contributed code and documentation over the last
  year.

I am particularly proud of the last number!

Cheers
 W.

--

Wolfgang Bangerth   email:bange...@math.tamu.edu
www: http://www.math.tamu.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.
For more options, visit https://groups.google.com/d/optout.