Re: [deal.II] Assemble system slowing down the program

[Jean-Paul Pelteret]

Hi Wasim,

It looks like you're passing your solution vector by copy for each cell
that you're assembling on. You probably want to pass it by reference.

Best,
Jean-Paul

Sent from my mobile device. Please excuse my brevity and any typos.

On Sun, 08 Jan 2023, 14:38 Wasim Niyaz Munshi ce21d400, <
ce21d...@smail.iitm.ac.in> wrote:

> Thank you Prof. Munch.
>
> I am now passing FEValues object as a parameter to the H_plus function. My
> assemble time has decreased from (4-5 seconds) to around 2 seconds, but it
> is still nowhere close to the time required if there is no call to h_plus
> function(say eg. step-3 tutorial problem).
> I don't expect to match that time but is there still anything that I can
> do to reduce the assembly time further?
>
> Thanks and regards
> Wasim
>
> On Sunday, January 8, 2023 at 4:11:27 PM UTC+5:30 Wasim Niyaz Munshi
> ce21d400 wrote:
>
>> Do I need to make this change in both declaration and definition?
>> Also, do I need a* const *because then* fe_values.reinit(cell) *will be
>> discarded?
>>
>> Thanks
>> Wasim
>>
>> On Sun, Jan 8, 2023 at 3:44 PM Peter Munch  wrote:
>>
>>> Change:
>>>
>>> > float H_plus(Vector solution_elastic, const auto cell,const
>>> unsigned int q_point,
>>>* FEValues<2> fe_values_damage*);
>>>
>>> to:
>>>
>>> > float H_plus(Vector solution_elastic, const auto cell,const
>>> unsigned int q_point,
>>>* const FEValues<2> & fe_values_damage*);
>>>
>>> Peter
>>> On Sunday, 8 January 2023 at 11:11:34 UTC+1 ce21...@smail.iitm.ac.in
>>> wrote:
>>>
 Thank you, Prof. Munch.

 I tried to pass the FEValues object as a parameter to the H_plus
 function as follows:

 I changed the function declaration from:
 float H_plus(Vector solution_elastic, const auto cell,const
 unsigned int q_point);
 to this:
 float H_plus(Vector solution_elastic, const auto cell,const
 unsigned int q_point,
* FEValues<2> fe_values_damage*);

 I made the same change in the function definition also.

 I also changed the call to my function from:
 H_plus(solution_elastic,cell,q_index)
 to this: H_plus(solution_elastic,cell,q_index,*fe_values_damage*)

 But I am getting the following error:
 error: use of deleted function ‘dealii::FEValues<2>::FEValues(const
 dealii::FEValues<2>&)’
   761 |{ float H_call =
 H_plus(solution_elastic,cell,q_index,fe_values_damage);


 On Sunday, January 8, 2023 at 2:32:24 PM UTC+5:30 peterr...@gmail.com
 wrote:

> You are creating a new instance of FEValues at each quadrature point.
> This is a very expensive operation, since there all the shape functions 
> are
> evaluated. Try to reuse that by passing it to the function as a parameter.
>
> Hope that helps!
> Peter
>
> On Sunday, 8 January 2023 at 09:58:41 UTC+1 ce21...@smail.iitm.ac.in
> wrote:
>
>> Following is my H_plus function:
>>
>> float PhaseField::H_plus(Vector solution_elastic
>> , const auto cell,const unsigned int q_point)
>> {
>> QGauss<2> quadrature_formula_damage(fe_damage.degree + 1);
>>
>> FEValues<2> fe_values_damage(fe_damage,
>> quadrature_formula_damage,
>> update_gradients |
>> update_quadrature_points );
>>
>> fe_values_damage.reinit(cell);
>>
>> int node = 0;
>>
>> /* Initialising all strains as zero */
>> float e_xx = 0.000;
>> float e_yy = 0.000;
>> float e_xy = 0.000;
>>
>> /*calculating strains*/
>> for (const auto vertex : cell->vertex_indices())
>> {
>> int a = (cell->vertex_dof_index(vertex, 0));
>> e_xx = e_xx +
>> solution_elastic[a*2]*fe_values_damage.shape_grad(node, q_point)[0];
>> e_yy = e_yy +
>> solution_elastic[a*2+1]*fe_values_damage.shape_grad(node, q_point)[1];
>> e_xy = e_xy
>> +0.5*(solution_elastic[a*2]*fe_values_damage.shape_grad(node, q_point)[1]
>>
>>
>>  +solution_elastic[a*2+1]*fe_values_damage.shape_grad(node, q_point)[0]);
>> node = node +1;
>> }
>>
>> const auto _q = fe_values_damage.quadrature_point(q_point);
>> float H_plus_val;
>>
>> /*This is the actual quantity I want to evaluate for each quadrature
>> point*/
>> H_plus_val = 0.5*lambda(x_q)*(pow((e_xx+e_yy),2))
>> +
>> mu(x_q)*((pow(e_xx,2))+2*(pow(e_xy,2)) + (pow(e_yy,2)));
>>
>> return H_plus_val;
>> }
>>
>> H_plus function is called in assemble_damage for each quadrature point
>>
>> I am also attaching some lines of code from assemble_damage where
>> H_plus is being called
>>
>> for (const auto  : dof_handler_damage.active_cell_iterators())
>> {
>>
>> fe_values_damage.reinit(cell);
>> 

Re: [deal.II] How to access variables in the postprocessor object

[Jean-Paul Pelteret]

Hi Raul,

The “input_data” argument to the evaluate_vector_field() function has a method 
that can be called to retrieve the cell that is currently being processed:
https://dealii.org/developer/doxygen/deal.II/structDataPostprocessorInputs_1_1CommonInputs.html#a2bc88342acd8e41314c8c1328bd98a67
 


Since you are defining your own data post processor, you are in control over 
what information from your simulation it has access to. You could therefore 
pass it the necessary data (or data structures) from the calling class in order 
to map the cell (+ evaluation point?) to the constitutive law that could be 
used to evaluate the stress in terms of the strain.

I hope that this helps!

Best,
Jean-Paul

> On 12. Dec 2022, at 16:01, Raúl Aparicio Yuste  wrote:
> 
> It is not clear to me how to access an object in the structure 
> “Postprocessor”. The idea is that I compute the solution, but I am also 
> computing secondary variables using the postprocessor structure in this way:
> 
> dealii::DataOut data_out;
> 
> data_out.attach_dof_handler(dof_handler);
> 
> Postprocessor postprocessor;
> 
> data_out.add_data_vector(solution, postprocessor);
> 
> data_out.build_patches();
> 
> When declaring the postprocessor class, I declare a function 
> evaluate_vector_field where I compute all the secondary variables that are 
> written on a vtk file later:
> 
> void evaluate_vector_field(const 
> dealii::DataPostprocessorInputs::Vector& input_data, 
> std::vector>& computed_quantities) const override;
> 
> …..
> 
> for (int q = 0; q < n_q_points; ++q) {
> 
> // Displacements
> 
> computed_quantities[q](0) = input_data.solution_values[q](0);
> 
> computed_quantities[q](1) = input_data.solution_values[q](1);
> 
> // Stress
> 
> computed_quantities[q](2)  = sigma_x
> 
> computed_quantities[q](3)  = sigma_y
> 
> }
> 
> These variables are saved on the data_out object, so I use 
> “data_out.write_vtk(output);” and I get them on the vtk file. However, I do 
> not know how to access to these new variables (computed_quantities) from 
> another file different from the one where I declare the functions.
> 
> The function evaluate_vector_field is a virtual function, and it is declared 
> as const override. I do not know how to export the variables 
> computed_quantities or modify them, because it is only allowed to read them 
> since the function is declared as constant. Is there any way to access the 
> structure postprocessor? Something like:
> 
> postprocessor.getVariables()
> 
> Or an example where I can see how to implement it. Thank you very much in 
> advance
> 
> Raul
> 
> 
> -- 
> 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/d9a60280-0181-427b-a372-2eee29ab3257n%40googlegroups.com
>  
> .

-- 
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/6712C852-25C5-433C-95FF-2610E693B80E%40gmail.com.

Re: [deal.II] Principal stress components

[Jean-Paul Pelteret]

Hi Raul,

I’m a bit late to the discussion, but maybe this piece of information might 
still be useful to you. There is a function that computes and returns the 
eigenvalues and eigenvectors of symmetric tensors: 
https://dealii.org/developer/doxygen/deal.II/symmetric__tensor_8h.html#aa18a9d623fcd520f022421fd1d6c7a14
 

 (the eigenvalues of non-symmetric tensors are, in general, complex valued and 
more complicated to compute, so this has not yet been implemented)

You can do this point-wise and, as previously suggested, could be stored for 
visualisation using the DataPostprocessTensor class. 

Paraview also has a Tensor glyph (maybe only as an extension?), so maybe that 
could also be worth investigating.
https://kitware.github.io/paraview-docs/latest/python/paraview.simple.TensorGlyph.html
 


Best,
Jean-Paul

> On 12. Dec 2022, at 12:27, Raúl Aparicio Yuste  wrote:
> 
> Hello,
> 
> Please find attached a script in which I calculate the principal stress 
> components by using the eigen library. This example is in 2D for a particular 
> case, but this piece of code can be modified to generalise the calculation of 
> the principal stress components in 3D. Hope it will be useful. 
> 
> Best
> 
> Raúl
> 
> El lunes, 21 de noviembre de 2022 a las 8:41:38 UTC+1, Raúl Aparicio Yuste 
> escribió:
> Dear Wolfgang and Richard,
> 
> Thank you for your answers. It is good to know how the library works. In my 
> case I am solving an isotropic linear elasticity problem, so I am going to 
> implement it by one of the ways I suggested in my previous comment. Your 
> comments have been really helpful in organising my ideas about Dealii. I will 
> try to come up with the solution and share it to colaborate with this 
> interesting resource. Thank you!
> 
> Best
> 
> Raúl
> 
> On Saturday, November 19, 2022 at 5:43:14 PM UTC+1 richard@gmail.com 
>  wrote:
> Hi,
> I just recently did something similar and as has been pointed out, there are 
> as always multiple ways of achieving this.
> Since I wanted to not only output the first principal stress, but actually 
> use it further for my calculations, I wanted to have a DoF vector resembling 
> the field in my mesh. Thus, there are again (at least) 2 options: 
> i) introduce a discontinuous field with corresponding DoFs (would require 
> more effort since I am only using continuous FEs)
> ii) use a continuous, averaged field, accepting the introduced error 
> (constant per element and averaged over neighbors)
> If you want to do ii) as well, it boils down to a classical assembly loop,  
> and one computes the Cauchy stress tensor (or whatever stress tensor you want 
> to get the principal stresses from) as you did in your momentum balance 
> equation.
> This might look something like the following in integration point q:
> {
> Tensor<2,dim> F_s = identity_tensor + 
> gradients_displacement[q];  // displacement gradient
> Tensor<2,dim> PK2_stress = 
> get_PK2_stress(F_s); // second Piola-Kirchhoff stress tensor, you define 
> this function based on your constitutive equation
> Tensor<2,dim> cauchy_stress = 
> symmetrize((1.0/determinant(F_s)) * F_s * PK2_s * transpose(F_s)); // Cauchy 
> stress tensor via Piola transform for finite strain theory
>   const std::array eigenvalues_cauchy = 
> eigenvalues(cauchy_stress);
> double max_principal_stress = cauchy_stress[0];
> }
> Optionally, one could always get a global DoF vector via projecting the 
> stress components or the first principal stress (or the quantity you need to 
> plot). This would be much much more accurate than what I suggest in ii).
> Going through i) or ii), both ways one ends up with (dis-)continuous global 
> vectors, possibly averaged over neighbors. These are then easily exported via 
> the classical dealii::DataOut data_out; data_out.add_data_vector(...).
> If you want to just output the results, maybe try the 
> dealii::DataPostprocessor as mentioned by Wolfgang.
> 
> Best regards
> Richard
> 
> 
> rapa...@unizar.es <> schrieb am Donnerstag, 17. November 2022 um 16:21:30 
> UTC+1:
> Hello everyone,
> 
> It is the first time I am using the library Deal II. I am wondering, is there 
> any way/example to get the principal stress components as an output of the 
> simulation? Thank you very much in advance
> 
> Raul
> 
> -- 
> 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 

Re: [deal.II] Looking for clarification on a few places on Step-44

[Jean-Paul Pelteret]

Hi Matthew,

I'm glad that you find step-44 to be a useful tutorial! Let me try to 
answer your questions directly.


   /My first question deals with the statement "The Euler-Lagrange
   equations corresponding to the residual"/
   /
   /
   /Directly above this sentence is the residual, whose derivation I
   understand. Where I am lost is that s tact on to equations. I
   have//only one residual equation. I cannot bridge that disconnect. /

This is just another way of saying that the three equations listed there 
(these E-L equations) are the strong form of the governing equations. 
Basically, if you take each of these equations (along the way, modifying 
the definition of the stress in the equilibrium equation), test them 
with the appropriate test function and sum up the three residual 
contributions then you recover the (total) residual, or stationary point 
of the residual, that is listed above. The point is that it not 
necessarily so straight forward to go from the strong form to the weak 
form for this mixed formulation, so identifying the conservation 
equations a-postori is a helpful sanity check here. They seem to align 
with what we're trying to do here.


   /I am completely lost here. What is the significance of p and J not
   having derivatives on them that makes it "easy" to solve for those
   terms in isolation?
   /

Well, that's a valid point. I can't quite recall what exactly we were 
trying to identify with this comment. I'll think about it, as that seems 
to be a point that we could improve on in the documentation. That there 
is no K_{pp} contribution is significant, because it makes condensing 
out the p and J fields easier. Maybe we meant to refer to the lack of 
contribution to K_{pp} (as there is no second derivative involving a 
variation and linearisation of p.


   /I am also confused how K_pJ, K_Jp and K_JJ  form a block diagonal
   matrix. I could get there if I ignore the top row but then the
   equations below do not make sense I think. Some detail on this part
   of the process would be great. /

So this is more easy to explain. We specifically choose discontinuous 
shape function to discretise these fields. As there are no 
interface/flux contributions, all local element contributions for these 
terms will remain local and you therefore end up with an assembled 
matrix for these contributions that has a block-like structure. The 
K_{JJ} matrix is evidently block-diagonal, as it is a field that couples 
with itself. As for the coupling matrices K_{pJ} and K_{Jp}, they are 
block-diagonal because we chose *exactly* the same discretisation for 
both fields (i.e. the shape functions and polynomial order match).


Does that make sense?

Best,

Jean-Paul

On 2022/09/30 19:16, Matthew Rich wrote:

Hi,

Step-44 has a lot going on and really sets you up to tackle a variety 
of real world problems. There is a significant jump in complexity 
between this tutorial and steps 8,17 & 18.


I have been reading the references and I am about there but need few 
clarifications for why things are the way they are.


Any assistance would be much appreciated...

My first question deals with the statement "The Euler-Lagrange 
equations corresponding to the residual"


Directly above this sentence is the residual, whose derivation I 
understand. Where I am lost is that s tact on to equations. I have 
only one residual equation. I cannot bridge that disconnect.


My other question has to deal with the solving procedure for K (see 
snippet below)

Ksolve.png


I am completely lost here. What is the significance of p and J not 
having derivatives on them that makes it "easy" to solve for those 
terms in isolation? I am also confused how K_pJ, K_Jp and K_JJ  form a 
block diagonal matrix. I could get there if I ignore the top row but 
then the equations below do not make sense I think. Some detail on 
this part of the process would be great.


Thanks in advance,

Matt
--
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/a090a200-fa7a-44d9-ba59-6c5e6064fd5bn%40googlegroups.com 
.


--
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 

Re: [deal.II] Stress in cylindrical coordinate system

[Jean-Paul Pelteret]

Dear Johanna,

What you describe here makes sense. Such a transformation is described 
at this link 
 
(see section 2.7 "Converting tensors between Cartesian and 
Spherical-Polar bases". I think that the circumferential stress would 
then be S_{\theta \theta}, according to their notation). Its just that 
(in general) your rotation matrix would have to change for each 
evaluation point, as the radius and angle with respect to the axis would 
change.


We have a couple of functions already implemented that might help you to 
achieve this:


 * Rotation matrices (2d,3d):
   
https://dealii.org/current/doxygen/deal.II/namespacePhysics_1_1Transformations_1_1Rotations.html#a68bba56f6c1ebfbb52f871996df965ae
 * Basis transformation:
   
https://dealii.org/current/doxygen/deal.II/namespacePhysics_1_1Transformations.html#a626b00a6e08a79449cbf120cb3e81fdb

I hope that this helps you.

Best,

Jean-Paul

On 2022/10/01 11:07, Johanna Meier wrote:

Hi all,

I am having a conceptual issue and hope someone might be able to help 
me out on it.
My question is, if there is a way to transform stresses from cartesian 
to cylindrical coordinates so that I can examine, for example, the 
circumferential stress in a tube? A setup I had in mind is similar to 
step 18 in geometry, but instead of applying a load on top of the 
cylinder I would pressurize the inside. Or step 44 but replacing the 
geometry by a cylinder.


My initial idea was to somehow rotate the stress at a quadrature point 
during postprocessing from the global cartesian coordinate system to a 
local cartesian system of which one axis is aligned with the radial 
direction and another one with the z-direction. The remaining axis 
would be tangential to the "theta" axis (circumferential direction). 
Does something like that make sense at all?


How are situations like this handled in practice? Any hints would be 
welcome!


Best,
Johanna
--
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/57d95553-e531-4030-b9b8-266fc394da96n%40googlegroups.com 
.


--
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/925a8425-1bd9-8595-603f-4232f5d63e6c%40gmail.com.

Re: [deal.II] automatic differentiation:

[Jean-Paul Pelteret]

Hi Simon,

Sorry that I didn't get back to you on this before now. I think that I get 
the gist of what you're trying to do, but I must admit that I'm a bit 
skeptical as to whether or not its going to work (the AD framework was not 
really conceptualised to be used in this manner, so it will be interesting 
to hear whether you end up finding success in this endeavor). Basically, 
what you need to do is somehow link the degrees of freedom in the found 
cell with those that you created C_ad with.  I guess suggests that you need 
to express how these values might change as your invariant point changes. 
If you *somehow* manage to form an association between these two sets of 
DoFs then you can use one of the various FEValuesViews 
get_function_gradients_from_local_dof_values() 
<https://dealii.org/current/doxygen/deal.II/classFEValuesViews_1_1Scalar.html#abdc8d5d7b846cc7e0d1e15e8b0cf66b5>
 
functions to compute gradients that have the required sensitivities encoded 
in them. This is actually what we already do in ScratchData 
<https://github.com/dealii/dealii/blob/master/include/deal.II/meshworker/scratch_data.h#L1712-L1713>
:: 
<https://github.com/dealii/dealii/blob/master/include/deal.II/meshworker/scratch_data.h#L1712-L1713>
get_gradients() 
<https://github.com/dealii/dealii/blob/master/include/deal.II/meshworker/scratch_data.h#L1712-L1713>,
 
which makes this class AD-capable. 

I hope that this helps, if you haven't succeeded with this already.

Best,
Jean-Paul

On Tuesday, July 19, 2022 at 11:07:50 AM UTC+2 Simon wrote:

> Hi Jean-Paul,
>
> thanks for pointing that out.
>
> However, I believe there has been a misunderstanding:
> I am working here with a FE discretized energy on a seperate 
> triangulation, say, 'triangulation_energy', with the coordinates being the 
> first and third invariant of 'C'; The corresponding nodal energy values are 
> stored in the vector 'solution_energy' and are computed once based on a 
> analytical energy function. 
> So for each quadrature point in my geometry (first triangulation) I am 
> computing 'C=F^T*F', thence the first and third invariant of 'C' and store 
> them in a Point<2> object denoted as 'invariant_point'. 
> Then, I employ 
> 'GridTools::find_active_cell_around_point(triangulation_energy, 
> invariant_point)' to finally create a second FEValues object with the only 
> purpose to compute the gradient of the energy ('solution_energy') at  
> 'invariant_point'.
> 'get_function_gradients(solution_energy, grad_energy_at_ref_point ) gives 
> me the gradient of 'solution_energy' with respect to the first and third 
> invariant of 'C' because the real coordinates on the associated 
> triangulation are the first and third invariant of 'C'.
> Now, I have all the quantities to compute the stress tensor as
> S_ad = 2*(grad_energy_at_ref_point[0][0]*invariant1_wrt_C_ad 
> + 
> grad_energy_at_ref_point[0][1]*invariant3_wrt_C_ad);
>
> My goal is to compute the 4th order tangent \frac{\partial S_ad}{\partial 
> C_ad}.
>
> All that said, is it not correct to start like this?:
> SymmetricTensor<2,dim> C = symmetrize(F^t *F);
> ad_helper.register_independent_variable(C, C_dofs);
> const SymmetricTensor<2, dim, ADNumberType> C_ad = 
> ad_helper.get_sensitive_variables(C_dofs);
>
> Best,
> Simon
>
>
>
> Am Mo., 18. Juli 2022 um 22:46 Uhr schrieb Jean-Paul Pelteret <
> jppel...@gmail.com>:
>
>> Hi Simon,
>>
>> Unfortunately I don’t have the time at this moment to give you a full 
>> explanation as to why the logic of your code is wrong, but in essence you 
>> have the sequence of operations inverted. You need to compute your energy 
>> based on the “sensitive” DoF values that would come from the reinit’d 
>> FEValues operation. You cannot compute something like C_ad ahead of time, 
>> like it appears that you have.
>>
>> Take a look at these lines in the (unfinished) tutorial that will 
>> illustrate the steps required to linearise an energy functional. This 
>> should hopefully help steer you in the right direction.
>>
>> https://github.com/dealii/dealii/pull/10394/files#diff-fc8b83d1370bfd7eb558ea76175bfc0e8d6305023d54b17ec9cccb0fba9b1e02R1758-R1831
>>
>> Best,
>> Jean-Paul
>>
>> On 18. Jul 2022, at 19:46, Simon  wrote:
>>
>> Dear all,
>>
>> I want to retrieve a tangent at quadrature point level using AD - 
>> attached is a snippet of my code:
>>
>> The computation of the dependent variable 'S_ad' in line 36 involves the 
>> call 
>> get_function_gradients (solution_energy, grad_energy_at_ref_point), 
>> see line 35. 
>> 'solution_energy' is a

Re: [deal.II] fourth-order referential deviatoric tensor Dev_P: why is 'S' used in the definition?

[Jean-Paul Pelteret]

Hi Simon,

If you compare Holzapfel's definition with that of Wriggers, for instance, 
one notices the difference in how they define this 4th-order identity 
tensor. This particular term comes from the derivative d*C*/d*C* (i.e. 
differentiating a [symmetric] tensor w.r.t itself), and if you do not 
account for the symmetries of tensor then you end up with Holzapfel's 
result, namely that 
d*C*/d*C *-> dC_{ij}/dC_{kl} = \delta{ik}\delta{jl} = I_{ijkl}. 
In my version of the book, the text below eq. 6.84 where the reference 
deviator tensor is defined points one to eq. 1.160. There you see that this 
tensor does not hold the symmetries that a SymmetricTensor does (it doesn't 
have the property of minor symmetry) and it also doesn't map all rank-2 
tensors onto a symmetric tensor. It also probably makes a difference in how 
one defines the transpose of this deviator tensor (which would rely on 
d*C*^T/d*C *-> dC_{ji}/dC_{kl} = \delta{jk}\delta{il} = I^{T}_{ijkl}, 
maybe?). If one considers Wrigger's approach (eq 3.125 and the text below 
it; specific reference listed in the step-44 introduction) and explicitly 
accounts for the symmetry of the tensor then 
d*C*/d*C *-> d(0.5*[C_{ij} + C_{ji}]) /dC_{kl} = 0.5*[\delta{ik}\delta{jl} 
+ \delta{jk}\delta{il}] = S_{ijkl}. 
Such a tensor definitely maps all rank-2 tensors to symmetric tensors and 
helps fulfill the relation that for SymmetricTensors *A*=*A*^{T}.

The differences in the definitions are subtle and your question reminds me 
of how many time I've pondered pretty much the same thing. I've also 
previously observed the similar differences in results of contractions that 
you mentioned in your second email, and have been equally surprised. In the 
end, the consequences on the outcome of each operation involving your 
definition of the deviator tensor *could* simply depend on which tensor 
class you are storing the operators and results in. Certainly the rank-4 
tensor *I* is not a SymmetricTensor and therefore *P* = *P*(*I*) would not 
be one either. But since the rank-4 tensor *S* is by construction and 
definition 

 
a SymmetricTensor, *P* = *P*(*S*) would also be one.

Best,
Jean-Paul

On Wednesday, August 10, 2022 at 12:54:07 AM UTC+2 Wolfgang Bangerth wrote:

> On 8/8/22 15:11, Simon Wiesheier wrote:
> > grafik.png
> > grafik.png
> > The only place I use Dev_P is to compute the above double contractions 
> ('P' in 
> > the above is what dealii returns as Dev_P)
> > As you can see, the fourth order tangent C_bar consists of outer 
> products of 
> > second order symmetric tensors:
> > boldsymbol 'I' is the second order unit tensor, C_bar is a symmetric 
> second 
> > order tensor, and blackboard 'I' is the general fourth order unit tensor,
> > the deltas are just scalars.
> > 
> > In my opinion, the double contractions 'P : outer_product(C_bar, C_bar)' 
> and 
> > 'P : I' produce different results if the fourth order symmetric unit 
> tensor 
> > 'S' is used to define 'P' .
> > The same holds also for doing the double contractions with P_T.
> > Correct?
>
> Not being a nonlinear mechanics person, I'll have to defer to someone else 
> with more knowledge about these matters :-(
>
> 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/7bffb41f-5926-4503-a8a9-d6e2465de78en%40googlegroups.com.

Re: [deal.II] Installation problem using spack

[Jean-Paul Pelteret]

Hi Marco,

I've open a PR in Spack (https://github.com/spack/spack/pull/32079) that 
backports the patches that we added to the development version to 9.4. Feel 
free to try it and provide some feedback as to whether or not it works for 
you.

Best,
Jean-Paul

On Thursday, August 11, 2022 at 7:50:46 AM UTC+2 marco@colosso.nl wrote:

> Hi Daniel and Timo,
>
> Thanks for the feedback. The bug indeed seems to be the problem, since the 
> spack HDF5 package is definitely build with MPI support. I first thought it 
> was because by default spack doesn't seem to build HDF5 with C++ support, 
> but that did not help (of course now I know why).
>
> Building without HDF5 would be an option for me for the short term, but I 
> will first try to see if I can get it working.
>
> Again, I am pretty impressed by the spack. It works like a charm and it 
> provides a lot of flexibility.
>
> Kind regards,
>
> Marco
>
> On Tuesday, August 9, 2022 at 7:27:38 PM UTC+2 Timo Heister wrote:
>
>> Your issue might be related to the bug 
>> https://github.com/dealii/dealii/issues/14065 (see the discussion and 
>> the linked PR that should solve the problem for deal.II master, but not 9.4)
>>
>> On Tuesday, August 9, 2022 at 1:23:55 PM UTC-4 d.arnd...@gmail.com wrote:
>>
>>> Marco,
>>>
>>> It appears that
>>>
>>> -- Insufficient hdf5 installation found: hdf5 has to be configured with 
>>> MPI support.
>>>
>>> is the problem. HDF5 has not been compiled with MPI support. Thus, you 
>>> can either try to make sure that HDF5 is built with MPI support or, in case 
>>> you are not going to use HDF5 anyway, just disable the dependency.
>>>
>>> Best,
>>> Daniel
>>>
>>> On Tue, Aug 9, 2022 at 7:41 AM Marco Nawijn  
>>> wrote:
>>>
 Dear All,

 I run into an issue when trying to install dealii using spack. The 
 error is as follows:

   Could not find the hdf5 library!

   Insufficient hdf5 installation found!

   hdf5 has to be configured with MPI support.

   Please ensure that a suitable hdf5 library is installed on your 
 computer.

   If the library is not at a default location, either provide some 
 hints for
   autodetection,

 A complete log and additional information is provided in the two 
 attachments.
 I am a little lost at the moment because as far as I can tell, the 
 installation process finds the correct HDF5 folder (I checked the tags). 
 In 
 addition, I installed HDF5 using spack with MPI, C++ and Fortran support 
 (I 
 added the output of `tree` to the attachment). 

 I am a little at loss now, because I don't know what dealii is exactly 
 missing from the HDF5 installation.

 The system is just a laptop, so nothing cluster like.

 Just as a side note. I am pretty impressed with the easy and 
 flexibility of spack. All other dependencies installed without a hitch 
 (petsc, sundials, trilinios etc.).

 Does anybody have an idea of what the problem is?

 Any help is highly appreciated. 

 Marco
 P.S. I am a complete novice with dealii, but otherwise comfortable in 
 the linux eco-system.

 -- 
 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.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/dealii/7383fcc8-af66-438f-b363-3aa1c9032d5en%40googlegroups.com
  
 
 .

>>>

-- 
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/5a93c39f-d2e5-4f3d-a58c-21196dc0efcdn%40googlegroups.com.

Re: [deal.II] automatic differentiation:

[Jean-Paul Pelteret]

Hi Simon,

Unfortunately I don’t have the time at this moment to give you a full 
explanation as to why the logic of your code is wrong, but in essence you have 
the sequence of operations inverted. You need to compute your energy based on 
the “sensitive” DoF values that would come from the reinit’d FEValues 
operation. You cannot compute something like C_ad ahead of time, like it 
appears that you have.

Take a look at these lines in the (unfinished) tutorial that will illustrate 
the steps required to linearise an energy functional. This should hopefully 
help steer you in the right direction.
https://github.com/dealii/dealii/pull/10394/files#diff-fc8b83d1370bfd7eb558ea76175bfc0e8d6305023d54b17ec9cccb0fba9b1e02R1758-R1831
 


Best,
Jean-Paul

> On 18. Jul 2022, at 19:46, Simon  wrote:
> 
> Dear all,
> 
> I want to retrieve a tangent at quadrature point level using AD - attached is 
> a snippet of my code:
> 
> The computation of the dependent variable 'S_ad' in line 36 involves the call 
> get_function_gradients (solution_energy, grad_energy_at_ref_point), 
> see line 35. 
> 'solution_energy' is a scalar function which depends on the independent 
> variable 'C_ad' as can be seen in the derivations from line 8 on.
> My issue is that I see no way to pass the NumberTypes type 
> (=Differentiation::AD::NumberTypes::sacado_dfad_dfad) to the corrosponding 
> FEValues object, and, as a consequence, the AD framework is not aware that 
> 'solution_energy' is a function of 'C_ad'. 
> In particular, 'grad_energy_at_ref_point' will be treated as a constant with 
> respect to 'C_ad' in line 36f. 
> 
> How can I incorporate this dependency in the AD framework?
> 
> Thank you,
> Simon
> 
> -- 
> 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/990f7f7f-37a2-4f9d-b6c2-bbf7dda21e8dn%40googlegroups.com
>  
> .
> 

-- 
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/D175C472-E708-4129-A15E-3FA67666AE9A%40gmail.com.

Re: [deal.II] RHS function represented by an interpolation

[Jean-Paul Pelteret]

Hi Alexander,

The answer that Wolfgang gave is the one that you want to follow. But I can 
give some input into your one question.

> The problem here is the step 3: somehow I need to specify the same geometric 
> cell for two FEValues with different finite element systems while preserving 
> the ability to use get_function_values. Surprisingly, there doesn't seem to 
> be any obvious way to convert CellAccessor given by 
> Triangulation::active_cell_iterators() to TriaIterator 
> needed for a "full reinit”.


There is, actually. Its a common question to which you can find the answer here:
https://github.com/dealii/dealii/wiki/Frequently-Asked-Questions#can-i-convert-triangulation-cell-iterators-to-dofhandler-cell-iterators
 


Having seen enough people ask this, I decided to open a PR to wrap this in a 
convenience function. (see https://github.com/dealii/dealii/pull/14143 
 ). This might simplify things in 
the future.

Best,
Jean-Paul


> On 15. Jul 2022, at 21:36, Wolfgang Bangerth  wrote:
> 
> On 7/15/22 08:36, Alexander Kiselyov wrote:
>> Which tools could be used to overcome this problem? Or is my approach 
>> deficient in general?
> 
> Alexander:
> You want to evaluate the solution obtained on one DoFHandler at quadrature 
> points so that you can form the right hand side for a system that lives on a 
> different DoFHandler (but if I understand correctly, the same mesh).
> 
> In that case, just use two different FEValues objects. You will just iterate 
> through the cells of the two DoFHandler objects in synch (the order of cells 
> in a DoFHandler is the same as in a triangulation, so they will always point 
> to the same cells), re-init the two FEValues objects on these two cells, and 
> then use one via get_function_values() to obtain the values of the previous 
> solution, and the other to obtain the values of shape functions of the other 
> DoFHandler. Your right hand side is then simply the product of the two, 
> summed over the quadrature points.
> 
> Using this scheme, you never need the (expensive) function 
> VectorTools::interpolate_to_different_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/917cdbad-e6f6-dc39-84ba-af7829952022%40colostate.edu.

-- 
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/ECF6D7FD-C3D4-4264-A4D9-8F5DF53FC492%40gmail.com.

Re: [deal.II] 3D Periodic BCs

[Jean-Paul Pelteret]

Hi Jack,

The message that you’re seeing after fixing your first problem using Daniel’s 
advice is being emitted from your own code. Specifically, the set_neumann_bc() 
function in the class RMHD::Entities::VectorBoundaryConditions. You’ll have to 
inspect your code more carefully to understand what’s going wrong here.

Best,
Jean-Paul

> On 8. Jul 2022, at 22:41, jack urombo  wrote:
> 
> After following Dan's advice the following exception is now thrown
> 
>  
> Exception on processing:  
>  
> An error occurred in line <595> of file 
>  in funct
> ion 
>void 
> RMHD::Entities::VectorBoundaryConditions::set_neumann_bc(dealii::types::boundary_id,
>  c
> onst std::shared_ptr >&, bool) [with int dim = 
> 3; dealii::types::boun
> dary_id = unsigned int] 
> The violated condition was:  
>!this->closed() 
> Additional information:  
>The boundary conditions have already been closed 
>  
> Aborting! 
> 
> 
> 
> 
> On Friday, 8 July 2022 at 00:17:17 UTC+2 d.arnd...@gmail.com wrote:
> Jack,
> 
> step-45 https://www.dealii.org/current/doxygen/deal.II/step_45.html 
>  provides an 
> example for dealing with periodic boundary conditions. Even though it's a 2D 
> example, the interface is the same in 3D. 
> 
> Assuming that the arguments for your set_periodic_boundary_condition function 
> are similar to the ones for GridTools::collect_periodic_faces and you use a 
> unit cube with standard coloring, you probably want to call it with arguments 
> 0,1,0 and 2,3,1 respectively.
> 
> Best,
> Daniel
> 
> On Thu, Jul 7, 2022 at 1:56 PM jack urombo  > wrote:
> I am trying to set periodic boundary conditions for a 3D problem like 
> 
> velocity->set_periodic_boundary_condition(0, 1, 2);
>   velocity->set_periodic_boundary_condition(2, 3, 1);
>   pressure->set_periodic_boundary_condition(0, 1, 2);
>   pressure->set_periodic_boundary_condition(2, 3, 1);
> 
> The boundary conditions are not matching and that i triggering errors.
> 
> How do you set the period BCs in 3D.
> 
> The information in this message is confidential and legally privileged. It is 
> intended solely for the addressee(s). Access to this message by anyone else 
> is unauthorized. If received in error, please accept our apologies and notify 
> the sender immediately. You must also delete the original message from your 
> machine. If you are not the intended recipient, any use, disclosure, copying, 
> distribution or action taken in reliance of it, is prohibited and may be 
> unlawful. The information, attachments, opinions or advice contained in this 
> email are not the views or opinions of Harare Institute of Technology, its 
> subsidiaries or affiliates. Although this email and any attachments are 
> believed to be free of any virus or other defects which might affect any 
> computer or IT system into which they are received, no responsibility is 
> accepted by Harare Institute of Technology and/or its subsidiaries for any 
> loss or damage arising in any way from the receipt or use thereof.
> 
> 
> -- 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dealii/5eaf4f26-00dd-4e6d-841d-4a22e2328fb1n%40googlegroups.com
>  
> .
> 
> The information in this message is confidential and legally privileged. It is 
> intended solely for the addressee(s). Access to this message by anyone else 
> is unauthorized. If received in error, please accept our apologies and notify 
> the sender immediately. You must also delete the original message from your 
> machine. If you are not the intended recipient, any use, disclosure, copying, 
> distribution or action taken in reliance of it, is prohibited and may be 
> unlawful. The information, attachments, opinions or advice contained in this 
> email are not the views or opinions of Harare Institute of Technology, its 
> subsidiaries or affiliates. Although this email and any attachments are 
> believed to be free of any virus or other defects which might affect any 
> computer or IT system into which they are received, no responsibility is 
> accepted by Harare Institute of Technology and/or its subsidiaries for any 
> loss or 

Re: [deal.II] error: installation of dealii using spack

[Jean-Paul Pelteret]

Hi Simon,

Daniel is right — only Sundials versions 5 through 5.8 are compatible with 
deal.II 9.3.2, while Sundials 6 is compatible with 9.3.4 onwards. This is in 
fact what is stated in the Spack package, so I don’t quite know how it is that 
you’re able to get this mixed configuration:
https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/dealii/package.py#L212-L213
 

The spack package has now been updated for deal.II 9.4, so you should be able 
to update the repo and install the latest version of deal.II without having to 
worry about the Sundials version.

Best,
Jean-Paul


> On 6. Jul 2022, at 16:01, Daniel Arndt  wrote:
> 
> Simon,
> 
> It looks like all the errors are related to the Sundials dependency (release 
> 6.0.0). Looking at https://github.com/dealii/dealii/pull/13918 
> , it seems that you need the 
> latest deal.II release (9.4.0) to support that Sundials version.
> If you don't anticipate needing it I would just turn the dependency off if I 
> were you.
> 
> Best,
> Daniel
> 
> On Wed, Jul 6, 2022 at 9:38 AM Simon  > wrote:
> Dear all:
> 
> I already have an older version of dealii installed and wanted to install now 
> a newer version of dealii including all the dependencies using the command
> 'spack install dealii'.
> 
> Many dependencies are installed successfully (see "spack_error.png"), 
> however, the installation of dealii itself failes at some point. 
> The error message states that I should have a look in the file 
> "spack-build-out.txt", which I attached as well.
> In there, there are indeed a bunch of error messages, which refer to a 
> similar message that too few arguments are passed to certain functions.
> 
> How can I fix this?
> 
> Thanks you,
> Simon
> 
> -- 
> 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/f995ce5f-4ed3-401c-8e8c-2c623ce45f81n%40googlegroups.com
>  
> .
> 
> -- 
> 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/CAOYDWbJMOi-aLruTVdX5Ki_-zG996kAeEb_fNGvLd5gTS%2B0S4g%40mail.gmail.com
>  
> .

-- 
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/D010A64B-EA20-43DF-B491-76230BDD1A5C%40gmail.com.

Re: [deal.II] Can Class DataPostprocessor access cell of triangulation?

[Jean-Paul Pelteret]

Dear Chen,

Would it be correct to say that you’ve implemented a class that derives from 
DataPostprocessor[Scalar,Vector,Tensor] and that you’re wanting to access the 
cell from your overriding implementation of evaluate_[scalar,vector]_field()? 
If so, then take a look at the DataPostprocessorInputs classes that are passed 
in as the first argument to this function. They implement a get_cell() 

 function that can be called from the point that you’re wanting to compute the 
stress.

I hope that this helps.

Best,
Jean-Paul


> On 28. Apr 2022, at 16:41, hkch...@gmail.com  wrote:
> 
> Hi, everyone
> 
> I want to use DataPostprocessor to compute the stress of solid, but my solid 
> is composed of more than one material, so I can distinguish each part by the 
> cell->material_id(), but how can I use Class DataPostprocessor to output 
> stress of different material? It seems that the active_cell_iterator can't be 
> accessed by the Class DataPostprocessor
> 
> Best
> Chen 
> 
> -- 
> 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/3ad02db2-2dfa-4ec3-a084-32e43e558399n%40googlegroups.com
>  
> .

-- 
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/190764E0-84A7-4A67-8140-67D87E62FC39%40gmail.com.

Re: [deal.II] Supported matrix/vector to LinearOperator

[Jean-Paul Pelteret]

Dear Chen,

Bruno pointed you to the exact example that I was going to. It is certainly 
possible to use linear operators as preconditioners for solvers.

It looks like support for TrilinosWrappers::SolverDirect has not yet been 
implemented:
https://github.com/dealii/dealii/blob/master/tests/lac/linear_operator_10.cc#L371-L414
 

I cannot recall what the reason was — maybe the class is simply missing some 
functions that are defined for the iterative solvers?

As for one of your early questions which Bruno did already answer: I must admit 
that I do not know if the PETSc linear algebra is compatible with linear 
operators. We had to write a special TrilinosPayload 

 for the Trilinos linear algebra classes in order for them to work correctly 
(with the Trilinos solvers, at least), and such a wrapper doesn’t exist for 
PETSc. But maybe it works just fine if you stick to the deal.II solvers? If you 
try this out, it would be interesting to know if it works or not.

Best,
J-P

> On 19. Apr 2022, at 17:27, Bruno Turcksin  wrote:
> 
> Chen,
> 
> I am not sure if TrilinosWrappers::SolverDirect is supported but for your 
> second point, you can use the linear_operator as a preconditioner. That's 
> exactly what's done here 
> 
>  for example. The preconditioner is wrapped in a LinearOperator and this 
> LinearOperator is then used as preconditioner.
> 
> Best,
> 
> Bruno
> 
> On Tuesday, April 19, 2022 at 10:39:17 AM UTC-4 hkch...@gmail.com 
>  wrote:
> Hi everyone,
> 
> More questions:
> 1. where can I find the supported linear solver of Trilinos of 
> linear_operator? TrilinosWrappers::SolverDirect seems not to be supported by 
> the linear_operator
> 2. Does linear_operator can be a preconditioner? for example, SparseMatrix A, 
> B, C, D, E, F; Matrix G=A-B*C^{-1}*D-E^{-1}*F; So Matrix G can only represent 
> by a linear_operator, not its entity. I want to get its inverse by 
> inverse_operator using some linear solvers as: PreconditionILU prec_G(op_G); 
> const auto op_G_inv = inverse_operator(G, Solver, prec_G); But it seems that 
> the precondition of linear_operator is not supported. Is there any solution?
> 
> best 
> Chen
> 
> 在2022年4月18日星期一 UTC+8 22:07:36 > 写道：
> Bruno Turcksin
> Thank you! it really helpful!
> 
> best
> chen
> 在2022年4月18日星期一 UTC+8 21:07:45> 写道：
> Chen,
> 
> Yes, LinearOperator does support Trilinos and PETSc matrices. LinearOperator 
> even supports your own matrix type as long as you define vmult and Tvmult 
> (see here 
> )
> 
> Best,
> 
> Bruno
> 
> On Monday, April 18, 2022 at 4:19:42 AM UTC-4 hkch...@gmail.com <> wrote:
> Hi everyone,
> 
> When solving a block matrix system, the LinearOperator is a useful tool. My 
> question is whether the LinearOpertor supports Matrix type (the same as the 
> Vector type) like PETSCWrapper::MPI::SparseMatrix or 
> TrilinosWrapper::MPI::SparseMatrix?
> 
> Best
> Chen
> 
> -- 
> 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/6ee40751-54ae-402d-903e-ae745545387bn%40googlegroups.com
>  
> .

-- 
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/3CCBC467-91F0-47CB-8F49-465FE5DB49E5%40gmail.com.

Re: [deal.II] Error using Operator/ in Vector and FullMatrix

[Jean-Paul Pelteret]

Hi Raghunandan,

I think that you misinterpreted the documentation: operator/= 

 is implemented for the Vector class and operator*= 

 is implemented for the FullMatrix class. So your code probably needs to be

r /= theta;
OM *= cos(theta);

I hope that this helps you resolve your issue.

Best,
Jean-Paul

> On 9. Apr 2022, at 03:20, Raghunandan Pratoori  wrote:
> 
> Hello team,
> 
> I am trying to use the following equations -
> r = r/theta;
> OM = OM_1*cos(theta);
> 
> where r is a dealii::Vector, theta is double, OM and OM_1 are 
> dealii::FullMatrix. 
> 
> According to the documentation, operator/ and operator* are implemented for 
> both Vector and FullMatrix, but both throw an error "no match for 'operator'".
> 
> I am using v9.3.0 and have included /lac/vector.h and /lac/fullmatrix.h. I 
> believe I am missing something trivial. Can anyone identify what mistake I 
> might be making?
> 
> Thanks in advance,
> Raghunandan.
> 
> -- 
> 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/1abee09e-2230-4087-882b-3b9871c9dfd8n%40googlegroups.com
>  
> .

-- 
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/66C30C07-9445-4E6F-9CA7-49816000EC6C%40gmail.com.

Re: [deal.II] Problem about cell iterator

[Jean-Paul Pelteret]

Dear Toddy,

This is a link to the documentation, where this function (a class constructor) 
is explained in more detail
https://dealii.org/current/doxygen/deal.II/classDoFAccessor.html#a8d14894a737bb1edf3719e4de058a284
 

I can’t see that you’re misusing it in any way. The order of the arguments that 
you’ve provided to it look correct to me.

Regarding the two approaches that you outlined a couple of posts earlier, I 
think that the intention is to use it in the way that you first proposed. 
Iterating over the triangulation, selecting a particular cell to perform and 
action on, and then converting that Tria cell iterator to the two DoFHandler 
cell iterators seems meaningful. The second approach is probably less 
meaningful - if you want the iterators outside of the loop, then you may as 
well have started with the first active iterator retrieved straight from the 
individual DoFHandlers in the first place. 

Best,
Jean-Paul


> On 23. Nov 2021, at 07:57, Toddy Liu  wrote:
> 
> Professor Wolfgang,
> 
> Thanks for your advice and I will try my best to do what you told me. I asked 
> the problem about the transform between dofhandler iterator and triangulation 
> iterator because I have never used this function. Except this function, I 'm 
> familiar with the other functions used in other parts of my code. So I'm not 
> sure whether the transform is right or not. Of course, if I got the right way 
> to do the transformation, I can make sure that the bad results do not result 
> from this part and I can focus on other parts of my code.
> 
> Thank you again. And I learned a lot from your excellent lecture videos, 
> including debugging my code using eclipse, that help me find and solve many 
> problems.
> 
> Best,
> Toddy
> 
> 在2021年11月23日星期二 UTC+8 上午11:53:44 写道：
> On 11/22/21 6:55 PM, Toddy Liu wrote: 
> > 
> > I used the method that you taught me. but unfortunately the results seems 
> > bad. 
> > And I'm not sure where the problem is including the transform between 
> > dofhandler iterator and triangulation iterator. So please take a look at my 
> > codes(two pieces of codes shown in the following figures) and tell me which 
> > one will be the right one. 
> 
> Toddy -- for both this post and the other one you sent earlier, you need to 
> learn techniques to debug your codes. This typically starts with asking the 
> right questions. So when you say above "the results seems bad", you should 
> ask 
> what specifically is wrong? Does the solution look right in the interior but 
> is wrong at the boundary? Or the other way around? Does it work on a single 
> processor, and is only wrong when run in parallel? What happens for cases 
> where you set the right hand side function to zero? 
> 
> All of these questions help you *observe* what specifically is wrong, and 
> helps you formulate *hypotheses* where the bug may lie. When you have a 
> hypothesis, you can star to test it, play with variations that allow you to 
> identify whether your guess that the problem is, for example, at the 
> boundary, 
> and narrow the places where the bug might be. 
> 
> In the codes you show, I believe that they should be identical. Both codes 
> should work the same. If you get different results, then that would be 
> strange, but you could in that case test *why* the results are different -- 
> for example by outputting the cell matrices and vectors. 
> 
> 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/6130a9a6-1918-49d2-95fd-3d8bfc72ffa3n%40googlegroups.com
>  
> .

-- 
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 

Re: [deal.II] Problem about cell iterator

[Jean-Paul Pelteret]

Hi Toddy,

It’s possible to convert a triangulation iterator to a DoF iterator using the 
technique described here:
https://github.com/dealii/dealii/wiki/Frequently-Asked-Questions#can-i-convert-triangulation-cell-iterators-to-dofhandler-cell-iterators
 

So one way would be just to loop over the triangulation and convert that to a 
velocity DoFHandler iterator and a pressure DoFHandler iterator. But it looks 
to me that you can convert between iterators in the same manner, so if you want 
you could also just use a standard loop over (DoF) cell iterators, and convert 
that primary iterator to the other kind.

I hope that this helps!

Best,
Jean-Paul


> On 12. Nov 2021, at 04:22, Toddy Liu  wrote:
> 
> Dear Deal.II community,
> 
> I'm programming on modifying step 35 using Parallel computing with multiple 
> processors using distributed memory. In step35, the tutorial program used 
> "synchronous" iterator which consists of two iterators, one for velocity and 
> the other for pressure.
> 
> Now I'm struggling with the cell iterator when I assemble system. In step 40, 
>  it's enough to access cells using access like
> " const auto  :   dof_handler.active_cell_iterators()". But how can I do 
> this when the assemble_system needs two iterators (in my case one for 
> velocity and the other for pressure)?
> 
> Any advice or suggestions will be appreciated!
> Thank you.
> 
> Best,
> Toddy
> 
> -- 
> 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/cb916c9f-c84c-4f94-86b9-360e0e19c7b4n%40googlegroups.com
>  
> .

-- 
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/7AB97D98-013B-4832-827A-DC761AD095BA%40gmail.com.

Re: [deal.II] Efficient Matrix-based Calculation

[Jean-Paul Pelteret]

Dear Masoud,

> As you mentioned, we expect this to be slower than the equivalent code in 
> step-8; however, it is very slower than the same code that I wrote before in 
> Matlab.

A quick question: are you sure that you’re running your problem in release 
mode, rather than debug mode? I had a colleague who adopted this BDB approach 
that you’ve described, and he never mentioned performance issues to the degree 
that you’re seeing here.

Best,
Jean-Paul

> On 20. Oct 2021, at 14:08, Masoud Ahmadi  wrote:
> 
> Dear Prof. Bangerth,
> 
> Thanks for your answer. 
> Indeed, I took the declaration of matrices out of the loop; but still, as I 
> mentioned, the part that is substantially reducing the speed is the product 
> between the matrices. 
> As you mentioned, we expect this to be slower than the equivalent code in 
> step-8; however, it is very slower than the same code that I wrote before in 
> Matlab. 
> My question is, I want to be sure that "FullMatrix" is the most efficient and 
> fast way in dealii to evaluate such like matrix calculations (the products). 
> Or should I be looking for alternatives?
> 
> Best regards
> 
> On Tuesday, 19 October 2021 at 19:24:11 UTC+1 Wolfgang Bangerth wrote:
> 
> Masoud, 
> 
> > Here is a part of the tutorial code for example 8 to calculate stiffness 
> > matrix of an element: 
> > Screenshot 2021-10-15 at 12.48.39.png 
> > 
> > And here is my equivalent code for the same purpose with a matrix-based 
> > viewpoint: 
> > Screenshot 2021-10-15 at 23.12.13.png 
> > 
> > it is based on the following formulation for a 3D elastic problem: 
> > thumbnail_image.png 
> > By "slow", I mean in comparison with the same code in tutorial (example 8). 
> > I 
> > measured the lines of the code, and I am sure the difference is for the 
> > mentioned part of the code. To be more accurate: the operations on 
> > matrices, 
> > as follow in the second image: 
> > B[I].Tmmult(tmpM,D); 
> > tmpM.mmult(BDB,B[J]); 
> 
> You could probably make the code substantially faster already if you moved 
> the 
> declaration of the B, tmpM, and BDB matrices out of the loop over the 
> quadrature points, and simply set them to zero inside the loop. Creating 
> these 
> variables requires allocating memory every time you do one iteration over the 
> quadrature points, which is expensive. 
> 
> But in the end, compare what work you are doing in your loop with what the 
> equivalent code in step-8 is doing, and you shouldn't be surprised by your 
> observation. step-8 only does 2 (and if i==j, then 3) tensor contractions for 
> each index i,j,q. You are allocating and releasing memory, and doing two 
> products between 6x3 and 3x3 matrices, plus a lot of index work. It does not 
> surprise me that this is slow. 
> 
> 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/00c2608c-7489-4538-8bd7-09c989d844c4n%40googlegroups.com
>  
> .

-- 
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/E3BA93D2-831E-453F-9CD6-1818587CC00D%40gmail.com.

Re: [deal.II] Mathematical clarification for step-44

[Jean-Paul Pelteret]

Hi Arnold,

When I compare the documentation to step-44 that you quote to the code itself, 
it would seem like there’s a typo there. The second term “-2 p \mathcal{I}” of 
the part that underlined should actually read “-2 p \mathcal{S}” since this 
really is the symmetric fourth order identity tensor that holds the symmetry 
properties that you also quoted.

To get from the Holzapfel equation that you quoted to the one used in the 
tutorial, you still need to “push forward” these quantities. The tensor 6.166 
is the volumetric tangent described in the reference configuration, while the 
tutorial / Miehe describe a tangent in the spatial configuration. The 
appropriate transformation is the Piola transformation 
.
 

As for your derivation, I’m not quite sure that I follow what you’re trying to 
do here. The identity that is applied at the equation below Miehe (57) — let’s 
take it at face value that its true — is used to simplify the calculation in 
(58) where the formal definition of the tangent involves the contraction from 
both sides of the derivative of the energy function by b, the left Cauchy-Green 
tensor. Since the identity involves produces to b^{-1} on either side of the 
symmetric fourth order unit tensor, they cancel out in (58). To verify your 
result, you’ll need to compute the LHS of the equation, i.e. \partial_{b} 
b^{-1}. But, in fact, this entire identity comes from the statement

0 = d/db (I)where I is the 2nd order identity tensor
   = d/db (b^{-1} . b)   where the “.” denotes a single contraction
   = [db^{-1}/db] . b + b^{-1} . [db/db]
  =  [db^{-1}/db] . b + b^{-1} . S where S is the forth order unit identity 
tensor (this is a standard derivation, specialised for the case of b being 
symmetric)
—> contracting by b^{-1} on the right and rearranging —>
 db^{-1}/db = -  b^{-1} . S . b^{-1}

I must say that, for me at least, trying to get straight to the result as Miehe 
does is not easy to understand unless you know some rather unusual (maybe?) 
identities. I prefer the to start in the reference configuration, as Holzapfel 
does, and then push forward all results to the spatial configuration. That way, 
the individual step are, in my opinion, quite clear albeit lengthy. There are 
some notes in Appendix A.3 of my dissertation 
 that sketch it out. 

I hope that helps you a little.

Best,
Jean-Paul

> On 6. Oct 2021, at 23:37, 'Arnold' via deal.II User Group 
>  wrote:
> 
> Hello,
> I don't get the formula for Jc_vol in step-44 (marked purple), particulary 
> the fourth order unit tensor in there. I looked up the source that is quoted 
> in step-44 (Miehe 1994), and the formula for db^-1/db uses a unit tensor as 
> well (see picture for details).
> 
> I'm not sure however if the formula Miehe uses is the correct one for 
> _symmetric_ tensors. It should theoretically be equal to the formula below 
> from "Nonlinear Solid Mechanics", but when I try to evaluate the Miehe 
> formula in index notation I get a weird result that is much different from 
> the Holzapfel formula.
> 
> Can someone confirm with certainty that these two formulas (marked red) are 
> actually the same thing? Or even better, locate the error in my derivation 
> attempt?
> 
> Best Regards,
> 
> Arnold
> 
> 
> -- 
> 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/31b711b6-1214-46e0-80e3-1a0cb78a5c9dn%40googlegroups.com
>  
> .
> 

-- 
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/3A8C4245-8F6A-4D92-90CB-54C6E6E2E448%40gmail.com.

Re: [deal.II] Implementing a fiber reinforcement in a biphasic model

[Jean-Paul Pelteret]

Hi Matt,

As a supplement what David already mentioned, I used the QP-based approach that 
you laid out for skeletal muscle modelling. Although the code-related 
implementation details are not documented in my dissertation 
,  the Linear Elastic Active Skeletal 
Muscle Model 

 code gallery example captures its essence for a much more simplified (single 
fibre family with a predefined muscle activation signal), completely linearised 
version of that model. That said, in the years since then I’ve thought that it 
might be nice to store the fibre direction field as an FE field. I think that 
the only complexity there is that if you have a different number of fibres in 
each cell (which is what I had to do) then the task of managing data at an FE 
level *may* be more challenging than storing it all locally.

Just in case It can be of use to you: I’ve also got a work-in-progress branch 
(see invariants.h 

 and constitutive_modelling.h 
)
 that shows how to compute the values and derivatives of a number of invariants 
(applicable to single and coupled physics). In there are two sets of invariants 
that may be of interest to you: what I label I4 through to pI5 (in 
invariants.h) relate to transverse isotropic materials (potentially with fibre 
dispersion), and I6-I8 add another fibre family to permit the material being 
completely orthotropic. For both of these, one just needs the right 
Cauchy-Green tensor and a structure tensor as inputs. The idea in that branch 
is that you provide coefficients that are the derivatives of an energy function 
with respect to certain invariants to one of the CM helper classes (e.g. 
Physics::ConstitutiveModelling::UncoupledConstitutiveModel)
 and then it will return to you, for instance, d2Psi_dC_dC which is the 
material tangent as computed from all of the invariants. All of the derivatives 
that have been implemented thus far have been verified (you can check the 
associated tests on the branch). Actually, all that remains is for me to 
complete the documentation.

I hope that some of this is helpful to you. Computing the derivatives of the 
invariants can be tricky for some of them, so you should definitely take care 
there.

Best,
Jean-Paul



> On 11. Oct 2021, at 19:50, Wells, David  wrote:
> 
> Hi Matt,
> 
> It is difficult to give a clear answer without some more information on how 
> you want to compute with fibers and where the material model for the fibers 
> is coming from.
> 
> If you have a way to compute the fourth-order tensor directly then an 
> approach like the one in the linked paper works. A good alternative is to 
> compute a vector field which represents the anisotropic property - a good 
> description of this for cardiac simulations is given in Pasquale's paper from 
> early this year:
> 
> https://arxiv.org/pdf/2101.10960.pdf 
> 
> that process (similar to what we do at UNC) involves computing a fiber field 
> as a finite element field, so you don't necessarily need to store quadrature 
> data - you can just compute values that you need cell-by-cell.
> 
> Best,
> David
> From: dealii@googlegroups.com  on behalf of Matthew 
> Rich 
> Sent: Thursday, September 30, 2021 9:49 PM
> To: deal.II User Group 
> Subject: [deal.II] Implementing a fiber reinforcement in a biphasic model
>  
> Hi all, 
> 
> I am trying to add some anisotropy to my model via fibers. These fibers would 
> only be active in tension and have different orientations depending on 
> spatial location in the model. My plan of attack was to simply store and 
> extra value at the quadrature points that had a direction representing the 
> fiber and update directions after each time step. (is this a good way to go 
> about doing that). I see a lot of papers doing fiber models in ABAQUS or 
> COMSOL, but I never see any details on how to do it so I am guessing it is 
> trivial. 
> 
> Then I stumbled upon https://doi.org/10.1016/j.compstruc.2020.106334 
>  which uses dealii to 
> implement a fiber model that has two grids and some sort of junction between 
> the grid representing the bulk material and one presenting the fiber. The 
> formulation seemed way more involved than what I was going to try. 
> 
> Am I making a gross simplification in my proposed approach. 
> 
> Matt
> 
> 
> 
> -- 
> 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 

Re: [deal.II] Massively parallel & inverse matrix solver

[Jean-Paul Pelteret]

Dear Hermes,

The equivalent classes to SparseDirectUMFPACK for parallel linear algebra would 
be:
- TrilinosWrappers::SolverDirect 

 : You can choose the implementation through the AdditionalData 

 struct that is passed into the class constructor.
- PETScWrappers::SparseDirectMUMPS 


Best,
Jean-Paul

> On 1. Sep 2021, at 20:10, Daniel Arndt  wrote:
> 
> Hermes,
> 
> The SparseDirectUMFPACK solver doesn't work with MPI parallel matrices. You 
> will need to find another solver based on the matrix class you are using. 
> Standard choices would be GMRES or CG but I am assuming that your linear 
> system might also be non-symmetric or indefinite.
> 
> Best,
> Daniel
> 
> 
> 
> Am Mi., 1. Sept. 2021 um 11:53 Uhr schrieb Hermes Sampedro 
> mailto:hermesampe...@gmail.com>>:
> Dear all,
> 
> I am trying to solve a similar problem as step-29 but including the massive 
> parallel solution as presented in step-40.
> I would like to ask how the solve() function would be in this case.
> 
> In step-29:
> //LU decomposition and inverse matrix
> SparseDirectUMFPACK A_direct;
> A_direct.initialize(system_matrix);
> 
> //Solve with inverse matrix
> A_direct.vmult(solution, system_rhs);
> When applying massive parallel computations, my initial guess was:
> 
> 
> LA::MPI::Vector
> completely_distributed_solution(locally_owned_dofs,mpi_communicator);
> 
> //LU decomposition and inverse matrix
> SparseDirectUMFPACK A_direct;
> A_direct.initialize(system_matrix);
> 
> //Solve with inverse matrix
> A_direct.vmult(completely_distributed_solution, system_rhs);
>  locally_relevant_solution = completely_distributed_solution;
> 
> 
>  However, I get a no matching member function for call to 'vmult' error. 
> 
> How can I use this LU decomposition and inverse matrix solver using MPI?
> 
> 
> 
> Thank you,
> 
> Regards,
> 
> H
> 
> 
> 
> -- 
> 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/ded2e156-7bd7-4474-aa5f-fb57e8540926n%40googlegroups.com
>  
> .
> 
> -- 
> 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/CAOYDWbKG87reQPBrhZu0RwoZHrMXMtVWS9Ui6EoFCWtmemG1vQ%40mail.gmail.com
>  
> .

-- 
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/6B045CAD-E179-4E5F-96B6-2CC00891CA2F%40gmail.com.

Re: [deal.II] Coarsening grid from Abaqus imported mesh

[Jean-Paul Pelteret]

Dear Truong,

To supplement Bruno’s remarks, and answer this question in particular:

>  I guess a procedure like associating the surface boundaries (from meshing 
> software) to the manifolds would also only works for meshing refinement, not 
> for mesh coarsening. 

It would work for mesh coarsening as well, but only up to the coarsest mesh 
that is read into deal.II. So if you do some initial refinement within deal.II 
itself, then both refinement and subsequent coarsening respect the attached 
manifold geometries.

The point to be understood is that deal.II does not, and cannot, have any more 
fundamental knowledge of the discretisation other than what you pass it in the 
original mesh. It does not know the steps that you took to get that mesh — the 
underlying CAD geometry, whether the mesh is cartesian or structured, has an 
even or odd number of divisions on each edge, etc. All of this information, 
which would be critical to determine how the mesh might be coarsened using the 
child-parent cell approach to adaptivity that deal.II adopts. So one always 
needs to consider a read in mesh to be “flattened”, i.e. at its coarsest state, 
and the benefits of mesh adaptivity may then be maximised when the read in grid 
is as coarse as possible and one is able to produce a satisfactorily refined 
mesh using the built in refinement tools (and possibly connecting the mesh to a 
CAD model or manifold geometries to provide information of boundary and 
interface curvature).

Best,
Jean-Paul

> On 1. Sep 2021, at 03:32, Thang W Pham  
> wrote:
> 
> Thanks for your instant and helpful answer. So, the grid from other mesh 
> generator cannot be made coarser at all. As I referred from step-5 tutorial, 
> I guess a procedure like associating the surface boundaries (from meshing 
> software) to the manifolds would also only works for meshing refinement, not 
> for mesh coarsening. 
> Vào lúc 00:09:00 UTC+9 ngày Thứ Tư, 1 tháng 9, 2021, blais...@gmail.com 
>  đã viết:
> Dear Truong,
> My understanding is that the triangulation in deal.II works like a 
> quad/oct-forest.That is, the mesh that is generated or read serves as the 
> forest and each cell is a tree. Consequently, it is not possible to coarsen a 
> mesh more than it's initial configuration.
> 
> For a lot of meshes generated by deal.II, this is not a problem since they 
> contain a very low number of cells (for example, a cubic grid has 1 cell in 
> it's coarsest level, hence it is a forest with once tree). However, if you 
> read your mesh from an external source, you cannot make it coarser than it is 
> when you have read it.
> 
> My suggestions would be to make a coarse abacus mesh, then you refine it 
> within deal.II. This way you would have a coarsest level with as few cell a 
> possible, then you could refine it adaptively. As far as I know, it is not 
> possible to coarsen a mesh below it's level 0, because this would imply 
> "merging cell".
> 
> I hope that was sufficiently clear.
> Best of luck!
> Bruno
> 
> On Tuesday, August 31, 2021 at 9:26:32 a.m. UTC-4 truongthangp...@gmail.com 
>  wrote:
> Hello everyone,
> I am new to deal.II and I am playing around with the grid of L-shape which is 
> imported from Abaqus input file using GridIn::read_abaqus(). The grid has 
> been successfully read as well as the boundary indicators ( from the surface 
> with the name of "SS1" and "SS2"). However, when I try to do coarsening the 
> grid by setting cell->set_coarsen_flag(), nothing happened. I also tested 
> with adaptive refinement as in step-6, only a figure of the new cell has been 
> generated, none has been coarsened even I set the coarsening ratio to high 
> value. 
> I wonder what is wrong here or is there something that I misunderstand with 
> the code. Thanks in advance. 
> 
> 
> 
> 
> -- 
> 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/c674a25b-0daa-4cdf-bd78-c64a90a5a86fn%40googlegroups.com
>  
> .

-- 
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 

[deal.II] Re: Boost version problem

[Jean-Paul Pelteret]

Hi Lucas,

The documentation that describes how to configure CMake options for 
external libraries is here: 
https://dealii.org/developer/users/cmake_dealii.html#configureext . You 
should just need to pass cmake the flag -DBOOST-DIR= (with 
the correct path added, of course. From your first post, I think that this 
would just be /usr). To be safe, you probably want to delete the 
CMakeCache.txt before reconfiguring. You should also take a look at this 
section: 
https://dealii.org/developer/users/cmake_dealii.html#buildinformation . 
There you can see that when an external version of boost is detected and 
can be used, this status should be reflected at the end of the 
configuration process, e.g.

# Configured Features (DEAL_II_ALLOW_BUNDLED = ON, 
DEAL_II_ALLOW_AUTODETECTION = ON): 
# DEAL_II_WITH_BOOST set up with external dependencies 
# [...] 

If you pass the boost directory to CMake and then don't see a message like 
that, then it doesn't necessarily mean that the boost path wasn't found -- 
it could also mean that this specific installation of boost was not found 
to be usable (i.e. it didn't pass the checks that are executed during the 
configuration process). To understand why that could be, you'd have to 
provide us with the detailed.log file, along with two log files that CMake 
generates, namely /CMakeFiles/CMakeError.log and 
/CMakeFiles/CMakeOutput.log.

I hope that this helps you sort out this issue.

Best,
Jean-Paul

On Thursday, August 19, 2021 at 6:36:55 PM UTC+2 lucasm...@gmail.com wrote:

> Hi folks,
>
> This problem is back, and I'm not sure what to do about it. To solve the 
> problem, I updated boost to the newest version (1.76.0), and then 
> reinstalled the newest dealii release (9.3.1). I configured it to use 
> external dependency for boost so that it configured and installed with 
> boost version 1.76.0. It was working for a while for some reason, but then 
> it broke again after updating cmake to the newest version. 
>
> I reinstalled the newest dealii version with external dependency for 
> boost, and it gives the error that it was giving before. Again, I think the 
> problem is that on line 506 of /include/deal.II/base/config.h there is a 
> #include which is pointing to the bundled boost version 
> as opposed to the externally installed one. How do I get this + all other 
> include directives to point to the proper boost installation? I think this 
> is a cmake problem, but I do not know how to tell the compiler where the 
> proper boost installation is.
>
> Any help is appreciated.
>
> Kind regards,
> Lucas
>
> On Tuesday, August 10, 2021 at 4:49:28 PM UTC-5 Lucas Myers wrote:
>
>> Update: the problem is that, when I installed the newest version of 
>> dealii, the boost version that I had separately installed was 1.67.0. 
>> Instead of using the version bundled in dealii (version 1.70.0), dealii 
>> configured with the separately installed version. However, whenever it does 
>> the compilation check, it #includes the bundled version of boost. I'm not 
>> sure why it does that, because when I run a loose source file (e.g. 
>> `boost_test.cpp` in my home directory) with boost included, it uses the 
>> separately installed version. 
>>
>> In any case, I think the fix will be to uninstall boost, and then 
>> re-install dealii so that it uses its bundled version. Just wanted to make 
>> a note about it because I think this is unintended behavior. 
>>
>> - Lucas
>>
>> On Tuesday, August 10, 2021 at 3:46:17 PM UTC-5 Lucas Myers wrote:
>>
>>> Hi folks,
>>>
>>> I'm getting the error "The version number of boost that you are 
>>> compiling with does not match the version number of boost found during 
>>> deal.II's configuration step." when I try to compile the first tutorial 
>>> program. It is thrown at /usr/local/include/deal.II/base/config.h:508:17
>>>
>>> This is confusing to me, because when I go into 
>>> /usr/include/boost/version.hpp, it states that my BOOST_VERSION is 106700. 
>>> Further, in /usr/local/include/deal.II/base/config.h, it says that my 
>>> DEAL_II_BOOST_VERSION_MAJOR is 1, DEAL_II_BOOST_VERSION_MINOR is 67, and 
>>> DEAL_II_BOOST_VERSION_SUBMINOR is 0 which makes my 
>>> DEAL_II_BOOST_VERSION_GTE 106700, the same as what boost says it ought to 
>>> be.
>>>
>>> For context, I had installed dealii version 9.2.0 earlier, but had 
>>> problems when I tried to update it to include CUDA (I think there was some 
>>> API change with CUDA 11). I then installed dealii version 9.3.1 (without 
>>> doing anything to the other version). Now none of the example files in 
>>> version 9.3.1 will compile.
>>>
>>> Any help is appreciated, thanks so much
>>>
>>> Kind regards,
>>> Lucas
>>>
>>

-- 
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 

Re: [deal.II] How to implement an orthotropic material on differnet parts

[Jean-Paul Pelteret]

Hi Ibrahim,

My guess is that the mesh has been exported without the connectivity between 
the parts being enforced. So even though the physical vertices of the mesh 
overlap where you have different parts, there are two or more distinct vertices 
that lie on top of one another and the “intersecting” parts of the geometry are 
therefore disconnected from one another. You can normally fix this within the 
meshing software by using an “Imprint” operation (it might be called something 
else in your specific software). 

Another approach which might work (depending on which finite elements you are 
using) is that you can use the AffineConstraints to effectively tie the two 
overlapping degrees of freedom from each region together. But you’d have to 
manage this yourself. You can look at 
https://github.com/dealii/dealii/wiki/Frequently-Asked-Questions#how-do-i-get-the-degree-of-freedom-indices-at-vertices
 

to see how you can get the indices for DoFs with support at vertices, and these 
functions might also be of use in this regard:
https://dealii.org/developer/doxygen/deal.II/namespaceDoFTools.html#a5514e4f59ea659f63953d62ca429eaff
 

https://dealii.org/developer/doxygen/deal.II/namespaceDoFTools.html#a06b3c33925c1a1f15de20deda20b4d21
 

https://dealii.org/developer/doxygen/deal.II/namespaceDoFTools.html#a8b97e816b29ecf963370a9d8b349828f
 


I hope that this helps,
Jean-Paul

> On 19. Aug 2021, at 04:39, Wolfgang Bangerth  wrote:
> 
> On 8/18/21 9:20 AM, ibrahim zawra wrote:
>> Thanks a lot that helped, I applied symmetric<2,dim> tensor because it is a 
>> heat problem. I also implemented the convection boundary condition. I have a 
>> problem in the results, it seems the contact between surfaces is not 
>> detected automatically, I want to model such contact.Please I will be 
>> grateful for your guidance.
> 
> You will have to explain more what you are doing, what the symptoms are, what 
> you have already tried, what worked and what doesn't. We can't see from just 
> one picture what might possibly be wrong.
> 
> 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/d8166e4d-06e6-7da4-e258-9c936fed2ce8%40colostate.edu.

-- 
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/7C7AD21E-A410-40A8-832A-4FE2BF857D6D%40gmail.com.

Re: [deal.II] point_value, Real parts, step-29

[Jean-Paul Pelteret]

Another thing: You probably also need to initialise with the right number of 
components. So something like
Vector vecSol (fe.n_components());


> On 10. Aug 2021, at 19:40, Jean-Paul Pelteret  wrote:
> 
> Hi Hermes,
> 
> You don’t say what errors you’re seeing, but my guess is that it now doesn’t 
> compile. This variant of the function (the one that Daniel linked to) returns 
> void, so you should call it before outputting the result:
> 
> Vector vecSol;
> VectorTools::point_value(dof_handler, solution,Point<2>(0.2, 0.2),vecSol)
> std::cout << "Solution at (0.2,0.2): "<< vecSol << std::endl;
> 
> This will hopefully get you what you want.
> 
> Best,
> Jean-Paul
> 
> 
>> On 10. Aug 2021, at 16:09, Hermes Sampedro > <mailto:hermesampe...@gmail.com>> wrote:
>> 
>> Thank you for your answer. I am not sure if I fully understand your 
>> suggestion. Do you mean something like that:
>> 
>>  Vector vecSol;
>>  std::cout << "Solution at (0.2,0.2): "<< 
>> VectorTools::point_value(dof_handler, solution,Point<2>(0.2, 0.2),vecSol)<< 
>> std::endl;
>>
>> 
>> I still get some errors. Is there not any way to get for example the real 
>> part of solution easily and use it directly on the point_value as in step-3?
>> 
>> Thank you 
>> H
>> 
>> El mar, 10 ago 2021 a las 15:49, Daniel Arndt (> <mailto:d.arndt.m...@gmail.com>>) escribió:
>> Hermes,
>> 
>> Use another overload. The one returning the solution as a parameter should 
>> work: 
>> https://www.dealii.org/current/doxygen/deal.II/namespaceVectorTools.html#acd358e9b110ccbf4a7f76796d206b9c7
>>  
>> <https://www.dealii.org/current/doxygen/deal.II/namespaceVectorTools.html#acd358e9b110ccbf4a7f76796d206b9c7>
>> 
>> Best,
>> Daniel
>> 
>> Am Di., 10. Aug. 2021 um 09:41 Uhr schrieb Hermes Sampedro 
>> mailto:hermesampe...@gmail.com>>:
>> Dear all, 
>> 
>> It is explained in Step-3 how to evaluate the solution in a point. I am 
>> trying to do the same for Step-29, to evaluate the real and imaginary parts 
>> separately in a single point:
>> std::cout << "Solution at (0.2,0.2): "<< 
>> VectorTools::point_value(dof_handler, solution,Point<2>(0.2, 0.2))<< 
>> std::endl;
>> 
>> I do not have any problems compiling however, an error occurs when running:
>> 
>> The violated condition was:  dof.get_fe(0).n_components() == 1
>> 
>> What is the proper way to call the real and imaginary parts of the solution 
>> at a particular point here?
>> 
>> 
>> 
>> Thank you very much!
>> 
>> H.
>> 
>> 
>> -- 
>> The deal.II project is located at http://www.dealii.org/ 
>> <http://www.dealii.org/>
>> For mailing list/forum options, see 
>> https://groups.google.com/d/forum/dealii?hl=en 
>> <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 
>> <mailto:dealii+unsubscr...@googlegroups.com>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/dealii/54a2d44e-194a-43c0-aa7f-9fddd5bd0dean%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/dealii/54a2d44e-194a-43c0-aa7f-9fddd5bd0dean%40googlegroups.com?utm_medium=email_source=footer>.
>> 
>> -- 
>> The deal.II project is located at http://www.dealii.org/ 
>> <http://www.dealii.org/>
>> For mailing list/forum options, see 
>> https://groups.google.com/d/forum/dealii?hl=en 
>> <https://groups.google.com/d/forum/dealii?hl=en>
>> --- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "deal.II User Group" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/dealii/Ru1_uMbix30/unsubscribe 
>> <https://groups.google.com/d/topic/dealii/Ru1_uMbix30/unsubscribe>.
>> To unsubscribe from this group and all its topics, 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/CAOYDWb%2BR0bRTVxB-F22Hwk_ZexN4%3DVwCbZ7ZKqs3JjEaHFhncA%40mail.gmail.com
>>  
>> <https://groups.

Re: [deal.II] point_value, Real parts, step-29

[Jean-Paul Pelteret]

Hi Hermes,

You don’t say what errors you’re seeing, but my guess is that it now doesn’t 
compile. This variant of the function (the one that Daniel linked to) returns 
void, so you should call it before outputting the result:

Vector vecSol;
VectorTools::point_value(dof_handler, solution,Point<2>(0.2, 0.2),vecSol)
std::cout << "Solution at (0.2,0.2): "<< vecSol << std::endl;

This will hopefully get you what you want.

Best,
Jean-Paul


> On 10. Aug 2021, at 16:09, Hermes Sampedro  wrote:
> 
> Thank you for your answer. I am not sure if I fully understand your 
> suggestion. Do you mean something like that:
> 
>  Vector vecSol;
>  std::cout << "Solution at (0.2,0.2): "<< 
> VectorTools::point_value(dof_handler, solution,Point<2>(0.2, 0.2),vecSol)<< 
> std::endl;
>
> 
> I still get some errors. Is there not any way to get for example the real 
> part of solution easily and use it directly on the point_value as in step-3?
> 
> Thank you 
> H
> 
> El mar, 10 ago 2021 a las 15:49, Daniel Arndt ( >) escribió:
> Hermes,
> 
> Use another overload. The one returning the solution as a parameter should 
> work: 
> https://www.dealii.org/current/doxygen/deal.II/namespaceVectorTools.html#acd358e9b110ccbf4a7f76796d206b9c7
>  
> 
> 
> Best,
> Daniel
> 
> Am Di., 10. Aug. 2021 um 09:41 Uhr schrieb Hermes Sampedro 
> mailto:hermesampe...@gmail.com>>:
> Dear all, 
> 
> It is explained in Step-3 how to evaluate the solution in a point. I am 
> trying to do the same for Step-29, to evaluate the real and imaginary parts 
> separately in a single point:
> std::cout << "Solution at (0.2,0.2): "<< 
> VectorTools::point_value(dof_handler, solution,Point<2>(0.2, 0.2))<< 
> std::endl;
> 
> I do not have any problems compiling however, an error occurs when running:
> 
> The violated condition was:  dof.get_fe(0).n_components() == 1
> 
> What is the proper way to call the real and imaginary parts of the solution 
> at a particular point here?
> 
> 
> 
> Thank you very much!
> 
> H.
> 
> 
> -- 
> 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/54a2d44e-194a-43c0-aa7f-9fddd5bd0dean%40googlegroups.com
>  
> .
> 
> -- 
> 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 a topic in the Google 
> Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/dealii/Ru1_uMbix30/unsubscribe 
> .
> To unsubscribe from this group and all its topics, send an email to 
> dealii+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dealii/CAOYDWb%2BR0bRTVxB-F22Hwk_ZexN4%3DVwCbZ7ZKqs3JjEaHFhncA%40mail.gmail.com
>  
> .
> 
> -- 
> 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/CAB%3DnHhZrnXUeYt5FrKa66oTwoV8WJ8b%3DFqLFJ9pfP%3DUHRTyV%2BQ%40mail.gmail.com
>  
> .

-- 
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 

Re: [deal.II] Computing the solution gradient at the quadrature point on a face

[Jean-Paul Pelteret]

Hi Michael,

I’m glad that you’re on the right track now. 

> If you could give some advice or refer to some references on this topic, I 
> would appreciate that very mush.

Unfortunately, this is where pretty much I hit the limit of what I can say on 
this topic as it would conflict with the expectations of my employer. There’s a 
little by-line on one approach in this paper
https://www.sciencedirect.com/science/article/abs/pii/S0997753814001508 
<https://www.sciencedirect.com/science/article/abs/pii/S0997753814001508>
But as for other references, I’m hoping that someone else can give you some 
guidance there. (There’s at least one fairly common book in nonlinear mechanics 
that discusses the "linearisation of external virtual work”. Maybe a search in 
this direction might get you somewhere.)

Another option would be to try the auto-differentiation tools to do all of the 
heavy lifting for you. With few restrictions, it would be compatible with any 
general traction load. At the very least and AD implementation it could help 
you validate any linearisation that you do by hand. You can take a look at 
steps 70 and 71 to get some idea as to what it might be able to do for you. 
Using the approach in step-71 is probably easiest to start off in your case. 
You could even limit it to just linearising the contribution that comes from 
this boundary / traction contribution.

Best,
Jean-Paul


> On 4. Aug 2021, at 23:22, Michael Li  wrote:
> 
> Hi Jean-Paul,
>  
> Yes, I set up the boundary check when taking care of the traction. It worked 
> as expected using Physics::Transformations::nansons_formula(face_normal, F).
>  
> To make a quick test, I did not linearize the load stiffness but just used 
> the load at last Newton-Raphson step, so it is like a mixture of N-R and 
> Picard iteration. The technique is not correct and there is some discrepancy 
> compared with the reference. But the result is better than not considering 
> the face area change at all. So in some sense, it tells me that the surface 
> transform is correct. I’m working on how to linearize an arbitrary surface 
> traction. I have found some references dealing with the normal(pressure) load 
> but not arbitrary surface load (the force is not normal to the face in my 
> case). If you could give some advice or refer to some references on this 
> topic, I would appreciate that very mush.
>  
> You’re totally right, it converges only if a very small load step is used. 
> The residual grows up fast and the result is meaningless if the load 
> increment is large.
>  
> Thanks for your great help!
>  
> Michael
>  
>  
>  
> From: Jean-Paul Pelteret <mailto:jppelte...@gmail.com>
> Sent: Wednesday, August 4, 2021 12:19 AM
> To: dealii@googlegroups.com <mailto:dealii@googlegroups.com>
> Subject: Re: [deal.II] Computing the solution gradient at the quadrature 
> point on a face
>  
> Hi Michael,
>  
> The one thing that stands out about the snippet of code that you shared is 
> that there is no check to 
> if (cell->face(face)->at_boundary() == true && )...
> Do you still have something like that?
>  
> Otherwise, after a cursory glance, everything appears to be alright with 
> this. It mimics what you’d do to get the deformation gradient at a QP in a 
> cell. 
>  
> To debug further, what happens when you apply a very small load? Maybe its 
> not scaled appropriately for the stiffness of the material. Also, if you’ve 
> now added a deformation dependent part to the load (i.e. the area 
> transformation) then you might need to consistently linearise this in order 
> to attain convergence for large loads.
>  
> Best,
> Jean-Paul
> 
> 
> On 2. Aug 2021, at 18:03, Michael Li  <mailto:lianxi...@gmail.com>> wrote:
>  
> Hi Jean-Paul,
>  
> Thank you for your hints. 
>  
> I initialized a local variable solution_grads_u_face_total with 
> fe_face_values_ref[u_fe].get_function_gradients to get the gradient of 
> displacement at the quadrature point on the face (see codes below). But the 
> gradient acquired is not sensible and the resultant deformation is totally 
> wrong.
>  
> void assemble_neumann_contribution_one_cell(…)
> {
> ….  
> const FEValuesExtractors::Vector _fe = data.solid->u_fe;
>  
> std::vector > 
> solution_grads_u_face_total(data.solid->qf_face.size());
>  
> scratch.fe_face_values_ref.reinit(cell, face);
>  
> 
> scratch.fe_face_values_ref[u_fe].get_function_gradients(scratch.solution_total,
> 
> solution_grads_u_face_total);
>for (unsigned int face = 0; face < GeometryInfo::

Re: [deal.II] Able to use umfpack in debug configuration, but not in release configuration

[Jean-Paul Pelteret]

Hi Lucas,

I’m glad that you managed to solve this issue yourself.

> Given that the problem was a silly mistake on my end, ought I delete the 
> forum post?

Given that you’ve explained what you did to fix the problem, this is useful 
information for all. So we’ll leave the thread in place just in case someone 
has a similar issue in the future.

Best,
Jean-Paul

> On 21. Jul 2021, at 23:23, Lucas Myers  wrote:
> 
> Hi folks,
> 
> Excuse me, the problem was on my end -- when using cmake4eclipse, you have to 
> specify that you want to use the "CMAKE_EXPORT_COMPILE_COMMANDS parser" as 
> the provider in the "Preprocessor Includes, Paths, Macros, etc." tab for your 
> project for both the Release and Debug configurations.
> 
> Given that the problem was a silly mistake on my end, ought I delete the 
> forum post?
> 
> Thanks,
> Lucas
> 
> On Wednesday, July 21, 2021 at 3:57:12 PM UTC-5 Lucas Myers wrote:
> Hi all,
> 
> I've used the #include  command in a program in 
> order to use UMFPack. I'm able to compile and run everything fine in Debug 
> mode (provided by Eclipse via the cmake4eclipse add-on). However, when I try 
> to switch to Release mode to optimize the program, it gives me the following 
> warning:
> 
> /usr/local/include/deal.II/lac/sparse_direct.h:31:12: fatal error: umfpack.h: 
> No such file or directory
>  #  include 
> ^~~
> 
> This is confusing to me because, given that I can use UMFPack in Debug mode, 
> I must've installed it properly during the dealii installation.
> 
> Let me know if you have any tips on how to fix, or if you need more 
> information.
> 
> Thanks so much for any help,
> Lucas
> 
> -- 
> 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/da868037-2256-43ab-953d-99e8eff30cbcn%40googlegroups.com
>  
> .

-- 
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/D7F346A4-4F5E-4C26-B79B-48C925CDB788%40gmail.com.

Re: [deal.II] Computing the solution gradient at the quadrature point on a face

[Jean-Paul Pelteret]

Hi Michael,

The one thing that stands out about the snippet of code that you shared is that 
there is no check to 
if (cell->face(face)->at_boundary() == true && )...
Do you still have something like that?

Otherwise, after a cursory glance, everything appears to be alright with this. 
It mimics what you’d do to get the deformation gradient at a QP in a cell. 

To debug further, what happens when you apply a very small load? Maybe its not 
scaled appropriately for the stiffness of the material. Also, if you’ve now 
added a deformation dependent part to the load (i.e. the area transformation) 
then you might need to consistently linearise this in order to attain 
convergence for large loads.

Best,
Jean-Paul

> On 2. Aug 2021, at 18:03, Michael Li  wrote:
> 
> Hi Jean-Paul,
>  
> Thank you for your hints. 
>  
> I initialized a local variable solution_grads_u_face_total with 
> fe_face_values_ref[u_fe].get_function_gradients to get the gradient of 
> displacement at the quadrature point on the face (see codes below). But the 
> gradient acquired is not sensible and the resultant deformation is totally 
> wrong.
>  
> void assemble_neumann_contribution_one_cell(…)
> {
> ….  
> const FEValuesExtractors::Vector _fe = data.solid->u_fe;
>  
> std::vector > 
> solution_grads_u_face_total(data.solid->qf_face.size());
>  
> scratch.fe_face_values_ref.reinit(cell, face);
>  
> 
> scratch.fe_face_values_ref[u_fe].get_function_gradients(scratch.solution_total,
> 
> solution_grads_u_face_total);
>for (unsigned int face = 0; face < GeometryInfo::faces_per_cell; 
> ++face)
>{
>for (unsigned int f_q_point = 0; f_q_point < n_q_points_f; ++f_q_point)
>{
>const Tensor<2,dim,NumberType> _u = 
> solution_grads_u_face_total[f_q_point];
>const Tensor<2,dim,NumberType> F = 
> Physics::Elasticity::Kinematics::F(grad_u);
>    ………….
>    }
>………..
> }
> ………..
> }
>  
> Can you tell me what’s wrong with the code above?
>  
> Thank you!
> Michael
>  
>  
> From: Jean-Paul Pelteret <mailto:jppelte...@gmail.com>
> Sent: Sunday, August 1, 2021 1:46 PM
> To: dealii@googlegroups.com <mailto:dealii@googlegroups.com>
> Subject: Re: [deal.II] Computing the solution gradient at the quadrature 
> point on a face
>  
> Hi Michael,
>  
> The problem here is that “scratch.solution_grads_u_total” is initialised with 
> the cell FEValues, and so has n_cell_quadrature_points entries. You need to 
> pass 
> "scratch.fe_face_values_ref[u_fe].get_function_gradients(scratch.solution_total,
>   scratch.solution_grads_u_total);” something that has size 
> n_face_quadrature_points. That’s what this error is informing you.
> 
> 
> As a side note, Physics::Transformations::nansons_formula() 
> <https://dealii.org/developer/doxygen/deal.II/namespacePhysics_1_1Transformations.html#aa82925b742c3708f625a48a7abc440bc>
>  can compute the transformation of the normal vector + area change for you, 
> should you like the traction direction to follow the moving boundary surface 
> as well.
>  
> Best,
> Jean-Paul
> 
> 
> On 1. Aug 2021, at 20:05, Michael Lee  <mailto:lianxi...@gmail.com>> wrote:
>  
> fe_face_values.get_function_gradients returns a rank 2 tensor as the solution 
> is the displacement vector.
>  
> Let me be more specific. In the code gallery " Quasi-Static Finite-Strain 
> Compressible Elasticity (The deal.II Library: The 'Quasi-Static Finite-Strain 
> Compressible Elasticity' code gallery program (dealii.org) 
> <https://www.dealii.org/current/doxygen/deal.II/code_gallery_Quasi_static_Finite_strain_Compressible_Elasticity.html>
>  ). It does not consider the follower force as described in the 
> documentation:  " 
> // We specify the traction in reference configuration.
> // For this problem, a defined total vertical force is applied
> // in the reference configuration.
> // The direction of the applied traction is assumed not to
> // evolve with the deformation of the domain."
>  
> So I made a modification to consider the effect of the deformed area on the 
> traction as follows according to the formula da/dA = J sqrt(N C^-1 N) .
>  
> void
> assemble_neumann_contribution_one_cell(const typename 
> DoFHandler::active_cell_iterator ,
>ScratchData_ASM ,
>PerTaskData_ASM )
> {
>   // Aliases for data referenced from the Solid cl

Re: [deal.II] profiling and parallel performance of deal.II user codes

[Jean-Paul Pelteret]

To add to this great list of tools (which we should document on our Wiki), 
there’s also the LIKWID performance monitoring and benchmarking suite  which is 
able to provide some very low-level metrics and tools to help benchmarking.
https://github.com/RRZE-HPC/likwid 

Best,
Jean-Paul

> On 4. Aug 2021, at 07:19, simon...@gmail.com  wrote:
> 
> Hi,
> 
> I've used the scalasca tool suite for profiling:
> 
> https://www.scalasca.org/scalasca/about/about.html
> 
> which use score-p for measuring and the cube gui for visualizing the results:
> 
> https://www.vi-hps.org/projects/score-p
> https://www.scalasca.org/scalasca/software/cube-4.x/download.html
> 
> I think it is really good. However, it is somewhat difficult to get started 
> with. If you are interested, this user guide is a good place to start:
> 
> https://www.scalasca.org/scalasca/software/scalasca-2.x/documentation.html
> 
> Best,
> Simon
> 
> -- 
> 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/e8ebed6a-4bd9-418c-9fb9-751f9b2babc7n%40googlegroups.com
>  
> .

-- 
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/1AB34102-7115-4D8D-B7FA-6E6525A53E7C%40gmail.com.

Re: [deal.II] Computing the solution gradient at the quadrature point on a face

[Jean-Paul Pelteret]

Hi Michael,

The problem here is that “scratch.solution_grads_u_total” is initialised with 
the cell FEValues, and so has n_cell_quadrature_points entries. You need to 
pass 
"scratch.fe_face_values_ref[u_fe].get_function_gradients(scratch.solution_total,
  scratch.solution_grads_u_total);” something that has size 
n_face_quadrature_points. That’s what this error is informing you.

As a side note, Physics::Transformations::nansons_formula() 

 can compute the transformation of the normal vector + area change for you, 
should you like the traction direction to follow the moving boundary surface as 
well.

Best,
Jean-Paul

> On 1. Aug 2021, at 20:05, Michael Lee  wrote:
> 
> fe_face_values.get_function_gradients returns a rank 2 tensor as the solution 
> is the displacement vector.
> 
> Let me be more specific. In the code gallery " Quasi-Static Finite-Strain 
> Compressible Elasticity (The deal.II Library: The 'Quasi-Static Finite-Strain 
> Compressible Elasticity' code gallery program (dealii.org) 
> 
>  ). It does not consider the follower force as described in the 
> documentation:  " 
> // We specify the traction in reference configuration.
> // For this problem, a defined total vertical force is applied
> // in the reference configuration.
> // The direction of the applied traction is assumed not to
> // evolve with the deformation of the domain."
> 
> So I made a modification to consider the effect of the deformed area on the 
> traction as follows according to the formula da/dA = J sqrt(N C^-1 N) .
> 
> void
> assemble_neumann_contribution_one_cell(const typename 
> DoFHandler::active_cell_iterator ,
>ScratchData_ASM ,
>PerTaskData_ASM )
> {
>   // Aliases for data referenced from the Solid class
>   const unsigned int _q_points_f = data.solid->n_q_points_f;
>   const unsigned int _per_cell = data.solid->dofs_per_cell;
>   const Time  = data.solid->time;
>   const FESystem  = data.solid->fe;
>   const unsigned int _dof = data.solid->u_dof;
>   const FEValuesExtractors::Vector _fe = data.solid->u_fe;
> 
>   // Next we assemble the Neumann contribution. We first check to see it 
> the
>   // cell face exists on a boundary on which a traction is applied and add
>   // the contribution if this is the case.
>   for (unsigned int face = 0; face < GeometryInfo::faces_per_cell; 
> ++face)
> if (cell->face(face)->at_boundary() == true
> && cell->face(face)->boundary_id() == 11)
>   {
> scratch.fe_face_values_ref.reinit(cell, face);
> 
> scratch.fe_face_values_ref[u_fe].get_function_gradients(scratch.solution_total,
> 
> scratch.solution_grads_u_total);
> 
> for (unsigned int f_q_point = 0; f_q_point < n_q_points_f; 
> ++f_q_point)
>   {
> // Note that the contributions to the right hand side vector 
> we
> // compute here only exist in the displacement components of 
> the
> // vector.
> const double time_ramp = (time.current() / time.end());
> const double magnitude  = 0.5*1.95*1000*0.32*0.32*time_ramp; 
> // (Total force) / (RHS surface area)
> Tensor<1,dim> dir;
> dir[0] = 1.0;
> Tensor<1,dim> face_normal = 
> scratch.fe_face_values_ref.normal_vector(f_q_point);
> 
> const Tensor<2,dim,NumberType> _u = 
> scratch.solution_grads_u_total[f_q_point];
> const Tensor<2,dim,NumberType> F = 
> Physics::Elasticity::Kinematics::F(grad_u);
> const SymmetricTensor<2,dim,NumberType> C = 
> Physics::Elasticity::Kinematics::C(F);
> const SymmetricTensor<2,dim,NumberType> C_inv = invert(C);
> const Tensor<1, dim> traction  = magnitude*dir;
> 
> for (unsigned int i = 0; i < dofs_per_cell; ++i)
>   {
> const unsigned int i_group = 
> fe.system_to_base_index(i).first.first;
> 
> if (i_group == u_dof)
>   {
> const unsigned int component_i =
>   fe.system_to_component_index(i).first;
> const double Ni =
>   scratch.fe_face_values_ref.shape_value(i, 
> f_q_point);
> const double JxW = 
> scratch.fe_face_values_ref.JxW(f_q_point);
> 
> data.cell_rhs(i) += (Ni * traction[component_i])
>

Re: [deal.II] 'make' returns error on step-1 example

[Jean-Paul Pelteret]

Dear Wakil,

I’m glad that you were able to solve this issue. It (the inclusion of this 
libdl.tbd library) is something that we have noticed, and are still actively 
trying to address to make the Mac package as robust as possible. May I ask, how 
did you solve the problem? It’s clear that you previously had the command line 
tools installed. Did you install Xcode after that, or something else?

Best,
Jean-Paul

> On 27. Jul 2021, at 21:44, 'Wakil Sarfaraz' via deal.II User Group 
>  wrote:
> 
> This issue is resolved!
> 
> On Tuesday, July 27, 2021 at 1:27:25 PM UTC+2 Wakil Sarfaraz wrote:
> Hi all,
> 
> I am coming back to using dealii after quite a few years.
> I installed it on MacOS BigSur Version: 11.4 (20F71) and attempted to execute 
> step-1.
> cmake . worked fine
> make returned this error:
> 
> bash-3.2$ cmake .
> 
> -- The C compiler identification is AppleClang 12.0.5.12050022
> 
> -- The CXX compiler identification is AppleClang 12.0.5.12050022
> 
> -- Detecting C compiler ABI info
> 
> -- Detecting C compiler ABI info - done
> 
> -- Check for working C compiler: 
> /Library/Developer/CommandLineTools/usr/bin/cc - skipped
> 
> -- Detecting C compile features
> 
> -- Detecting C compile features - done
> 
> -- Detecting CXX compiler ABI info
> 
> -- Detecting CXX compiler ABI info - done
> 
> -- Check for working CXX compiler: 
> /Applications/deal.II.app/Contents/Resources/spack/opt/spack/openmpi-4.0.5-yh6r/bin/mpic++
>  - skipped
> 
> -- Detecting CXX compile features
> 
> -- Detecting CXX compile features - done
> 
> -- Autopilot invoked
> 
> ###
> 
> #
> 
> #  Project  step-1  set up with  deal.II-9.3.0  found at
> 
> #  /Applications/deal.II.app/Contents/Resources/Libraries
> 
> #
> 
> #  CMAKE_BUILD_TYPE:  Debug
> 
> #
> 
> #  You can now run
> 
> #   $ make- to compile and link the program
> 
> #   $ make run- to (compile, link and) run the program
> 
> #
> 
> #   $ make sign   - to sign the executable with the supplied OSX 
> developer key
> 
> #
> 
> #   $ make debug  - to switch the build type to 'Debug'
> 
> #   $ make release- to switch the build type to 'Release'
> 
> #
> 
> #   $ make edit_cache - to change (cached) configuration variables
> 
> #   and rerun the configure and generate phases 
> of CMake
> 
> #
> 
> #   $ make strip_comments - to strip the source files in this
> 
> #   directory off their comments; this is 
> irreversible
> 
> #   $ make clean  - to remove the generated executable as well as
> 
> #   all intermediate compilation files
> 
> #   $ make runclean   - to remove all output generated by the program
> 
> #   $ make distclean  - to clean the directory from _all_ generated
> 
> #   files (includes clean, runclean and the 
> removal
> 
> #   of the generated build system)
> 
> #   $ make info   - to view this message again
> 
> #
> 
> #  Have a nice day!
> 
> #
> 
> ###
> 
> -- Configuring done
> 
> -- Generating done
> 
> -- Build files have been written to: 
> /Applications/deal.II.app/Contents/Resources/examples/step-1
> 
> bash-3.2$ make
> 
> [ 50%] Building CXX object CMakeFiles/step-1.dir/step-1.cc.o
> 
> make[2]: *** No rule to make target 
> `/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/libdl.tbd',
>  needed by `step-1'.  Stop.
> 
> make[1]: *** [CMakeFiles/step-1.dir/all] Error 2
> 
> make: *** [all] Error 2
> 
> bash-3.2$ 
> 
> 
> 
> Any help will be much appreciated.
> 
> 
> 
> Wakil,
> 
> 
> -- 
> 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/26cf8aa0-37a4-47e3-8bc2-6aee222670bcn%40googlegroups.com
>  
> .

-- 
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 

Re: [deal.II] Matrix Multiplication

[Jean-Paul Pelteret]

Hi Michael,

> I revisited the code gallery example “The deal.II Library: The 'Quasi-Static 
> Finite-Strain Compressible Elasticity' code gallery program (dealii.org) 
> <https://www.dealii.org/developer/doxygen/deal.II/code_gallery_Quasi_static_Finite_strain_Compressible_Elasticity.html>”.
>  It seems I just need to modify two functions, i.e., getJc(det_F, b_bar) and 
> get_tau(det_F, b_bar) if I want to implement the St. Vienant Kirchhoff 
> material. Is that correct?

Yes, that’s correct. You need only supply a new definition of the Kirchhoff 
stress and its linearisation in order to implement a new constitutive law. The 
child namespaces of Physics::Transformations 
<https://www.dealii.org/developer/doxygen/deal.II/namespacePhysics_1_1Transformations.html>
 can be of some assistance if you choose a different parameterisation (i.e. use 
a different strain measure leading to different natural stress measure) and 
need to push-forward the result into the current configuration. You also don’t 
need to adhere to the volumetric/isochoric split that is used in the code 
gallery example. 

With regard to the error message that you’re seeing, this was a bug that was 
fixed in the upcoming 9.3 release.
https://github.com/dealii/dealii/pull/12217 
<https://github.com/dealii/dealii/pull/12217>
The warning messages also relate to some functions that are going to be removed 
later, so we need to update the program to use the function which supersedes 
it. Thanks for the letting us know about it!

Best,
Jean-Paul


> On 22. Jul 2021, at 23:54, Michael Li  wrote:
> 
> Hi Jean-Paul,
>  
> I revisited the code gallery example “The deal.II Library: The 'Quasi-Static 
> Finite-Strain Compressible Elasticity' code gallery program (dealii.org) 
> <https://www.dealii.org/developer/doxygen/deal.II/code_gallery_Quasi_static_Finite_strain_Compressible_Elasticity.html>”.
>  It seems I just need to modify two functions, i.e., getJc(det_F, b_bar) and 
> get_tau(det_F, b_bar) if I want to implement the St. Vienant Kirchhoff 
> material. Is that correct?
>  
> I compiled cook_membrane.cc <http://cook_membrane.cc/> a couple of days ago, 
> but for no reason, it fails giving the following errors:
>  
> /home/michael/dealii-9.2.0/examples/code-gallery/Quasi_static_Finite_strain_Compressible_Elasticity/cook_membrane.cc:1815
>  <http://cook_membrane.cc:1815/>:5:   required from here
> /home/michael/share/trilinos/include/Sacado_Fad_Exp_Ops.hpp:775:1: error: no 
> type named ‘type’ in ‘struct 
> Sacado::mpl::disable_if, 
> Sacado::Fad::Exp::MultiplicationOp  double> >, double, false, true, Sacado::Fad::Exp::ExprSpecDefault, 
> Sacado::Fad::Exp::PowerImpl::Scalar>, double, false, true, 
> Sacado::Fad::Exp::ExprSpecDefault> >’
>  
> /usr/local/include/deal.II/physics/elasticity/kinematics.h:294:47: error: no 
> match for ‘operator*’ (operand types are 
> ‘Sacado::Fad::Exp::PowerOp  double> >, double, false, true, Sacado::Fad::Exp::ExprSpecDefault, 
> Sacado::Fad::Exp::PowerImpl::Scalar>’ and ‘const dealii::Tensor<2, 2, 
> Sacado::Fad::Exp::GeneralFad 
> > >’)
>   294 |   return std::pow(determinant(F), -1.0 / dim) * F;
>   |  ~^~~
>  
> And some warnings:
>  
> /home/michael/dealii-9.2.0/examples/code-gallery/Quasi_static_Finite_strain_Compressible_Elasticity/cook_membrane.cc
>  <http://cook_membrane.cc/>: In instantiation of ‘void 
> Cook_Membrane::Solid::system_setup() [with int dim = 2; 
> NumberType = double]’:
> /home/michael/dealii-9.2.0/examples/code-gallery/Quasi_static_Finite_strain_Compressible_Elasticity/cook_membrane.cc:1005
>  <http://cook_membrane.cc:1005/>:5:   required from ‘void 
> Cook_Membrane::Solid::run() [with int dim = 2; NumberType = 
> double]’
> /home/michael/dealii-9.2.0/examples/code-gallery/Quasi_static_Finite_strain_Compressible_Elasticity/cook_membrane.cc:2263
>  <http://cook_membrane.cc:2263/>:24:   required from here
> /home/michael/dealii-9.2.0/examples/code-gallery/Quasi_static_Finite_strain_Compressible_Elasticity/cook_membrane.cc:1136
>  <http://cook_membrane.cc:1136/>:35: warning: ‘void 
> dealii::DoFTools::count_dofs_per_block(const DoFHandlerType&, 
> std::vector&, const std::vector&) [with 
> DoFHandlerType = dealii::DoFHandler<2, 2>]’ is deprecated 
> [-Wdeprecated-declarations]
> 1136 | DoFTools::count_dofs_per_block(dof_handler_ref, dofs_per_block,
>   | ~~^
> 1137 |block_component);
>   |
>  
>  
> Thanks,
> Michael
>  
> From: Jean-Paul Pelteret <mailto:jppelte...@gmail.com>

Re: [deal.II] Matrix Multiplication

[Jean-Paul Pelteret]

Dear Michael,

Although this BDB form is, as you say, ubiquitous in the literature, it is a 
consequence to using global scalar-valued shape functions everywhere as opposed 
to vector-valued shape functions that we support. So it falls out of the way 
that the finite element Ansatz is defined for a vector field. It’s definitely 
possible to write a deal.II program in this BDB form (a former colleague did 
this), but its completely not straightforward. I’m afraid to say that you’d 
have to work out all of the translation from the tensor-based, per DoF shape 
function operators to this global cell operator yourself. 

Have you looked at the finite strain solid mechanics tutorials and code gallery 
examples? They are really implementing the same thing, only with the native or 
“natural" deal.II constructs due to the use of vector-valued shape functions. 
It's easy enough to translate those tutorials to some other parameterisation, 
if need be.

Best,
Jean-Paul

> On 22. Jul 2021, at 17:47, Michael Li  wrote:
> 
> Dear Jean-Paul,
> Thank you for your information. It seems tensor is an elegant way to do the 
> computation. However I don’t know how to translate the following formulation 
> with tensor notation. The Voigt notation is used ubiquitous in the FEM 
> formulation of solid mechanics. It is straightforward to use matrix vector 
> operation as demonstrated in many references. In the following equation, the 
> B matrix (displacement-strain matrix with geometric nonlinearity) is not 
> square, so it looks like Bcannot be represented by a tensor. If I use Voigt 
> notation, then it seems I can only choose FullMatrix class which looks clumsy 
> and not fully exploiting deal.II. I suppose it can be implemented in deal.II 
> using tensor notation but just have no idea how to do that. 
>  
> <991EE976D38946F2A751BB07719E062B.png>
>  
> Thanks,
> Michael
>  
>  
> From: Jean-Paul Pelteret <mailto:jppelte...@gmail.com>
> Sent: Wednesday, July 21, 2021 10:45 PM
> To: dealii@googlegroups.com <mailto:dealii@googlegroups.com>
> Subject: Re: [deal.II] Matrix Multiplication
>  
> Dear Michael,
>  
> The classes that better serve your purpose are the Tensor and SymmetricTensor 
> classes:
> https://dealii.org/current/doxygen/deal.II/classTensor.html 
> <https://dealii.org/current/doxygen/deal.II/classTensor.html>
> https://dealii.org/current/doxygen/deal.II/classSymmetricTensor.html 
> <https://dealii.org/current/doxygen/deal.II/classSymmetricTensor.html>
> These classes have a number of member and non-member functions that make 
> performing the sort of operations that you listed much easier.
> There is also the unit_symmetric_tensor() function that returns the rank-2 
> identity tensor.
> https://dealii.org/current/doxygen/deal.II/classSymmetricTensor.html#a1e8821eb23f5416543aa98cf4e0f1aab
>  
> <https://dealii.org/current/doxygen/deal.II/classSymmetricTensor.html#a1e8821eb23f5416543aa98cf4e0f1aab>
>  
> Furthermore, we have a function that will compute the Green-Lagrange strain 
> tensor from a given deformation gradient tensor:
> https://dealii.org/current/doxygen/deal.II/namespacePhysics_1_1Elasticity_1_1Kinematics.html#ae607c6743e1481e02d0eb75cd4e32e78
>  
> <https://dealii.org/current/doxygen/deal.II/namespacePhysics_1_1Elasticity_1_1Kinematics.html#ae607c6743e1481e02d0eb75cd4e32e78>
>  
> I hope that this helps.
>  
> Best,
> Jean-Paul
> 
> 
> On 22. Jul 2021, at 00:39, Michael Lee  <mailto:lianxi...@gmail.com>> wrote:
>  
> Dear dealii users,
>  
> I want to construct a matrix . My approach is as follows.
>  
> FullMatrix F(3,3) = 0.0; // deformation gradient
> FullMatrix E(3,3) = 0.0; // Green strain
> FullMatrix I (IdentityMatrix(3));
> F.Tmmult(E, F);
> E.add(-1, I);
> E.add(2, E);
>  
> I wonder if there is an more elegant or easier way to do the matrix 
> construction as I need to do other similar operations.
>  
> Best,
> Michael
>  
> -- 
> The deal.II project is located at http://www.dealii.org/ 
> <http://www.dealii.org/>
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en 
> <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 
> <mailto:dealii+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dealii/CAEyr2zhNC9RpZVjD%2B4ggHp-PCBCRz9YCtBLSyxxqqeCDE-giSA%40mail.gmail.com
>  
> <https://groups.google.com/d/m

Re: [deal.II] Deal.II programming environment

[Jean-Paul Pelteret]

Hi Martin,

This is the sort of case where where VSCode is really useful. It has an easy to 
use remote development extension, where you would open and use the editor in 
Windows but you’d be editing and building files on the virtual machine. Here 
are a couple of official links that explain the concept, and if this interests 
you then I think that a quick google search would be able to clear up the 
details on how to set it all up. 
https://code.visualstudio.com/docs/remote/ssh 

https://code.visualstudio.com/docs/remote/ssh-tutorial 


The hardest thing is getting the initial ssh connection to the virtual machine 
working, because after that you can navigate the virtual machine in VSCode and 
set up a workspace as if it was the physical machine that you’re working on.

Best,
Jean-Paul


> On 22. Jul 2021, at 04:02, Jiang Hu  wrote:
> 
> Hi Bruno,
> 
> Thanks for the link. 
> The thing is, I am using a virtual box machine with Deal.II and Ubuntu. 
> where should I get Eclipse installed? I guess doing it in windows should not 
> work.
> 
> Thanks for your time.
> Martin 
> 
> 
> On Wednesday, 21 July 2021 at 10:11:01 pm UTC+10 bruno.t...@gmail.com 
>  wrote:
> Martin,
> 
> You can use whatever you like, there is no such thing as a typical 
> environment. With that being said, we do have documentation and videos to 
> help you setup Eclipse. See 
> https://github.com/dealii/dealii/wiki/Eclipse 
> 
> https://www.math.colostate.edu/~bangerth/videos.676.7.html 
> 
> https://www.math.colostate.edu/~bangerth/videos.676.8.html 
> 
> https://www.math.colostate.edu/~bangerth/videos.676.8.01.html 
> 
> 
> Best,
> 
> Bruno
> 
> On Wednesday, July 21, 2021 at 1:22:36 AM UTC-4 jian...@gmail.com 
>  wrote:
> Hello everyone,
> 
> Quite excited to find Deal.II and its potential.
> 
> I installed virtual machine with Deal.II, and run step 7 on terminal without 
> any problem.
> 
> The question is if I want to compile bigger program with Deal.II , what is 
> the typical working environment? 
> 
> I assume we can not with terminal for such a purpose. I saw people using Nano 
> to run Deal.II, but want to ask the standard tool for such process.
> 
> Emacs or Vscode?  Do I need to connect them to Deal.II?
> 
> I am very new, and this could be a quite silly question.
> 
> Thanks 
> 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dealii/d44db170-42e1-463d-8e39-3f0b096c215en%40googlegroups.com
>  
> .

-- 
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/61A9632C-675E-4A96-BC84-C9F8F772E605%40gmail.com.

Re: [deal.II] Matrix Multiplication

[Jean-Paul Pelteret]

Dear Michael,

The classes that better serve your purpose are the Tensor and SymmetricTensor 
classes:
https://dealii.org/current/doxygen/deal.II/classTensor.html 

https://dealii.org/current/doxygen/deal.II/classSymmetricTensor.html 

These classes have a number of member and non-member functions that make 
performing the sort of operations that you listed much easier.
There is also the unit_symmetric_tensor() function that returns the rank-2 
identity tensor.
https://dealii.org/current/doxygen/deal.II/classSymmetricTensor.html#a1e8821eb23f5416543aa98cf4e0f1aab
 


Furthermore, we have a function that will compute the Green-Lagrange strain 
tensor from a given deformation gradient tensor:
https://dealii.org/current/doxygen/deal.II/namespacePhysics_1_1Elasticity_1_1Kinematics.html#ae607c6743e1481e02d0eb75cd4e32e78
 


I hope that this helps.

Best,
Jean-Paul

> On 22. Jul 2021, at 00:39, Michael Lee  wrote:
> 
> Dear dealii users,
> 
> I want to construct a matrix . My approach is as follows.
> 
> FullMatrix F(3,3) = 0.0; // deformation gradient
> FullMatrix E(3,3) = 0.0; // Green strain
> FullMatrix I (IdentityMatrix(3));
> F.Tmmult(E, F);
> E.add(-1, I);
> E.add(2, E);
> 
> I wonder if there is an more elegant or easier way to do the matrix 
> construction as I need to do other similar operations.
> 
> Best,
> Michael
> 
> -- 
> 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/CAEyr2zhNC9RpZVjD%2B4ggHp-PCBCRz9YCtBLSyxxqqeCDE-giSA%40mail.gmail.com
>  
> .

-- 
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/6A8D385C-1E4F-4F9A-87DA-9DC57966D289%40gmail.com.

Re: [deal.II] How to add 2nd iterator to MeshWorker::mesh_loop ?

[Jean-Paul Pelteret]

To add to what Wolfgang has already said, there’s this entry in our FAQ on this 
topic:
https://github.com/dealii/dealii/wiki/Frequently-Asked-Questions#can-i-convert-triangulation-cell-iterators-to-dofhandler-cell-iterators
 



> On 15. Jul 2021, at 17:31, Wolfgang Bangerth  wrote:
> 
> On 7/15/21 2:45 AM, Sylvain Mathonnière wrote:
>> *typenameDoFHandler::active_cell_iteratorcell_2 
>> (cell_1->get_triangulation(), cell_1->level(), cell_1->index(), 
>> dof_handler_2);*
> 
> The compiler error tells you that you need pointers, not references. So this 
> should work:
> 
>  typename DoFHandler::active_cell_iterator
> cell_2 (_1->get_triangulation(), cell_1->level(), cell_1->index(),
> _handler_2);
> 
> 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/53c90809-04b1-c2f0-3d35-ec11726fa46f%40colostate.edu.

-- 
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/5759F5A1-53A7-4978-AA38-A65F431DE3A4%40gmail.com.

Re: [deal.II] Map from dof index to vertex index

[Jean-Paul Pelteret]

To add to what Wolfgang has already said, there’s this entry in our FAQ on this 
topic (well, the reverse mapping from vertex to DoF):
https://github.com/dealii/dealii/wiki/Frequently-Asked-Questions#how-do-i-get-the-degree-of-freedom-indices-at-vertices
 



> On 16. Jul 2021, at 00:30, Wolfgang Bangerth  wrote:
> 
> On 7/15/21 3:09 PM, Kaushik Das wrote:
>> Is there a way to know which dof_index is located at which vertex.
>> For example, I want to "map" a dof_index that I get from 
>> affine_constrains.get_constraint_entries(line);
>> to a vertex index that are in the range of triangulation.begin_vertex() and 
>> triangulation.end_vertex().
> 
> Kaushik,
> there is no such way in the library because, in general, DoFs need not be 
> located on vertices. That is only true for the Q1 element.
> 
> But if you look at the implementation of the 
> DoFTools::map_dofs_to_support_points(), you can probably come up with a way 
> to get what you are looking, assuming you really are only using Q1 elements.
> 
> 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/b963d470-97f9-f79a-3ab8-4c31dbb70c94%40colostate.edu.

-- 
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/1AEDB596-AB45-45BD-B23A-847E077842EA%40gmail.com.

Re: [deal.II] New location for sacado.hpp

[Jean-Paul Pelteret]

Hi Matthew,

Great, I’m glad to hear that! 

> So my last question is what is the difference between a flag being ON vs set 
> up with external dependencies ( which is what trilinos is set at now) 


When you set one of these flags to “ON”, you are demanding from CMake that this 
option be enabled and expect that the associated package must be set up 
correctly. Similarly, when the flag is set to “OFF” then the auto-detection for 
that package will be skipped (and, even if you tell deal.II where that library 
is by providing its path, it will ignore it anyway). When you leave flag this 
out altogether  you rely on the auto-detection mechanism to find the package 
and if it cannot be found (or there’s some detected compatibility issue) then 
you give CMake the leeway to disable and ignore this package. So, in summary, 
it just gives the granularity to say “Yes, I definitely want this dependency 
enabled” or “No, under all circumstances ignore this optional dependency” or 
“if you find it and it works, then I want this enabled".

When the package is said to be an "external dependency”, then it just means 
that the user or OS has provided said package. We bundle a few mandatory 
packages ourselves (e.g. the boost libraries), so that if the user hasn’t got 
them installed then we can fall back to these packages that are maintained 
within deal.II itself. 

> Will I be able to run those tutorials now? or is there still more work to be 
> done. 

For step-72 and step-33, I’d say yes
https://github.com/dealii/dealii/blob/master/examples/step-72/CMakeLists.txt#L40-L51
 
<https://github.com/dealii/dealii/blob/master/examples/step-72/CMakeLists.txt#L40-L51>
https://github.com/dealii/dealii/blob/master/examples/step-33/CMakeLists.txt#L43-L53
 
<https://github.com/dealii/dealii/blob/master/examples/step-33/CMakeLists.txt#L43-L53>

But to run step-71 you’ll also need to install SymEngine
https://github.com/dealii/dealii/blob/master/examples/step-71/CMakeLists.txt#L40-L54
 
<https://github.com/dealii/dealii/blob/master/examples/step-71/CMakeLists.txt#L40-L54>

I don’t think that there’s an Ubuntu package for that yet, but it’s not too 
hard to install by hand. You can take a look at their GitHub page for build 
instructions. At the bottom of the page there is their "Recommended options to 
build”, which you might want to take note of.
https://github.com/symengine/symengine <https://github.com/symengine/symengine>

Best,
Jean-Paul

> On 7. Jul 2021, at 20:49, Matthew Rich  wrote:
> 
> Thanks that worked! 
> 
> I needed to install the full trilinos-all-dev to get all the packages. I also 
> needed to install libptscotch-dev. 
> 
> So my last question is what is the difference between a flag being ON vs set 
> up with external dependencies ( which is what trilinos is set at now) 
> 
> Will I be able to run those tutorials now? or is there still more work to be 
> done. 
> 
> Thank you for all your help resolving this issue. 
> 
> 
> 
> On Wednesday, 7 July 2021 at 14:36:36 UTC-4 Jean-Paul Pelteret wrote:
> Hi again Matthew,
> 
> I’ve also found this build log for the Debian deal.II apt package
> https://buildd.debian.org/status/fetch.php?pkg=deal.ii=all=9.2.0-3=1606990185=0
>  
> <https://buildd.debian.org/status/fetch.php?pkg=deal.ii=all=9.2.0-3=1606990185=0>
> and you can see that in amongst all of the dependencies are listed the 
> "trilinos-all-dev” and " trilinos-dev” packages. They are meta-packages for 
> all of the development files for Trilinos 
> <https://packages.ubuntu.com/groovy/trilinos-all-dev>. I reckon that you 
> should install these packages, and then give it another try. 
> 
> Best,
> Jean-Paul
> 
> 
>> On 7. Jul 2021, at 20:15, Jean-Paul Pelteret > > wrote:
>> 
>> Hi Matthew,
>> 
>> If you look at either log file, then you’ll see that Trilinos was in fact 
>> not detected for some reason.
>> 
>>> DEAL_II_WITH_TRILINOS = OFF
>> 
>> 
>> I’m no longer experienced in building deal.II using apt packages, but it 
>> might be that you have to install the entire trilinos-dev to get all of the 
>> headers. Some of the modules that Trilinos provides are mandatory, and some 
>> like Sacado are optional. It could be that some of the other necessary 
>> headers aren’t there for the mandatory modules, and so the configure-time 
>> checks for core Trilinos packages cannot pass.
>> 
>> Try that, and if it fails then you can also add this
>> -DDEAL_II_WITH_TRILINOS=ON -DTRILINOS_DIR=“/usr"
>>  to the cmake command to explicitly state that you want Trilinos enabled. 
>> Then if it doesn’t detect it CMake should emit an error and you’ll know for 
>> sure that there’s still something wrong. From these 

Re: [deal.II] New location for sacado.hpp

[Jean-Paul Pelteret]

Hi again Matthew,

I’ve also found this build log for the Debian deal.II apt package
https://buildd.debian.org/status/fetch.php?pkg=deal.ii=all=9.2.0-3=1606990185=0
 
<https://buildd.debian.org/status/fetch.php?pkg=deal.ii=all=9.2.0-3=1606990185=0>
and you can see that in amongst all of the dependencies are listed the 
"trilinos-all-dev” and " trilinos-dev” packages. They are meta-packages for all 
of the development files for Trilinos 
<https://packages.ubuntu.com/groovy/trilinos-all-dev>. I reckon that you should 
install these packages, and then give it another try. 

Best,
Jean-Paul


> On 7. Jul 2021, at 20:15, Jean-Paul Pelteret  wrote:
> 
> Hi Matthew,
> 
> If you look at either log file, then you’ll see that Trilinos was in fact not 
> detected for some reason.
> 
>> DEAL_II_WITH_TRILINOS = OFF
> 
> 
> I’m no longer experienced in building deal.II using apt packages, but it 
> might be that you have to install the entire trilinos-dev to get all of the 
> headers. Some of the modules that Trilinos provides are mandatory, and some 
> like Sacado are optional. It could be that some of the other necessary 
> headers aren’t there for the mandatory modules, and so the configure-time 
> checks for core Trilinos packages cannot pass.
> 
> Try that, and if it fails then you can also add this
> -DDEAL_II_WITH_TRILINOS=ON -DTRILINOS_DIR=“/usr"
>  to the cmake command to explicitly state that you want Trilinos enabled. 
> Then if it doesn’t detect it CMake should emit an error and you’ll know for 
> sure that there’s still something wrong. From these lines
> https://github.com/dealii/dealii/blob/master/cmake/configure/configure_2_trilinos.cmake#L58-L68
>  
> <https://github.com/dealii/dealii/blob/master/cmake/configure/configure_2_trilinos.cmake#L58-L68>
> there should also be some messages that indicate exactly which modules it 
> could not find.
> 
> I hope that this helps.
> 
> Best,
> Jean-Paul
> 
> 
>> On 7. Jul 2021, at 19:43, Matthew Rich > <mailto:mjric...@gmail.com>> wrote:
>> 
>> Hi 
>> 
>> Thanks for the prompt reply.
>> 
>> Yes I built deal.II from source but libtrilinos-sacado-dev was installed via 
>> the debian package and apt (log files attached). I have all the headers in 
>> my /usr/include/trilinos directory. Just skimming the summary file it 
>> appears that deal.II did not detect sacado. Not sure why not though. 
>> 
>> Thanks for the tip on the new tutorials. I will check them out once I get 
>> this working. 
>> 
>> Matt
>> 
>> On Wednesday, 7 July 2021 at 12:51:26 UTC-4 Jean-Paul Pelteret wrote:
>> Hi Matthew,
>> 
>> I don’t quite understand exactly how you installed deal.II and Trilinos. 
>> Perhaps you can provide some more explicit details so that we can help you 
>> out.
>> 
>> * Is Trilinos installed using the apt package, and deal.II installed from 
>> source? If you built deal.II from source, may you please attach the build 
>> logs (summary.log and detailed.log) for us to look at.
>> 
>> * Did you install the Trilinos development packages (e.g. trilinos-dev or 
>> libtrilinos-sacado-dev), which should install the headers into a central 
>> location?
>> 
>> * When you built deal.II, and it detects Trilinos and Sacado, the following 
>> two variable is defined in config.h (this is also output to the console 
>> during configuration):
>> $ cat include/deal.II/base/config.h | grep SACADO
>>   #define DEAL_II_TRILINOS_WITH_SACADO
>> Do you see it there? If not, then deal.II did not successfully detect Sacado 
>> during configuration, and does not support it. If you try to configure 
>> step-33, an error should be emitted that expresses this.
>> 
>> When you #include  then the compiler first looks for this header 
>> in the default location for the system, which I think is  /usr/include. If 
>> it doesn’t find it there then it looks in some other specific locations that 
>> deal.II (through the configured packages) suggests that it goes looking in.
>> 
>> As a side note, there are two new tutorials (step-71 
>> <https://www.dealii.org/current/doxygen/deal.II/step_71.html> and step-72 
>> <https://www.dealii.org/current/doxygen/deal.II/step_72.html>) that cover 
>> the topic of auto-differentiation as well. You might want to consider 
>> looking at those before step-33. Step-33 uses Sacado at a low-level, and 
>> these two new tutorials introduce some wrappers that we’ve implemented 
>> inside the library that make using Sacado a bit more tractable.
>> 
>> Best,
>> Jean-Paul
>> 
>> 

Re: [deal.II] New location for sacado.hpp

[Jean-Paul Pelteret]

Hi Matthew,

If you look at either log file, then you’ll see that Trilinos was in fact not 
detected for some reason.

> DEAL_II_WITH_TRILINOS = OFF


I’m no longer experienced in building deal.II using apt packages, but it might 
be that you have to install the entire trilinos-dev to get all of the headers. 
Some of the modules that Trilinos provides are mandatory, and some like Sacado 
are optional. It could be that some of the other necessary headers aren’t there 
for the mandatory modules, and so the configure-time checks for core Trilinos 
packages cannot pass.

Try that, and if it fails then you can also add this
-DDEAL_II_WITH_TRILINOS=ON -DTRILINOS_DIR=“/usr"
 to the cmake command to explicitly state that you want Trilinos enabled. Then 
if it doesn’t detect it CMake should emit an error and you’ll know for sure 
that there’s still something wrong. From these lines
https://github.com/dealii/dealii/blob/master/cmake/configure/configure_2_trilinos.cmake#L58-L68
 
<https://github.com/dealii/dealii/blob/master/cmake/configure/configure_2_trilinos.cmake#L58-L68>
there should also be some messages that indicate exactly which modules it could 
not find.

I hope that this helps.

Best,
Jean-Paul


> On 7. Jul 2021, at 19:43, Matthew Rich  wrote:
> 
> Hi 
> 
> Thanks for the prompt reply.
> 
> Yes I built deal.II from source but libtrilinos-sacado-dev was installed via 
> the debian package and apt (log files attached). I have all the headers in my 
> /usr/include/trilinos directory. Just skimming the summary file it appears 
> that deal.II did not detect sacado. Not sure why not though. 
> 
> Thanks for the tip on the new tutorials. I will check them out once I get 
> this working. 
> 
> Matt
> 
> On Wednesday, 7 July 2021 at 12:51:26 UTC-4 Jean-Paul Pelteret wrote:
> Hi Matthew,
> 
> I don’t quite understand exactly how you installed deal.II and Trilinos. 
> Perhaps you can provide some more explicit details so that we can help you 
> out.
> 
> * Is Trilinos installed using the apt package, and deal.II installed from 
> source? If you built deal.II from source, may you please attach the build 
> logs (summary.log and detailed.log) for us to look at.
> 
> * Did you install the Trilinos development packages (e.g. trilinos-dev or 
> libtrilinos-sacado-dev), which should install the headers into a central 
> location?
> 
> * When you built deal.II, and it detects Trilinos and Sacado, the following 
> two variable is defined in config.h (this is also output to the console 
> during configuration):
> $ cat include/deal.II/base/config.h | grep SACADO
>   #define DEAL_II_TRILINOS_WITH_SACADO
> Do you see it there? If not, then deal.II did not successfully detect Sacado 
> during configuration, and does not support it. If you try to configure 
> step-33, an error should be emitted that expresses this.
> 
> When you #include  then the compiler first looks for this header 
> in the default location for the system, which I think is  /usr/include. If it 
> doesn’t find it there then it looks in some other specific locations that 
> deal.II (through the configured packages) suggests that it goes looking in.
> 
> As a side note, there are two new tutorials (step-71 
> <https://www.dealii.org/current/doxygen/deal.II/step_71.html> and step-72 
> <https://www.dealii.org/current/doxygen/deal.II/step_72.html>) that cover the 
> topic of auto-differentiation as well. You might want to consider looking at 
> those before step-33. Step-33 uses Sacado at a low-level, and these two new 
> tutorials introduce some wrappers that we’ve implemented inside the library 
> that make using Sacado a bit more tractable.
> 
> Best,
> Jean-Paul
> 
> 
> 
>> On 7. Jul 2021, at 17:41, Matthew Rich > > wrote:
>> 
> 
>> Hi all,
>> 
>>  I am a bit confused on step-33 which uses the differentiation of sacado. I 
>> installed the latest version. 9.3 which has trilinios in it, and therefore 
>> sacado. Browsing that directory I see other header files for the package but 
>> not sacado.hpp
>> 
>> The tutorial has the line
>> #include 
>> 
>> Was this file renamed or something? I am on Debian and I have installed the 
>> trilinios through their package, which does have the header file. However I 
>> cannot get the program to work properly.
>> 
>> I am looking for guidance on this issue of getting the right headers in the 
>> program so I can run this tutorial and others leveraging the sacado package.
>> 
>> Thanks in advance,
>> 
>> Maty
>> 
>> 
>> 
>> 
> 
>> -- 
>> The deal.II project is located at http://www.dealii.org/ 
>> <http://www.dealii.org/>
>

Re: [deal.II] New location for sacado.hpp

[Jean-Paul Pelteret]

Hi Matthew,

I don’t quite understand exactly how you installed deal.II and Trilinos. 
Perhaps you can provide some more explicit details so that we can help you out.

* Is Trilinos installed using the apt package, and deal.II installed from 
source? If you built deal.II from source, may you please attach the build logs 
(summary.log and detailed.log) for us to look at.

* Did you install the Trilinos development packages (e.g. trilinos-dev or 
libtrilinos-sacado-dev), which should install the headers into a central 
location?

* When you built deal.II, and it detects Trilinos and Sacado, the following two 
variable is defined in config.h (this is also output to the console during 
configuration):
$ cat include/deal.II/base/config.h | grep SACADO
  #define DEAL_II_TRILINOS_WITH_SACADO
Do you see it there? If not, then deal.II did not successfully detect Sacado 
during configuration, and does not support it. If you try to configure step-33, 
an error should be emitted that expresses this.

When you #include  then the compiler first looks for this header in 
the default location for the system, which I think is  /usr/include. If it 
doesn’t find it there then it looks in some other specific locations that 
deal.II (through the configured packages) suggests that it goes looking in.

As a side note, there are two new tutorials (step-71 
 and step-72 
) that cover the 
topic of auto-differentiation as well. You might want to consider looking at 
those before step-33. Step-33 uses Sacado at a low-level, and these two new 
tutorials introduce some wrappers that we’ve implemented inside the library 
that make using Sacado a bit more tractable.

Best,
Jean-Paul


> On 7. Jul 2021, at 17:41, Matthew Rich  wrote:
> 
> Hi all,
> 
>  I am a bit confused on step-33 which uses the differentiation of sacado. I 
> installed the latest version. 9.3 which has trilinios in it, and therefore 
> sacado. Browsing that directory I see other header files for the package but 
> not sacado.hpp
> 
> The tutorial has the line
> #include 
> 
> Was this file renamed or something? I am on Debian and I have installed the 
> trilinios through their package, which does have the header file. However I 
> cannot get the program to work properly.
> 
> I am looking for guidance on this issue of getting the right headers in the 
> program so I can run this tutorial and others leveraging the sacado package.
> 
> Thanks in advance,
> 
> Maty
> 
> 
> 
> 
> -- 
> 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/CAN3OR9oH-Za8weU3xHrMs5H86VeJffqtnrNxo_xh%3DddjMhc88g%40mail.gmail.com
>  
> .

-- 
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/C1F05D6B-DC3D-427B-B350-F0767A98B6B4%40gmail.com.

Re: [deal.II] On the discretization of the time harmonic Maxwell equation

[Jean-Paul Pelteret]

Hi Abbas,

I’m sorry that nobody has answered your question to date. It could be that 
there is no-one on the forum with the requisite knowledge to help you, or maybe 
those that have the knowledge just aren’t capable of responding at the moment. 
If you haven’t done so already, then perhaps you might choose to ask your 
question on another forum (StackOverflow might be a good one to start with) — 
hopefully you’d have better luck getting some advice or guidance there.

Best,
Jean-Paul 

> On 28. Jun 2021, at 18:04, Abbas  wrote:
> 
> This is not a dealii question per se but again, if it's someone who can 
> answer this question it's going to be someone from here. 
> 
> The literature mostly refers to two approaches todiscretizing the time 
> harmonic Maxwell equation. The first one is through the use of edge curl 
> conforming Nedelec elements and the other being through the use of interior 
> penalty DG. 
> 
> Any comments on the use of one approach over the other? 
> 
> -- 
> 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/ace82c1c-42b4-4e76-ade7-c591fc898940n%40googlegroups.com
>  
> .

-- 
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/490BCD80-A99D-425C-85B8-AE8617AA1ECD%40gmail.com.

Re: [deal.II] Saving PointHistory data to file for restart

[Jean-Paul Pelteret]

Hi Dario,

To add to what’s already been suggested, you can also look at the 
TransferableQuadraturePointData 

 and  ContinuousQuadratureDataTransfer 

 classes (and the corresponding tests 
). 
These as mentioned in the CellDataStorage 
 class 
documentation, and were implemented to support the transfer of QP data upon 
refinement / coarsening with  p::d::SolutionTransfer. The 
TransferableQuadraturePointData::pack_values()/unpack_values() functions can 
also be used to help with the serialisation process. 

As a side note, why there is no direct support for serialisation in the 
CellDataStorage is that the data stored there is very general and 
user-controlled, so its not straightforward to recreate polymorphic types upon 
restarting. For instance, there is no guarantee that you keep the data types 
stored in the CellDataStorage consistent at save and load time. 

So the idea is that the user is delegated responsibility for creating and 
initialising these classes, and then the unpack_values() function can be used 
to unroll some serialised data in to the fully initialised user-defined class 
instance. How you could to this is to create a save()/load() function (see how 
we use BOOST_SERIALIZATION_SPLIT_MEMBER() in the various classes that have 
this) and call the pack_values() and unpack_values() in save() and load() 
respectively. In save(), for instance, you could call pack_data() and unroll 
all of your data into the input std::vector that would have scope in the save() 
function. You would then serialise the std::vector. Loading would be the 
opposite — deserialise the vector, and pass it into the unpack_values() 
function that then extracts the data and initialises your class member 
variables with the loaded data. Something like that… The benefit of doing it 
this way is that you then get the interpolation-upon-refinement capabilities 
for the ContinuousQuadratureDataTransfer class for free! 

I see that we don’t actually have a test that shows how to do this, but if 
you’d be interested in adding one, that would be much appreciated. We could 
then augment the documentation with a working example to show how one can do it.

Best,
Jean-Paul


> On 2. Jul 2021, at 18:19, 'Dario Abbondanza' via deal.II User Group 
>  wrote:
> 
> Thank you for your reply.
> 
> > I don't have a particularly good solution in my head, but if you look at how
> > programs such as ASPECT do checkpoint/restart, then they use a mechanism 
> > such
> > as p::d::SolutionTransfer to attach data to the triangulation, save/restore,
> > and unattach.
> 
> This is exactly what I am doing for the solution vectors. 
> 
> 
> > You might be able to achieve the same effect by using the
> > CellDataTransfer class, though I have no idea if anyone has ever tried that.
> 
> I will have a look at the CellDataTransfer class and see what I am able to 
> achieve.
> Eventually I will reply to this discussion.
> 
> Best,
> Dario
> 
> Il giorno venerdì 2 luglio 2021 alle 05:51:58 UTC+2 Wolfgang Bangerth ha 
> scritto:
> On 7/1/21 4:48 AM, 'Dario Abbondanza' via deal.II User Group wrote: 
> > 
> > I'm studying a problem in which I need to store quantities (symmetric 
> > tensors 
> > and doubles) at quadrature points, and I do that by using a PointHistory 
> > class 
> > as done in step 44 
> > (https://www.dealii.org/current/doxygen/deal.II/step_44.html#Quadraturepointhistory
> >  
> > ).
> >  
> > The only difference is that I'm defining the CellDataStorage as 
> > 
> > CellDataStorage > parallel::distributed::Triangulation::cell_iterator, 
> >PointHistory > 
> > quadrature_point_history; 
> > 
> > because I use a parallel distributed triangulation. 
> 
> I don't have a particularly good solution in my head, but if you look at how 
> programs such as ASPECT do checkpoint/restart, then they use a mechanism such 
> as p::d::SolutionTransfer to attach data to the triangulation, save/restore, 
> and unattach. You might be able to achieve the same effect by using the 
> CellDataTransfer class, though I have no idea if anyone has ever tried that. 
> 
> Best 
> W. 
> 
> -- 
>  
> Wolfgang Bangerth email:  bang...@colostate.edu 
>  
> www: http://www.math.colostate.edu/~bangerth/ 
>  
> 
> 
> 
> Le informazioni contenute in questo messaggio di posta elettronica sono 
> strettamente riservate e indirizzate esclusivamente al 

Re: [deal.II] Using periodic boundary conditions with parallell processing

[Jean-Paul Pelteret]

Hi Raghunandan,

Quick question: This sort of setup sounds like something that you would do for 
homogenisation problems… Have you fixed your periodicity frame? (This amounts 
to completely fixing one point to remove rigid body translations, and partially 
constraining n-dim other points to remove rigid body rotations. Without doing 
so, the solution is “floating” and the convergence of the linear solver may 
stagnate. See the article below if you need some explanation as to what I mean 
about the periodicity frame.) 

@Article{Miehe2003a,
  author= {Miehe, C.},
  title = {Computational micro-to-macro transitions for discretized 
micro-structures of heterogeneous materials at finite strains based on the 
minimization of averaged incremental energy},
  journal   = {Computer Methods in Applied Mechanics and Engineering},
  year  = {2003},
  volume= {192},
  number= {5--6},
  pages = {559--591},
  month = jan,
  doi   = {10.1016/s0045-7825(02)00564-9},
}

Best,
Jean-Paul

> On 6. Jul 2021, at 01:46, Raghunandan Pratoori  wrote:
> 
> Hi Peter,
> 
> Thanks for your reply. I have PBC in all the 3 directions ( I have included 
> the code snippet above for only 1 direction). In addition to this, I want to 
> apply compression in 1 direction.
> 
> I checked the constraints using 
> AffineConstraints::is_consistent_in_parallel() and it returned 1. So, that 
> does not seem to be the issue. I found this problem with multiple processes 
> even with the step-45 example. Everything works fine when I have DBC instead 
> of PBC.
> 
> Thanks in advance, 
> 
> On Sun, Jul 4, 2021 at 1:44 AM 'peterrum' via deal.II User Group 
> mailto:dealii@googlegroups.com>> wrote:
> Dear Raghunandan,
> 
> I don't quite understand what you want to accomplish. You are setting PBC 
> constraint between the left and right face and after that you apply DBC on 
> the left face? Is that about right?
> 
> My first guess would be that you constraints are somewhere not globally 
> consistent. Maybe you could try to check them with 
> AffineConstraints::is_consistent_in_parallel(). There is also the function 
> AffineConstraints::make_consistent_in_parallel(), which might also help. 
> Latter is quite a new function so we might have missed some corner cases.
> 
> Hope this helps,
> PM
> 
> On Sunday, 4 July 2021 at 03:36:28 UTC+2 r...@iastate.edu 
>  wrote:
> Hello team,
> 
> I am running a 3D simulation with periodicity in all 3 directions.
> I have defined the periodic boundary conditions using (similarly in the other 
> 2 directions) - 
> DoFTools::make_periodicity_constraints(dof_handler,
> /*b_id*/ 0,
> /*b_id*/ 1,
> /*direction*/ 0,
> constraints);
> and the deformation of the box using - 
> IndexSet selected_dofs_x;
>std::set< types::boundary_id > boundary_ids_x= 
> std::set();
>boundary_ids_x.insert(0);
> 
>DoFTools::extract_boundary_dofs(dof_handler,
>   fe.component_mask(y_displacement),
>selected_dofs_x,
>boundary_ids_x);
>unsigned int nb_dofs_face_x = selected_dofs_x.n_elements();
>IndexSet::ElementIterator dofs_x = selected_dofs_x.begin();
> 
>double relative_displacement_x = 0.0;
> 
>if(timestep<=020)
> relative_displacement_x = 5e-4;
>else if(timestep%02==0)
> relative_displacement_x = 2e-4;
>else
> relative_displacement_x = 0.0;
> 
>for(unsigned int i = 0; i < nb_dofs_face_x; i++)
>{
> constraints.add_line (*dofs_x);
>  constraints.set_inhomogeneity(*dofs_x, (apply_dirichlet_bc ? 
> relative_displacement_x : 0.0));
>dofs_x++;
>}
> This works fine when run using a single process. But when increased to 2 
> processes, it pauses after few time steps without any error message. When 
> used more than 2 processes, it does not converge in the first time step 
> itself. I am not sure what is causing the problem.
> 
> I also tested it with step-45. It works fine with 1 and 2 processes. But when 
> 4 processes are used, it gives out the following error:
> [100%] Built target step-45
> Refinement cycle 0
>Assembling...
>Computing preconditioner...
>Solving...
> 
> 
> Exception on processing:
> 
> 
> 
> Exception on processing:
> 
> 
> An error occurred in line <457> of file 
>  in function
> void dealii::SolverCG::solve(const MatrixType&, VectorType&, 
> const VectorType&, const PreconditionerType&) [with MatrixType = 
> Step45::SchurComplement; 
> PreconditionerType 

Re: [deal.II] Questions on Step-18

[Jean-Paul Pelteret]

HI Michael,

I’m not the original author of step-18, but I think that I’ve found some 
sources that can explain both the construction of the non-normalised rotation 
axis w and the angle θ calculation.

1. Axial vector ω (the non-normalised axis of rotation)

For this, I’m summarising the salient parts of the references that I list 
later; specifically for following equations: 

Chadwick1998a: p 29 eq. 71, the paragraph on p79 between equations 46 and 47
Holzapfel2007a: p 17 eq. 1.118, p 18 eq. 1.124, p 49 eq. 1.276

The axial vector w is related to some skew symmetric tensor W in the following 
manner:
W.u = ω x u  for any vector u.

It can then be shown that
ω = -1/2[ ε_{ijk} W_{ij} e_{k}  ]
   = 1/2 curl(u)

So how this factor comes into the calculation would be most easily understood 
by introducing an intermediate quantity,

const Point<3> curl = …;
const Tensor<1,3> axial_vector = 0.5*curl;
const double tan_angle = std::sqrt(axial_vector * axial_vector);
const double angle = std::atan(tan_angle);

With some generalisation, this should hold in 2-d and 3-d (and addresses your 
one observation, that I comment on again in the next section).


@Book{Chadwick1998a,
  title = {Continuum Mechanics: Concise Theory and Problems},
  publisher = {Dover Publications Inc.},
  year  = {1998},
  author= {Chadwick, P.},
  address   = {Mineola, New York, USA},
  edition   = {2$^{\text{nd}}$},
  isbn  = {9780486401805},
  owner = {Jean-Paul Pelteret},
  timestamp = {2016.01.20},
}

@Book{Holzapfel2007a,
  title = {Nonlinear Solid Mechanics: A Continuum Approach for Engineering},
  publisher = {John Wiley \& Sons Ltd.},
  year  = {2007},
  author= {Holzapfel, G. A.},
  address   = {West Sussex, England},
  isbn  = {0-471-82304-X},
  file  = {Holzapfel2007a.pdf:References/Books/Holzapfel2007a.pdf:PDF},
  owner     = {Jean-Paul Pelteret},
  timestamp = {2014.09.26},
}


2. Angle from ω

For the angle itself, I defer to this wikipedia entry. 
https://en.wikipedia.org/wiki/Rotation_matrix#Axis_and_angle 
<https://en.wikipedia.org/wiki/Rotation_matrix#Axis_and_angle>
There you can see that the rotation angle θ is the arctangent of the norm of 
the non-normalised axis magnitude, |ω|.

As for why there is the inverse trigonometric operation involved, this can be 
understood most easily by thinking about the units involved. The norm |ω| is 
dimensionless, and we’re needing an angle in radians — an inverse trigonometric 
function does this conversion. As to why its the arctan and not something else… 
maybe some of the references on that page have a proof for the formula that 
would then provide that insight.
> Moreover, for 2D, do we need to do the same as 3D   tan_angle = 
> std::sqrt(curl * curl)? I mean we first calculate the magnitude of the curl 
> then calculate the angle. I’m concerned about the sign of the curl in 2D 
> angle = std::atan(curl) (we need the magnitude of the curl).
> 

I think that your observation in 2-d is correct. According to the wikipedia 
entry, one should likely always use the magnitude of the curl. I also think 
that the where the rotation matrix is returned via the call to   
Rotations::rotation_matrix_<2,3>d(axis, -angle);   
, we should be passing in the angle and not its negation. The axial vector ω 
supposedly encodes both the axis direction and “sign" of the rotation angle, 
and should be treated as a pair. That reference says that one should construct 
the rotation matrix from either (ω, θ) or (-ω, -θ), which would ultimately lead 
to the same result.

Thanks for being inquisitive and for asking all of these questions. It looks 
like its lead to a better understanding (which we now use to improve the 
documentation of the tutorial), and might have uncovered a couple of bugs!

Best,
Jean-Paul


> On 3. Jul 2021, at 02:56, Michael Lee  wrote:
> 
> Hi Jean-Paul and All,
> 
>  
> I would like to discuss the formulas in step-18 further. 
> 
>  
> 
> In the code, the angles are computed as follows.
> 
> For 2D, 
> 
> const double curl = (grad_u[1][0] - grad_u[0][1]);
> 
> const double angle = std::atan(curl);
> 
>  
> For 3D,
> 
> const double tan_angle = std::sqrt(curl * curl);
> 
> const double angle = std::atan(tan_angle);
> 
>  
> I don’t really understand why we need to do the atan operation to get the 
> angle. It seems to me that half of the curl of displacement itself is the 
> rotation angle. 
> 
> 
> 
> Moreover, for 2D, do we need to do the same as 3D   tan_angle = 
> std::sqrt(curl * curl)? I mean we first calculate the magnitude of the curl 
> then calculate the angle. I’m concerned about the sign of the curl in 2D 
> angle = std::atan(curl) (we need the magnitude of the curl).
> 
>  
> I wonder what references I can get from these formulas. I hope I can b

Re: [deal.II] Parallelizing a code with Linear Operators and Packaged Operations

[Jean-Paul Pelteret]

Hi Kubra,

Someone asked a similar question just a few day ago, so I have some information 
pre-prepared for you. 

LinearOperators do support Trilinos linear algebra classes, but there is no 
implementation for PETSc yet. The documentation is lacking a little bit in 
explaining how to use the parallelised version of LinearOperators, but I’d 
recorded this deficiency in this issue, along with a couple of examples. 
https://github.com/dealii/dealii/issues/12466 

The key points are 
1. the use of the template parameter, e.g. 
linear_operator(…), and,
2. the need for exemplars when wrapping preconditioners in LinearOperators.

As for PETSc support, if this is something that you’d be interested in adding 
to the library, then we’d very much appreciate the contribution and would be 
happy to help you along the way.

Best,
Jean-Paul


> On 30. Jun 2021, at 00:12, Kubra Karayagiz (Alumni) 
>  wrote:
> 
> Hello all,
> 
> I have a code in which I extensively use linear operators and packaged 
> operations to make matrix inverses and solve the system of equations. I am 
> wondering if such a code would be parallelized via PETSc and MPI, or any 
> other way.
> 
> Thanks,
> Kubra
> 
> 
> 
> 
> 
> -- 
> 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/CANnYN%2B1j6VsMWVzBs1KO2K1LH0Pg88JdcZXZ07ivLYhkoMk71w%40mail.gmail.com
>  
> .

-- 
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/D6A62479-B51C-4A0C-B215-5EC1BE44DA6E%40gmail.com.

Re: Messaggio privato su: [deal.II] step-17: MPI parallelisation doesn't run (macOS Catalina)

[Jean-Paul Pelteret]

Hi Bob,

I’ve copied your message to me back onto the mailing list.

Yes, as you observed you need to use the terminal that opens when you run the 
deal.II application. I’m glad that you figured this out. When you run the app, 
it sets up the local environment (for that specific terminal instance) such 
that everything that your executable (compiled in the same terminal) requires 
is available to the loaded and used. Since these dependent libraries are, 
effectively, sandboxed inside the deal.II app, running your executable outside 
of its terminal means that those libraries are not available for use.

Best,
Jean-Paul

> On 27. Jun 2021, at 22:37, bob bill  wrote:
> 
> Dear Jean-Paul,
> 
> Yes, I installed deal.II with the prepacked image file .dmg for macOS, but I 
> used to compile my deal.II projects from command line, instead of using the 
> dealii terminal. I've just noticed that if I use the dealii terminal, and try 
> to run in parallel my dealii projects with mpirun, it works perfectly. 
> 
> If, instead, I use the usual command line, I got the error in my previous 
> message, but I don't see any "summary.log" or "detailed.log" file. 
> 
> Best,
> Bob
> 
> 
> Hi Bob,
> 
> I think that for anyone to be able to try to help diagnose the source of this 
> problem, they’d have to know the specifics about the way that you’ve 
> installed deal.II. Are you using the Mac package, or have you built deal.II 
> from source? If the latter, then can you please provide us with the build 
> logs (“summary.log" and “detailed.log")?
> 
> Best,
> Jean-Paul
> 
> 
>> On 26. Jun 2021, at 10:25, bob bill > > wrote:
>> 
> 
>> Hi everyone,
>> 
>> I'm learning how to parallelise dealii programs with MPI, and I've started 
>> with tutorial number 17. I have a macOS Catalina, 10.15.7 and if I query the 
>> version to the command line
>> > mpirun -version 
>> > mpirun (Open MPI) 4.1.1
>> 
>> I can compile with 
>> > make
>> and after I get the executable I type
>> > mpirun -np 4 ./step-17
>> 
>> Unfortunately, the I obtain the following error message. Does anyone know 
>> how to solve this? 
>> 
>> At least one pair of MPI processes are unable to reach each other for MPI 
>> communications.  This means that no Open MPI device has indicated that it 
>> can be used to communicate between these processes.  This is an error; Open 
>> MPI requires that all MPI processes be able to reach each other.  This error 
>> can sometimes be the result of forgetting to specify the "self" BTL.
>> 
>>   Process 1 ([[19907,1],1]) is on host: MacBook-Pro-of-Bob
>> 
>>   Process 2 ([[19907,1],0]) is on host: MacBook-Pro-of-Bob
>> 
>>   BTLs attempted: self tcp vader
>> 
>> 
>> 
>> Your MPI job is now going to abort; sorry.
>> 
>> 
>> 
>> MPI_INIT has failed because at least one MPI process is unreachable from 
>> another.  This *usually* means that an underlying communication plugin -- 
>> such as a BTL or an MTL -- has either not loaded or not allowed itself to be 
>> used.  Your MPI job will now abort.
>> 
>> You may wish to try to narrow down the problem;
>> 
>>  * Check the output of ompi_info to see which BTL/MTL plugins are  available.
>> 
>>  * Run your application with MPI_THREAD_SINGLE.
>> 
>>  * Set the MCA parameter btl_base_verbose to 100 (or mtl_base_verbose,   if 
>> using MTL-based communications) to see exactly which  communication plugins 
>> were considered and/or discarded.
>> 
>> 
>> 
>> Best regards,
>> 
>> Bob
>> 
>> 
> 
>> -- 
>> 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 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/dealii/6bcd4bd4-3af0-45f6-98de-5dd102d2fb6an%40googlegroups.com
>>  
>> .
> 

-- 
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/EC08BEEF-F6AB-4D46-8733-28EF7D68F32B%40gmail.com.

Re: [deal.II] Questions on Step-18

[Jean-Paul Pelteret]

Hi Michael,

What’s written in the implementation suggests that computing the curl of the 
displacement (increments) is the right thing to do in this instance:

> Nevertheless, if the material was prestressed in a certain direction, then 
> this direction will be rotated along with the material. To this end, we have 
> to define a rotation matrix R(Δun) that describes, in each point the rotation 
> due to the displacement increments. It is not hard to see that the actual 
> dependence of R on Δun can only be through the curl of the displacement, 
> rather than the displacement itself or its full gradient (as mentioned above, 
> the constant components of the increment describe translations, its 
> divergence the dilational modes, and the curl the rotational modes). 


I think that this is because the displacement field for solids is analogous to 
the velocity field for fluids, for which that equation in the Wiki link was 
expressly written (Compare incompressible linear elasticity to Stokes flow — 
the equations have the same form). Furthermore, having dug through my continuum 
mechanics notes, I now see that this specific rotation matrix is called the 
“infinitesimal rotation tensor 
<https://antoniobilotta-structuralengineer.github.io/MyWebSite/SMbook_en/infinitesimal_sec_strain_chap_en.html>”
 and is defined as the antisymmetric part of \grad u. Since step-18 is dealing 
with incremental updates, the incremental form of the rotation tensor is 
computed.

Sorry for the confusion. So, to my understanding it’s just the factor of 1/2 
that needs to be added.

Best,
Jean-Paul

> On 26. Jun 2021, at 16:14, Michael Lee  wrote:
> 
> I would be happy to do the comparison and make the fix. But before doing 
> that, I want to make sure I understand the formula correctly. 
> 
> When we calculate the rotation matrix, it seems that the du (incremental 
> displacement) is used.
>   // Then initialize the FEValues object on the present
>   // cell, and extract the gradients of the displacement at the
>   // quadrature points for later computation of the strains
>   fe_values.reinit(cell);
>   fe_values.get_function_gradients(incremental_displacement,
>displacement_increment_grads);
> 
> Should we use the velocity (), since  ?
> 
> Can you check this as well?
> 
> 
> Best,
> Michael
> 
> 
> 
> 
> 
> 
> On Sat, Jun 26, 2021 at 1:48 AM Jean-Paul Pelteret  <mailto:jppelte...@gmail.com>> wrote:
> Following Andrew’s explanation, I suppose that this is relation for which 
> we’re lacking the factor of 1/2, right?
> 
> https://en.wikipedia.org/wiki/Angular_velocity#Angular_velocity_as_a_vector_field
>  
> <https://en.wikipedia.org/wiki/Angular_velocity#Angular_velocity_as_a_vector_field>
> 
> If so, then maybe we should link to this equation in the tutorial 
> documentation too.
> 
>> If this is wrong in the deal.II code, would you be interested in writing a 
>> patch to correct this? It should be an easy fix, and a good first patch to 
>> contribute to the library!
> 
> I concur — it would be great if you’d be willing to write a patch that fixes 
> this! It would be interesting to see the effect on the results of the 
> tutorial.
> 
> Best,
> Jean-Paul
> 
> 
>> On 26. Jun 2021, at 05:58, Wolfgang Bangerth > <mailto:bange...@colostate.edu>> wrote:
>> 
>> On 6/24/21 6:32 PM, Michael Li wrote:
>>> Andrew, thanks for confirming that. The missing 1/2 does not affect the 
>>> demonstration of functionalities of deal.II but it may change the results.
>> 
>> If this is wrong in the deal.II code, would you be interested in writing a 
>> patch to correct this? It should be an easy fix, and a good first patch to 
>> contribute to the library!
>> 
>> If you're curious about ho to write a patch, take a look at
>>  https://github.com/dealii/dealii/wiki/Contributing 
>> <https://github.com/dealii/dealii/wiki/Contributing>
>> 
>> Best
>> W.
>> 
> 
> 
> On Sat, Jun 26, 2021 at 1:48 AM Jean-Paul Pelteret  <mailto:jppelte...@gmail.com>> wrote:
> Following Andrew’s explanation, I suppose that this is relation for which 
> we’re lacking the factor of 1/2, right?
> 
> https://en.wikipedia.org/wiki/Angular_velocity#Angular_velocity_as_a_vector_field
>  
> <https://en.wikipedia.org/wiki/Angular_velocity#Angular_velocity_as_a_vector_field>
> 
> If so, then maybe we should link to this equation in the tutorial 
> documentation too.
> 
>> If this is wrong in the deal.II code, would you be interested in writing a 
>> patch to correct this? It should be an easy fix, and a good 

Re: [deal.II] step-17: MPI parallelisation doesn't run (macOS Catalina)

[Jean-Paul Pelteret]

Hi Bob,

I think that for anyone to be able to try to help diagnose the source of this 
problem, they’d have to know the specifics about the way that you’ve installed 
deal.II. Are you using the Mac package, or have you built deal.II from source? 
If the latter, then can you please provide us with the build logs 
(“summary.log" and “detailed.log")?

Best,
Jean-Paul

> On 26. Jun 2021, at 10:25, bob bill  wrote:
> 
> Hi everyone,
> 
> I'm learning how to parallelise dealii programs with MPI, and I've started 
> with tutorial number 17. I have a macOS Catalina, 10.15.7 and if I query the 
> version to the command line
> > mpirun -version 
> > mpirun (Open MPI) 4.1.1
> 
> I can compile with 
> > make
> and after I get the executable I type
> > mpirun -np 4 ./step-17
> 
> Unfortunately, the I obtain the following error message. Does anyone know how 
> to solve this? 
> 
> At least one pair of MPI processes are unable to reach each other for MPI 
> communications.  This means that no Open MPI device has indicated that it can 
> be used to communicate between these processes.  This is an error; Open MPI 
> requires that all MPI processes be able to reach each other.  This error can 
> sometimes be the result of forgetting to specify the "self" BTL.
> 
>   Process 1 ([[19907,1],1]) is on host: MacBook-Pro-of-Bob
> 
>   Process 2 ([[19907,1],0]) is on host: MacBook-Pro-of-Bob
> 
>   BTLs attempted: self tcp vader
> 
> 
> 
> Your MPI job is now going to abort; sorry.
> 
> 
> 
> MPI_INIT has failed because at least one MPI process is unreachable from 
> another.  This *usually* means that an underlying communication plugin -- 
> such as a BTL or an MTL -- has either not loaded or not allowed itself to be 
> used.  Your MPI job will now abort.
> 
> You may wish to try to narrow down the problem;
> 
>  * Check the output of ompi_info to see which BTL/MTL plugins are  available.
> 
>  * Run your application with MPI_THREAD_SINGLE.
> 
>  * Set the MCA parameter btl_base_verbose to 100 (or mtl_base_verbose,   if 
> using MTL-based communications) to see exactly which  communication plugins 
> were considered and/or discarded.
> 
> 
> 
> Best regards,
> 
> Bob
> 
> 
> -- 
> 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/6bcd4bd4-3af0-45f6-98de-5dd102d2fb6an%40googlegroups.com
>  
> .

-- 
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/61DAACE9-236D-4A3B-8AB5-125398E6C29E%40gmail.com.

Re: [deal.II] Questions on Step-18

[Jean-Paul Pelteret]

Following Andrew’s explanation, I suppose that this is relation for which we’re 
lacking the factor of 1/2, right?

https://en.wikipedia.org/wiki/Angular_velocity#Angular_velocity_as_a_vector_field
 


If so, then maybe we should link to this equation in the tutorial documentation 
too.

> If this is wrong in the deal.II code, would you be interested in writing a 
> patch to correct this? It should be an easy fix, and a good first patch to 
> contribute to the library!

I concur — it would be great if you’d be willing to write a patch that fixes 
this! It would be interesting to see the effect on the results of the tutorial.

Best,
Jean-Paul


> On 26. Jun 2021, at 05:58, Wolfgang Bangerth  wrote:
> 
> On 6/24/21 6:32 PM, Michael Li wrote:
>> Andrew, thanks for confirming that. The missing 1/2 does not affect the 
>> demonstration of functionalities of deal.II but it may change the results.
> 
> If this is wrong in the deal.II code, would you be interested in writing a 
> patch to correct this? It should be an easy fix, and a good first patch to 
> contribute to the library!
> 
> If you're curious about ho to write a patch, take a look at
>  https://github.com/dealii/dealii/wiki/Contributing
> 
> 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/32840123-c6f5-abd9-18bb-03f06b5f918e%40colostate.edu.

-- 
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/1D258AD6-FC4C-43B7-9056-A4B21114D694%40gmail.com.

Re: [deal.II] Questions on Step-18

[Jean-Paul Pelteret]

he second point nicely. On the first point, I think 
> there is a 1/2 missing. The curl of the velocity gradient is the vorticity 
> which is twice the angular velocity - hence I think you need a 1/2. Happy to 
> be corrected on this.
>  
> Best,
> Andrew
> 
> 
> On 24 Jun 2021, at 21:03, Jean-Paul Pelteret  <mailto:jppelte...@gmail.com>> wrote:
>  
> Hi Michael,
>  
> I cannot comment on the first question, but might be able to assist a bit 
> with the second. But may I first ask, what precisely are you trying to 
> achieve with this extension? 
>  
> As interesting as it is, in the past I had found step-18 to deviate too 
> significantly from the “classical” approach to elasticity to be a natural 
> candidate extend towards finite strain elasticity, for example (this is 
> kind-of implied by the caveat that you partially quoted). I’ve been looking 
> at some of my textbooks (e.g. reviewing the topic of the updated Lagrangian 
> formulation in Holzapfel’s “Nonlinear solid mechanics” and Wrigger’s 
> “Nonlinear finite element methods”) to try to answer (2), but cannot 
> trivially reconcile the two approaches. I think that there’s a bit too much 
> going on to be able to correctly deduce by eye what the requisite changes 
> are. I think that you’d need to reformulate the balance laws and consider 
> their implications for the implemented weak forms — in particular, I think 
> that you’d be missing a contribution that (for finite deformation) looks like 
> the geometric stiffness, but there could be further differences that extend 
> from the overall approach taken to the problem. 
>  
> If you’re interested in an examples that are more closely aligned with what 
> you might see in the literature, then you can take a look at step-44 
> <https://www.dealii.org/current/doxygen/deal.II/step_44.html> or the 
> “Quasi-Static Finite-Strain Compressible Elasticity 
> <https://dealii.org/current/doxygen/deal.II/code_gallery_Quasi_static_Finite_strain_Compressible_Elasticity.html>”
>  code-gallery example, which is effectively step-44 reduced to the one-field 
> total Lagrangian formulation that you’d find in many standard textbooks. It 
> would be easy enough to rework this to use the updated Lagrangian approach, 
> if that it what you desire.
>  
> I hope that this helps you a little.
>  
> Best,
> Jean-Paul
>  
> 
> 
> On 22. Jun 2021, at 15:24, Michael Lee  <mailto:lianxi...@gmail.com>> wrote:
>  
> Hello,
> I have two questions when studying Step-18. 
>  
> 1) Should there be a factor 1/2 when calculating the rotation matrix angle 
> (code in tutorial: angle 
> <https://www.dealii.org/current/doxygen/deal.II/grid__tools__nontemplates_8cc.html#a1b9d6e95246f7a6b7ecc7430631dd0b6>
>  = std::atan 
> <https://www.dealii.org/current/doxygen/deal.II/namespaceDifferentiation_1_1SD.html#a803fcea270d7a523a91e3b7c173059f9>(curl)
>  ) ? This is a mathematical problem. Can anyone give some material for the 
> formula to clear out my doubt?
>  
> 2) In the introduction, it says "we will consider a model in which we produce 
> a small deformation, deform the physical coordinates of the body by this 
> deformation, and then consider the next loading step again as a linear 
> problem. This isn't consistent, since the assumption of linearity implies 
> that deformations are infinitesimal and so moving around the vertices of our 
> mesh by a finite amount before solving the next linear problem is an 
> inconsistent approach." My question is how to make it consistent. Can I just 
> add the nonlinear part of the strain tensor like the following (of course in 
> both get_strain functions)? I just want to consider the geometrical 
> nonlinearity.
>  
>   template 
>   inline SymmetricTensor<2, dim>
>   get_strain(const std::vector> )
>   {
> Assert(grad.size() == dim, ExcInternalError());
>  
> SymmetricTensor<2, dim> strain;
> for (unsigned int i = 0; i < dim; ++i)
>   strain[i][i] = grad[i][i];
>  
> for (unsigned int i = 0; i < dim; ++i)
>   for (unsigned int j = i + 1; j < dim; ++j)
> strain[i][j] = (grad[i][j] + grad[j][i] +   // linear part
>   grad[i][0] * grad[j][0] +//nonlinear part
>   grad[i][1] * grad[j][1] +   
>   grad[i][2] * grad[j][2]) / 2;
>  
> return strain;
>   }
>  
> Thanks,
> Michael
>  
> -- 
> The deal.II project is located at http://www.dealii.org/ 
> <http://www.dealii.org/>
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en 
> <https://groups.google.com/d/f

Re: [deal.II] Deal.II compilation error issued at example steps phase

[Jean-Paul Pelteret]

Dear Saad,

Well, after briefly browsing the Ginkgo repository online, its a bit of a 
mystery to me. The mask looks to be declared by this call 

 to this piece of macro 

 magic, and is defined here 
.
 Maybe your compiler doesn’t like the way that these static constexpr variables 
are defined (a vaguely recall experiencing such a problem when writing this bit 
of code 
).

Is it a prerequisite that you use the Ginkgo library? Can you perhaps compile 
deal.II without it enabled? If you are wanting to use Ginkgo, then does that 
library provide some benchmarks or tests that you can use to validate that it’s 
built correctly and works as expected?

Best,
Jean-Paul

> On 23. Jun 2021, at 16:59, Debbahi Saad  wrote:
> 
> Dear Deal.ii community,
> 
> I'm trying to compile the Deal.II (9.2.0, 9.3.0 or dev branch) with 
> examples enabled, the compilation goes well until it reaches the example 
> phase, for example step-9 in version dev branch breaks the compilation with 
> an error
> ../../lib/libdeal_II.g.so.10.0.0-pre: error: undefined reference to 
> 'gko::log::Logger::criterion_check_completed_mask'
> it is worth mentioning that the same error arises when I was compiling 
> version 9.2.0.
> 
> of course disabling the examples -DDEAL_II_WITH_EXAMPLES=OFF byoasses the 
> issue and the compilation carries on well.
> 
> I have compiled Ginkgo dev branch then version 1.3.0 down to version 1.0.0 
> but inspecting the generated shared libraries for every ginkgo version with 
> nm utility shows no symbols corresponding to  criterion_check_completed_mask:
> 
> nm --dynamic --print-file-name /path/ginkgo/lib/libgimkgo*|grep -i 
> criterion_check_completed_mask
> 
> Any help to figure this out would be really appreciated.
> 
> Thank you in advance,
> 
> Kind regards,
> 
> Saad
> 
> 
> System: Centos 6.10 final x86_64
> cmake : version 3.20.4
> GNU compiler : version 9.3.1
>   
>   
> 
> -- 
> 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/CAGb1Yyx21co8w5X04bfWYxpsbspbNPL%2BQWo1htLMzYDseUBULQ%40mail.gmail.com
>  
> .

-- 
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/31941ABA-292D-4F99-83EA-63142888DD8F%40gmail.com.

Re: [deal.II] Marking Boundary Nodes in Triangulation

[Jean-Paul Pelteret]

Hi Chen,

Is the DoFTools::extract_boundary_dofs() 

 function perhaps what you’re looking for?

Best,
Jean-Paul

> On 23. Jun 2021, at 10:08, Chen R  wrote:
> 
> Hi all,
> 
> So I am trying to use dealii together with our own geometric modeling 
> environment to do different FE calculations on.
> 
> I am transferring our geometry into the Triangulation object based on the way 
> that the read_msh function does.
> 
> The problem is that I want to keep track of boundary nodes so as later, after 
> calculating some solution to a problem (for example an elasticity problem on 
> the object) I want to only show graphically the changes on the boundaries of 
> the geometry as, for example through some color map, those are the only parts 
> of the geometry that are shown. 
> 
> I know the Triangulation object has some property of boundary IDs that can be 
> used but how exactly to use it I'm not sure?
> 
> Thank you,
> Chen
> 
> -- 
> 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/082fc358-393f-4bee-bd66-13bcd5548326n%40googlegroups.com
>  
> .

-- 
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/A8D76801-B46F-42F9-8421-CF57C4269769%40gmail.com.

Re: [deal.II] Different get_function_gradients

[Jean-Paul Pelteret]

Hi Michael,
> Does the (1) do all the work that the last two do? I.e., (1) gives the whole 
> chunk of gradient, and the last two extract the scalar and vector parts from 
> the chunk, respectively.
> 
They are very closely related. (1) has no knowledge on the nature of the 
field(s) for which the gradient is being computed, so it just returns the 
gradient of all individual components of the solution field at once, and it's 
up to you to interpret that however you need. For (2) and (3), one is 
interpreting the solution field (or a subset of its components) to have a 
certain nature, and so more context can be given to the gradients that are 
returned. In particular, the gradient of a scalar field is a rank-1 tensor, and 
the gradient of a vector field would be a rank-2 tensor. So the return types 
are in fact different, but essentially encode the some/all information that is 
given by (1). 

Does that make sense?

The great thing about using the FEValuesExtractors/FEValuesViews concept is 
that you are able to achieve a near 1-1 match of the written and programmed 
weak form, which makes implementing things a lot easier. So in most of the more 
recent tutorials we use them, and I’d say that more often than not we’d 
advocate their use.

Best,
Jean-Paul

> On 24. Jun 2021, at 18:20, Michael Lee  wrote:
> 
> After reading the documentation on Handling vector valued problems (The 
> deal.II Library: Handling vector valued problems (dealii.org) 
> ), 
> I have the following question.
> 
> What are the differences between the three functions?
> 
> (1) FEValuesBase::get_function_gradients 
> 
>  
> 
> (2) FEValuesViews::Scalar::get_function_gradients 
> 
>  
> 
> (3) FEValuesViews::Vector::get_function_gradients 
> 
>  
> 
> 
> 
> Does the (1) do all the work that the last two do? I.e., (1) gives the whole 
> chunk of gradient, and the last two extract the scalar and vector parts from 
> the chunk, respectively.
> 
> 
> 
> 
> -- 
> 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/89ec12a9-9553-4ee2-9bf0-8900517587c3n%40googlegroups.com
>  
> .

-- 
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/97AA7B43-5CF1-4ECE-9238-272250916C76%40gmail.com.

Re: [deal.II] Questions on Step-18

[Jean-Paul Pelteret]

Hi Michael,

I cannot comment on the first question, but might be able to assist a bit with 
the second. But may I first ask, what precisely are you trying to achieve with 
this extension? 

As interesting as it is, in the past I had found step-18 to deviate too 
significantly from the “classical” approach to elasticity to be a natural 
candidate extend towards finite strain elasticity, for example (this is kind-of 
implied by the caveat that you partially quoted). I’ve been looking at some of 
my textbooks (e.g. reviewing the topic of the updated Lagrangian formulation in 
Holzapfel’s “Nonlinear solid mechanics” and Wrigger’s “Nonlinear finite element 
methods”) to try to answer (2), but cannot trivially reconcile the two 
approaches. I think that there’s a bit too much going on to be able to 
correctly deduce by eye what the requisite changes are. I think that you’d need 
to reformulate the balance laws and consider their implications for the 
implemented weak forms — in particular, I think that you’d be missing a 
contribution that (for finite deformation) looks like the geometric stiffness, 
but there could be further differences that extend from the overall approach 
taken to the problem. 

If you’re interested in an examples that are more closely aligned with what you 
might see in the literature, then you can take a look at step-44 
 or the 
“Quasi-Static Finite-Strain Compressible Elasticity 
”
 code-gallery example, which is effectively step-44 reduced to the one-field 
total Lagrangian formulation that you’d find in many standard textbooks. It 
would be easy enough to rework this to use the updated Lagrangian approach, if 
that it what you desire.

I hope that this helps you a little.

Best,
Jean-Paul


> On 22. Jun 2021, at 15:24, Michael Lee  wrote:
> 
> Hello,
> I have two questions when studying Step-18. 
> 
> 1) Should there be a factor 1/2 when calculating the rotation matrix angle 
> (code in tutorial: angle 
> 
>  = std::atan 
> (curl)
>  ) ? This is a mathematical problem. Can anyone give some material for the 
> formula to clear out my doubt?
> 
> 2) In the introduction, it says "we will consider a model in which we produce 
> a small deformation, deform the physical coordinates of the body by this 
> deformation, and then consider the next loading step again as a linear 
> problem. This isn't consistent, since the assumption of linearity implies 
> that deformations are infinitesimal and so moving around the vertices of our 
> mesh by a finite amount before solving the next linear problem is an 
> inconsistent approach." My question is how to make it consistent. Can I just 
> add the nonlinear part of the strain tensor like the following (of course in 
> both get_strain functions)? I just want to consider the geometrical 
> nonlinearity.
> 
>   template 
>   inline SymmetricTensor<2, dim>
>   get_strain(const std::vector> )
>   {
> Assert(grad.size() == dim, ExcInternalError());
> 
> SymmetricTensor<2, dim> strain;
> for (unsigned int i = 0; i < dim; ++i)
>   strain[i][i] = grad[i][i];
> 
> for (unsigned int i = 0; i < dim; ++i)
>   for (unsigned int j = i + 1; j < dim; ++j)
> strain[i][j] = (grad[i][j] + grad[j][i] +   // linear part
>   grad[i][0] * grad[j][0] +//nonlinear part
>   grad[i][1] * grad[j][1] +   
>   grad[i][2] * grad[j][2]) / 2;
> 
> return strain;
>   }
> 
> Thanks,
> Michael
> 
> -- 
> 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/02f465df-3cab-4d84-bd48-92ca4a7981efn%40googlegroups.com
>  
> .

-- 
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 

Re: [deal.II] Question about deal.II flexibility

[Jean-Paul Pelteret]

Dear Abdelrahman,

To add to some further details to what Konrad has already provided:
- the step-44 tutorial 
 implements one of 
many incompressible elasticity formulations. There is also the Quasi-Static 
Finite-Strain Quasi-incompressible Visco-elasticity 

 code gallery example that implements a linear viscoelastic model in 
combination with near-incompressible material behaviour.
- the Quasi-Static Finite-Strain Compressible Elasticity 

 code gallery example implements a more traditional finite strain elasticity 
formulation, which could also be a basis for extension to other 
incompressibility formulations.
- the (new) step-71 tutorial 
 introduces some 
useful techniques that can be applied to modelling complex constitutive laws. 
As a part of this tutorial, a magneto-viscoelastic constitutive law is 
implemented and verified.

If you have a look at the “Applications” tab on the top of the home page 
(https://www.dealii.org/ ), then you can see some of 
the libraries that are built on top of deal.II — some of these include some 
interesting and challenging constitutive laws. You can also look to those for 
inspiration on how to implement your constitutive laws within a finite element 
framework.

Best,
Jean-Paul

> On 19. Jun 2021, at 23:38, Konrad Simon  wrote:
> 
> Dear Abdo,
> 
> I do think that Deal.II can help you with solving your problem. If you are 
> just starting with Deal.II have a look at the tutorials 
> . It is always a 
> good idea to start with some code basis that other people have shared and 
> that was thoroughly tested. As to your future problem, please have a look at 
> the code gallery 
>  as well. 
> There are codes that other users shared dealing with visco-plastic materials, 
> in particular (but not only Jean-Paul).
> 
> Cheers,
> Konrad
> 
> On Saturday, June 19, 2021 at 10:23:37 PM UTC+2 aael...@ncsu.edu 
>  wrote:
> Hi
> I am Abdo, Ph.D. student at NC state university and was looking for a FE 
> package library that is flexible and can be used in modeling and analyzing 2D 
> and 3D elastic wave equation propagation within an incompressible medium. 
> Also, at some point, I might need to add the viscoelastic behavior to the 
> model. So, I am not sure if deal.II is flexible enough to add, modify some 
> feature in it or not such that I can do what I have mentioned earlier. So, 
> Can you please give me some pointers or advice regarding this?, your help is 
> much appreciated.
> 
> Best regards.
> Abdo.
> 
> -- 
> 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/481afb9d-fa92-4eae-b369-0881cbd7d70fn%40googlegroups.com
>  
> .

-- 
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/92CDFB6E-B2A6-4124-8E40-D44EBF64CB60%40gmail.com.

Re: [deal.II] Linear operators - TrilinosWrappers

[Jean-Paul Pelteret]

Dear Felipe,

Changing this
const auto op_pre = linear_operator(prec_M);
to this
const auto op_pre = linear_operator(M, prec_M);
allowed your program "FEMDG-Dar-par_tofix" to compile for me. If you have a 
look at this documentation for this variant of linear_operator
https://dealii.org/current/doxygen/deal.II/group__LAOperators.html#ga14dbc8c2c27ea3fd45576528a891c6e2
 
<https://dealii.org/current/doxygen/deal.II/group__LAOperators.html#ga14dbc8c2c27ea3fd45576528a891c6e2>
you'll see that it specifically mentions its use to encapsulate preconditioners 
— this is what I was referring to in my previous message. It’s not a 
particularly easy problem to diagnose, so I’ll give some thought on what (if 
anything) we can do to programatically improve this situation on our side. In 
the mean time, I've added a note to the GitHub issue to detail this further.

(BTW. You also probably want to change this
const auto op_M  = linear_operator(M, prec_M);
to this
const auto op_M = linear_operator(system_matrix.block(0, 0));
if you are to use it, as op_M then acts like a preconditioner for M, which I 
don’t think is what you want.)

I didn’t try to run the code after checking that it compiled, but I hope that 
this now sorts things out for you. If not, just let us know.

Best,
Jean-Paul

> On 16. Jun 2021, at 12:19, Juan Felipe Giraldo  wrote:
> 
> Dear Jean-Paul,
> 
> Thank you for your reply,
> 
> I already set up the Identity preconditioner with a block matrix, but the 
> problem remains the same. I am not sure this is the problem because I didn't 
> need to set up the identity operator to any matrix in the scenario where I 
> could invert. I think my problem is in the Schur preconditioner operator 
> before to invert.
> I attach the problematic code and the "working code" I am coding. The only 
> difference between them is the line 1251:
> 
> (const auto op_S_inv = inverse_operator(opa_S, solver_S, preconditioner_S ); 
> //(problematic case)
> (const auto op_S_inv = inverse_operator(op_S, solver_S, preconditioner_S );  
> //(Case I could invert)
> 
> (Please excuse me for the extension of the code, but the solver function 
> where I have the issue is too short. In the case you consider it necessary, I 
> could code a shorter one)
> 
> Thank you so much,
> 
> Regards,
> Felipe
> 
> 
> 
> El miércoles, 16 de junio de 2021 a las 15:45:27 UTC+8, Jean-Paul Pelteret 
> escribió:
> Dear Felipe,
> 
> It might be that you need to set up the preconditioner operator with an 
> exemplar matrix (since the identity operator doesn't know the size of the 
> range and domain that it's working on).
> 
> If that's not the issue then could you please try to reproduce this as a 
> minimal example and share it with us? The program doesn't need to produce any 
> meaningful result, but it would be good if it shows both the working scenario 
> and the problematic one. That way we could investigate further and try to 
> figure out what's going wrong here. 
> 
> Best,
> Jean-Paul
> 
> Sent from my mobile device. Please excuse my brevity and any typos.
> 
> On Wed, 16 Jun 2021, 08:50 Juan Felipe Giraldo,  > wrote:
> Dear Jean-Paul,
> 
> Thank you for your reply and the complete information you provide me. 
> Effectively, declaring the preconditioner (out-of-line) was one problem, but 
> the inverse_operator function is still not matching. 
> 
> What I just realized is that when I compute the operator as a multiplication 
> of a linear operator, an inverse operator and a linear operator ( for 
> instance, when I compute the Schur complement )
> 
> const auto op_S = op_BT * op_M_inv * op_B;
> 
> this operator becomes to the type 
> 'dealii::TrilinosWrappers::internal::LinearOperatorImplementation::TrilinosPayload'
>  ,
> 
> but when I compute the operator as a multiplication of other linear operators 
> directly (for instance, when I compute the Schur preconditioner, following 
> the procedure in step 20 )
> 
> const auto op_pre = linear_operator(prec_M);
> const auto op_aS = op_BT * op_pre * op_B;
> 
> this operator becomes to the type 
> 'dealii::internal::LinearOperatorImplementation::EmptyPayload&'.
> 
> So, If I use the inverse_operator function with the first operator (op_S), I 
> can obtain the inverse without any problem,
> (const auto op_S_inv = inverse_operator(op_S, solver_S, preconditioner_S );
> 
> But if I do it with the second case, it doesn't work because the functions 
> are not matching. 
> (const auto op_S_inv = inverse_operator(opa_S, solver_S, preconditioner_S );
> 
> I am not sure what is happening because all the operators are declared as  
> "LA::MPI::Vector".
> If you have any suggestion, would be greatly appreciated. 

Re: [deal.II] Linear operators - TrilinosWrappers

[Jean-Paul Pelteret]

Dear Felipe,

It might be that you need to set up the preconditioner operator with an
exemplar matrix (since the identity operator doesn't know the size of the
range and domain that it's working on).

If that's not the issue then could you please try to reproduce this as a
minimal example and share it with us? The program doesn't need to produce
any meaningful result, but it would be good if it shows both the working
scenario and the problematic one. That way we could investigate further and
try to figure out what's going wrong here.

Best,
Jean-Paul

Sent from my mobile device. Please excuse my brevity and any typos.

On Wed, 16 Jun 2021, 08:50 Juan Felipe Giraldo, 
wrote:

> Dear Jean-Paul,
>
> Thank you for your reply and the complete information you provide me.
> Effectively, declaring the preconditioner (out-of-line) was one problem,
> but the inverse_operator function is still not matching.
>
> What I just realized is that when I compute the operator as a
> multiplication of a linear operator, an inverse operator and a linear
> operator ( for instance, when I compute the Schur complement )
>
> const auto op_S = op_BT * op_M_inv * op_B;
>
> this operator becomes to the type
> 'dealii::TrilinosWrappers::internal::LinearOperatorImplementation::TrilinosPayload'
> ,
>
> but when I compute the operator as a multiplication of other linear
> operators directly (for instance, when I compute the Schur preconditioner,
> following the procedure in step 20 )
>
> const auto op_pre = linear_operator(prec_M);
> const auto op_aS = op_BT * op_pre * op_B;
>
> this operator becomes to the type
> 'dealii::internal::LinearOperatorImplementation::EmptyPayload&'.
>
> So, If I use the inverse_operator function with the first operator (op_S),
> I can obtain the inverse without any problem,
> (const auto op_S_inv = inverse_operator(op_S, solver_S, preconditioner_S );
>
> But if I do it with the second case, it doesn't work because the functions
> are not matching.
> (const auto op_S_inv = inverse_operator(opa_S, solver_S, preconditioner_S
> );
>
> I am not sure what is happening because all the operators are declared as
> "LA::MPI::Vector".
> If you have any suggestion, would be greatly appreciated.
>
> Thank you so much,
>
> Regards,
> Felipe Giraldo
>
>
>
> El martes, 15 de junio de 2021 a las 19:16:54 UTC+8, Jean-Paul Pelteret
> escribió:
>
>> Hi again Feilpe,
>>
>> Regarding the lack of documentation, I’ve opened an issue on Github to
>> track this. You can find that here:
>> https://github.com/dealii/dealii/issues/12466
>>
>> Best,
>> Jean-Paul
>>
>> On 15. Jun 2021, at 12:57, Jean-Paul Pelteret  wrote:
>>
>> Hi Feilpe,
>>
>> Firstly, I agree that the documentation is very light on details on how
>> to use the linear operators with Trilinos linear algebra types. We can
>> definitely improve this, and any contributions to that effect would be
>> greatly appreciated!
>>
>> Right now, I can direct you to a few of the tests that use Trilinos LA in
>> conjunction with the inverse operator, so that you can compare what you
>> have and figure out what the problematic differences are. There is this
>> one, for instance
>>
>> https://github.com/dealii/dealii/blob/master/tests/lac/linear_operator_12a.cc#L323-L341
>> that looks like a similar setup to yours, and
>>
>> https://github.com/dealii/dealii/blob/master/tests/lac/schur_complement_04.cc#L126-L137
>> that uses a Trilinos::SolverCG (as opposed to deal.II’s solver).
>>
>> Comparing to both of these, I think that the important point might be
>> that the preconditioner must be declared (out-of-line) before the
>> inverse_operation() function is called. The linear operators typically
>> expect the lifetime of the LA objects to exceed that of the operators, and
>> so you have to first create the matrix or preconditioner and then pass it
>> to the linear operators. This is similar to what you’d done when setting up 
>> op_M,
>> for example. The case of passing in a deal::PreconditionerIdentity() for
>> serial operations is a special case, and I don’t think that we’ve
>> duplicated that for TrilinosWrappers:: PreconditionerIdentity(). Maybe
>> that could be improved too.
>>
>> I hope that with this single change you’d be able to get your
>> program running. If not, then please do let us know so that we can try to
>> help further.
>>
>> Best,
>> Jean-Paul
>>
>>
>> On 14. Jun 2021, at 19:18, Juan Felipe Giraldo 
>> wrote:
>>
>> Hello everyone,
>>
>> I have implemented a residual-minimization framework 

Re: [deal.II] Linear operators - TrilinosWrappers

[Jean-Paul Pelteret]

Hi again Feilpe,

Regarding the lack of documentation, I’ve opened an issue on Github to track 
this. You can find that here: https://github.com/dealii/dealii/issues/12466 
<https://github.com/dealii/dealii/issues/12466>

Best,
Jean-Paul

> On 15. Jun 2021, at 12:57, Jean-Paul Pelteret  wrote:
> 
> Hi Feilpe,
> 
> Firstly, I agree that the documentation is very light on details on how to 
> use the linear operators with Trilinos linear algebra types. We can 
> definitely improve this, and any contributions to that effect would be 
> greatly appreciated!
> 
> Right now, I can direct you to a few of the tests that use Trilinos LA in 
> conjunction with the inverse operator, so that you can compare what you have 
> and figure out what the problematic differences are. There is this one, for 
> instance
> https://github.com/dealii/dealii/blob/master/tests/lac/linear_operator_12a.cc#L323-L341
>  
> <https://github.com/dealii/dealii/blob/master/tests/lac/linear_operator_12a.cc#L323-L341>
> that looks like a similar setup to yours, and
> https://github.com/dealii/dealii/blob/master/tests/lac/schur_complement_04.cc#L126-L137
>  
> <https://github.com/dealii/dealii/blob/master/tests/lac/schur_complement_04.cc#L126-L137>
> that uses a Trilinos::SolverCG (as opposed to deal.II’s solver).
> 
> Comparing to both of these, I think that the important point might be that 
> the preconditioner must be declared (out-of-line) before the 
> inverse_operation() function is called. The linear operators typically expect 
> the lifetime of the LA objects to exceed that of the operators, and so you 
> have to first create the matrix or preconditioner and then pass it to the 
> linear operators. This is similar to what you’d done when setting up op_M, 
> for example. The case of passing in a deal::PreconditionerIdentity() for 
> serial operations is a special case, and I don’t think that we’ve duplicated 
> that for TrilinosWrappers:: PreconditionerIdentity(). Maybe that could be 
> improved too.
> 
> I hope that with this single change you’d be able to get your program 
> running. If not, then please do let us know so that we can try to help 
> further.
> 
> Best,
> Jean-Paul
> 
> 
>> On 14. Jun 2021, at 19:18, Juan Felipe Giraldo > <mailto:jfgiral...@gmail.com>> wrote:
>> 
>> Hello everyone,
>> 
>> I have implemented a residual-minimization framework that somehow is similar 
>> to DPG. I want to extend my results by using parallelization using MPI with 
>> PETSc or Trilinos. 
>> So far, I have solved the saddle point problem using the Schur complement 
>> exactly how it is described in step 20. Now, I am trying to replicate 
>> exactly the same solver but using the MPI wrappers and the linear operators.
>> 
>> The problem is that when I am trying to implement the inverse_operator to 
>> compute the Preconditioner of the Schur complement, I get an error saying 
>> that the functions are not matching "inverse_operator(op_aS, solver_aS, 
>> TrilinosWrappers::PreconditionIdentity())."
>> 
>> There is no much documentation about linear operators in parallel solvers, 
>> so if anyone has any suggestion on how to fix this problem, it would be well 
>> appreciated. 
>> 
>> I have pasted the complete function in below:
>> 
>> 
>> template 
>> void FEMwDG::
>>   solve()
>>   {
>> TimerOutput::Scope t(computing_timer, "solve");
>> 
>> LA::MPI::PreconditionJacobi prec_M;
>>  LA::MPI::PreconditionJacobi::AdditionalData data;
>>  prec_M.initialize(system_matrix.block(0, 0), data);
>> }
>> 
>> auto  = solution.block(0);
>> auto  = solution.block(1);
>> const auto  = system_rhs.block(0);
>> const auto  M = linear_operator(system_matrix.block(0, 
>> 0));
>> 
>> const auto op_M  = linear_operator(M, prec_M);
>> const auto op_B   = 
>> linear_operator(system_matrix.block(0, 1));
>> const auto op_BT = 
>> linear_operator(system_matrix.block(1, 0));
>> 
>> ReductionControl  inner_solver_control2(5000,
>> 1e-18 * 
>> system_rhs.l2_norm(),
>> 1.e-2);
>> 
>> SolverCG cg(inner_solver_control2);
>> const auto op_M_inv = inverse_operator(M, cg, prec_M);
>> 
>> const auto op_S = op_BT * op_M_inv * op_B;
>> const auto op_aS = op_BT * linear_operator(prec_M) * 
>> op_B;
>> 
>> IterationNumberControl   iteration_number_control_aS(30, 1.e-18

Re: [deal.II] Linear operators - TrilinosWrappers

[Jean-Paul Pelteret]

Hi Feilpe,

Firstly, I agree that the documentation is very light on details on how to use 
the linear operators with Trilinos linear algebra types. We can definitely 
improve this, and any contributions to that effect would be greatly appreciated!

Right now, I can direct you to a few of the tests that use Trilinos LA in 
conjunction with the inverse operator, so that you can compare what you have 
and figure out what the problematic differences are. There is this one, for 
instance
https://github.com/dealii/dealii/blob/master/tests/lac/linear_operator_12a.cc#L323-L341
 

that looks like a similar setup to yours, and
https://github.com/dealii/dealii/blob/master/tests/lac/schur_complement_04.cc#L126-L137
 

that uses a Trilinos::SolverCG (as opposed to deal.II’s solver).

Comparing to both of these, I think that the important point might be that the 
preconditioner must be declared (out-of-line) before the inverse_operation() 
function is called. The linear operators typically expect the lifetime of the 
LA objects to exceed that of the operators, and so you have to first create the 
matrix or preconditioner and then pass it to the linear operators. This is 
similar to what you’d done when setting up op_M, for example. The case of 
passing in a deal::PreconditionerIdentity() for serial operations is a special 
case, and I don’t think that we’ve duplicated that for TrilinosWrappers:: 
PreconditionerIdentity(). Maybe that could be improved too.

I hope that with this single change you’d be able to get your program running. 
If not, then please do let us know so that we can try to help further.

Best,
Jean-Paul


> On 14. Jun 2021, at 19:18, Juan Felipe Giraldo  wrote:
> 
> Hello everyone,
> 
> I have implemented a residual-minimization framework that somehow is similar 
> to DPG. I want to extend my results by using parallelization using MPI with 
> PETSc or Trilinos. 
> So far, I have solved the saddle point problem using the Schur complement 
> exactly how it is described in step 20. Now, I am trying to replicate exactly 
> the same solver but using the MPI wrappers and the linear operators.
> 
> The problem is that when I am trying to implement the inverse_operator to 
> compute the Preconditioner of the Schur complement, I get an error saying 
> that the functions are not matching "inverse_operator(op_aS, solver_aS, 
> TrilinosWrappers::PreconditionIdentity())."
> 
> There is no much documentation about linear operators in parallel solvers, so 
> if anyone has any suggestion on how to fix this problem, it would be well 
> appreciated. 
> 
> I have pasted the complete function in below:
> 
> 
> template 
> void FEMwDG::
>   solve()
>   {
> TimerOutput::Scope t(computing_timer, "solve");
> 
> LA::MPI::PreconditionJacobi prec_M;
>  LA::MPI::PreconditionJacobi::AdditionalData data;
>  prec_M.initialize(system_matrix.block(0, 0), data);
> }
> 
> auto  = solution.block(0);
> auto  = solution.block(1);
> const auto  = system_rhs.block(0);
> const auto  M = linear_operator(system_matrix.block(0, 
> 0));
> 
> const auto op_M  = linear_operator(M, prec_M);
> const auto op_B   = 
> linear_operator(system_matrix.block(0, 1));
> const auto op_BT = 
> linear_operator(system_matrix.block(1, 0));
> 
> ReductionControl  inner_solver_control2(5000,
> 1e-18 * 
> system_rhs.l2_norm(),
> 1.e-2);
> 
> SolverCG cg(inner_solver_control2);
> const auto op_M_inv = inverse_operator(M, cg, prec_M);
> 
> const auto op_S = op_BT * op_M_inv * op_B;
> const auto op_aS = op_BT * linear_operator(prec_M) * 
> op_B;
> 
> IterationNumberControl   iteration_number_control_aS(30, 1.e-18);
> SolverCG solver_aS(iteration_number_control_aS);
> 
> const auto preconditioner_S =
> inverse_operator(op_aS, solver_aS, 
> TrilinosWrappers::PreconditionIdentity());
> const auto schur_rhs = op_BT * op_M_inv * L ;
> 
> SolverControlsolver_control_S(2000, 1.e-12);
> SolverCG solver_S(solver_control_S);
> 
> const auto op_S_inv = inverse_operator(op_S, solver_S, preconditioner_S );
> 
> U = op_S_inv * schur_rhs;
> std::cout << solver_control_S.last_step()
>   << " CG Schur complement iterations to obtain convergence."
>   << std::endl;
> E = op_M_inv * (L - op_B * U);
>  }
> 
> Thank you so much, 
> 
> Regards,
> Felipe
> 
> 
> 
> 
> 
> -- 
> 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 

Re: [deal.II] Problem Running Step-1

[Jean-Paul Pelteret]

Hi Kavya,

The 9.2 Mac package was built before these new Apple M1 chips were released, so 
it is unfortunately not compatible with them. I’ve got no experience with it, 
but you could try to use the Apple Rosetta application to see if that can 
somehow work around the issue. Here’s a link that explains what Rosetta is: 
https://support.apple.com/en-us/HT211861 


If that doesn’t work, then there is still some promising news: one of the 
developers is in the process of acquiring a new Apple computer so that we can 
build a new package that will be compatible with the latest Apple silicon. 
You’ll just have to be a little patient, and wait for the announcement of the 
new release. At that point, we should have a package that targets both Intel 
and Apple processors.

Best,
Jean-Paul

> On 15. Jun 2021, at 10:10, Kavya Velmurugan  wrote:
> 
> Hi, 
> 
> I'm trying to run something that requires Deal.II. I had an older MacBook Air 
> which ran on an Intel chip where I didn’t seem to have any problems. However, 
> I cannot seem to run step-1 successfully on my MacBook Pro which uses the 
> Apple M1 chip. Would anyone happen to have any advice on this? I’ve attached 
> a text file with the inputs and outputs of what I ran as well. 
> 
> 
> 
> Thanks,
> 
> Kavya
> 
> 
> -- 
> 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/f3a87f4e-36fc-43a5-a0d7-20473e2f3ba4n%40googlegroups.com
>  
> .
> 

-- 
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/1A39A724-7747-42B6-B37E-80139C4202C3%40gmail.com.

Re: [deal.II] Deal.II Make error || Make release

[Jean-Paul Pelteret]

Dear Sumanth,

Do you have Xcode installed? If not, then can you try to install Xcode and try 
again? I’m not sure why, but it looks like some library that is provided by 
Xcode creeped into the link line. We’ll have to investigate this further on our 
side to see if we can further sanitise our build environment, but it would be 
good to know if installing Xcode is at least a temporary solution to the 
problem.

Best,
Jean-Paul

> On 14. Jun 2021, at 02:34, Sumanth Theeda  wrote:
> 
> Hello Paul,
> 
> I have tried installing the 9.3 release and re-run the example of step-1. It 
> resulted in a similar error with another new error. Please have a look at the 
> following .txt file to know more about it. I'm not sure what's going wrong 
> every time. 
> 
> Thanks in advance,
> 
> On Saturday, June 12, 2021 at 2:15:28 AM UTC-5 Jean-Paul Pelteret wrote:
> Hi David and Sumanth,
> 
> There is a new Mac package for the soon to be announced 9.3 release that is 
> built for BigSur. Can you try that, and see if it works for you? If you have 
> any troubles then we’d appreciate the feedback.
> 
> https://github.com/dealii/dealii/releases/download/v9.3.0/dealii-9.3.0-bigsur-intel.dmg
>  
> <https://github.com/dealii/dealii/releases/download/v9.3.0/dealii-9.3.0-bigsur-intel.dmg>
> 
> Best,
> Jean-Paul
> 
> 
>> On 11. Jun 2021, at 20:33, David Montiel Taboada > > wrote:
>> 
> 
>> Hello everyone, 
>> 
>> A few PRISMS-PF users trying to run the deal.II prepacked image file on 
>> MacOS Big Sur are reporting similar issues. Any help with this would be 
>> greatly appreciated!
>> 
>> David
>> 
>> On Fri, Jun 11, 2021 at 1:59 PM Sumanth Theeda > > wrote:
>> Hello all,
>> 
>> I have installed Deal.II (v 9.2) using binary package on MacOS Big Sur 
>> (Version 11.4). I installed deal.ii as a part of Prisms-pf installation. 
>> Whenever I run an example, after compilation when I run $ make release 
>> command, it results in following error. I tried to run step-1 of examples. 
>> Please go through it and let me know if anyone has any questions.
>> 
>> Thanks in advance,
>> 
>> Sumanth
>> 
>> 
>> -- 
>> The deal.II project is located at http://www.dealii.org/ 
>> <http://www.dealii.org/>
>> For mailing list/forum options, see 
>> https://groups.google.com/d/forum/dealii?hl=en 
>> <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 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/dealii/0184379f-f5bf-4334-b391-d51868662acfn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/dealii/0184379f-f5bf-4334-b391-d51868662acfn%40googlegroups.com?utm_medium=email_source=footer>.
>> 
>> -- 
>> The deal.II project is located at http://www.dealii.org/ 
>> <http://www.dealii.org/>
>> For mailing list/forum options, see 
>> https://groups.google.com/d/forum/dealii?hl=en 
>> <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 
>> .
> 
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/dealii/CAJdNbL_GCa7o-RuMdqe5H_0D7OeJwCJ9rn_uiY%3D%3D2o5Db58KKw%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/dealii/CAJdNbL_GCa7o-RuMdqe5H_0D7OeJwCJ9rn_uiY%3D%3D2o5Db58KKw%40mail.gmail.com?utm_medium=email_source=footer>.
> 
> 
> -- 
> The deal.II project is located at http://www.dealii.org/ 
> <http://www.dealii.org/>
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en 
> <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 
> <mailto:dealii+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dealii/b0bf0447-f53a-403d-aa41-30daad6469c5n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/dealii/b0bf0447-f53a-403d-aa41-30daad6469c5n%40googlegroups.com?utm_medium=email_source=footer>.
> 

-- 
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/ECD4DE46-4C6E-4D3F-9FD7-02B7562840CD%40gmail.com.

Re: [deal.II] Deal.II Make error || Make release

[Jean-Paul Pelteret]

Hi David and Sumanth,

There is a new Mac package for the soon to be announced 9.3 release that is 
built for BigSur. Can you try that, and see if it works for you? If you have 
any troubles then we’d appreciate the feedback.

https://github.com/dealii/dealii/releases/download/v9.3.0/dealii-9.3.0-bigsur-intel.dmg
 


Best,
Jean-Paul

> On 11. Jun 2021, at 20:33, David Montiel Taboada  wrote:
> 
> Hello everyone, 
> 
> A few PRISMS-PF users trying to run the deal.II prepacked image file on MacOS 
> Big Sur are reporting similar issues. Any help with this would be greatly 
> appreciated!
> 
> David
> 
> On Fri, Jun 11, 2021 at 1:59 PM Sumanth Theeda  > wrote:
> Hello all,
> 
> I have installed Deal.II (v 9.2) using binary package on MacOS Big Sur 
> (Version 11.4). I installed deal.ii as a part of Prisms-pf installation. 
> Whenever I run an example, after compilation when I run $ make release 
> command, it results in following error. I tried to run step-1 of examples. 
> Please go through it and let me know if anyone has any questions.
> 
> Thanks in advance,
> 
> Sumanth
> 
> 
> -- 
> 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/0184379f-f5bf-4334-b391-d51868662acfn%40googlegroups.com
>  
> .
> 
> -- 
> 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/CAJdNbL_GCa7o-RuMdqe5H_0D7OeJwCJ9rn_uiY%3D%3D2o5Db58KKw%40mail.gmail.com
>  
> .

-- 
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/82AC272A-E73A-4E6F-8E9C-D1B43C2FD684%40gmail.com.

Re: [deal.II] time dependent navier stokes (gallery) does not work

[Jean-Paul Pelteret]

Hi Giang,

> Does anyone know which version of deal.II that this example run perfectly?

To answer your immediate question:

It looks like the last major change to the code happened in Apr/May 2018 which, 
in conjunction with the version of deal.II that it previously used to target in 
the CMakeLists.txt file, means that it was most likely written for deal.II 
version 9.0.

> I would like to report that the time dependent Navier Stokes example in 
> 
> https://dealii.org/developer/doxygen/deal.II/code_gallery_time_dependent_navier_stokes.html
>  
> 
> 
> compile but does not run correctly with deal.II 9.2.0 

That’s frustrating. Thanks for reporting this; I’ve opened up an issue for this 
problem (see https://github.com/dealii/code-gallery/issues/88 
 ). If you do test it against 
an older version and find that it works, perhaps you could let us know and we 
could then try to investigate further. It might be possible to bisect the 
problem if we know what a good version of the library is (it could also be due 
to some subtle change related to the parallel partitioning, the PETSc 
interface, etc. which might have been a bug before and has since been fixed, 
but breaks this code. Hard to say exactly.). The next release of deal.II is 
imminent, so it would also be interesting to see if whatever is causing the 
issue has been fixed between 9.2 and 9.3. 

Thanks again!
Jean-Paul


> On 2. Jun 2021, at 19:12, hgbk...@gmail.com  wrote:
> 
> Does anyone know which version of deal.II that this example run perfectly?
> 
> Best
> Giang
> 
> On Wednesday, June 2, 2021 at 11:07:34 AM UTC+2 hgbk...@gmail.com 
>  wrote:
> Hello
> 
> I would like to report that the time dependent Navier Stokes example in 
> 
> https://dealii.org/developer/doxygen/deal.II/code_gallery_time_dependent_navier_stokes.html
>  
> 
> 
> compile but does not run correctly with deal.II 9.2.0 . The analysis can run 
> until step 204 and then diverge. Would it be possible changes in 
> preconditioner destroy the convergence?
> 
> 
> Time step = 201, at t = 2.01e-01
>  GMRES_ITR = 8   GMRES_RES = 4.052763e-10
> 
> Time step = 202, at t = 2.02e-01
>  GMRES_ITR = 8   GMRES_RES = 7.194398e-10
> 
> Time step = 203, at t = 2.03e-01
>  GMRES_ITR = 8   GMRES_RES = 1.361073e-09
> 
> Time step = 204, at t = 2.04e-01
>  GMRES_ITR = 8   GMRES_RES = 4.896128e-09
> 
> Time step = 205, at t = 2.05e-01
>  GMRES_ITR = 8   GMRES_RES = 3.220123e-08
> 
> Time step = 206, at t = 2.06e-01
>  GMRES_ITR = 8   GMRES_RES = 7.647033e-07
> 
> Time step = 207, at t = 2.07e-01
>  GMRES_ITR = 8   GMRES_RES = 3.355695e-04
> 
> Time step = 208, at t = 2.08e-01
>  GMRES_ITR = 8   GMRES_RES = 5.007715e+01
> 
> Time step = 209, at t = 2.09e-01
>  GMRES_ITR = 8   GMRES_RES = 1.262003e+12
> 
> Time step = 210, at t = 2.10e-01
>  GMRES_ITR = 8   GMRES_RES = 1.279221e+33
> 
> Best
> Giang
> 
> 
> -- 
> 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/4263fa68-e89f-4748-90cf-4d84980102c6n%40googlegroups.com
>  
> .

-- 
The deal.II project is located at http://www.dealii.org/
For mailing 

Re: [deal.II] Looping over cells and faces: MeshWorker vs WorkStream

[Jean-Paul Pelteret]

Hi Praveen,

Correction, I meant to say face worker instead of boundary worker. Step-74 
<https://dealii.org/developer/doxygen/deal.II/step_74.html#Theassemble_systemfunction>
 is a DG code that uses mesh_loop() with a face worker, and also makes use of 
the nice FEInterfaceValues 
<https://dealii.org/developer/doxygen/deal.II/classFEInterfaceValues.html> 
class that has also very recently been extended to use FEValuesExtractors (see 
item 17 in the specific improvements section 
<https://dealii.org/developer/doxygen/deal.II/changes_between_9_2_0_and_9_3_0.html>
 for the upcoming release). 

Best,
Jean-Paul

> On 31. May 2021, at 19:57, Jean-Paul Pelteret  wrote:
> 
> Hi Praveen,
> 
>> Is it possible to use WorkStream to loop over faces ?
> 
> It is, in the sense that you can use it to multithread the loop over all 
> cells, and then loop over all all faces on a cell yourself. 
> 
> This has been automated in the mesh_loop() 
> <https://dealii.org/developer/doxygen/deal.II/group__MeshWorker.html#ga76ec61fbd188fb320fe8ca166a79b322>
>  function (in fact, mesh_loop() is used as a part of the backend to 
> MeshWorker). There you can specify a boundary worker that will be called 
> either before all after the cells — you get to choose using the 
> MeshWorker::AssembleFlags 
> <https://dealii.org/developer/doxygen/deal.II/namespaceMeshWorker.html#ac7a9db8b34d398d7d398d1e8809874aaa44a76e905b1d4cd80af387b5fac4d8aa>
>  . It’s quite a convenient assembly device, and its being put to use in most 
> of the new tutorials. There are a few tutorials that use mesh_loop() already. 
> Just look in the keywords of the tutorial list 
> <https://dealii.org/developer/doxygen/deal.II/Tutorial.html> to find them. 
> I’m sure that there must also be a DG example in the test suite somewhere, if 
> you need it.
> 
>> I know MeshWorker can be used for this, but it seems to be not used by many 
>> people and I suspect it may not be maintained well. 
> 
> Yes, it seems not to be used terribly often (at least, the questions on the 
> mailing list are infrequent, and the number of people that can answer those 
> questions seems somewhat limited). I advocate using mesh_loop() in preference 
> to MeshWorker.
> 
> Best,
> Jean-Paul
> 
>> On 31. May 2021, at 06:21, Praveen C > <mailto:cprav...@gmail.com>> wrote:
>> 
>> Dear all
>> 
>> I have a DG-type scheme which is totally quadrature-free and matrix-free. I 
>> need to first loop over cells and then loop over faces. I know MeshWorker 
>> can be used for this, but it seems to be not used by many people and I 
>> suspect it may not be maintained well. 
>> 
>> Is it possible to use WorkStream to loop over faces ?
>> 
>> Thanks
>> praveen
>> 
>> -- 
>> The deal.II project is located at http://www.dealii.org/ 
>> <http://www.dealii.org/>
>> For mailing list/forum options, see 
>> https://groups.google.com/d/forum/dealii?hl=en 
>> <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 
>> <mailto:dealii+unsubscr...@googlegroups.com>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/dealii/98B64908-C102-4C4F-B18E-99066E32C1A4%40gmail.com
>>  
>> <https://groups.google.com/d/msgid/dealii/98B64908-C102-4C4F-B18E-99066E32C1A4%40gmail.com>.
> 

-- 
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/2D3471C3-6094-4BEF-AA32-7F1B7F97CDF2%40gmail.com.

Re: [deal.II] Re-using outputdata from a previous analysis into a new one

[Jean-Paul Pelteret]

Hi,

That’s quite an interesting coupled problem that you’re solving!

If I understand correctly, you’re wanting your one problem to solve to 
completion, and you then want to save that state and load it in another, new 
simulation? If that’s the case then we have save/load functionality built into 
most (if not all) linear algebra vectors (see here in the documentation of the 
Vector class 
,
 for example). Of course, you’ll need to access that data with a matching 
DoFHandler (paired with the correct FE / FESystem), but all of those are also 
serialisable too. Although I don’t think that we have too many tutorials that 
demonstrate serialisation (I cannot think of one off the top of my head), we do 
have a collection of tests 
 that can 
illustrate how its done.

Was that the information that you were looking for? 

Best,
Jean-Paul

> On 30. May 2021, at 04:03, SAR  wrote:
> 
> Dear all
> 
> I am working on a study to investigate the role of elastic energy on hydride 
> evolution in Zr claddings in NPP. 
> 
> Through dealii, I have developed a program that solves the coupled system 
> system of equations :
> 1. Laplace equation (steady thermal conduction)
> 2. Mechanical equilibrium 
> 3. Cahn- Hilliard equation
> 4. Allen-cahn equation
> 
> The program runs well and no issues there. A typical simulation takes large 
> number of time steps to solve and generate a micro-structure. 
> 
> However, I want to investigate how will the hydride phase will re-orient 
> depending on a particular mechanical boundary load. 
> 
> Although that I can implement a time dependent boundary condition that will 
> allow me to achieve this goal, I dont want to do that. 
> 
> I want to use the results from the last time step in my original analysis and 
> use that as a starting point in a new analysis, that includes all of the 
> system information from the previous analysis. 
> 
> Is there a way to do that through dealii?
> 
> Thank you
> 
> 
> -- 
> 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/1010a77e-c14e-4871-bacf-51e5dbf11cd7n%40googlegroups.com
>  
> .

-- 
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/C46A2229-1CE3-4712-8600-2EE8C03FF6D9%40gmail.com.

Re: [deal.II] Looping over cells and faces: MeshWorker vs WorkStream

[Jean-Paul Pelteret]

Hi Praveen,

> Is it possible to use WorkStream to loop over faces ?

It is, in the sense that you can use it to multithread the loop over all cells, 
and then loop over all all faces on a cell yourself. 

This has been automated in the mesh_loop() 

 function (in fact, mesh_loop() is used as a part of the backend to 
MeshWorker). There you can specify a boundary worker that will be called either 
before all after the cells — you get to choose using the 
MeshWorker::AssembleFlags 

 . It’s quite a convenient assembly device, and its being put to use in most of 
the new tutorials. There are a few tutorials that use mesh_loop() already. Just 
look in the keywords of the tutorial list 
 to find them. I’m 
sure that there must also be a DG example in the test suite somewhere, if you 
need it.

> I know MeshWorker can be used for this, but it seems to be not used by many 
> people and I suspect it may not be maintained well. 

Yes, it seems not to be used terribly often (at least, the questions on the 
mailing list are infrequent, and the number of people that can answer those 
questions seems somewhat limited). I advocate using mesh_loop() in preference 
to MeshWorker.

Best,
Jean-Paul

> On 31. May 2021, at 06:21, Praveen C  wrote:
> 
> Dear all
> 
> I have a DG-type scheme which is totally quadrature-free and matrix-free. I 
> need to first loop over cells and then loop over faces. I know MeshWorker can 
> be used for this, but it seems to be not used by many people and I suspect it 
> may not be maintained well. 
> 
> Is it possible to use WorkStream to loop over faces ?
> 
> Thanks
> praveen
> 
> -- 
> 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/98B64908-C102-4C4F-B18E-99066E32C1A4%40gmail.com.

-- 
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/A5AA339A-E94A-44AD-B098-6035CC37033A%40gmail.com.

Re: [deal.II] Integrated material and spatial traction forces on boundary not equal

[Jean-Paul Pelteret]

Hi Alex,

Yes, at first glance it does look to me like the integration is a problem. You 
are using the same FEFaceValues object to perform the integration in both the 
material and spatial configurations, and this is not quite correct with the way 
that you have things set up. The following (which comes from the continuum 
identity for the volume integral of the divergence of a contravariant quantity, 
i.e. in your case, a stress measure) is equivalent:

F_{t} == \int_{dB_{0}} T_{0} dA = \int_{B_{0}} P . N dA   // “Reference 
quantities”, with “P” being the two-point Piola stress tensor
 ==  \int_{dB_{t}} \sigma . n da =  \int_{B_{t}} t da.  // “Spatial 
quantities"

That is to say, that the current traction per unit reference area integrated 
over the reference area is equal to the current traction per unit current area 
integrated over the current area. With this operation

spatial_force[boundary_id - 1] += cauchy * spatial_normal *
  fe_face_values.JxW(q_i) *
  deformation_grad_det;

you are integrating the current traction per unit current area over the 
reference area. So you either need to use a mapping and set up another 
FEFaceValues object that would perform integration on the spatial 
configuration, or you can use the following identity for the ratio of surface 
areas to get the correct scaling factor for what is returned by 
fe_face_values.JxW(q_i):

da/dA = det(F) n . F^{-T} . N   

That said, there’s also the question about what you’re doing for the "material 
force". Is ” piola_kirchhoff" really the symmetric, fully referential 
Piola-Kirchhoff stress? If so, then no you cannot expect these two quantities 
to match. F_{0} = \int_{dB_{0}} S . N dA is not the same force as  F_{t}, but 
is rather a “pseudo-force” that describes some reference traction per unit 
reference area. You need to push forward its first index (i.e. compute P = F.S) 
and then you can get to computing F_{t} as stated above.

I hope that helps clear things up a bit.

Best,
Jean-Paul


> On 11. May 2021, at 12:46, Alex Cumberworth  
> wrote:
> 
> Hello,
> 
> As a test to validate my code, I am solving the equations for geometrically 
> nonlinear elasticity (the Saint Venant-Kirchhoff model) for a beam with a 
> small displacement boundary condition on the right end such that I can 
> compare with Euler-Bernoulli beam theory. I can compare both the displacement 
> and the shear force between the FEM solution and the beam theory solution. In 
> my FEM integration, I output the normal and shear forces for both sides of 
> the beam in both the material and spatial reference. The left and right sides 
> are balanced, as expected, but the spatial and material forces are not quite 
> equal.
> 
> Shouldn't it be the case that spatial and material force is the same? Here 
> are the outputted forces for the right side
> 
> Right boundary material normal force: 0.0694169
> Right boundary spatial normal force: 0.0724468
> 
> Right boundary material shear force: 0.152057
> Right boundary spatial shear force: 0.152864
> 
> Further, beam theory gives a shear force with a magnitude of exactly 0.2. If 
> I make the displacement smaller the FEM and beam theory shear forces do not 
> converge. Is it expected for them to converge?
> 
> Below is the deformed system with the stress vectors on the faces included. 
> The black grid is the deformed FEM solution, while the solid red is the beam 
> theory solution.
> 
> If there is an issue, I would guess it would be in the integration. In 
> converting the material normal vector to the spatial reference, I first only 
> applied the inverse transpose of the deformation gradient, and did not 
> multiply by the determinant until calculating the force vector. I did this so 
> that I can get the unit normal spatial vectors to add up and later average so 
> that I have an average normal vector for the whole boundary face to calculate 
> the normal and shear force vectors. I have pasted the function in below:
> 
> template 
> void SolveRing::integrate_over_boundaries() {
> QGauss quadrature_formula(fe.degree + 1);
> FEFaceValues fe_face_values(
> fe,
> quadrature_formula,
> update_values | update_gradients | update_quadrature_points |
> update_JxW_values | update_normal_vectors);
> 
> std::vector> material_force(2);
> std::vector> spatial_force(2);
> std::vector> ave_material_normal(2);
> std::vector> ave_spatial_normal(2);
> const FEValuesExtractors::Vector displacements(0);
> for (const auto& cell: dof_handler.active_cell_iterators()) {
> for (const auto face_i: GeometryInfo::face_indices()) {
> const unsigned int boundary_id 
> {cell->face(face_i)->boundary_id()};
> if (not(boundary_id == 1 or boundary_id == 2)) {
> continue;
> }
> 

Re: [deal.II] Inhomogeneous periodic boundary constraints

[Jean-Paul Pelteret]

Hi Alex,

I’m sorry that I didn’t find the time to contribute any further to our 
discussion. But I’m really glad to hear that you carried on experimenting and 
ultimately found a solution to the problem that you were facing. Thank you for 
sharing the solution with us. When I next have some time, I’ll try to look 
through the final code that you attached, and perhaps we can find a way to 
incorporate the modified function (in some form) into the library.

Best,
Jean-Paul

> On 4. May 2021, at 11:52, Alex Cumberworth  
> wrote:
> 
> I ended up getting it working, so in case anyone else is interested in doing 
> something similar, I have attached updated versions of the previous scripts. 
> I further modified set_periodicity_constraints so that it can take a function 
> to set the inhomogeneity based on the values of the two support points 
> associated with the two degrees of freedom that are being tied together, 
> although it would need to be modified for more general use (the functions 
> works on the difference of the two points, and further it uses only the 
> absolute value of the difference in the x-component). I have also not made 
> changes to allow for adaptive mesh refinement. I think this is a pretty ugly 
> solution to the general problem of inhomogeneous periodic boundary 
> constraints, but I couldn't see how to do it without modifying these 
> functions without largely replicating them.
> 
> The issues mentioned in the previous post regarding 
> distribute_local_to_global() and AffineConstraints::distribute() stemmed from 
> a misunderstanding of exactly what these functions were doing, and have been 
> fixed. It does seem that with these constraints, SolverCG does not work as a 
> solver (I suppose the matrix is not symmetric anymore?), but either 
> SolverGMRES or the direct solver SparseDirectUMFPACK work.
> 
> The script has also been improved based on other tutorials, and now includes 
> parsing for a parameter file. I tried to include an example parameter file 
> but I guess the mailing list has a restriction on allowable file types.
> 
> Best,
> Alex
> 
> 
> -- 
> 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/0c692129-a363-4d67-98a7-8c7e04ba3892n%40googlegroups.com
>  
> .
> 

-- 
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/69055AE8-2C74-488A-8D7F-3CF47F051A8F%40gmail.com.

Re: [deal.II] LineMinimization and p-Laplace

[Jean-Paul Pelteret]

Hi Julie,

I’m glad to hear that you managed to figure out what the problem was! Thank you 
for letting us know that you made progress, and that the line search part was 
in fact working as expected. Good luck with solving the next part of the puzzle 
:-)

Best,
Jean-Paul

> On 5. May 2021, at 18:09, J.Y. Merten  wrote:
> 
> Hi all,
> 
> just wanna give you an update. LineMinimization was doing what it is supposed 
> to do. The problem was p-Laplace and the configuration of a few parameters in 
> the code. I am facing another problem but now it is of theoretical nature.
> 
> Thanks a lot for the reply, Jean and Bruno :)
> 
> On Wednesday, April 28, 2021 at 5:31:44 PM UTC+2 J.Y. Merten wrote:
> Hi Jean,
> 
> f and g are build correctly according to the manual but I don't understand 
> why it still stagnates in the third iteration (please see the attached log). 
> And
> 
> auto perform_linesearch = [&]()
> {
>  const auto res_0 = ls_min_function(0.0);
>   Assert(res_0.second < 0.0,
>  ExcMessage("Gradient should be negative. 
> Current value: " +
>  std::to_string(res_0.second)));
>   const auto res_1 = ls_min_function(1.0);
> 
>   if (res_0.second * res_1.second > 0.0)
>   return 1.0;
> 
>   const double a1= 1.0; //Initial trial step 
> for the bracketing phase
>   const double eta   = 0.5; //A parameter in the 
> second Wolfe condition (curvature condition)
>   const double mu= 0.49; //A parameter in the 
> first Wolfe condition (sufficient decrease)
>   const double a_max = 1.25; //The maximum 
> allowed step size
>   const double max_evals = 100; //The maximum allowed 
> number of function evaluations
>   const bool debug_output = true; //A flag to output 
> extra debug information into the deallog static object
> 
>   const auto res = 
> LineMinimization::line_search(...);
> 
>   return res.first; // Final stepsize
> };
> 
> that if condition has not been fulfilled but from what I see in the console 
> output, ls_min_function(1.0) has been passed down to the 
> LineMinimization::line_search() function, is it supposed to be that 
> way?
> 
> Many thanks in advance.
> 
> Best wishes, 
> Julie
> On Wednesday, April 21, 2021 at 8:36:03 PM UTC+2 J.Y. Merten wrote:
> Hi Jean, 
> 
> I was thinking the same. I have followed the example in the namespace 
> reference of LineMinimization 
> <https://www.dealii.org/current/doxygen/deal.II/namespaceLineMinimization.html#a0c96260fdb08c83fd9c7d84007e0e937>
>  and adjusted it to my problem. I'm currently reviewing the part where f and 
> g are build. A full deallog is attached as well.
> 
> Thank you so much for the help, it is highly appreciated.
> 
> Best wishes,
> Julie
> 
> On Tue, Apr 20, 2021 at 9:47 PM Jean-Paul Pelteret > 
> wrote:
> Hi Julie,
> 
> So I was correct that in that the bracket evaluations converge towards one 
> another, until they are equal to machine precision. It would be good if you 
> could attach the full log, because I think that one interesting part where 
> the values of the “f" and "g" function change sign has been cropped out. That 
> leads to another question: How do you choose “f” and “g”, i.e. how do you 
> define the function returns these values as line search is performing its 
> evaluations?
> 
> Best,
> Jean-Paul
> 
>> On 20. Apr 2021, at 11:34, J.Y. Merten > wrote:
>> 
>> Hi  Bruno and Jean
>> 
>> Thanks a lot for the answers. Sorry to reply this late, was busy with other 
>> PhD duties.  I did have a look at KINSOL when encountered the problem for 
>> the first time, I think it would be a convenient tool for more stable 
>> nonlinear problems. 
>> 
>> @Jean:  here is the dealllog output 
>> 
>> Initial residual: 0.1875
>> Number of active cells:   16
>> Number of degrees of freedom: 25
>> = Solving torsion function for p = 3 =
>> DEAL:cg::Starting value 0.187500
>> DEAL:cg::Convergence step 3 value 1.15076e-17
>> 3 CG steps
>> DEAL::Bracketing phase: 1
>> DEAL::1.0 8.15283e+16 7.41104e+07 0 0 -0.00395508
>> DEAL::Sectioning phase: 2
>> DEAL::0.0 0.0175781 -0.0351563 1 0
>> DEAL::1.0 8.15283e+16 7.41104e+07 0 

Re: [deal.II] Calculating normal vectors to deformed surface with pushforward operation

[Jean-Paul Pelteret]

Hi Alex,

Well, the one thing that I can clearly identify as being problematic is that 
the normal vector does not transform with the deformation gradient (directly), 
but rather with its cofactor. This is what Nanson’s formula for the 
transformation of surface areas tell us. We actually have a function that does 
this transformation, namely Physics::Transformations::nansons_formula() 

 . Maybe you could try to use that and see if you get the result that you’re 
looking for.

Best,
Jean-Paul

> On 4. May 2021, at 12:36, Alex Cumberworth  
> wrote:
> 
> Hello,
> 
> I would like to calculate traction/stress vectors for the deformed 
> configuration. I have solved for a non-linear elasticity problem and am 
> dealing with the Green-Lagrange strain tensor and the second Piola-Kirchoff 
> stress tensor. I thought the simplest way to get the traction vectors would 
> be to first calculate them in the material reference frame (by calculating 
> the stress tensor and applying it to normal vectors in the material 
> reference), and then using a pushforward operation (by applying the 
> deformation gradient) to produce the stress vectors in the spatial reference 
> frame (and also dividing by the determinant of the deformation vector to take 
> care of the change in area).
> 
> However, the results do not appear as expected. To understand what was going 
> on, I first decided to apply the pushforward operation to the normal vectors. 
> I used the following code to carry this out.
> 
> template 
> class SpatialNormalVectorPostprocess: public DataPostprocessorVector {
>   public:
> SpatialNormalVectorPostprocess();
> virtual void evaluate_vector_field(
> const DataPostprocessorInputs::Vector& input_data,
> std::vector>& computed_quantities) const;
> };
> 
> template 
> SpatialNormalVectorPostprocess::SpatialNormalVectorPostprocess():
> DataPostprocessorVector(
> "spatial_normal",
> update_gradients | update_normal_vectors) {}
> 
> template 
> void SpatialNormalVectorPostprocess::evaluate_vector_field(
> const DataPostprocessorInputs::Vector& input_data,
> std::vector>& computed_quantities) const {
> 
> for (unsigned int i {0}; i != input_data.normals.size(); i++) {
> Tensor<2, dim, double> grad_u {};
> Tensor<2, dim, double> identity_tensor {};
> for (unsigned int d {0}; d != dim; d++) {
> grad_u[d] = input_data.solution_gradients[i][d];
> identity_tensor[d][d] = 1;
> }
> const Tensor<2, dim, double> deformation_grad {
> grad_u + identity_tensor};
> const Tensor<1, dim, double> material_normal_vector {
> input_data.normals[i]};
> const Tensor<1, dim, double> spatial_normal_vector_t {
> deformation_grad * material_normal_vector};
> Vector spatial_normal_vector(dim);
> for (unsigned int d {0}; d != dim; d++) {
> spatial_normal_vector[d] = spatial_normal_vector_t[d];
> }
> computed_quantities[i] = spatial_normal_vector;
> }
> }
> 
> However, as seen below, the resulting vectors are not normal to the surfaces:
> 
> 
> Contrast this with if I instead update the mesh and directly output the 
> normal vectors:
> 
> 
> Any input would be greatly appreciated.
> 
> Best wishes,
> Alex
> 
> -- 
> 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/2e3fcd85-f799-419b-b66b-097513328f46n%40googlegroups.com
>  
> .
> 

-- 
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/46B64689-DE75-4FCE-9FA8-59157848FBAA%40gmail.com.

Re: [deal.II] dealii does not work on mac OS Big Sur

[Jean-Paul Pelteret]

Hi Farid,

Would you care to share more details about what the exact problem is? Are you 
trying to use the MacOS package, or building from source? If the latter then a 
full build log would be very useful. I’m not sure if any of the developers has 
a Mac that runs Big Sur (or if our CI testers run it), so it might be that we’d 
need some help in testing any possible fixes.

Best,
Jean-Paul

> On 3. May 2021, at 21:57, Farid Mehri Sofiani  
> wrote:
> 
> Hi! It seems that dealii doesn't work on Big Sur mac OS. Is there any way to 
> address this issue?
> 
> 
> kind regards,
> Farid
> 
> -- 
> 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/d5a952af-d070-4333-84f9-9abe13f2102en%40googlegroups.com
>  
> .

-- 
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/1AE0F61C-EDF3-4394-80DC-5DC99C95CD71%40gmail.com.

Re: [deal.II] GridTools::find_cells_adjacent_to_vertex: how to avoid multiple calling ?

[Jean-Paul Pelteret]

Hi Simon,

You could call GridTools:: find_cells_adjacent_to_vertex() with the 
triangulation instead of a DoFHandler, and then just convert the returned 
iterators to the type used by each DoFHandler using the method outlined here:
https://github.com/dealii/dealii/wiki/Frequently-Asked-Questions#can-i-convert-triangulation-cell-iterators-to-dofhandler-cell-iterators
 


Best,
Jean-Paul

> On 30. Apr 2021, at 18:37, Simon Wiesheier  wrote:
> 
> Hello Wolfgang, 
> 
> I actually have a Time Measurement in my code implemented. 
> For my current computations the difference (one call vs two calls per vertex) 
> is neglible. But my model will become much bigger and therefore I'd like to 
> avoid unnecessary calls to that function. 
> 
> Since I can pass only one dof_handler to that function, I guess there is no 
> "obvious" way to make only one call, is it? 
> 
> -Simon 
> 
> Wolfgang Bangerth mailto:bange...@colostate.edu>> 
> schrieb am Fr., 30. Apr. 2021, 18:16:
> On 4/30/21 10:13 AM, Simon wrote:
> > 
> > auto cells_ref = GridTools::find_cells_adjacent_to_vertex(dof_handler_ref, 
> > /*vertex*/);
> > auto cells_tmp = GridTools::find_cells_adjacent_to_vertex(dof_handler_tmp, 
> > /*vertex*/);
> > 
> > I am not sure how "expensive" this function actually is. I have to call 
> > this 
> > function for all vertices of my triangulation, so currently I call it 
> > "2*n_vertices()" times.
> > 
> > I´d like to call this function only once for a given vertex, i.e. 
> > "n_vertices()"times.
> > Is there a way to realize this in combination with two different 
> > dof_handlers?
> 
> There are probably ways to work around this, but I'd like to repeat a point 
> Bruno made the other day on this very mailing list:
> 
> "Unless you have measured that this is a bottleneck in you code, you should 
> use what's the more readable. If there is a difference between these two 
> codes, it would need to be in a hot loop to matter. My advice is to write 
> easy 
> to understand code and once you have made sure that the code works, then use 
> a 
> profiler to find the bottleneck and optimize the code."
> 
> I think this is good advice!
> 
> 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/966f38ec-5ce2-f879-c9c4-2df21ab1110b%40colostate.edu
>  
> .
> 
> -- 
> 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/CAM50jEtCWSTAhzEi7uPmgvkC94DMGJnP43AAhOuJw_97KCVT7g%40mail.gmail.com
>  
> .

-- 
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/9301657C-CE72-4129-A738-A7AAA52F0C0F%40gmail.com.

Re: [deal.II] integrating over boundaries

[Jean-Paul Pelteret]

Hi Sylvain,

Thanks for detailing your attempts so thoroughly. With this

>   // I recover the value of conductivity
>   MaterialData material_data;
>   const typename DoFHandler::cell_iterator current_cell = 
> input_data.template get_cell>();
>   FullMatrix  conductivity = 
> material_data.get_th_conductivity(current_cell->material_id());
> 
>   double heat_flux_cell_norm = 0.;
> 
>   for (auto face_index : GeometryInfo::face_indices())
>   {
>   if (current_cell->face(face_index)->boundary_id() == 2)
>   {
> double long_cell = 0;
> long_cell = (current_cell->face(face_index)->vertex(0) - 
> current_cell->face(face_index)->vertex(1)).norm();
> 
> for (unsigned int d=0; d {
>   heat_flux_cell_norm += 
> -conductivity[d][d]*input_data.solution_gradients[face_index][d] * 
>   
> conductivity[d][d]*input_data.solution_gradients[face_index][d];
> }
> std::cout << "total heat flux = " << heat_flux_cell_norm << 
> std::endl;
> heat_flux_cell_norm *= long_cell;
>   }
>   }

you’ve got most of the structure for your calculation completely correct, but 
embedding it within a DataPostprocessor is not what you want to do. These 
classes are there to help visualise quantities via DataOut (i.e. do some 
per-cell calculations), rather than computing some boundary integral like you 
want. Instead, you should encapsulate the above within your own function and 
the standard DoFHandler active cell loop. You would then replace “input_data” 
with some FEFaceValues object (reinitialised on the given cell and face_index) 
and then call "fe_face_values.get_function_gradients 
(solution_vector,
 gradients);” to store the solution gradients at each face quadrature point and 
from that compute the heat flux at each face quadrature point. But I think that 
you’re also just wanting to consider the component of the heat flux that is 
normal to the boundary, right? 

I think that your calculation should have this sort of structure:

double total_heat_flux = 0.0;
FEFaceValues fe_face_values(fe, face_quadrature, update_gradients | 
update_normal_vectors | update_JxW_values);
std::vector> temperature_gradient(face_quadrature.size());

  for (const auto cell : dof_handler.active_cell_iterators())
for (const auto face_index : GeometryInfo::face_indices())
  If (… at boundary of interest …)
  {
   fe_face_values.reinit(cell, face_index);
   fe_face_values.reinit.get_solution_gradents(solution_vector, 
temperature_gradient);
for (const auto q_point : fe_face_values.quadrature_point_indices())
{
  const Tensor<1,dim> heat_flux_q = 
-conductivity*temperature_gradient[q_point]; // Q = -K.Grad(T)
  total_heat_flux += heat_flux_q * 
fe_face_values.normal_vector(q_point) * fe_face_values.JxW(q_point); // q = 
Q.N. ; q_total = \int q dA
  }
}

If I’ve interpreted things correctly then that (or something close to it) 
should achieve what you’re looking to do.

I hope that this help!

Best,
Jean-Paul

> On 23. Apr 2021, at 12:03, Sylvain Mathonnière 
>  wrote:
> 
> By the way, I am aware than I forgot to take the square root of 
> heat_flux_cell_norm. I am also aware that using 
> input_data.solution_gradients[face_index][d]  is weird in this context since 
> the first indices should refer to a vertex indices of the cell and not the 
> face index and it only works because quadrangle have 4 faces and 4 vertices 
> but so far this was not my main issue but it is definitively on my list of 
> fixing.
> 
> El viernes, 23 de abril de 2021 a la(s) 10:07:23 UTC+2, Sylvain Mathonnière 
> escribió:
> Hello everyone !
> 
> I have a very basic question but somehow I did not manage to find the answer 
> in tutorials, neither looking at the documentation or in the this user group. 
> Or more probably I did not understand it when I saw it since I am fairly new 
> to deal.II and to C++.
> 
> My main goal : I am trying to integrate over a boundary (a line since I am in 
> 2D) the heat flux to get the total heat flux through my boundary.
> 
> What I did :
> 1 - I looked at this documentation 
> https://www.dealii.org/current/doxygen/deal.II/classDataPostprocessorVector.html
>  
> 
>  to calculate first the heat flux on my boundary which worked fine.
> 
> 2 - I tried to integrate the norm of the heat flux over my boundary in the 
> function evaluate_scalar_field() function but I could not. My best effort is 
> this :
> 
> template 
> class HeatFluxPostprocessor : public DataPostprocessorVector
> {
> public:
>   HeatFluxPostprocessor ()
> :
> DataPostprocessorVector ("_k_grad_T",
>   update_gradients 

Re: [deal.II] interpolate FE_Nelelec

[Jean-Paul Pelteret]

Dear John,

The class documentation 
<https://dealii.org/current/doxygen/deal.II/classFE__Nedelec.html> states

> Several aspects of the implementation are experimental. For the moment, it is 
> safe to use the element on globally refined meshes with consistent 
> orientation of faces.

My interpretation would be that the mesh should be Cartesian aligned, or at 
least “grid-like". My limited experience with the standard FE_Nedelec element 
on a mesh of similar geometric “complexity” to yours was not satisfactory. Of 
course, I wouldn’t discount that I made a mistake somewhere, so it would be 
good if others who have spent more time using the FE_Nedelec element would 
share their experiences. Konrad is actively working on improving the current 
situation (see https://github.com/dealii/dealii/pull/12016 
<https://github.com/dealii/dealii/pull/12016>, thanks Konrad!), but naturally 
it's an ongoing project. I believe that the FE_NedelecSZ does not suffer from 
the face/edge orientation issues, which is why I recommended that you try it 
(especially if you’re going to stick to the lowest order elements that, all 
things being equal, should render identical results to the canonical Nedelec 
element).

Best,
Jean-Paul

> On 21. Apr 2021, at 16:23, John Smith  wrote:
> 
> Dear Konrad,
> 
> 
> I do not understand when a geometry gets complicated. Is a toroid inside a 
> sphere, both centred at the origin, a complicated geometry? To start with, I 
> will use a relatively simple mesh. I will not use local refinement, only 
> global. I can do without refinement as well, i.e. making the mesh in gmsh.
> 
> 
> Yes, I would like to know more about orientations issues on complicated 
> geometries. Could please tell me about it? I would very much prefer to use 
> FE_Nedelec without hierarchical shape functions. The first order 3D 
> FE_Nedelec will do nicely provided the orientation issues will be irrelevant 
> to the mesh.
> 
> 
> John
> 
> 
> 
> On Tuesday, April 20, 2021 at 9:43:31 PM UTC+2 Konrad Simon wrote:
> Dear John,
> 
> As Jean-Paul pointed out the entries of the solution vector for a Nedelec 
> element have a different meaning. The entries are weights that result from 
> edge moments (and in case of higher order also face moments and volume 
> moments), i.e, integrals on edges. Nedelec elements have a deep geometric 
> meaning: they discretize quantities that you can integrate (a physicist would 
> say "measure") along 1D-lines in 3D.
> 
> Btw, if you are using Nedelec in 2d be aware that it has some difficulties on 
> complicated meshes. In 3D the lowest order is fine. NedelecSZ (for 2D lowest 
> order and 3D all orders), as Jean-Paul pointed out, are another option. They 
> are meant to by-pass certain mesh orientation issues on complicated 
> geometries (I can tell you a bit about that since currently I am chasing some 
> problems there).
> 
> Best,
> Konrad
> 
> On Tuesday, April 20, 2021 at 9:23:23 PM UTC+2 Jean-Paul Pelteret wrote:
> Hi John,
> 
> Unfortunately, you’ve fallen into the trap of confusing what the entries in 
> the solution vector mean for the different element types. For Nedelec 
> elements, they really are coefficients of a polynomial function, so you can’t 
> simply set each coefficient to 1 to visualise the shape function (like one 
> might be inclined to try for Lagrange type polynomials). If you want a little 
> piece of code that will plot the Nedelec shape functions for you, then take a 
> look over here:
> https://github.com/dealii/dealii/issues/8634#issuecomment-595715677 
> <https://github.com/dealii/dealii/issues/8634#issuecomment-595715677>
> 
> BTW. In case you’re not aware, a newer (and probably more robust) 
> implementation of a Nedelec element is the FE_NedelecSZ 
> <https://dealii.org/current/doxygen/deal.II/classFE__NedelecSZ.html> that 
> uses hierarchical shape functions to form the higher order bases. The PhD 
> thesis of S. Zaglmayr that describes the element is mentioned in the class 
> documentation.  
> 
> Best,
> Jean-Paul
> 
> 
>> On 20. Apr 2021, at 15:47, John Smith > wrote:
>> 
> 
>> 
>> Dear Konrad,
>> 
>> 
>> Thank you for your help! I have recently modified the step-3 tutorial 
>> program to save FE_Nedelec<2> fe(0) shape function into *.csv files. It is 
>> attached to this message. The result of this program is not what I would 
>> expect it to be. I have also attached a pdf file which compares my 
>> expectations (marked as “Expectations” in the pdf file) with the results of 
>> the modified step-3 program (marked as “Reality” in the pdf file). My 
>> expectations are based on the literature I have. My question is: why 

Re: [deal.II] Removing cells in parallel distributed triangulation

[Jean-Paul Pelteret]

Hi Reza,

With no context as to how element deletion affects the geometry itself, may I 
ask if you’ve considered element deactivation using the FE_Nothing element? If 
you can afford to store the mesh but primarily want to ensure that no DoFs are 
assigned to a region outside of the physical domain boundaries, then this might 
be an alternate approach to adjusting the mesh directly.

Best,
Jean-Paul

> On 20. Apr 2021, at 21:58, mohammadreza yaghoobi 
>  wrote:
> 
> Thanks Marc. 
> 
> My biggest challenges are both time and memory. I'm trying to model a crystal 
> plasticity sample with ~20 million elements. In the case of no element 
> deletion, I can simply use global refinement and I won't face memory issues 
> while generating mesh and running the code (and of course no time on element 
> deletion).
> 
> However, when I'm trying to add the element deletion feature, then I cannot 
> use global refinement,  and I'll face the memory issue, since all of the 
> triangulation will be on the coarsest level. On top of that, for every 
> processor, the code has to search the element deletion pattern for all of the 
> triangulation (~20 million elements). As I increase the sample size, each 
> processor still needs to handle all the elements which becomes a big 
> bottle-neck, and also uses the resources very inefficiently. Actually, 
> parallelization cannot help at all with this part of the code, which actually 
> serves as the serial with large memory requirements. Just to give you an 
> idea, it will take about 12 hrs in my example to bypass the element deletion 
> search part running on 1500 processors, each has 38gb memory. I actually have 
> to underutilize my node (instead of 24, I'm using 5) because of memory issues.
> 
> The ideal case would be each processor just handling their own part and some 
> reduction happened throughout the processors.
> 
> I hope I was able to clarify the bottle neck.
> 
> Thanks
> Reza
> 
> 
> 
> On Tue, Apr 20, 2021 at 3:47 PM Marc Fehling  > wrote:
> Hello Reza,
> 
> `parallel::distributed::Triangulation` objects store the entire coarse mesh, 
> see also the module documentation 
> . 
> This allows for a quick execution of adaptive refinement. So from my 
> understanding, you need to perform this operation on all active cells, 
> including ghost and artificial ones. So the working code you have might be 
> the only way to use 
> `GridGenerator::create_triangulation_with_removed_cells()` in the parallel 
> distributed context.
> 
> Can you quantify how inefficient your code is? For example did you time how 
> long your mesh creation takes and compare it to the overall runtime?
> 
> Best,
> Marc
> 
> On Tuesday, April 20, 2021 at 12:14:10 PM UTC-6 mohammadre...@gmail.com 
>  wrote:
> Hi,
> 
> I'm trying to subtract some elements based on a user-defined criteria. 
> Ideally, I want to use each processor in a way that they are responsible only 
> for their partition (using is_locally_owned()) to remove the cells from the 
> triangulation using GridGenerator::create_triangulation_with_removed_cells. 
> However, when I used  this, it will not proceed after 
> GridGenerator::create_triangulation_with_removed_cells. 
> Very inefficient solution is each processor will process the whole 
> triangulation space and remove the elements. This works. However, as the 
> simulation size increases, this becomes really a bottle neck.
> 
> Is there any way I can tackle this smarter?
> 
> Thanks
> Reza
> 
> Below is the version of the code which works but very inefficiently.
> I added the red lines so every processor be responsible just for their own 
> parts. It stops at GridGenerator::create_triangulation_with_removed_cells.
> 
> 
> 
> GridGenerator::subdivided_hyper_rectangle (triangulation2, 
> userInputs.subdivisions, Point(), 
> Point(userInputs.span[0],userInputs.span[1],userInputs.span[2]), true);
> 
> typename Triangulation< dim, dim >::active_cell_iterator cell = 
> triangulation2.begin_active(), endc = triangulation2.end();
> 
> for (; cell!=endc; ++cell) {
> if (cell->is_locally_owned()){
> double pnt3[3];
> const Point pnt2=cell->center();
> for (unsigned int i=0; i pnt3[i]=pnt2[i];
> }
> 
> gID=orientations_Mesh.getMaterialID(pnt3);
> cellOrientationMap_Mesh.push_back(gID);
> }
> }
> 
> unsigned int materialID;
> unsigned int cell2=0;
> cell = triangulation2.begin_active(); endc = triangulation2.end();
> std::set::active_cell_iterator> 
> cells_to_remove;
> unsigned int NumberOwned=0;
> for (; cell!=endc; ++cell) {
> if (cell->is_locally_owned()){
> materialID=cellOrientationMap_Mesh[cell2];
> NumberOwned=NumberOwned+1;
> if (materialID ==userInputs.deletionGrainID){
> cells_to_remove.insert (cell);
> }
> cell2=cell2+1;
> }
> }
> 
> char buffer[200];
> 
> if (cells_to_remove.size()>0){
> 

Re: [deal.II] LineMinimization and p-Laplace

[Jean-Paul Pelteret]

10 0 0
> DEAL::Sectioning phase: 5
> DEAL::0.0 0.00102256 -0.00204512 1 0
> DEAL::0.027 1.42319e+24 4.03704e+10 0 0
> DEAL::0.0081 1.15278e+22 3.6e+09 0 0
> DEAL::Sectioning phase: 6
> DEAL::0.0 0.00102256 -0.00204512 1 0
> DEAL::0.0081 1.15278e+22 3.6e+09 0 0
> DEAL::0.00243000 9.33741e+19 3.26998e+08 0 0
> DEAL::Sectioning phase: 7
> DEAL::0.0 0.00102256 -0.00204512 1 0
> DEAL::0.00243000 9.33741e+19 3.26998e+08 0 0
> DEAL::0.000729000 7.56303e+17 2.94293e+07 0 0
> DEAL::Sectioning phase: 8
> DEAL::0.0 0.00102256 -0.00204512 1 0
> DEAL::0.000729000 7.56303e+17 2.94293e+07 0 0
> DEAL::0.000218700 6.12531e+15 2.64847e+06 0 0
> DEAL::Sectioning phase: 9
> DEAL::0.0 0.00102256 -0.00204512 1 0
> DEAL::0.000218700 6.12531e+15 2.64847e+06 0 0
> DEAL::6.56100e-05 4.95950e+13 238314. 0 0
> DEAL::Sectioning phase: 10
> DEAL::0.0 0.00102256 -0.00204512 1 0
> DEAL::6.56100e-05 4.95950e+13 238314. 0 0
> DEAL::1.96830e-05 4.01179e+11 21433.9 0 0
> . . . 
> DEAL::Sectioning phase: 49
> DEAL::6.58615e-10 0.000743997 -0.00137850 1 0
> DEAL::6.58615e-10 0.000743997 -0.00137850 1 0
> DEAL::6.58615e-10 0.000743997 -0.00137850 1 0
> DEAL::Sectioning phase: 50
> DEAL::6.58615e-10 0.000743997 -0.00137850 1 0
> DEAL::6.58615e-10 0.000743997 -0.00137850 1 0
> DEAL::6.58615e-10 0.000743997 -0.00137850 1 0
> DEAL::Sectioning phase: 51
> DEAL::6.58615e-10 0.000743997 -0.00137850 1 0
> DEAL::6.58615e-10 0.000743997 -0.00137850 1 0
> DEAL::6.58615e-10 0.000743997 -0.00137850 1 0
> 
> 
> An error occurred in line <457> of file 
> 
>  in function
> NumberType dealii::LineMinimization::poly_fit(NumberType, NumberType, 
> NumberType, NumberType, NumberType, NumberType, const 
> dealii::FiniteSizeHistory&, const 
> dealii::FiniteSizeHistory&, const 
> dealii::FiniteSizeHistory&, std::pair<_FIter, _FIter>) [with 
> NumberType = double]
> The violated condition was: 
> bounds.first < bounds.second
> Additional information: 
>     Incorrect bounds
> 
> The last few LS iterations do look strange, they barely changed.
> 
> When run with more dofs on the same mesh (16 cells, 81 dofs) I get 
> convergence failure. There is a regularization parameter  epsilon=1e-5,  with 
> larger epsilon on the same mesh, I get bounds error again. For smaller p like 
> 3-5, this epsilon should actually be enough for regularization...
> 
> Any help is highly appreciated.   
> 
> Best wishes,
> Julie
> On Friday, April 16, 2021 at 11:59:29 PM UTC+2 Jean-Paul Pelteret wrote:
> Hi Julie,
> 
> So as you know from the error message, the assertion on this line 
> <https://github.com/dealii/dealii/blob/master/include/deal.II/optimization/line_minimization.h#L453>
>  is being triggered. The fit function is called from this section of code 
> <https://github.com/dealii/dealii/blob/master/include/deal.II/optimization/line_minimization.h#L692-L697>,
>  and the only logical explanation is that the brackets have precisely the 
> same value. If you could provide the output from line_search() algorithm with 
> the debug_output flag enabled, then perhaps is might be possible to tell 
> what’s going on here. Otherwise, if you can provide the failing case then I 
> could try to have a look at it in the coming days to see if I can work out 
> what’s going on.
> 
> Best,
> Jean-Paul
> 
> 
> 
>> On 15. Apr 2021, at 12:08, J.Y. Merten > > wrote:
>> 
> 
>> Dear all,
>> 
>> I am trying to solve a p-Laplace Dirichlet problem with zero boundary and 
>> used step-15 as the base. The code works well for p=1.1-2.9 with Newton and 
>> standard linesearch procedure. But when p>=3 the program diverges, 
>> continuation method brought me to p=2.99 but not beyond. Recently I have 
>> used the LineMinimization class and got this error after a few iterations:
>> 
>> using poly_fit and these param:
>> const double a1= 1.0; 
>> const double eta   = 0.9; 
>> const double mu= 1e-4;
>> const double a_max = 1.25; 
>> const double max_evals = 100; 
>> const bool debug_output = true;
>> 
>>   
>> An error occurred in line <457> of file 
>> 
>>  in function
>> NumberType dealii::LineMinimization::poly_fit(NumberType, NumberType, 
>> NumberType, NumberType, NumberType, NumberType, const 
>> dealii::FiniteSizeHistory&, const 
>> dealii::FiniteSizeHistory&, const 
>> dealii::FiniteSizeHistory&, std::pair<_FIter, _FIter>) [with 
>> NumberType 

Re: [deal.II] interpolate FE_Nelelec

[Jean-Paul Pelteret]

Hi John,

Unfortunately, you’ve fallen into the trap of confusing what the entries in the 
solution vector mean for the different element types. For Nedelec elements, 
they really are coefficients of a polynomial function, so you can’t simply set 
each coefficient to 1 to visualise the shape function (like one might be 
inclined to try for Lagrange type polynomials). If you want a little piece of 
code that will plot the Nedelec shape functions for you, then take a look over 
here:
https://github.com/dealii/dealii/issues/8634#issuecomment-595715677 


BTW. In case you’re not aware, a newer (and probably more robust) 
implementation of a Nedelec element is the FE_NedelecSZ 
 that uses 
hierarchical shape functions to form the higher order bases. The PhD thesis of 
S. Zaglmayr that describes the element is mentioned in the class documentation. 
 

Best,
Jean-Paul

> On 20. Apr 2021, at 15:47, John Smith  wrote:
> 
> 
> Dear Konrad,
> 
> 
> Thank you for your help! I have recently modified the step-3 tutorial program 
> to save FE_Nedelec<2> fe(0) shape function into *.csv files. It is attached 
> to this message. The result of this program is not what I would expect it to 
> be. I have also attached a pdf file which compares my expectations (marked as 
> “Expectations” in the pdf file) with the results of the modified step-3 
> program (marked as “Reality” in the pdf file). My expectations are based on 
> the literature I have. My question is: why the shape functions of 
> FE_Nedelec<2> fe(0) differ from my expectations? I guess my expectations are 
> all wrong. I would also appreciate if you will share with me a reference to a 
> paper or a book, so I can extend my modest library.
> 
> 
> Thanks!
> 
> John
> 
> 
> P.S. I have sent you an e-mail as you have requested. Could you please check 
> your spam folder? 
> 
> 
> 
> 
> On Monday, April 19, 2021 at 8:47:29 AM UTC+2 Konrad Simon wrote:
> Dear John,
> 
> I had a look at the pdf you sent. I noticed some conceptual inconsistencies 
> that are important for the discretization. Let me start like this: The 
> curl-curl-problem that you are trying to solve is - according to your 
> description of the gauge - actually a curl-curl + grad-div problem and hence 
> a Laplace-problem that describes a Helmholtz-decomposition. In other words in 
> order to get a well-posed simulation problem you need more boundary 
> conditions. You already noticed that since your curl-curl-matrix is singular 
> (the kernel is quite complicated and contains all longitudinal waves). 
> 
> You have of course the option to solve (0.0.2) with a Krylov-solver but then 
> you need to make sure that the right-hand side is in the orthogonal 
> complement of this kernel before each iteration which is quite difficult. I 
> would not recommend that option.
> 
> Another point is that if you have a solution for your field A like in (0.0.4) 
> you can not have a similar representation for T. This is mathematically not 
> possible.
> 
> Since you not care about the gauge let me tell you how I would tackle this: 
> The reason  is  - to come back to my original point - you are missing a 
> boundary condition that makes you gauge unique. Since you apply natural 
> boundary conditions (BCs) on A you must do so as well to determine div(A). 
> This second BC for A is applied to a different part of the system that is 
> usually neglected in the literature and A is partly determined from this part 
> (this part then describes the missing transversal waves). The conditions you 
> mention on curl(A) are some what contradictory to the space in which A lives. 
> Nedelec elements which you must use (you can not use FE_Q to enforce the 
> conditions) cannot generate your desired T_0.
> 
> There are some principles when discretizing these problems (which are not 
> obvious) that you MUST adhere to (choice of finite elements, boundary 
> conditions, what is the exact system etc) if you want to get a stable 
> solution and these are only understood recently. I am solving very similar 
> problems (with Deal.II) in a fluid context and will be happy to share my 
> experiences with you. Just email me: konrad...@uni-hamburg.de 
> 
> 
> Best,
> Konrad
> 
> On Monday, April 19, 2021 at 5:51:17 AM UTC+2 Wolfgang Bangerth wrote:
> On 4/18/21 12:24 PM, John Smith wrote: 
> > 
> > Thank you for your reply. It is a bit difficult to read formulas in text. 
> > So I 
> > have put a few questions I have in a pdf file. Formulas are better there. 
> > It 
> > is attached to this message. May I ask you to have a look at it? 
> 
> John: 
> 
> If I understand your first question right, then you are given a vector field 
> J 
> and you are looking for a vector field T so that 
> curl T = J 
> I don't really have anything to offer to this kind of question. There are 
> many 
> vector fields T that 

Re: [deal.II] LineMinimization and p-Laplace

[Jean-Paul Pelteret]

Hi Julie,

So as you know from the error message, the assertion on this line 

 is being triggered. The fit function is called from this section of code 
,
 and the only logical explanation is that the brackets have precisely the same 
value. If you could provide the output from line_search() algorithm with the 
debug_output flag enabled, then perhaps is might be possible to tell what’s 
going on here. Otherwise, if you can provide the failing case then I could try 
to have a look at it in the coming days to see if I can work out what’s going 
on.

Best,
Jean-Paul


> On 15. Apr 2021, at 12:08, J.Y. Merten  wrote:
> 
> Dear all,
> 
> I am trying to solve a p-Laplace Dirichlet problem with zero boundary and 
> used step-15 as the base. The code works well for p=1.1-2.9 with Newton and 
> standard linesearch procedure. But when p>=3 the program diverges, 
> continuation method brought me to p=2.99 but not beyond. Recently I have used 
> the LineMinimization class and got this error after a few iterations:
> 
> using poly_fit and these param:
> const double a1= 1.0; 
> const double eta   = 0.9; 
> const double mu= 1e-4;
> const double a_max = 1.25; 
> const double max_evals = 100; 
> const bool debug_output = true;
> 
>   
> An error occurred in line <457> of file 
> 
>  in function
> NumberType dealii::LineMinimization::poly_fit(NumberType, NumberType, 
> NumberType, NumberType, NumberType, NumberType, const 
> dealii::FiniteSizeHistory&, const 
> dealii::FiniteSizeHistory&, const 
> dealii::FiniteSizeHistory&, std::pair<_FIter, _FIter>) [with 
> NumberType = double]
> The violated condition was: 
> bounds.first < bounds.second
> Additional information: 
> Incorrect bounds
> 
> I have looked into the source code and understood these bounds are meant for 
> the sectioning and bracketing intervals. I tried different settings of the 
> param and still get this error. I am running out of ideas how to debug this...
> 
> Any help is highly appreciated.
> 
> Thanks a lot and best wishes,
> Julie
> 
> 
> 
> -- 
> 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/d8844ccc-1f9e-4669-ad03-c71abf33eadbn%40googlegroups.com
>  
> .

-- 
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/D67144B5-4494-4A4F-959B-EA8DF052662F%40gmail.com.

Re: [deal.II] interpolate FE_Nelelec

[Jean-Paul Pelteret]

To add to Wolfgang’s comment, you can have a look at the 
compute_edge_projection_l2() function 

 that forms a part of the function that computes curl-conforming boundary 
conditions. You might be able to gain some inspiration from there? The 
associated paper 

 that explains the method that’s being implemented is 

// See, for example, section 4.2 of:
// Electromagnetic scattering simulation using an H (curl) conforming hp-
// finite element method in three dimensions, PD Ledger, K Morgan, O
// Hassan, Int. J. Num. Meth. Fluids, Volume 53, Issue 8, pages
// 1267-1296, 20 March 2007:
// http://onlinelibrary.wiley.com/doi/10.1002/fld.1223/abstract 


Best,
Jean-Paul

> On 16. Apr 2021, at 22:26, Wolfgang Bangerth  wrote:
> 
> On 4/16/21 11:36 AM, John Smith wrote:
>> However, the FE_Nedelec is different. It implements edge elements. They are 
>> vector-based. That is, functions are represented by a superposition of 
>> vector-valued shape functions:
>> \vec{A} = \sum u_i vec{N}_i .
>> Therefore, the output of the "value" method in “class CustomFunction : 
>> public Function” must be vector-valued. Three components in a 
>> three-dimensional space.  Otherwise, there is no point in interpolation.
>> This kind of vectorial approximations is a bread-and-butter topic in 
>> magnetics. See, for example, equation (7) in:
>> https://ieeexplore.ieee.org/document/497322 
>> 
>> In short, the source, i.e the current vector potential, must be projected on 
>> the space spanned by the vector-valued shape functions. Otherwise, the 
>> simulation is numerically unstable. The last, from my experience, is 
>> definitely true.
> 
> I think you already found your solution, but just for clarity: When we use 
> the term "interpolation", we typically ask for (scalar) coefficients U_i so 
> that
> 
>  u_h(x_j) = sum U_i \phi_i(x_j)  =  g(x_j)
> 
> where g is given and x_j are the node points. The problem is that for the 
> Nedelec element, this is not always possible: Not all possible vectors g(x_j) 
> can be represented. This makes sense because if you have N node points in 3d, 
> then you have N scalar coefficients U_i, but you have 3N components of the 
> values g(x_j).
> 
> One way to deal with this is to associate a vector, let's say y_j with every 
> node point x_j, and require that
> 
>  y_j \cdot u_h(x_j) = sum U_i y_j \cdot \phi_i(x_j)  =  y_j \cdot g(x_j)
> 
> These y_j could, for example, be the tangential direction associated with the 
> shape function phi_j. One *could* call this a variation of the term 
> "interpolation", but it is not what VectorTools::interpolate() implements. It 
> would probably not be terribly difficult to implement this kind of function, 
> however!
> 
> 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/567f6646-df23-8c97-f210-87fd5a74e3ae%40colostate.edu.

-- 
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/DDD82757-089D-4391-A367-5464AA304081%40gmail.com.

Re: [deal.II] dealii/spack on apple m1

[Jean-Paul Pelteret]

Dear Praveen,

Even though you’re trying to install deal.II, it would seem that the issue that 
you documented

sysctl: unknown oid 'machdep.cpu.leaf7_features'
sysctl: unknown oid 'machdep.cpu.vendor'
sysctl: unknown oid 'machdep.cpu.model'
sysctl: unknown oid 'machdep.cpu.leaf7_features'
sysctl: unknown oid 'machdep.cpu.vendor'
sysctl: unknown oid 'machdep.cpu.model'

must be pervasive for all Spack packages. So I think that if you want to get to 
the bottom of this, then you should probably raise the question with the Spack 
developers. It might in fact be that someone has already raised this issue with 
them? 

https://github.com/spack/spack/issues/22273 

https://github.com/spack/spack/issues/22088 


In fact, there was confirmation of an initial fix on a feature branch just 
hours ago:
https://github.com/spack/spack/issues/22088#issuecomment-820694521 


Best,
Jean-Paul

> On 15. Apr 2021, at 11:11, Praveen C  wrote:
> 
> Thank you for sharing your experience.
> 
> So it looks like we cannot yet install spack natively, right ?
> 
>> On 15-Apr-2021, at 12:08 PM, Alberto Salvadori > > wrote:
>> 
>> 1 - After opening a terminal rosetta, installing gcc, installing deal.ii via 
>> spack and using gfortran from gcc installation, it works just fine
> 
> Here both gfortran and spack are under rosetta.
> 
>> 2 - Even in a rosetta terminal, the current dmg package does not seem to work
>> 3 - After opening a terminal rosetta, NOT installing gcc, installing deal.ii 
>> via spack and using gfortran from homebrew installation, deal.ii apparently 
>> does not work
> 
> Here gfortran is native but spack is under emulation, which does not work.
> 
>> 4 - I had some issues with openmpi after installation, because of the 
>> dynamic library that apparently conflicts with cmake. My skills are very 
>> limited, but with some further work (that I cannot recall now)
>> I made it, even with Xcode projects.
> 
> Best
> praveen
> 
> -- 
> 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/2A8F616D-FF4B-4993-95B1-32BBEE43A00F%40gmail.com
>  
> .

-- 
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/8910C8E4-76F0-404B-B689-DBECDA550927%40gmail.com.

Re: [deal.II] interpolate FE_Nelelec

[Jean-Paul Pelteret]

Dear John,

I’m not sure that there is an interpolation function that would work in that 
way for Nedelec elements (there is 
VectorTools::project_boundary_values_curl_conforming_l2() 

 for Neumann boundary conditions, not that this is particularly useful for you 
here). As always we’d be happy to accept a contribution to the library for the 
extension that you require!

You don’t mention specifically what you’re trying to model, or where this 
interpolated function is to be used, so I’m just going to throw out a couple of 
things for you to think about and decide if they’re valid or of use to your 
specific application. What I’ve done in the past is to use a dim-component 
Function for the free current source, and I’d written a check (which I’ve 
pasted below) to verify that I’d not set up this source function incorrectly. 
Admittedly, I had a relatively straight-forward geometry so it wasn’t 
challenging to write such a source function. If you’ve got a more complex setup 
with the current source derived from some secondary finite element problem then 
maybe such an approach is not appropriate. But if it so happens that you can 
define or solve for a scalar potential whose gradient is the source current, 
then this is divergence free if the scalar potential is approximated using 
Lagrange polynomials (i.e. FE_Q 
 . You can then use 
an FEFieldFunction 

 to compute this gradient at each point within the current source, to act as a 
source term for the magnetic vector potential problem.

Best,
Jean-Paul

template 
void WireMagneticField::verify_source_terms () const
{
  TimerOutput::Scope timer_scope (computing_timer, "Verify source terms");

  hp::FEFaceValues hp_fe_face_values (mapping_collection,
   fe_collection,
   qf_collection_face,
   update_quadrature_points |
   update_normal_vectors |
   update_JxW_values);

  // To verify that the source terms are divergence free,
  // we make use of the divergence theorem:
  // 0 = \int_{\Omega_{e}} div (J_f)
  //   = \int_{\partial\Omega_{e}} J_f . n

  typename hp::DoFHandler::active_cell_iterator
  cell = hp_dof_handler.begin_active(),
  endc = hp_dof_handler.end();
  for (; cell!=endc; ++cell)
  {
if (cell->subdomain_id() != this_mpi_process) continue;

double div_J_f = 0.0;
for (unsigned int face=0; face::faces_per_cell; ++face)
{
  hp_fe_face_values.reinit(cell,face);
  const FEFaceValues _face_values = 
hp_fe_face_values.get_present_fe_values();
  const unsigned int  _fq_points = fe_face_values.n_quadrature_points;

  std::vector > source_values (n_fq_points, 
Vector(dim));
  function_free_current_density.vector_value_list 
(fe_face_values.get_quadrature_points(),
   source_values);

  for (unsigned int fq_point=0; fq_point J_f ({source_values[fq_point][0],
  source_values[fq_point][1],
  source_values[fq_point][2]}); // Note: J_f 
must be divergence free!
const double JxW = fe_face_values.JxW(fq_point);
const Tensor<1,dim>  = fe_face_values.normal_vector(fq_point);

div_J_f += (J_f*N) * JxW;
  }
}

AssertThrow(std::abs(div_J_f) < 1e-9, ExcMessage("Source term is not 
divergence free!"));
  }
}

> On 16. Apr 2021, at 19:36, John Smith  wrote:
> 
> Dear Simon,
> 
> Thank you for your reply. Your suggestion definitely works. I used functions 
> that output one component when I was interpolating scalar potentials. It 
> works well. 
> 
> However, the FE_Nedelec is different. It implements edge elements. They are 
> vector-based. That is, functions are represented by a superposition of 
> vector-valued shape functions: 
> \vec{A} = \sum u_i vec{N}_i . 
> Therefore, the output of the "value" method in “class CustomFunction : public 
> Function” must be vector-valued. Three components in a three-dimensional 
> space.  Otherwise, there is no point in interpolation.
> 
> This kind of vectorial approximations is a bread-and-butter topic in 
> magnetics. See, for example, equation (7) in:
> 
> https://ieeexplore.ieee.org/document/497322 
> 
> 
> In short, the source, i.e the current vector potential, must be projected on 
> the space spanned by the vector-valued shape functions. Otherwise, the 
> simulation is numerically unstable. The last, from my experience, is 
> definitely true. 
> 
> Best,
> John
> 
> On Fri, Apr 16, 2021 at 5:28 PM simon...@gmail.com 
>   

Re: [deal.II] Mesh Refinement & Periodic B.C.

[Jean-Paul Pelteret]

Hi Stephen,

I know that Wolfgang has already answered you and has mentioned that having the 
refinement levels differ across periodic interfaces is permitted. At some point 
I wanted to ensure that they were identical, and I wrote a little function to 
do that and have pasted it below just in case its of any use to you. From this 
part of you question

> elements on opposite sides of linked boundaries to be of the same size 
> locally otherwise the constraints won't match

I’m curious to know if you mean that the elements must be conformal across the 
interface? There seems to be a wide body of literature that discusses the weak 
imposition of periodic constraints, so I guess if you take that approach then 
there’s (probably) no specific requirements for the mesh to match across the 
interface.

Best,
Jean-Paul


template 
void
add_periodic_refinement_signals(Triangulation )
{
  // Before refining we ensure that periodic face pairs have the same
  // refinement flag.
  {
auto signal_periodic_faces_symmetric_marking = []() -> 
void {
  for (typename Triangulation::active_cell_iterator cell = 
triangulation.begin_active(); cell != triangulation.end(); ++cell)
{
  for (unsigned int face = 0; face < 
GeometryInfo::faces_per_cell; ++face)
{
  if (cell->has_periodic_neighbor(face))
{
  if (cell->refine_flag_set())
{
  cell->periodic_neighbor(face)->clear_coarsen_flag();
  cell->periodic_neighbor(face)->set_refine_flag();
}
  else if (cell->periodic_neighbor(face)->refine_flag_set())
{
  cell->clear_coarsen_flag();
  cell->set_refine_flag();
}
  else if (cell->coarsen_flag_set())
{
  cell->periodic_neighbor(face)->clear_refine_flag();
  cell->periodic_neighbor(face)->set_coarsen_flag();
}
  else if 
(cell->periodic_neighbor(face)->coarsen_flag_set())
{
  cell->clear_refine_flag();
  cell->set_coarsen_flag();
}
}
}
}

  // Its quite possible that, after all of this, we violate some
  // of the 2:1 cell level ratio expectations... Thats this error:
  // An error occurred in line <12816> of file 
<.../dealii/source/grid/tria.cc> in function
  // virtual bool dealii::Triangulation<2, 
2>::prepare_coarsening_and_refinement() [dim = 2, spacedim = 2]
  // The violated condition was:
  // cell_is_patch_level_1(cell)
  // To fix this, we  make the following call:
  triangulation.prepare_coarsening_and_refinement();
};

// Add signals

triangulation.signals.pre_refinement.connect(signal_periodic_faces_symmetric_marking);
  }
   }

> On 7. Apr 2021, at 20:24, Stephen  wrote:
> 
> Hi all,
> 
> Has anyone here successfully implemented mesh refinement for problems with 
> (spatial) periodic boundary conditions before? If so, I'd welcome ideas on 
> the best way to approach the problem. As far as I can tell, it is a 
> requirement in deal.II for the elements on opposite sides of linked 
> boundaries to be of the same size locally otherwise the constraints won't 
> match and, I'd imagine, bad things would happen. What is the best way to 
> maintain these constraints assuming an arbitrary refinement vector? I'm 
> thinking the best approach is to just refine the mesh as normal then "patch 
> it up" through a second sweep to ensure the mesh sizes on opposite sides of 
> the linked boundaries are the same by forcing additional refinement if 
> necessary.
> 
> Thanks,
> 
> Stephen
> 
> -- 
> 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/21c92dac-55de-4ef8-89c7-f3aee063c1a4n%40googlegroups.com
>  
> .

-- 
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

Re: [deal.II] Creating a FESystem with bulk and surface FE spaces

[Jean-Paul Pelteret]

HI Manuel,

I’ve got a brief answer to your followup questions, but let me first say that 
Andrew’s suggestion, which seems to be the most elegant/optimal approach to the 
problem, is one that is possible to for you to realise. It’s also made me think 
that perhaps some of the tools that have been added somewhat recently to help 
tackle immersed problems could be of help? I have zero experience with these 
tools, so I’m just going to put it out there for you to investigate and draw 
your own conclusions from:

https://dealii.org/current/doxygen/deal.II/namespaceNonMatching.html 
<https://dealii.org/current/doxygen/deal.II/namespaceNonMatching.html>
https://dealii.org/current/doxygen/deal.II/step_60.html 
<https://dealii.org/current/doxygen/deal.II/step_60.html>

I’m sure that if you have any questions on those, then the other developers 
would be willing to help out to answer them!

> My question is what happens to the DoFs that are shared by a cell with a 
> FE_Nothing space and another cell with a FE_Q space? This is of course going 
> to happen at all cells in the boundary since some DoFs of those cells are 
> indeed in the boundary while others are still internal DoFs. Does this make 
> sense? I suppose I can apply a constraint to those internal DoFs, similar to 
> my previous "hack”.

Yes, that’s correct. You’d be doing exactly the same thing as you’d detailed 
before, but just for fewer elements / DoFs.

> The advantage following your suggestion is that the number of DoFs that I 
> need to constrain is much smaller. 

Indeed. So not only is your global linear system smaller, but the 
AffineConstraints object also has less entries. Why this might be important is 
due to a comment that can be found in the AffineConstraints introductory notes 
<https://dealii.org/current/doxygen/deal.II/classAffineConstraints.html>:

The class is meant to deal with a limited number of constraints relative to the 
total number of degrees of freedom, for example a few per cent up to maybe 30 
per cent; and with a linear combination of M other degrees of freedom where M 
is also relatively small (no larger than at most around the average number of 
entries per row of a linear system). It is not meant to describe full rank 
linear systems.

Its hard to say whether this might have a performance effect wrt. what you’re 
trying to do, but nevertheless using Fe_Nothing to limit the number of DoFs 
that you have to constrain would likely mean that you could consider finer 
discretisation before you have to start considering what the impact of the 
number of constraints have on performance (and anything else).

Best,
Jean-Paul


> On 29. Mar 2021, at 22:27, manuel.q...@gmail.com 
>  wrote:
> 
> Hi Jean-Paul, 
> 
> I have taken a look at FE_Nothing and hp::DoFHandler. If I understand 
> correctly, the idea is that all the interior cells will use an FE_Nothing 
> space and the boundary cells will use a standard FE_Q space, right? My 
> question is what happens to the DoFs that are shared by a cell with a 
> FE_Nothing space and another cell with a FE_Q space? This is of course going 
> to happen at all cells in the boundary since some DoFs of those cells are 
> indeed in the boundary while others are still internal DoFs. Does this make 
> sense? I suppose I can apply a constraint to those internal DoFs, similar to 
> my previous "hack". The advantage following your suggestion is that the 
> number of DoFs that I need to constrain is much smaller. 
> 
> Thanks for your suggestion. I think this is a very nice approach, 
> 
> Manuel 
> 
> 
> On Monday, March 29, 2021 at 8:09:39 PM UTC+3 Jean-Paul Pelteret wrote:
> Hi Manuel,
> 
> As a small addition to what Wolfgang has already suggested, you can also 
> considering using the hp framwwork in conjunction with FE_Nothing 
> <https://dealii.org/current/doxygen/deal.II/classFE__Nothing.html> elements 
> in order to, effectively, disable elements in the interior of the volumetric 
> domain instead of constraining them directly. This is the equivalent of 
> saying that you simply wouldn’t assign DoFs for those elements, but rather 
> only for the elements that are positioned along the boundary of the domain. 
> You’d still have to constrain the DoFs that are off of the surface itself, 
> but at least there are a lot fewer DoFs that require this.
> 
> Best,
> Jean-Paul
> 
> 
>> On 29. Mar 2021, at 18:59, Wolfgang Bangerth > > wrote:
>> 
> 
>> 
>> Manuel,
>> 
>>> I need to solve a system of many PDEs (currently 18). The actual number 
>>> changes since the PDEs are defined by a truncated infinite sum and some 
>>> recursive equations. Anyway, the first two equations are defined on a 2D or 
>>> 3D domain (call it Omega) and the rest is only defi

Re: [deal.II] Doubt in collect_periodic_faces() documentation

[Jean-Paul Pelteret]

Hi Vachan,

To supplement the link that Wolfgang shared, there’s also a detailed 
step-by-step guide for contributing patches to the library that can be found on 
our Wiki page:
https://github.com/dealii/dealii/wiki/Contributing 


Looking forward to your contribution!
Jean-Paul


> On 30. Mar 2021, at 14:22, Wolfgang Bangerth  wrote:
> 
> On 3/30/21 11:20 AM, vachanpo...@gmail.com wrote:
>> I would like to. However, I do not know how to write patches. Nor have I any 
>> experience with using github collaboratively; I have only used it for my 
>> personal repos. I would love to contribute if the experts can provide a 
>> little guidance.
>> I have also noticed a small mistake in the param doc of 
>> subdivided_hyper_cube() 
>> .
>>  I would like to submit a patch for that too. I have never seen a library 
>> documented so well (in the few years since I started doing CFD). I wish it 
>> stays so and would love to contribute in making its doc better.
> 
> Vachan,
> we would certainly love to have those patches! We wrote up some instructions 
> on how to contribute here:
>  https://dealii.org/participate.html
> Does this help? If not, let us know and we'll walk you through the process!
> 
> 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/6b3ba865-88ea-11fb-cf3b-1b47ae9f876c%40colostate.edu.

-- 
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/35E57967-35BF-43C3-9B60-FC33AEEAD4AB%40gmail.com.

Re: [deal.II] Creating a FESystem with bulk and surface FE spaces

[Jean-Paul Pelteret]

Hi Manuel,

As a small addition to what Wolfgang has already suggested, you can also 
considering using the hp framwwork in conjunction with FE_Nothing 
 elements in 
order to, effectively, disable elements in the interior of the volumetric 
domain instead of constraining them directly. This is the equivalent of saying 
that you simply wouldn’t assign DoFs for those elements, but rather only for 
the elements that are positioned along the boundary of the domain. You’d still 
have to constrain the DoFs that are off of the surface itself, but at least 
there are a lot fewer DoFs that require this.

Best,
Jean-Paul

> On 29. Mar 2021, at 18:59, Wolfgang Bangerth  wrote:
> 
> 
> Manuel,
> 
>> I need to solve a system of many PDEs (currently 18). The actual number 
>> changes since the PDEs are defined by a truncated infinite sum and some 
>> recursive equations. Anyway, the first two equations are defined on a 2D or 
>> 3D domain (call it Omega) and the rest is only defined on the boundary of 
>> Omega. My first idea was to create a FESystem object and attach to it 2 FE 
>> spaces defined on Omega and 16 FE spaces defined on the boundary. That is, I 
>> tried these options
>>  * FESystem<1, 2> fe(FE_Q<2, 2>(degree), 2, FE_Q<1, 2>(degree), 16)
>>  * FESystem<2, 2> fe(FE_Q<2, 2>(degree), 2, FE_Q<1, 2>(degree), 16)
>> However, that produced compilation errors. What I understand is that the 
>> FESystem must be created by either FE spaces defined in Omega or FE spaces 
>> defined in the manifold, but not a combination.
> 
> Yes, that is correct -- because FESystem is derived from 
> FiniteElement, the elements that form the system must have a 
> unique 'dim' parameter.
> 
> 
>> As a way around I tried (a very ugly hack) where I defined all FE spaces in 
>> Omega and then add constraints to all DoFs associated with the internal 
>> nodes for the variables that are defined on the manifold. This sounds like a 
>> tremendous waste of resources since most of the equations in my system live 
>> in the manifold, so I end up constraining most of the DoFs. And even worse, 
>> it produced a matrix that seems to be sometimes singular and sometimes 
>> non-singular. That is, I can solve the system and get accurate results (I 
>> have the exact solution) for some grids but in other grids the matrix is 
>> singular so I get NaNs. I suspect this problem is a consequence of 
>> constraining most of my DoFs. FYI, the solver that I am using is the MUMPS 
>> implementation in PETSc.
> 
> I don't know about the origins of the illposedness, but this is a valid 
> approach. ASPECT, for example, does this kind of thing when implementing a 
> free boundary. You could take a look here
> https://github.com/geodynamics/aspect/blob/master/include/aspect/mesh_deformation/free_surface.h
> https://github.com/geodynamics/aspect/blob/master/source/mesh_deformation/free_surface.cc
> 
> In particular, ASPECT just doesn't do anything at all with the interior 
> degrees of freedom in the solve phase:
> https://github.com/geodynamics/aspect/blob/master/source/mesh_deformation/free_surface.cc#L345-L352
> In other words, we happily solve a linear system with a matrix with a lot of 
> zero rows and columns. I've got questions about this here:
>  https://github.com/geodynamics/aspect/issues/3110
> But it seems to work.
> 
> 
>> I wonder if there is a proper or standard way to construct systems that are 
>> defined by some equations in a domain and some in a manifold of the domain. 
>> I definitely don't think constraining most of my DoFs is the way to go.
> 
> The "proper" way to deal with this would probably be to have two DoFHandler 
> objects with dim and dim-1, and then to build a coupled linear system. I 
> believe that we have most of the building blocks for this already in place 
> (take, for example, a look at step-60 and step-70) but there is no concrete 
> example of coupling bulk and surface problems. It has been on my TODO list 
> for quite a while already to write a tutorial program for this and see what 
> it would take to make that work properly.
> 
> Out of curiosity, what is the problem you are trying to solve?
> 
> 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 
> 

Re: [deal.II] The periodic boundary condition for an RVE analysis

[Jean-Paul Pelteret]

Hi Farzin,

To complement what Daniel already said, I noted in this previous post 
 an approach 
whereby you solve for the microscopic fluctuation field directly (i.e. using 
homogeneous periodic constraints) and then correct for the superimposed linear 
deformation field as a post-processing step. Although I’d previously approached 
the problem in the same general manner that you’ve described (specifically, 
introducing a Lagrangian periodicity frame to compute the inhomogeneity for the 
affine constraints), a colleague of mine found success using the simpler method 
of first solving for the fluctuation field. 

I hope that this (well, the information in my prior post) helps a bit. 

Best,
Jean-Paul

> On 12. Mar 2021, at 22:44, Daniel Arndt  wrote:
> 
> Farzin,
> 
> it appears what you want to do is almost what 
> DoFTools::make_periodicity_constraints(https://www.dealii.org/current/doxygen/deal.II/namespaceDoFTools.html#a929249499b1e5624728d212e90a8e037
>  
> )
>  gives you.
> You "only" have to apply the additional displacement +H(\chi_+-\chi_-). You 
> can check for the support points of the constraints using 
> DoFTools::map_dofs_to_support_points(https://www.dealii.org/current/doxygen/deal.II/namespaceDoFTools.html#a5514e4f59ea659f63953d62ca429eaff
>  
> )
>  assuming that you are using a nodal finite element. With this information, 
> you should be able to calculate the displacement for each constrained dof pair
> and add it using AffineConstraints::set_inhomogeneity 
> (https://www.dealii.org/current/doxygen/deal.II/classAffineConstraints.html#a370b2b485a03fe2bb82c1098a6bdfc4c
>  
> ).
> 
> Best,
> Daniel
> 
> Am Fr., 12. März 2021 um 12:29 Uhr schrieb Farzin Mozafari 
> mailto:mozafari.far...@gmail.com>>:
>  
> 
> Dear all,
> 
>  
> 
> I am a new user of Deal ii. I am going to solve a multiscale problem in solid 
> mechanics using Deal ii. To this end, I am going to model a simple cube with 
> a linear elastic material under periodic boundary condition as the RVE of the 
> material containing its microstructural features. Then by applying simple 
> shear and uniaxial strain-controlled boundary conditions, I am going to 
> determine the associated components of the averaged stress and elasticity 
> tensor.
> 
>  
> 
> The way that usually people use is to involve an H matrix (as explained in 
> the attached file). In the literature, this method is called the generalized 
> periodic boundary condition. Indeed, this method makes us able to directly 
> apply shear and uniaxial loading through the H matrix components (i.e. 
> Displacement gradient matrix). I am not sure how can I implement this method 
> in deal II.
> 
>  
> 
> I would be grateful if anyone gives me a piece of advice to carry it out 
> properly.
> 
>  
> 
> Regards
> 
> Farzin
> 
>  
> 
>  
> 
> 
> -- 
> 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/7D60CE96-E78D-45FA-A5C7-C51AAD2E3918%40hxcore.ol
>  
> .
> 
> -- 
> 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/CAOYDWbLbQmfrgPJxsoYc8k%2B54vF6rugJ%2B4hHuA61mfDv9HKA3A%40mail.gmail.com
>  
> .

-- 
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 

Re: [deal.II] Remeshing strategy discussion and implementation

[Jean-Paul Pelteret]

Hi Rajat,

I’m a bit ashamed to say that I’ve had a pull-request that adds support for 
Mesquite and Verdict to the library out for quite some time now. That’s this 
one here:
https://github.com/dealii/dealii/pull/8196 

That includes all of the CMake stuff to pick up Mesquite and Verdict that are 
built as stand-alone projects, as well as the header-only implementation of the 
grid smoothing tools as well as a load of tests (which also demonstrate how to 
use the interface). You can do the untangling/smoothing in the 
original/reference configuration or the current/Eulerian configuration (so, 
untangle the displaced mesh). Everything works “in memory” — no copies to and 
from temporary files. The only thing that I think that isn’t yet implemented 
(if my memory serves me correctly) is support for distributed triangulations 
(and some of the quality algorithms from Verdict).

In case its useful, there’s also a sister pull request that adds Mesquite to 
our bundled libraries:
https://github.com/dealii/dealii/pull/5971 
 


Here your can see a glimpse of the untangler at work:
https://github.com/dealii/dealii/pull/5971#issuecomment-369842462 


Unfortunately things got a little tricky, because Mesquite is now considered a 
“dead” project upstream. So we had to pause to think about how we’d make this 
available for users that get the library from all sources (i.e. build it 
themselves vs. builds distributed with linux). After that, I didn’t have the 
time to work on this any further, and I’ve not found the right occasion to make 
another push to get it into the library. But maybe after this next release I’ll 
try to do so. 

For now, you can use Mesquite+Verdict from the pull request in (at least) one 
of these two ways:
1. By adding CMake configuration files from one of those two open PRs to your 
own deal.II source, and then just transferring the header-only implementation 
that can be found here: 
https://github.com/dealii/dealii/pull/8196/files#diff-16296062eac3dac69ddadc0f4d1647c1d8ad7c2d82e108ccb3d69932c88ba90a
 

 . Or you can rebase the branch from the PR on a more recent version of deal.II 
and use it “as is”. Github doesn’t indicate that there are any merge conflicts.
2. You could write your own CMake configuration files for your own project that 
can be used to pick up a Mesquite + Verdict, and then add the header file that 
does the implementation directly to your project.

I know that neither of these are a great solution, but they’re probably less 
effort than writing this all from scratch? Since there’s definitely some active 
interest from the community, I’ll try a bit harder to get this feature into the 
library in the release after the next one.

Best,
Jean-Paul


> On 1. Mar 2021, at 23:55, rajat.a...@gmail.com  
> wrote:
> 
> Hello everyone,
> 
> I am trying to solve a 3d solid mechanics problem using deal.ii, PetSc, and 
> p4est (p::d::triangulation) where in the mesh moves in time (like step-18).  
> After a while, the distortion in the mesh is too much and I am looking for a 
> re-meshing strategy that can help untangle the mesh and transfer the solution 
> and Gauss point history variables from old mesh to new mesh. 
> 
> 
> After looking at several posts in this group related to the above use case, I 
> have come to the following strategy. Please let me know if this is okay. I 
> would also like to contribute my solution for anyone else to use, therefore I 
> am also open to any implementation-specific suggestions.
> 
> 1. Write the old mesh in the vtk file.
> 2. Read the mesh in mesquite and smoothen it.
> 3. Calculate the "displacement" of the mesh coordinates and write them in a 
> file.
> 
> 4. Now, restart your code with the old mesh file, and setup everything like 
> before.
> 5. Create a new triangulation that is same as old mesh and then move its 
> verticesusing the displacements calculated above in Mesquite.
> 
> 6. You may use FeFieldFunction to transfer the solution from the old mesh to 
> the new mesh by one of the following 2 methods:
>   a) L2 projection from old mesh to new mesh (Projection)
>   b) Simple evaluation of solution values on the new nodal coordinates 
> (Interpolation)
> 
> Note 1: One good thing in this approach is that FeFieldFunction would not 
> throw exception if you ensure that the new mesh has the same partition as the 
> old mesh. In this case,  new mesh is just displaced from the old mesh.
> 
> Note 2: Also, instead of writing mesh and displacement solutions to file, 
> things can be transferred in memory but the strategy remains the same.
> 
> Here are my questions related to implementation.
> 
> 
> Q1. Please let me know if this strategy is fine. 
> 
> Q2. Can we 

Re: [deal.II] Inhomogeneous periodic boundary constraints

[Jean-Paul Pelteret]

Hi Alex,

I can only give you a very brief answer right now: Using the 
AffineConstraints::set_inhomgeneity() 
 
method, you can add the inhomogeneity after constructing the homogeneous 
periodic constraints. If you're stuck trying to figure out which global 
DoF index you're wanting to set the inhomogeneity for, then there are 
some other posts on the group and information in the Wiki that describe 
some ways that you can
get that information. If you're still stuck, then let us know and I (or 
someone else) can try to give you some more details.


Best,
Jean-Paul

On 25.02.21 16:45, Alex Cumberworth wrote:
I need to implement periodic boundary constraints with 
inhomogeneities. From reading through the documentation and source 
code of the library, it seems that to do this I will need to modify 
the set_periodicity_constraints function in the 
dof_tools_constraints.cc file to also add an inhomogeneity. Is there a 
simpler way to do this that I missed that allows me to use the 
make_periodicity_constraints() function and then add the inhomogeneity 
after calling it?


To give some context, I am solving an elasticity problem that involves 
taking a beam, deforming it, and "glueing" together some of the faces 
(e.g. to form a ring -- I included an image of this in a previous post 
).


Any thoughts would be greatly appreciated.

Best,
Alex
--
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/777d38f4-bc4d-459d-aef6-63c35143997dn%40googlegroups.com 
.


--
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/3f242711-8fd5-62d1-007f-ea0594fdc57a%40gmail.com.

Re: [deal.II] Multiple material IDs

[Jean-Paul Pelteret]

Hi Corbin,

To add to Daniel's suggestion, you could also associated some generic 
data structures to your cell that you could store the multi-material id 
data in, and query it as you like. I can think of three different ways 
to do this:


1. Directly attach your data structure to each cell's user pointer. See 
the TriaAccessor::set_user_pointer() 
 
function and the other functions related to the user_pointer. Step-18 
 
uses the cell user pointer to store quadrature point data.
2. Create a map between the CellID 
 and your 
data structure, e.g. std::map>
3. In the same spirit as suggestion (2), you can use the CellDataStorage 
 
class to associate cell iterators with some generic data. Step-44 
 
leverages this class to store quadrature point data.


I hope that this help you achieve what you're trying to do.

Best,
Jean-Paul

On 08.02.21 02:06, Daniel Arndt wrote:

Corbin,

if you have a maximal range for either of the two material ranges you 
could just compute a single material ID by

material_id   = material_id1 * max_material_id2 + material_id2
material_id2 = material_id % max_material_id2
material_id1 = material_id / max_material_id2

Best,
Daniel

Am So., 7. Feb. 2021 um 17:23 Uhr schrieb Corbin Foucart 
mailto:corbin.fouc...@gmail.com>>:


Hello all,

I've read the documentation on material ID and it's not clear to
me if there's a way to define more than one material ID. This
could be helpful when wanting to isolate elements that correspond
to the same material, but also when looking to isolate elements of
different materials that might exist in a particular "layer" of
the domain.

I can see three ways to define multiple IDs per each element:

 1. Define two identical meshes and set the material IDs
differently on each. This seems suboptimal because I don't
really want to use up the extra memory
 2. Define functions that re-label the material IDs based on the
current task at hand, at the expense of extra computation and
logic
 3. Define an external vector of structs that contain the
different element IDs by cell, but then it's unclear how to
filter elements by MaterialIDEqualTo() without first
relabeling as in (2)

Is there a standard way to do this that I'm missing? Any advice is
much appreciated!

Best,
Corbin

-- 
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/a66dcb53-8a6b-46ce-8c29-90067829a0a3n%40googlegroups.com

.

--
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%2B_k%3DyZ%2BOuEp55VxxzjFRscq1U3QUC5qKSn2RRkd6oATQ%40mail.gmail.com 
.


--
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/7bf57952-fb0c-7759-11a8-be90215fd7f8%40gmail.com.

Re: [deal.II] Hashing / mapping Point locations to material ID

[Jean-Paul Pelteret]

Hi Corbin,

Just add such a hash function for Point. 


In case you haven't yet done this, I've dug out an old snippet of code 
that implements a reliable hash function for the point class. I used 
this approach successfully when implementing some exotic constraints 
manager, so hopefully it would suit your purposes too.


template
structPointHashFunc
{
std::size_t
operator()(constdealii::Point) const
{
std::size_th;
h =std::hash()(p[0]);
if(spacedim >1)
{
std::size_th2 =std::hash()(p[1]);
h =h ^(h2 <<1);
}
if(spacedim >2)
{
size_th3 =std::hash()(p[2]);
h =h ^h3;
}
if(spacedim >3)
{
AssertThrow(false, ExcNotImplemented());
}
returnh;
}
};// struct PointHashFunc
template
usingPointMap=
std::unordered_map, T, PointHashFunc>;

Best,
Jean-Paul

On 06.02.21 22:15, Wolfgang Bangerth wrote:

On 2/6/21 1:55 PM, Corbin Foucart wrote:


The compiler is rightly complaining that there isn't a hash method 
for the Point object, and it seems like this could indeed be 
dangerous, because of floating point comparison later between Point 
objects during lookup.


Just add such a hash function for Point. It's true that two nearby 
points will have different hash values, but that shouldn't stop you 
from using hashes if you query the same points over and over.


That said, I would suggest to do the indexing not on geometric 
locations but the logic position of a cell. You can either do that 
with a cell iterator itself, or if you want to make it work in a 
parallel context, the CellId of a cell.


Best
 W.




--
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/910a7400-ecd9-4d9e-b76b-db83370fc0d6%40gmail.com.

Re: [deal.II] Transferring data between two triangulations (dof handlers)

[Jean-Paul Pelteret]

Hi Yu,

Have you tried the VectorTools::interpolate_to_different_mesh() 
 
functions? It sounds to me like they perform the operation that you're 
trying to do. They require that the two DoFHandlers originate from the 
same coarse triangulation. If you have hanging nodes, then you want to 
use the variant that takes in the affine constraints as an argument. 
Note as well that if you're using a parallel::distributed::Triangulation 
then you have to ensure that the partitioning is the same for both 
meshes -- the note in the documentation states how to ensure that this 
happens.


Best,
Jean-Paul


On 31.01.21 20:35, Yu Leng wrote:

Dear all,

I would like to transfer data between two grids, which originate from 
the same coarse grid.
Here are two approaches I can come up with. I would appreciate any of 
your feedbacks/suggestions.


1. Two triangulations and two dofhandlers. I can not get this to work 
using solution transfer even if I reinitialize the dofhandler with 
another triangulation.


2. One triangulation. Store the refinement/coarsen history and 
refine/coarsen every time I transfer data.



Thanks,
Yu
--
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/25ba90e7-45b8-486c-847d-370b4fc7b337n%40googlegroups.com 
.


--
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/2768330a-48ea-2f63-1025-6c698141e2a9%40gmail.com.

Re: [deal.II] ADOL-C not found through SPACK installation of deal.ii 9.2

[Jean-Paul Pelteret]

Hi Behrooz,

When you install deal.II using Spack, it is completely isolated from the 
system environment. That way, you can install multiple versions of the 
same package without them conflicting with one another. Before you can 
use deal.II though spack, you populate all of the environment variables 
with the paths to deal.II and its dependencies. The quickest way to do 
this is using "spack load" which is documented here 
 
(spack's documentation) and here 
 
(the deal.II wiki). For you, this would mean running "spack load 
dealii@9.2" or something similar, and then simply running "cmake ." in 
the tutorial folder (don't forget to delete CMakeCache.txt first). You 
can also look into using filesystem views 
 
and environment modules 
 to the same 
effect.


Best,
Jean-Paul

On 17.01.21 12:50, Behrooz Karami wrote:

Hi Wolfgang,

That's true but maybe I should have given a bit of a background here.

I have three versions of deal.ii installed at the moment. The first 
one 9.0 installed through Spack, the second one 9.2 manually installed 
according to procedures described in the readme file; and the third 
one again 9.2 but installed through Spack.


The reason for the third installation was exactly the same problem 
mentioned here (which happened after the 2nd installation). Meaning 
that during the 2nd installation I didn't call my required libraries . 
But as the third attempt I decided to use Spack as it was already 
available on the machine and could install all the libraries along the 
way.
Finally the third installation was successful according to the output 
log. And when I check the config. files they are correct. I mean it 
seems that installation has been done with PETSc, MPI and all other 
required libraries. The configurations are also correct e.g. it has 
been indicated that:


DEAL_II_WITH_MPI = ON
DEAL_II_WITH_PETSC = ON
DEAL_II_PETSC_WITH_COMPLEX = FALSE (not OFF!)

I attach the config. files here as a reference.

So to me still it seems that deal.ii is not looking at the right folder.

I have not installed deal.ii in "/usr/local" but I could see that 
somehow it has been installed there (as well) probably by default! I 
guess it in fact has happened during the second installation. Because 
I got the same message when I was using the 2nd installation. I am not 
sure exactly which of my modifications resolved it but it was revealed 
to me that somehow I have a copy of deal.ii there which is called as a 
first choice.


Regards,
Behrooz



On Sat, Jan 16, 2021 at 5:25 PM Wolfgang Bangerth 
mailto:bange...@colostate.edu>> wrote:


On 1/16/21 2:04 AM, Behrooz Karami wrote:
>
> Error! This tutorial requires a deal.II library that was
configured with
>    the following options:
>
>        DEAL_II_WITH_MPI = ON
>        DEAL_II_WITH_PETSC = ON
>        DEAL_II_PETSC_WITH_COMPLEX = OFF
> However, the deal.II library found at /usr/local was configured
with these
>    options
>
>        DEAL_II_WITH_MPI = OFF
>        DEAL_II_WITH_PETSC = OFF
>        DEAL_II_PETSC_WITH_COMPLEX =
>
> This is while I use the
> 'cmake -DDEAL_II_DIR=/path/to/the/source .'
> command to address the right configurations. Also when I check
the cmake
> configurations in installed folder they look OK and with correct
configurations.
> Could you please advise me on this issue as well?

Behrooz -- the error message says what the problem is. step-18
requires
"DEAL_II_WITH_MPI=ON", but your installation has
"DEAL_II_WITH_MPI=OFF", and
similarly for PETSc. In order to run step-18, you need to install
deal.II with
a PETSc installation and with MPI installed, but you didn't. The
steps
necessary to do that are listed in the doc/readme.html file.

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 

Re: [deal.II] Re: issue in installing dealii@9.2 on ubuntu through spack

[Jean-Paul Pelteret]

Hi Alberto,

Thanks for pointing out that the Wiki is out of date. I've updated that 
portion of the page with the correct information.


Best,
Jean-Paul

On 15.01.21 09:25, Alberto Salvadori wrote:

Thank you, very useful.
I suggest adding this info to the wiki page , in place of git checkout 
master.


*Alberto Salvadori
* Dipartimento di Ingegneria Meccanica e Industriale (DIMI)
 Universita` di Brescia, via Branze 43, 25123 Brescia
 Italy
 tel 030 3715426

e-mail:
alberto.salvad...@unibs.it <mailto:alberto.salvad...@unibs.it>
web-page:
http://m4lab.unibs.it/faculty.html <http://m4lab.unibs.it/faculty.html>



On Thu, Jan 14, 2021 at 7:57 PM Jean-Paul Pelteret 
mailto:jppelte...@gmail.com>> wrote:


Hi Alberto,

I concur with Bruno. ADOL-C changed the location of their project
and repository, so Spack's master branch must be directing you
towards the old site. Clearly it doesn't have an updated package
for deal.II either, because its trying to deduce the location of
the deal.II tarball on GitHub. Using Spack's "develop" branch is
the way to keep up to date with the latest developments or, should
you want to be a little more conservative, you could check out
their latest tag, which is v0.16.0
<https://github.com/spack/spack/tree/v0.16.0> .

Best,
Jean-Paul

On 14.01.21 19:37, Bruno Turcksin wrote:

Alberto,

Do not use the master branch in spack. The last commit from the
master branch on spack is from 2018. I'm guessing you want to use
develop. develop for spack is the equivalent of master in deal.II

Best,

Bruno

On Thursday, January 14, 2021 at 1:20:09 PM UTC-5 Alberto
Salvadori wrote:

Dear community

I have been trying installing dealii@9.2 <mailto:dealii@9.2>
on ubuntu 18.04 gcc7.5.0, unsuccesfully.
The version 9.1.1 is already installed and works just fine,
at that installation time
I did manage to install ado...@2.7.3 <mailto:ado...@2.7.3>
and I put its path into the pacages.yaml
as I did for dea...@9.1.1 <mailto:dea...@9.1.1>
URL in fetch seem to be wrong, in fact they do not exist, if
I am not misunderdanding.
Any suggestion is appreciated.
Alberto

I did the following:

1 - in spack directory
     git checkout master

response: your branch is up to date with 'origin/master'

2 - in the same directory
    spack install dealii@9.2 <mailto:dealii@9.2>

response:
Warning: Missing a source id for ado...@2.7.3
<mailto:ado...@2.7.3>
Warning: Missing a source id for dealii@9.2 <mailto:dealii@9.2>

==> 26892: Installing dealii
==> Warning: There is no checksum on file to fetch dealii@9.2
<mailto:dealii@9.2> safely.
==>   Fetch anyway? [y/N] y
==> Fetching with no checksum.
  Add a checksum or use --no-checksum to skip this check.
==> Fetching

https://github.com/dealii/dealii/releases/download/v9.2/dealii-9.2.tar.gz

<https://github.com/dealii/dealii/releases/download/v9.2/dealii-9.2.tar.gz>
#=#=-  #       #     #=O=#     #        #
curl: (22) The requested URL returned error: 404
==> Failed to fetch file from URL:

https://github.com/dealii/dealii/releases/download/v9.2/dealii-9.2.tar.gz

<https://github.com/dealii/dealii/releases/download/v9.2/dealii-9.2.tar.gz>
    URL

https://github.com/dealii/dealii/releases/download/v9.2/dealii-9.2.tar.gz

<https://github.com/dealii/dealii/releases/download/v9.2/dealii-9.2.tar.gz> was
not found!
==> Fetching from

https://github.com/dealii/dealii/releases/download/v9.2/dealii-9.2.tar.gz

<https://github.com/dealii/dealii/releases/download/v9.2/dealii-9.2.tar.gz> 
failed.
==> Error: FetchError: All fetchers failed for
spack-stage-dealii-9.2-s4o6vff2suxztaxmilrhrzts34jngztn

/home/dealii/spack/lib/spack/spack/package.py:1127, in do_fetch:
       1124                raise FetchError("Will not fetch %s" %
       1125 self.spec.format('{name}{@version}'), ck_msg)
       1126
  >>   1127        self.stage.create()
       1128        self.stage.fetch(mirror_only)
       1129        self._fetch_time = time.time() - start_time
       1130


==> Error: Failed to install dealii due to ChildError:
FetchError: All fetchers failed for
spack-stage-dealii-9.2-s4o6vff2suxztaxmilrhrzts34jngztn
/home/dealii/spack/lib/spack/spack/package.py:1127, in do_fetch:
       1124                raise FetchError("Will not fetch %s" %
       1125 self.spec.format('{name}{@version}'), ck_msg)
  

Re: [deal.II] Re: issue in installing dealii@9.2 on ubuntu through spack

[Jean-Paul Pelteret]

Hi Alberto,

I concur with Bruno. ADOL-C changed the location of their project and 
repository, so Spack's master branch must be directing you towards the 
old site. Clearly it doesn't have an updated package for deal.II either, 
because its trying to deduce the location of the deal.II tarball on 
GitHub. Using Spack's "develop" branch is the way to keep up to date 
with the latest developments or, should you want to be a little more 
conservative, you could check out their latest tag, which is v0.16.0 
 .


Best,
Jean-Paul

On 14.01.21 19:37, Bruno Turcksin wrote:

Alberto,

Do not use the master branch in spack. The last commit from the master 
branch on spack is from 2018. I'm guessing you want to use develop. 
develop for spack is the equivalent of master in deal.II


Best,

Bruno

On Thursday, January 14, 2021 at 1:20:09 PM UTC-5 Alberto Salvadori wrote:

Dear community

I have been trying installing dealii@9.2 on ubuntu 18.04 gcc7.5.0,
unsuccesfully.
The version 9.1.1 is already installed and works just fine, at
that installation time
I did manage to install ado...@2.7.3 and I put its path into the
pacages.yaml
as I did for dea...@9.1.1
URL in fetch seem to be wrong, in fact they do not exist, if I am
not misunderdanding.
Any suggestion is appreciated.
Alberto

I did the following:

1 - in spack directory
     git checkout master

response: your branch is up to date with 'origin/master'

2 - in the same directory
    spack install dealii@9.2

response:
Warning: Missing a source id for ado...@2.7.3
Warning: Missing a source id for dealii@9.2

==> 26892: Installing dealii
==> Warning: There is no checksum on file to fetch dealii@9.2 safely.
==>   Fetch anyway? [y/N] y
==> Fetching with no checksum.
  Add a checksum or use --no-checksum to skip this check.
==> Fetching
https://github.com/dealii/dealii/releases/download/v9.2/dealii-9.2.tar.gz

#=#=-  #       #                       #=O=#     #        #
curl: (22) The requested URL returned error: 404
==> Failed to fetch file from URL:
https://github.com/dealii/dealii/releases/download/v9.2/dealii-9.2.tar.gz

    URL
https://github.com/dealii/dealii/releases/download/v9.2/dealii-9.2.tar.gz
 
was
not found!
==> Fetching from
https://github.com/dealii/dealii/releases/download/v9.2/dealii-9.2.tar.gz
 
failed.
==> Error: FetchError: All fetchers failed for
spack-stage-dealii-9.2-s4o6vff2suxztaxmilrhrzts34jngztn

/home/dealii/spack/lib/spack/spack/package.py:1127, in do_fetch:
       1124                raise FetchError("Will not fetch %s" %
       1125 self.spec.format('{name}{@version}'), ck_msg)
       1126
  >>   1127        self.stage.create()
       1128        self.stage.fetch(mirror_only)
       1129        self._fetch_time = time.time() - start_time
       1130


==> Error: Failed to install dealii due to ChildError: FetchError:
All fetchers failed for
spack-stage-dealii-9.2-s4o6vff2suxztaxmilrhrzts34jngztn
/home/dealii/spack/lib/spack/spack/package.py:1127, in do_fetch:
       1124                raise FetchError("Will not fetch %s" %
       1125 self.spec.format('{name}{@version}'), ck_msg)
       1126
  >>   1127        self.stage.create()
       1128        self.stage.fetch(mirror_only)
       1129        self._fetch_time = time.time() - start_time
       1130

Traceback (most recent call last):
  File "/home/dealii/spack/lib/spack/spack/build_environment.py",
line 801, in child_process
    return_value = function()
  File "/home/dealii/spack/lib/spack/spack/installer.py", line
1046, in build_process
    pkg.do_patch()
  File "/home/dealii/spack/lib/spack/spack/package.py", line 1167,
in do_patch
    self.do_stage()
  File "/home/dealii/spack/lib/spack/spack/package.py", line 1152,
in do_stage
    self.do_fetch(mirror_only)
  File "/home/dealii/spack/lib/spack/spack/package.py", line 1128,
in do_fetch
    self.stage.fetch(mirror_only)
  File "/home/dealii/spack/lib/spack/spack/util/pattern.py", line
68, in getter
    getattr(item, self.name )(*args, **kwargs)
  File "/home/dealii/spack/lib/spack/spack/stage.py", line 476, in
fetch
    raise fs.FetchError(err_msg, None)
spack.fetch_strategy.FetchError: All fetchers failed for
spack-stage-dealii-9.2-s4o6vff2suxztaxmilrhrzts34jngztn






--
The deal.II project is located at http://www.dealii.org/ 

Re: [deal.II] ADOL-C not found through SPACK installation of deal.ii 9.2

[Jean-Paul Pelteret]

Hi Behrooz,

It looks like you're getting some internal compiler errors:

g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
source/dofs/CMakeFiles/obj_dofs_debug.dir/build.make:169: recipe for 
target 
'source/dofs/CMakeFiles/obj_dofs_debug.dir/dof_handler_policy.cc.o' failed
make[2]: *** 
[source/dofs/CMakeFiles/obj_dofs_debug.dir/dof_handler_policy.cc.o] Error 4

make[2]: *** Waiting for unfinished jobs

This could indicate that you're still running out of memory. I would 
suggest compiling with '-j 2' or even '-j 1', just to be sure.


Let us know if you still have troubles after trying that. You're using 
GCC 7.3.0, which as far as I know shouldn't have any troubles building 
the library.


Best,
Jean-Paul

On 14.01.21 10:45, Behrooz Karami wrote:

Hi Jean-Paul,

Please kindly find the 'spack-build.out' file as attached. This is 
what Spack mentioned as a build log for details. Hope to be the 
correct one.


Thank you very much,
Behrooz

On Wed, Jan 13, 2021 at 8:14 PM Jean-Paul Pelteret 
mailto:jppelte...@gmail.com>> wrote:


Hi Behrooz,

Great, I'm glad that you're at least one step closer to getting
deal.II installed. Unfortunately, the information that you've
provided about the build error is not enough to diagnose what the
problem is. Can you attach the build log so that we can take a
look at them? When the build is not successful, Spack normally
tells you where the log files are located (they're in a "staging"
directory where deal.II gets built, so its some temporary that
Spack sets up and is specific to your system so I can't tell you
precisely where they'd be). For further reference, search for
"build log" on this page

https://spack-tutorial.readthedocs.io/en/latest/tutorial_packaging.html#creating-the-package-file

<https://spack-tutorial.readthedocs.io/en/latest/tutorial_packaging.html#creating-the-package-file>
to see what I mean -- they give an example of some output of a
package that has not built successfully.

Best,
Jean-Paul

On 13.01.21 11:50, Behrooz Karami wrote:

Dear  Jean-Paul,

Thanks very much for your explanations. It helped me a lot to
better understanding of Spack environment and its functionality.
You were also right, my Spack version is a bit old.
Anyway, after some further manipulations I was a able to
configure Trilions.

However thereafter, and when it comes to deal.ii installation I
receive the following error message:
Error: ProcessError: Command exited with status 2:
    'make' '-j8'

Since the machine on which I am trying to install deal.ii is old
and I have already been facing memory limitations, I thought it
might be a again memory related issue. Thereby I reduced the
number of jobs to 4 but it did not help this time and conditions
exist with the same message.
So I was wondering if there might still be any way around?

Thank you very much,
Behrooz



On Friday, January 8, 2021 at 7:22:45 PM UTC+1 Jean-Paul Pelteret
wrote:

Dear Behrooz,

The problem here is that your Trilinos installation includes
the SEACASChaco package. We'd discovered that there's a
common global symbol that both ADOL-C and
Trilinos-SEACASChaco emit, which causes some very strange
issues when using ADOL-C. Naturally, we had to make sure that
nobody runs into these troubles, because the symptoms of the
issue are not indicative of the underlying problem and are
incredibly difficult to debug. So although deal.II is picking
up the ADOL-C library, deal.II also detects that Trilinos has
the SEACASChaco module enabled and therefore is doing the
safe thing by having the configuration process fail with an
error.

I'm betting that you have a slightly old version of Spack,
because we have some conflicts in place to prevent this
"illegal" combination of packages / package variants from
being installed. You can see these restrictions here:

https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/dealii/package.py#L273-L284

<https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/dealii/package.py#L273-L284>
The way to fix the problem is by recompiling Trilinos without
this package (variant, in Spack parlance) enabled. You can do
this in the following way:
spack install dealii@9.2+adol-c+trilinos ^trilinos~chaco

You'll note that it's also not possible to enable both ADOL-C
and Netcdf, for the same reason, so you actually want to be
even more restrictive:
spack install dealii@9.2+adol-c+trilinos~netcdf
^trilinos~chaco~exodus~netcdf~pnetcdf

  

Re: [deal.II] ADOL-C not found through SPACK installation of deal.ii 9.2

[Jean-Paul Pelteret]

Hi Behrooz,

Great, I'm glad that you're at least one step closer to getting deal.II 
installed. Unfortunately, the information that you've provided about the 
build error is not enough to diagnose what the problem is. Can you 
attach the build log so that we can take a look at them? When the build 
is not successful, Spack normally tells you where the log files are 
located (they're in a "staging" directory where deal.II gets built, so 
its some temporary that Spack sets up and is specific to your system so 
I can't tell you precisely where they'd be). For further reference, 
search for "build log" on this page
https://spack-tutorial.readthedocs.io/en/latest/tutorial_packaging.html#creating-the-package-file 
<https://spack-tutorial.readthedocs.io/en/latest/tutorial_packaging.html#creating-the-package-file>
to see what I mean -- they give an example of some output of a package 
that has not built successfully.


Best,
Jean-Paul

On 13.01.21 11:50, Behrooz Karami wrote:

Dear  Jean-Paul,

Thanks very much for your explanations. It helped me a lot to better 
understanding of Spack environment and its functionality. You were 
also right, my Spack version is a bit old.
Anyway, after some further manipulations I was a able to configure 
Trilions.


However thereafter, and when it comes to deal.ii installation I 
receive the following error message:

Error: ProcessError: Command exited with status 2:
    'make' '-j8'

Since the machine on which I am trying to install deal.ii is old and I 
have already been facing memory limitations, I thought it might be a 
again memory related issue. Thereby I reduced the number of jobs to 4 
but it did not help this time and conditions exist with the same message.

So I was wondering if there might still be any way around?

Thank you very much,
Behrooz



On Friday, January 8, 2021 at 7:22:45 PM UTC+1 Jean-Paul Pelteret wrote:

Dear Behrooz,

The problem here is that your Trilinos installation includes the
SEACASChaco package. We'd discovered that there's a common global
symbol that both ADOL-C and Trilinos-SEACASChaco emit, which
causes some very strange issues when using ADOL-C. Naturally, we
had to make sure that nobody runs into these troubles, because the
symptoms of the issue are not indicative of the underlying problem
and are incredibly difficult to debug. So although deal.II is
picking up the ADOL-C library, deal.II also detects that Trilinos
has the SEACASChaco module enabled and therefore is doing the safe
thing by having the configuration process fail with an error.

I'm betting that you have a slightly old version of Spack, because
we have some conflicts in place to prevent this "illegal"
combination of packages / package variants from being installed.
You can see these restrictions here:

https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/dealii/package.py#L273-L284

<https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/dealii/package.py#L273-L284>
The way to fix the problem is by recompiling Trilinos without this
package (variant, in Spack parlance) enabled. You can do this in
the following way:
spack install dealii@9.2+adol-c+trilinos ^trilinos~chaco

You'll note that it's also not possible to enable both ADOL-C and
Netcdf, for the same reason, so you actually want to be even more
restrictive:
spack install dealii@9.2+adol-c+trilinos~netcdf
^trilinos~chaco~exodus~netcdf~pnetcdf

I hope that this helps you getting deal.II installed through Spack.

Best,
Jean-Paul



On 08.01.21 08:22, Behrooz Karami wrote:

Dear Everyone,

During installation of deal.ii 9.2 through SPACK I receive the
following error on ADOL-C:
1 error found in build log:
     549    -- Could not find a sufficient ADOL-C installation:
Possible symbol
             clash between the ADOL-C library and Trilinos'
SEACASChaco detecte
            d
     550    -- Performing Test ADOLC_DOUBLE_CAST_CHECK
     551    -- Performing Test ADOLC_DOUBLE_CAST_CHECK - Success
     552    -- Performing Test ADOLC_ADOUBLE_OSTREAM_CHECK
     553    -- Performing Test ADOLC_ADOUBLE_OSTREAM_CHECK - Success
     554    -- DEAL_II_WITH_ADOLC has unmet external dependencies.
  >> 555    CMake Error at
cmake/macros/macro_configure_feature.cmake:112 (MESS
            AGE):

This is while 3 versions of ADOL-C are installed (separately and
through SPACK as well) and even deal.ii is detecting one of them as:
==> adol-c is already installed in

/home/behrooz/Spack/opt/spack/linux-ubuntu18.04-x86_64/gcc-7.3.0/adol-c-develop-omjty56hedqyctgkyppbd5cgszby3fmv

Any idea on what I should do about that?
Thanks very much,
Behrooz


-- 
The deal.II project is located at http://www.dealii.org/

<http://ww

Re: [deal.II] ADOL-C not found through SPACK installation of deal.ii 9.2

[Jean-Paul Pelteret]

Dear Behrooz,

The problem here is that your Trilinos installation includes the 
SEACASChaco package. We'd discovered that there's a common global symbol 
that both ADOL-C and Trilinos-SEACASChaco emit, which causes some very 
strange issues when using ADOL-C. Naturally, we had to make sure that 
nobody runs into these troubles, because the symptoms of the issue are 
not indicative of the underlying problem and are incredibly difficult to 
debug. So although deal.II is picking up the ADOL-C library, deal.II 
also detects that Trilinos has the SEACASChaco module enabled and 
therefore is doing the safe thing by having the configuration process 
fail with an error.


I'm betting that you have a slightly old version of Spack, because we 
have some conflicts in place to prevent this "illegal" combination of 
packages / package variants from being installed. You can see these 
restrictions here:
https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/dealii/package.py#L273-L284 

The way to fix the problem is by recompiling Trilinos without this 
package (variant, in Spack parlance) enabled. You can do this in the 
following way:

spack install dealii@9.2+adol-c+trilinos ^trilinos~chaco

You'll note that it's also not possible to enable both ADOL-C and 
Netcdf, for the same reason, so you actually want to be even more 
restrictive:
spack install dealii@9.2+adol-c+trilinos~netcdf 
^trilinos~chaco~exodus~netcdf~pnetcdf


I hope that this helps you getting deal.II installed through Spack.

Best,
Jean-Paul


On 08.01.21 08:22, Behrooz Karami wrote:

Dear Everyone,

During installation of deal.ii 9.2 through SPACK I receive the 
following error on ADOL-C:

1 error found in build log:
     549    -- Could not find a sufficient ADOL-C installation: 
Possible symbol
             clash between the ADOL-C library and Trilinos' 
SEACASChaco detecte

            d
     550    -- Performing Test ADOLC_DOUBLE_CAST_CHECK
     551    -- Performing Test ADOLC_DOUBLE_CAST_CHECK - Success
     552    -- Performing Test ADOLC_ADOUBLE_OSTREAM_CHECK
     553    -- Performing Test ADOLC_ADOUBLE_OSTREAM_CHECK - Success
     554    -- DEAL_II_WITH_ADOLC has unmet external dependencies.
  >> 555    CMake Error at 
cmake/macros/macro_configure_feature.cmake:112 (MESS

            AGE):

This is while 3 versions of ADOL-C are installed (separately and 
through SPACK as well) and even deal.ii is detecting one of them as:
==> adol-c is already installed in 
/home/behrooz/Spack/opt/spack/linux-ubuntu18.04-x86_64/gcc-7.3.0/adol-c-develop-omjty56hedqyctgkyppbd5cgszby3fmv


Any idea on what I should do about that?
Thanks very much,
Behrooz


--
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/CAPPKNqY0h0ZBUQ_D8tzPOuP_mz7L%3DwaPFUD%2B0dmHgqtCQMwmJA%40mail.gmail.com 
.


--
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/cbf82813-5bff-34fd-8da6-679baa96a34c%40gmail.com.

Re: [deal.II] Stabilized FEM implementation with bubble function

[Jean-Paul Pelteret]

Hi Lixing,

Another tutorial that might be of interest to you to look at is step-44 
. In that 
tutorial, two discontinuous fields are condensed out in one of two ways 
(there's a switch to choose which method is applied). The first approach 
 
uses the "local condensation" technique, where one block of the global 
block-system matrix is augmented when doing the condensation. The second 
approach 
 
incorporates condensation into the solver strategy for the linear system 
by adopting a (nested) global Schur complement; unlike the first 
technique, this one does not change the values in the stored in the 
system matrix. In either case, just one field of a three field problem 
is solved for, and the others computed as a post-processing step.


I think that the first approach might cover the details of one possible 
way of doing what you list as point (2) "element-wise static 
condensation". However, the second method (using LinearOperators) is, in 
my opinion, much easier to implement (although, in the end, both 
approaches have their advantages and disadvantages).


I hope that this helps a little.

Best,
Jean-Paul

On 07.01.21 08:11, Lixing Zhu wrote:

Dear Wolgang,

1. I looked into the step-51 of the tutorial. It does illustrate a 
paradigm of segregating local DOFs and global DOFs. If I utilize this 
paradigm, the workflow would solve the local DOFs first (virtual node 
of the bubble function), which is a block matrix since bubble support 
from adjacent cells is irrelevant. Then I substitute the solution to 
the system related to global DOFs (vertices of the standard Lagrange 
shape function), namely, stabilizing the system. However, this would 
require certain FEM space in the barycenter of the element (like a 
FE_Center, in the same fashion as FE_Face), which seems not provided 
in deal.ii.


2. On the other hand, I am more inclined to use element-wise static 
condensation (I guess this is somewhat not a rational decision). Is 
there any example of how to eliminate the virtual DOFs of bubbles from 
the global system once we have eliminated them locally? I guess this 
route can reduce the time of implementation since I can at least 
utilize the FE_Q_Bubbles with its linear realization.


3. The bubbles in FE_Q_Bubbles for a quadratic and higher-order 
element are not the standard bubbles. Are there any specific 
references to these bubbles? or how hard it is to modify the bubble 
function in FE_Q_Bubbles for my own choice?


Thank you for your time in advance.

Best
Lixing

On Tuesday, January 5, 2021 at 1:21:56 PM UTC+8 Wolfgang Bangerth wrote:


Lixing,

> I am trying to implement a stabiliazed weak form (e.g.
advection-diffusion)
> where the stabilization tensor is computed element-wise through
a standard
> bubble: \Pi(1-x_i^2). It seems that FE_Q_Bubbles should provides
all I need,
> but here are two things I am not quite clear about,
>
> 1. Is the definition of bubble function in FE_Q_Bubbles in [0,1]
span or
> [-1,1] span?

Everything in deal.II is on the reference cell define as [0,1]^d.


> Does it has the standard bubble shape (1 at element center and
> vanishes at the edges)? The (2x_j-1)^{p-1} part is a little bit
confusing to
> me. The bubble function corresponds to linear element in
FE_Q_Bubbles is the
> standard bubble that I desire, but I am really confusing at the
shape of this
> expression at higher orders.

For higher orders, you end up with multiple bubble functions, one
for each
j=0..dim-1. This wasn't quite clear from the documentation, and
I'll submit a
patch later for that.


> 2. I tried to utilize this class (i.e., FE_Q_Bubbles). One issue
is that it
> takes the virtual nodes of the bubble function into account of
the total DOFs,
> which is not the way we prefer in the stabilization method.

But the behavior is correct -- the class describes a finite
element *space*
and that space contains the bubble function. I think that what you
are trying
to do is to do static elimination of that degree of freedom right
away, and
that can be implemented as well but is not the philosophical view
we generally
take in deal.II if you select such an element.

The question is what you want the finite element space to be (i)
locally, on
every cell, and (ii) globally. There are a number of tutorials
that discuss
these sorts of questions. I would encourage you to read through
step-61 and
step-51, for example.

Best
WB

-- 



Wolfgang Bangerth email: bang...@colostate.edu
www: