Re: [deal.II] Modelling Anistropic materials for electrostatic simulations

[Wolfgang Bangerth]

> I have been reading through you paper a couple of times now but I od not see 
> how it relates to anisotropic materials. I could be missing something or 
> misunderstanding some parts. From what I can tell from the paper, the strong 
> form of linear elasticity is:
> 
> ∇· σ + b = 0 on Ω.
> 
> where σ is the stress tensor which is modeled by σ = σ m + σ f. The isotropic 
> linear constitutive law is given by: σm = C m : ε. Which is basically Hooke's 
> law. Now, hooke's law does have an analogue for the polarization of a 
> dielectric material when the material is exposed to an electric field. I am 
> not very sure if this is the direction that I need to go in.
> 
> 
> I have been looking up anisotropic materials for linear elasticity. I might 
> be 
> missing something but I am having a hard time seeing how this relates to the 
> electrostatic case? Maybe I need to spend a little bit more time on this 
> topic. I do see that there is a similarity between div *[* *\epsilon* *e*] = 
> \rho^{f} and ∇· σ + b = 0 where σ = *\epsilon* *e *and b = - \rho^{f}.

You have
   sigma = C eps(u)
and
   -div sigma = b
which together yields
   -div (C eps(u)) = b
and is the equivalent of
   -div (K grad u) = f

The elastic material is anisotropic if the stress-strain tensor C represents 
an anisotropic material. In the elasticity case, it isn't just a dxd matrix, 
but a dxdxdxd (rank-4) tensor. So it looks more complicated, but it isn't 
really.

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

Re: [deal.II] Modelling Anistropic materials for electrostatic simulations

[Wolfgang Bangerth]

On 11/6/18 8:10 PM, phillip mobley wrote:
> 
> I ma currently exploring 2 directions, Jean-Paul linear elastic direction and 
> the Mixed-Laplace direction. From what I can tell, modeling the anisotropic 
> materials will not be a problem in deal.ii. Which is a nice thing.

Yes, definitely not a problem!

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

Re: [deal.II] Modelling Anistropic materials for electrostatic simulations

[phillip mobley]

Hello Dr. Bangerth,

Thank you for your response and clearing up those questions. I am 
continually going through steps 8, 20, and 21.

I ma currently exploring 2 directions, Jean-Paul linear elastic direction 
and the Mixed-Laplace direction. From what I can tell, modeling the 
anisotropic materials will not be a problem in deal.ii. Which is a nice 
thing.

On Tuesday, November 6, 2018 at 9:17:45 AM UTC-5, Wolfgang Bangerth wrote:
>
>
> Philip, 
>
> > The equations for finding these are exactly in step-20. But the symbols 
> used 
> > are different. 
>
> Yes -- the beautiful universality of mathematics :-) 
>
>
> > 1) Is Raviet-Thomas elements specific for mixed Laplace equations? I 
> > understand that step-20 is a tutorial and for learning. Other then being 
> a 
> > good learning opportunity, is there any specific reason why RT elements 
> were 
> > chosen for step-20? 
>
>  From the introduction of step-20: 
>
> "It is a well-known fact stated in almost every book on finite element 
> theory 
> that if one chooses discrete finite element spaces for the approximation 
> of 
> u,p inappropriately, then the resulting discrete saddle-point problem is 
> instable and the discrete solution will not converge to the exact 
> solution. 
>
> To overcome this, a number of different finite element pairs for u,p have 
> been 
> developed that lead to a stable discrete problem. One such pair is to use 
> the 
> Raviart-Thomas spaces RT(k) for the velocity u and discontinuous elements 
> of 
> class DQ(k) for the pressure p. For details about these spaces, we refer 
> in 
> particular to the book on mixed finite element methods by Brezzi and 
> Fortin, 
> but many other books on the theory of finite elements, for example the 
> classic 
> book by Brenner and Scott, also state the relevant results." 
>
>
> > 1b) From another perspective, If I am solving for the mixed Laplace 
> equation, 
> > do I need to setup the system to use the RT elements? 
>
> Yes. Or some of the other Hdiv elements. 
>
>
> > 2) The weak derivation for step-20 has Dirichlet boundary values 
> incorporated 
> > into it. I believe the sentence is "Note how in this formulation, 
> Dirichlet 
> > boundary values of the original problem are incorporated in the weak 
> form." I 
> > am guessing that this is because of the p = g on d(omega) term. Later 
> down the 
> > road, I might need to implement different B.C. such as a periodic, 
> > anti-periodic, or a mixed coefficient B.C. If this is the case, would I 
> need 
> > to re-derive the weak form? Or can I utilize the one found in step-20? 
> Or, 
> > would it be better for me to derive a more general weak form that can be 
> used 
> > with any B.C.? 
>
> In general, whenever you integrate by parts, you get a boundary term and 
> you 
> will have to think what to do with it. That's the place where you can 
> apply 
> boundary values into the weak formulation. In the case of the mixed 
> Laplace, 
> that just happens to be where Dirichlet boundary conditions go, just like 
> with 
> the usual (non-mixed) formulation of the Laplace equation, the boundary 
> term 
> allows you to take care of Neumann boundary conditions. 
>
>
> > 3) From what I have read so far, I get the impression that the R.T 
> elements 
> > are also incorporated into the weak form. Basically this sentence here: 
> "Both 
> > xhand whare from the space Xh=RT(k)×DQ(k), where RT(k)is itself a 
> space"? is 
> > this thought correct? If so, if I wanted to change the element type 
> later, 
> > would I need to re-derive the weak form? 
>
> No. You derive the weak formulation of the PDE, i.e., the continuous 
> model. It 
> makes no reference to the (later step of) discretization. 
>
>
> > 4) The weak enforcement of the pressure boundary conditions, does this 
> need to 
> > be factored in even if the B.C are not Dirichlet? 
>
> If you have Neumann boundary conditions, then you'll have to see what to 
> do 
> with it in the context of the weak form you happen to have. I think I have 
> a 
> whole video lecture on boundary conditions :-) 
>
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Modelling Anistropic materials for electrostatic simulations

[phillip mobley]

Hello Jean-Paul,

Thank you for the links and resources. I am going through them now. I am 
not very familiar with linear elastic. I was able to better understand the 
step-20 and how it applies to electrostatics because I was able to relate 
the equations to their electrostatic equivalents.

I have been reading through you paper a couple of times now but I od not 
see how it relates to anisotropic materials. I could be missing something 
or misunderstanding some parts. From what I can tell from the paper, the 
strong form of linear elasticity is:

∇· σ + b = 0 on Ω.

where σ is the stress tensor which is modeled by σ = σ m + σ f. The 
isotropic linear constitutive law is given by: σm = C m : ε. Which is 
basically Hooke's law. Now, hooke's law does have an analogue for the 
polarization of a dielectric material when the material is exposed to an 
electric field. I am not very sure if this is the direction that I need to 
go in.


I have been looking up anisotropic materials for linear elasticity. I might 
be missing something but I am having a hard time seeing how this relates to 
the electrostatic case? Maybe I need to spend a little bit more time on 
this topic. I do see that there is a similarity between div *[* *\epsilon* 
*e*] = \rho^{f} and ∇· σ + b = 0 where σ = *\epsilon* *e *and b = - 
\rho^{f}. 



On Tuesday, November 6, 2018 at 3:51:43 AM UTC-5, Jean-Paul Pelteret wrote:
>
> Dear Philip,
>
> Let me offer an alternative to what Wolfgang has suggested. I don’t think 
> that it is necessary to use a mixed formulation to introduce material 
> anisotropy into your problem. If you go back to the derivation in our 
> previous discussion, there was this line:
>
> (6) div *[*\epsilon_{0} \epsilon_{r} *e*] = \rho^{f} 
>
> For tensor valued coefficient you could restate this in one of two ways. 
> Either
>
> (6a) div *[* *\epsilon_{r}* *e*] = \rho^{f} / \epsilon_{0}
>
> where *\epsilon_{r}* is a tensor of relative electric permittivity 
> coefficients, or
>
> (6b) div *[* *\epsilon* *e*] = \rho^{f}
>
> where *\epsilon* is a tensor of electric permittivity coefficients.
>
> The latter, (6b) is analogous to linear elasticity. In fact, we have a 
> code-gallery 
> example 
> 
>  (here’s 
> a link to the theory pdf 
> )
>  
> that deals with anisotropic linear elasticity. I think that you would 
> benefit greatly by reading the literature on piezoelectric materials, which 
> are regularly modelled with a linear constitutive law. 
>
> Touching on one of your other questions, I would say that nowadays many 
> people would tend to use the electric scalar potential approach (solving 
> for *d* with *e* as the independent field) to modelling these materials 
> under electrostatic conditions, rather than the electric vector potential 
> formulation (solving for *e* with *d* as the independent field). I’m not 
> saying that one is more correct than the other - I’m just reporting what I 
> perceive the trend in the literature to be (I’d be happy to have someone 
> offer a different opinion that me on this). There is literally a mountain 
> of literature dating back to the 1980’s on this topic, so I leave it up to 
> you to read into this more.
>
> Best,
> Jean-Paul
>
> On 02 Nov 2018, at 18:57, phillip mobley  > wrote:
>
> Hello all,
>
> This is a follow up discussion to the Jean-Paul answer to the question "Is 
> the approach for the electrostatic Bi-linear form correct?". The question 
> (and answer) can be found at the following link:
>
> https://groups.google.com/forum/#!topic/dealii/i8P4JTwm7kQ
>
> In short, I am modeling the maxwell equations for the electric field and 
> voltage scalar field. The equations that I am using are displayed below:
>
> div(*E*) = rho / epsilon where epsilon = epsilon_{0} * epsilon_{r} and 
> rho is the charge density of the material.
>
> -grad(V) = *E*
>
> Using Dr. Bangerth's recommendation, I am solving for the scalar voltage 
> field first then taking the gradient of my solution using the 
> DataPostprocessorVector class. This has worked extremely well in my test 
> program. For more information on that, see this post: 
> https://groups.google.com/forum/#!topic/dealii/XIiPyMh0Jz4
>
> However, now that I am actually coding the solver of the simulation, I 
> will need to expand on my test simulation to include modeling anisotropic 
> materials.
>
> When the material is anisotropic, the epsilon value (the permittivity) of 
> the material is represented by a tensor. To make things slightly 
> simplified, I am only running 2D simulations.
>
> I am attempting to determine the best method on modeling these types of 
> materials. One approach that I have considered is to still solve for the 
> voltage scalar field. If I go with this approach,

Re: [deal.II] How to compute the cellwise error of the finite element solution without exact solution?

[Wolfgang Bangerth]

On 11/06/2018 08:52 AM, chucui1...@gmail.com wrote:
> 
> And now I have another question: I want to compute numerical solutions 
> in different widths of meshgrid, so I need different triangulations, 
> dof_handlers, solution vectors. And I need to compute the finest one at 
> first because I need to use the solution_finest as the 'exact solution'. 
> The question is how to coarse the meshgrid after getting the 
> solution_finest? If I want to refine the mesh, I will use 
> 'triangulation.refine(1)'.

There is no function that automatically does this, but the following 
will do the trick:

   for (auto &cell : triangulation.active_cell_iterators())
 cell->set_coarsen_flag();
   triangulation.execute_coarsening_and_refinement();

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

Re: [deal.II] Re: Status of matrix-free CUDA support

[Stephen DeWitt]

Bruno and Martin,
Thank you for your responses. I'll try to get a CUDA version of step-48 up 
and running.

Thanks!
Steve

On Monday, November 5, 2018 at 3:18:25 PM UTC-5, Martin Kronbichler wrote:
>
> Steve,
>
> Just to add on what Bruno said: Explicit time integration typically 
> requires only a subset of what you need for running an iterative solver (no 
> decision making like in convergence test of conjugate gradient, no 
> preconditioner), so running that should be pretty straight-forward.
>
> Best,
> Martin
> On 05.11.18 21:06, Bruno Turcksin wrote:
>
> Steve
>
> On Monday, October 29, 2018 at 10:43:48 AM UTC-4, Stephen DeWitt wrote: 
>>
>> So far I've read through the "CUDA Support" issue 
>> , the "Roadmap for 
>> inclusion of GPU implementation of matrix free in Deal.II" issue 
>> , the Doxygen 
>> documentation for classes in the CUDAWrappers namespace 
>> , 
>> and the manuscript by Karl Ljungkvist 
>> . 
>> Are there any other pages I should be looking at?
>>
> No that's pretty much it. 
>
> My understanding from these pages is that deal.II has partial support for 
>> using CUDA with matrix free calculations. Currently, calculations can be 
>> done with scalar variables (but not vector variables) and adaptive meshes.
>>
> That's correct with the weird exception that you cannot impose constraints 
> (and thus have hanging nodes) if dim equals 2 and fe_degree is even. There 
> is a bug in that case but we don't know why.
>
> A few (somewhat inter-related) questions:
>> 1). Do all of the tools exist to create a GPU version of step-48? Has 
>> anyone done so?
>>
> I think so but nobody as tried so I am not 100% sure. Note that we don't 
> have MPI support yet. 
>
>> 2). What exactly would be involved in creating a GPU version of step-48? 
>> Is it just changing the CPU Vector, MatrixFree, and FEEvaluation classes to 
>> their GPU counterparts, plus packaging some data (plus local apply 
>> functions?) into a CUDAWrappers::MatrixFree< dim, Number >::Data 
>> 
>>  struct?
>>
> Yes, pretty much. You can take a look at the matrix_free_matrix_vector 
> tests here . 
> These tests are doing a matrix-vector multiplication using an Helmholtz 
> operator. As you can see here 
>  
> the main difference between the GPU and the CPU code is that the body loop 
> over the quadrature points needs to be encapsulated in a functor when using 
> GPU. The tests are based on the CPU tests matrix_vector here 
> . So you 
> should have a good idea of the modifications required to use the GPU code.
>
>> 3). Most of the discussions seemed to revolve around linear solves. For 
>> something like step-48 with explicit updates, will the current paradigm 
>> work well? Or would that require shuttling data between the GPU and CPU 
>> every time step, causing too much overhead? (I know that in general GPUs 
>> can work very well for explicit codes.)
>>
> That should work fine. Most people are interested in using matrix-free 
> with a solver but I don't see a reason why it would be slow in step 48. The 
> communication between the CPU and the GPU should be limited in step-48.
>
> Best,
>
> Bruno
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to dealii+un...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
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] How to restart a time dependent code from its breakpoint?

[Jean-Paul Pelteret]

Dear Chucui,

The standard Triangulation class has a save function 
,
 so the methodology shown in those examples can likely be applied exactly to 
the serial case.

Best,
Jean-Paul

> On 06 Nov 2018, at 16:20, chucui1...@gmail.com wrote:
> 
> Dear Jean-Paul,
> 
> Thank you for your reply! As the examples you set, and an answer I found:  
> See "Use for serialization" in 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.dealii.org_developer_doxygen_deal.II_classparallel-5F1-5F1distributed-5F1-5F1SolutionTransfer.html&d=DwIBaQ&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw&m=88KR9zh1f_gaVgWHpZwwXXlaOCduKgZ1yzsuERztdmU&s=Q549G3WmW1DtS06Yq9GyH98gIg8Rl44Ezac7I1Fc1Tc&e=
>  
> 
>  
> these functions such as  ' Triangulation::save()', 'Triangulation::load()', 
> void SolutionTransfer< dim, VectorType, DoFHandlerType 
> >::prepare_serialization   (   const VectorType &  in  )  
>  
>  void SolutionTransfer< dim, VectorType, DoFHandlerType >::deserialize
> (   VectorType &in  )
> are all used in the parallel examples.
> But my code is not use any class and headfile for parallel one. Shall I 
> rewrite my code into a parallel one? Thank you very much!
> 
> Best,
> Chucui   
> 
> 在 2018年11月5日星期一 UTC+8下午5:01:06，Jean-Paul Pelteret写道：
> Dear Chucui,
> 
> I don’t use this functionality myself, so I can only point you to the test 
> suite  
> where its functionality is tested. Here 
>  is 
> one example where a distributed triangulation is saved and loaded, and here 
>  is 
> one where a distributed triangulation + solution is saved and loaded with a 
> different number of MPI processes.
> 
> Best,
> Jean-Paul
> 
> 
> 
> -- 
> 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 
> .

-- 
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] How to compute the cellwise error of the finite element solution without exact solution?

[chucui1016]

Dear Prof. Bangerth,

Thank you very much! 
FEFieldFunction fe_function_finest (dof_handler_finest, solution_finest
);
And I can use the fe_function_finest in function:  VectorTools::
integrate_difference 

And now I have another question: I want to compute numerical solutions in 
different widths of meshgrid, so I need different triangulations, 
dof_handlers, solution vectors. And I need to compute the finest one at 
first because I need to use the solution_finest as the 'exact solution'. 
The question is how to coarse the meshgrid after getting the 
solution_finest? If I want to refine the mesh, I will use 
'triangulation.refine(1)'. But I don't know how to coarse the mesh. Or 
maybe I have to define different triangulations, dof_handlers at first, and 
compute different solution vectors. If so, the code will be very long. 
Thank you very much!

Best,
Chucui

>
> You can't do this directly -- the function just wants an object that can 
> be evaluated at arbitrary points. Passing a vector by itself will not 
> help: a vector is just a bunch of numbers, but it does not by itself 
> explain how it is to be interepreted. Indeed, a vector by itself is 
> meaningless unless you also specify a DoFHandler that makes the 
> connection between nodal values, where these nodes are located in 
> physical space, and how the shape functions are defined. 
>
> But there is a class that combines all of this knowledge and that then 
> represents a finite element field (=DoFHandler + Vector) as a function: 
> FEFieldFunction. Take a look at that class, as it implements the 
> interface of a Function object that can be passed in the place you point 
> out. It is not particularly fast, but should allow you to do what you 
> want. 
>
> Of course, you have to make sure that both the 'dof' and 'fe_function' 
> arguments to the VectorTools::integrate_difference() function match 
> (i.e., you can't just save a solution vector, and then refine the 
> triangulation and thereby change the DoFHandler), as well as the 
> DoFHandler and Vector objects you pass to FEFieldFunction. 
>
> 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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: How to restart a time dependent code from its breakpoint?

[chucui1016]

Dear Jean-Paul and dear Stephen,

Thank you for your reply! As the examples you set, and an answer I 
found:  See "Use for serialization" in 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.dealii.org_developer_doxygen_deal.II_classparallel-5F1-5F1distributed-5F1-5F1SolutionTransfer.html&d=DwIBaQ&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw&m=88KR9zh1f_gaVgWHpZwwXXlaOCduKgZ1yzsuERztdmU&s=Q549G3WmW1DtS06Yq9GyH98gIg8Rl44Ezac7I1Fc1Tc&e=
 

 
these functions such as  ' Triangulation::save()', 'Triangulation::load()', 
void SolutionTransfer< dim, VectorType, DoFHandlerType 
>::prepare_serialization ( const VectorType &  in ) 
 void SolutionTransfer< dim, VectorType, DoFHandlerType >::deserialize ( 
VectorType 
&  in )
are all used in the parallel examples.
But my code is not use any class and headfile for parallel one. Shall I 
rewrite my code into a parallel one? Thank you very much!

Best,
Chucui 


-- 
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] How to restart a time dependent code from its breakpoint?

[chucui1016]

Dear Jean-Paul,

Thank you for your reply! As the examples you set, and an answer I 
found:  See "Use for serialization" in 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.dealii.org_developer_doxygen_deal.II_classparallel-5F1-5F1distributed-5F1-5F1SolutionTransfer.html&d=DwIBaQ&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw&m=88KR9zh1f_gaVgWHpZwwXXlaOCduKgZ1yzsuERztdmU&s=Q549G3WmW1DtS06Yq9GyH98gIg8Rl44Ezac7I1Fc1Tc&e=
 

 
these functions such as  ' Triangulation::save()', 'Triangulation::load()', 
void SolutionTransfer< dim, VectorType, DoFHandlerType 
>::prepare_serialization ( const VectorType & in ) 
 void SolutionTransfer< dim, VectorType, DoFHandlerType >::deserialize ( 
VectorType 
& in )
are all used in the parallel examples.
But my code is not use any class and headfile for parallel one. Shall I 
rewrite my code into a parallel one? Thank you very much!

Best,
Chucui   

在 2018年11月5日星期一 UTC+8下午5:01:06，Jean-Paul Pelteret写道：
>
> Dear Chucui,
>
> I don’t use this functionality myself, so I can only point you to the 
> test suite 
>  where 
> its functionality is tested. Here 
>  is 
> one example where a distributed triangulation is saved and loaded, and 
> here 
>  is 
> one where a distributed triangulation + solution is saved and loaded with a 
> different number of MPI processes.
>
> Best,
> Jean-Paul
>
>
>

-- 
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] Modelling Anistropic materials for electrostatic simulations

[Wolfgang Bangerth]

Philip,

> The equations for finding these are exactly in step-20. But the symbols used 
> are different.

Yes -- the beautiful universality of mathematics :-)


> 1) Is Raviet-Thomas elements specific for mixed Laplace equations? I 
> understand that step-20 is a tutorial and for learning. Other then being a 
> good learning opportunity, is there any specific reason why RT elements were 
> chosen for step-20?

 From the introduction of step-20:

"It is a well-known fact stated in almost every book on finite element theory 
that if one chooses discrete finite element spaces for the approximation of 
u,p inappropriately, then the resulting discrete saddle-point problem is 
instable and the discrete solution will not converge to the exact solution.

To overcome this, a number of different finite element pairs for u,p have been 
developed that lead to a stable discrete problem. One such pair is to use the 
Raviart-Thomas spaces RT(k) for the velocity u and discontinuous elements of 
class DQ(k) for the pressure p. For details about these spaces, we refer in 
particular to the book on mixed finite element methods by Brezzi and Fortin, 
but many other books on the theory of finite elements, for example the classic 
book by Brenner and Scott, also state the relevant results."


> 1b) From another perspective, If I am solving for the mixed Laplace equation, 
> do I need to setup the system to use the RT elements?

Yes. Or some of the other Hdiv elements.


> 2) The weak derivation for step-20 has Dirichlet boundary values incorporated 
> into it. I believe the sentence is "Note how in this formulation, Dirichlet 
> boundary values of the original problem are incorporated in the weak form." I 
> am guessing that this is because of the p = g on d(omega) term. Later down 
> the 
> road, I might need to implement different B.C. such as a periodic, 
> anti-periodic, or a mixed coefficient B.C. If this is the case, would I need 
> to re-derive the weak form? Or can I utilize the one found in step-20? Or, 
> would it be better for me to derive a more general weak form that can be used 
> with any B.C.?

In general, whenever you integrate by parts, you get a boundary term and you 
will have to think what to do with it. That's the place where you can apply 
boundary values into the weak formulation. In the case of the mixed Laplace, 
that just happens to be where Dirichlet boundary conditions go, just like with 
the usual (non-mixed) formulation of the Laplace equation, the boundary term 
allows you to take care of Neumann boundary conditions.


> 3) From what I have read so far, I get the impression that the R.T elements 
> are also incorporated into the weak form. Basically this sentence here: "Both 
> xhand whare from the space Xh=RT(k)×DQ(k), where RT(k)is itself a space"? is 
> this thought correct? If so, if I wanted to change the element type later, 
> would I need to re-derive the weak form?

No. You derive the weak formulation of the PDE, i.e., the continuous model. It 
makes no reference to the (later step of) discretization.


> 4) The weak enforcement of the pressure boundary conditions, does this need 
> to 
> be factored in even if the B.C are not Dirichlet?

If you have Neumann boundary conditions, then you'll have to see what to do 
with it in the context of the weak form you happen to have. I think I have a 
whole video lecture on boundary conditions :-)

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

[deal.II] Re: Trouble building from source on MacOS

[Denis Davydov]

On Monday, November 5, 2018 at 9:20:21 PM UTC, mrjonm...@gmail.com wrote:
>
> Thanks for the suggestion. I tried building with candi today, but it 
> failed somewhere during the p4est-2.0/FAST build from the look of it. I've 
> been using macports instead of homebrew, and I'm wondering if some of the 
> ports are causing issues. I might try removing all the ports and macports 
> this evening to see if that fixes it. 
>

Try https://github.com/dealii/dealii/wiki/deal.II-in-Spack 
that is what we use to deliver macOS binaries.
It won't assume that you have anything installed (won't use macports or 
homebrew).
It will also allow to you keep around multiple versions of Software without 
conflicts.

The only thing is that you shall either have `gfortran` installed (can also 
do via Spack) or it being in path and then tell spack to use clang + 
gfortran,
see https://github.com/dealii/dealii/wiki/deal.II-in-Spack#using-macos 

I use Spack for build deal.II for several years, probably sins Sierra. Now 
I am on Mojave.
 

>
> Also, I didn't install any of the packages listed as optional in the candi 
> instructions. Those were: wget, gnuplot, bash and modules. 
>

those (any many more) can also be installed via Spack.

Regards,
Denis.

-- 
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] Modelling Anistropic materials for electrostatic simulations

[Jean-Paul Pelteret]

Dear Philip,

Let me offer an alternative to what Wolfgang has suggested. I don’t think that 
it is necessary to use a mixed formulation to introduce material anisotropy 
into your problem. If you go back to the derivation in our previous discussion, 
there was this line:

(6) div [\epsilon_{0} \epsilon_{r} e] = \rho^{f} 

For tensor valued coefficient you could restate this in one of two ways. Either

(6a) div [ \epsilon_{r} e] = \rho^{f} / \epsilon_{0}

where \epsilon_{r} is a tensor of relative electric permittivity coefficients, 
or

(6b) div [ \epsilon e] = \rho^{f}

where \epsilon is a tensor of electric permittivity coefficients.

The latter, (6b) is analogous to linear elasticity. In fact, we have a 
code-gallery example 

 (here’s a link to the theory pdf 
)
 that deals with anisotropic linear elasticity. I think that you would benefit 
greatly by reading the literature on piezoelectric materials, which are 
regularly modelled with a linear constitutive law. 

Touching on one of your other questions, I would say that nowadays many people 
would tend to use the electric scalar potential approach (solving for d with e 
as the independent field) to modelling these materials under electrostatic 
conditions, rather than the electric vector potential formulation (solving for 
e with d as the independent field). I’m not saying that one is more correct 
than the other - I’m just reporting what I perceive the trend in the literature 
to be (I’d be happy to have someone offer a different opinion that me on this). 
There is literally a mountain of literature dating back to the 1980’s on this 
topic, so I leave it up to you to read into this more.

Best,
Jean-Paul

> On 02 Nov 2018, at 18:57, phillip mobley  wrote:
> 
> Hello all,
> 
> This is a follow up discussion to the Jean-Paul answer to the question "Is 
> the approach for the electrostatic Bi-linear form correct?". The question 
> (and answer) can be found at the following link:
> 
> https://groups.google.com/forum/#!topic/dealii/i8P4JTwm7kQ 
> 
> 
> In short, I am modeling the maxwell equations for the electric field and 
> voltage scalar field. The equations that I am using are displayed below:
> 
> div(E) = rho / epsilon where epsilon = epsilon_{0} * epsilon_{r} and rho is 
> the charge density of the material.
> 
> -grad(V) = E
> 
> Using Dr. Bangerth's recommendation, I am solving for the scalar voltage 
> field first then taking the gradient of my solution using the 
> DataPostprocessorVector class. This has worked extremely well in my test 
> program. For more information on that, see this post: 
> https://groups.google.com/forum/#!topic/dealii/XIiPyMh0Jz4 
> 
> 
> However, now that I am actually coding the solver of the simulation, I will 
> need to expand on my test simulation to include modeling anisotropic 
> materials.
> 
> When the material is anisotropic, the epsilon value (the permittivity) of the 
> material is represented by a tensor. To make things slightly simplified, I am 
> only running 2D simulations.
> 
> I am attempting to determine the best method on modeling these types of 
> materials. One approach that I have considered is to still solve for the 
> voltage scalar field. If I go with this approach, then I will end up 
> simulating a Possion equation where f = rho / epsilon and epsilon is a 
> tensor. My concern for this direction would be that the Laplacian operator 
> results in a scalar value. So I am not sure how I would handle the tensor on 
> the RHS. Unless Deal.II has some sort of provision for this.
> 
> I have also been kicking around the idea of solving for the displacement 
> vector D(i)= epsilon(i)(j) * E by substituting this equation into one of the 
> equations above. Or at the very least, to use this equation as a constitutive 
> relation to the equations above.
> 
> A third approach that I haven't quite explored very much is solving for the 
> polarization of the material. But I am not sure if this is a practical 
> approach since I could unnecessarily complicate the problem.
> 
> I wanted to post a discussion on this form to discuss what the best direction 
> I should take to model anisotropic materials in Deal.ii? I have been looking 
> at 3 different approaches and I would like to discuss which one of these 3 
> directions is the better. Or if there might be others that I have not 
> considered yet.
> 
> -- 
> 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 r