Re: [deal.II] type/value mismatch error in geometry/geometries/point_xy

[Michael Pilipchuk]

Hi Vimukthi,

I did end up by resolving that issue by making sure that gcc, g++, and
gfortran were all on a single version. Ended up using 9 for them. Seems to
be working now.

Michael

On Wed, Feb 21, 2024 at 8:06 AM Wolfgang Bangerth 
wrote:

> On 2/21/24 02:46, vimukthi Nanayakkara wrote:
> > I have recently started using deal II and am encountering the same
> error. Any
> > assistance you can provide in resolving this would be greatly
> appreciated.
>
> Vimukthi, no easy ones other than upgrading your compiler as mentioned in
> the
> previous message. The only alternative I can suggest is edits to BOOST
> itself,
> but not having the compiler that is troublesome, I have no way to test
> that
> edits I could suggest will actually work.
>
> Best
>   W.
>
> --
> 
> Wolfgang Bangerth  email: bange...@colostate.edu
> www: http://www.math.colostate.edu/~bangerth/
>
>
> --
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see
> https://groups.google.com/d/forum/dealii?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/dealii/UBcs-4c3u_M/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/98bfec12-12b2-4936-8743-94f4432a78ae%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/CA%2BHzbpY%2BhdiHDPGsAoXHTzQwz4D9F_6vN_UiUVHLyZOxtCkQJw%40mail.gmail.com.

Re: [deal.II] type/value mismatch error in geometry/geometries/point_xy

[Michael Pilipchuk]

Hi Wolfgang,

I appreciate you taking a look at it. Before changing the files I'll try
with other compilers, currently, I'm using gcc11.4, the latest available on
Ubuntu 22.04, so maybe others will work.

Thanks again,
Michael

On Sat, Feb 10, 2024 at 1:21 PM Wolfgang Bangerth 
wrote:

>
> Michael,
> I looked at the error message and the code it references. The error makes
> no
> sense to me, and I believe that it must be a compiler error. It happens in
> the
> BOOST library, which deal.II packages but has no control over either. I
> double
> checked with the latest version of BOOST, which is unchanged in this
> location.
>
> I could think of ways of working around this problem if you wanted to edit
> the
> file in question, but you might also just consider upgrading your compiler.
>
> Best
>   Wolfgang
>
>
> On 2/9/24 09:13, Michael Pilipchuk wrote:
> > *** Caution: EXTERNAL Sender ***
> >
> > Wolfgang,
> >
> > I understand that the projects are independent, but I was hoping that
> someone
> > here might know since the error message seems to point back to deal.ii.
> The
> > errors I get are below. Sorry if I misunderstood the error messages.
> >
> > image.png
> > image.png
> >
> > Thanks,
> > Michael
> >
> > On Fri, Feb 9, 2024 at 10:53 AM Wolfgang Bangerth <
> bange...@colostate.edu
> > <mailto:bange...@colostate.edu>> wrote:
> >
> >
> > On 2/9/24 07:58, Michael Pilipchuk wrote:
> >  >
> >  > Discussion in the PRISMS-Plasticity group seems like it might
> point to
> >  > GCC 11.4 compiler issues. Does anyone here have any possible
> advice?
> >
> > Michael,
> > can you show the entirety of the error message (top to bottom) to see
> > how exactly you end up in the place where the problem happens?
> >
> > I will not that the PRISMS project is independent of deal.II, and we
> are
> > not involved in their codes. Unless you observe this problem while
> > compiling deal.II, or in a place where this function is called from
> > inside deal.II, there is nothing we can do on our end to fix this.
> >
> > Best
> >W.
> >
> > --
> > 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/UBcs-4c3u_M/unsubscribe
> > <https://groups.google.com/d/topic/dealii/UBcs-4c3u_M/unsubscribe>.
> > To unsubscribe from this group and all its topics, send an email to
> > dealii+unsubscr...@googlegroups.com
> > <mailto:dealii%2bunsubscr...@googlegroups.com>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/dealii/9944a594-a03d-4203-b449-8ee07cfae820%40colostate.edu
> <
> https://groups.google.com/d/msgid/dealii/9944a594-a03d-4203-b449-8ee07cfae820%40colostate.edu
> >.
> >
> > --
> > 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/CA%2BHzbpYvgPtvhSCcwcRqKCTgoamEMQdk9wsnoGyKGvkx5Xz-kg%40mail.gmail.com
> <
> https://groups.google.com/d/msgid/dealii/CA%2BHzbpYvgPtvhSCcwcRqKCTgoamEMQdk9wsnoGyKGvkx5Xz-kg%40mail.gmail.com?utm_medium=email_source=footer
> >.
>
> --
> 
> 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.go

[deal.II] Re: type/value mismatch error in geometry/geometries/point_xy

[Michael Pilipchuk]

Oh, and I forgot to add the main error message - 

/home/mpilipch/dealii-candi/deal.II-v9.5.1/include/deal.II/bundled/boost/geometry/geometries/point_xy.hpp:
 
In member function ‘void 
boost::geometry::model::d2::point_xy::y(const CoordinateType&)’:
/home/mpilipch/dealii-candi/deal.II-v9.5.1/include/deal.II/bundled/boost/geometry/geometries/point_xy.hpp:78:27:
 
error: type/value mismatch at argument 1 in template parameter list for 
‘template class std::set’
   78 | { this->template set<1>(v); }

On Friday, February 9, 2024 at 9:58:04 AM UTC-5 Michael Pilipchuk wrote:

> Hello all,
>
> I installed deal.II-v9.5.1 using candi and that installed cleanly. Then I 
> tried to install the open-source PRISMS-Plasticity 
> <https://github.com/prisms-center/plasticity>package that uses deall.II, 
> and it compiled with no errors up until using "make release". The chain of 
> errors eventually leads back to point_xy.hpp, showing 
> /dealii-candi/deal.II-v9.5.1/include/deal.II/bundled/geometry/geometries/point_xy.hpp:78:27:
>  
> note:   expected a type, got ‘1’
>
> /dealii-candi/deal.II-v9.5.1/include/deal.II/bundled/boost/geometry/geometries/point_xy.hpp:78:27:
>  
> error: template argument 2 is invalid
>
> /dealii-candi/deal.II-v9.5.1/include/deal.II/bundled/boost/geometry/geometries/point_xy.hpp:78:27:
>  
> error: template argument 3 is invalid
>
> Discussion in the PRISMS-Plasticity group seems like it might point to GCC 
> 11.4 compiler issues. Does anyone here have any possible advice? 
>
> Thanks
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to 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/110caf71-7b0f-4697-9dab-2ceca80503c7n%40googlegroups.com.

[deal.II] type/value mismatch error in geometry/geometries/point_xy

[Michael Pilipchuk]

Hello all,

I installed deal.II-v9.5.1 using candi and that installed cleanly. Then I 
tried to install the open-source PRISMS-Plasticity 
package that uses deall.II, 
and it compiled with no errors up until using "make release". The chain of 
errors eventually leads back to point_xy.hpp, showing 
/dealii-candi/deal.II-v9.5.1/include/deal.II/bundled/geometry/geometries/point_xy.hpp:78:27:
 
note:   expected a type, got ‘1’

/dealii-candi/deal.II-v9.5.1/include/deal.II/bundled/boost/geometry/geometries/point_xy.hpp:78:27:
 
error: template argument 2 is invalid

/dealii-candi/deal.II-v9.5.1/include/deal.II/bundled/boost/geometry/geometries/point_xy.hpp:78:27:
 
error: template argument 3 is invalid

Discussion in the PRISMS-Plasticity group seems like it might point to GCC 
11.4 compiler issues. Does anyone here have any possible advice? 

Thanks

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to 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/68f09ab9-9cbc-4d2a-99d3-192e6c3e962cn%40googlegroups.com.

RE: [deal.II] How to get the shape_value at the quadrature point in the reference cell?

[Michael Li]

Dr. Bangerth, Thank you for your hints. I tried using shape_value, but it seems  finite_element_output is a protected member. The error shows as follows: error: ‘dealii::internal::FEValuesImplementation::FiniteElementRelatedData<2, 2> dealii::FEValuesBase<2, 2>::finite_element_output’ is protected within this context   59 |   double shape_value = fe_values.finite_element_output.shape_value(i, q_index);   ^error: ‘class dealii::internal::FEValuesImplementation::FiniteElementRelatedData<2, 2>’ has no member named ‘shape_value’; did you mean ‘shape_values’?  By the way, I also want to get the shape_grad of the reference cell to compare with some other code implementation regarding shape function.  Based on Thong’s method, the following codes gives me the desired results for a Q1 element:  const FE_Q<2> Q_2d_element(1);  const Point<2> center(1, 1);  for(unsigned int i=0; i  {std::cout << " shape value = " << Q_2d_element.shape_value(i, center);std::cout << " shape grad = "  << Q_2d_element.shape_grad(i, center) << std::endl;  } I wonder if there are other ways to access the shape_grad on the ref cell directly. Do I need to use fe_values.inverse_jacobian(q_index) to convert from shape_grad on the real cell to the reference cell?  Best,Michael From: Wolfgang BangerthSent: Sunday, September 12, 2021 5:13 PMTo: dealii@googlegroups.comSubject: Re: [deal.II] How to get the shape_value at the quadrature point in the reference cell? On 9/10/21 4:48 PM, Michael Lee wrote:> > I want to require the value of a shape function at some quadrature point. But > the following code throws an error saying finite_element_output is protected.> double shape_value = fe_values.finite_element_output.shape_values(i, q_index);>  You already solved the problem, but just for completeness: You get the error because you try to access a 'protected' member variable called 'shape_values' (plural). What you want is to use the 'public' member function 'shape_value' (singular). 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/8cd6a2e7-5ad5-fbf5-3240-3237352335a9%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/8ACD76BA-4163-4FFB-832E-01D37DCF18C0%40hxcore.ol.

RE: [deal.II] Re: How to get the shape_value at the quadrature point in the reference cell?

[Michael Li]

Hi Dear Thang,Thank you for you code snippet! It is simple and works well and is what I want. The link helps me understand the shape function in deal.ii. Have a good weekend!Michael  From: Thang W PhamSent: Saturday, September 11, 2021 12:20 AMTo: deal.II User GroupSubject: [deal.II] Re: How to get the shape_value at the quadrature point in the reference cell? Hi Michael,I think you should have a look at FE_Q (Lagrange elements) at this link. In deal.II, the reference cell's domain is [0,1]^2 for 2d element. So, the point you are about to evaluate (to get the value of phi_i equal 0.25)  is (0.5, 0.5).You can refer to this snippet:/*  const FE_Q<2> Q_2d_element(1);  const Point<2> center(0.5, 0.5);  for(int i=0; istd::cout << Q_2d_element.shape_value(i, center) << std::endl;  }*///output 0.25 0.25 0.25 0.25Also  have a look at step-3 to understand how FE_Q works in real problem since the shape functions will be evaluated at real cell coordinates. Good luck. Regards,T.P Vào lúc 07:48:35 UTC+9 ngày Thứ Bảy, 11 tháng 9, 2021, lian...@gmail.com đã viết:Deal deal.ii comunity, I want to require the value of a shape function at some quadrature point. But the following code throws an error saying finite_element_output is protected.     double shape_value = fe_values.finite_element_output.shape_values(i, q_index); For a 2D bilinear element, I expect the shape values  at the cell center(kesi=0, eta=0) are 0.25 for all the 4 shape functions.              Is there other way to acquire this information? 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/b939b310-fd2b-46ee-83fa-59b46e6f9130n%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/11C955E7-916F-420A-94AD-9479516E24F8%40hxcore.ol.

RE: [deal.II] How to watch the variable of BlockVector type?

[Michael Li]

Yeah! .block(0) is essential. Without this, the data obtained is garbage! Thanks for this great hint! From: Wolfgang BangerthSent: Wednesday, August 18, 2021 8:37 PMTo: dealii@googlegroups.comSubject: Re: [deal.II] How to watch the variable of BlockVector type? On 8/18/21 7:18 PM, Michael Lee wrote:> >            BlockVector & system_rhs;>            system_rhs.reinit(dofs_per_block);> > For normal vectors, I can use *((double(*)[10]) v.begin()), but it does not > work for BlockVector. I'm using VS code. Try *( (double(*)[10]) v.block(0).begin()) 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/46c327fa-1d8c-0eb9-d03e-40e5c3611447%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/B0E16C6C-D172-4D48-BD6D-30EEC923A16A%40hxcore.ol.

RE: [deal.II] How to watch the variable of BlockVector type?

[Michael Li]

Sorry, it seems to work using *((double(*)[20])residual.begin()).   From: Michael LeeSent: Wednesday, August 18, 2021 7:18 PMTo: deal.II User GroupSubject: [deal.II] How to watch the variable of BlockVector type? I want to check if I have system_rhs assembled correctly. Is there an easy way to watch the contents of this BlockVector during debugging?           BlockVector & system_rhs;          system_rhs.reinit(dofs_per_block); For normal vectors, I can use *((double(*)[10]) v.begin()), but it does not work for BlockVector. I'm using VS code. 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/9db1415e-812b-4825-8f73-eb7ed3866c17n%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/B3897C92-3FC3-4B18-88D2-185E7F2AD4D9%40hxcore.ol.

[deal.II] How to watch the variable of BlockVector type?

[Michael Lee]

I want to check if I have *system_rhs* assembled correctly. Is there an 
easy way to watch the contents of this BlockVector during debugging?

  BlockVector & system_rhs;
  system_rhs.reinit(dofs_per_block);

For normal vectors, I can use *((double(*)[10]) v.begin()), but it does not 
work for BlockVector. I'm using VS code.

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/9db1415e-812b-4825-8f73-eb7ed3866c17n%40googlegroups.com.

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

[Michael Li]

Hi Jean-Pau, You’re always helpful. The deformation dependent loads are discussed in Wriggers, Wood and some other books and papers. I’m studying that. It seems the formulation is complicated. I believe that the auto-differentiation tools is a good approach to this nonlinear problem and I’ll dig into it later. For now I hope I can have a better understanding this topic and implement it in deal.II by hand then I will be comfortable with AD. Thank you!Michael  From: Jean-Paul PelteretSent: Sunday, August 8, 2021 12:16 PMTo: dealii@googlegroups.comSubject: Re: [deal.II] Computing the solution gradient at the quadrature point on a face 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 paperhttps://www.sciencedirect.com/science/article/abs/pii/S0997753814001508But 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 <lianxi...@gmail.com> 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 PelteretSent: Wednesday, August 4, 2021 12:19 AMTo: dealii@googlegroups.comSubject: 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-PaulOn 2. Aug 2021, at 18:03, Michael Li <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::vector2, dim,NumberType> > 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_po

Re: [deal.II] Debug multithread code

[Michael Lee]

Yes, I'm in debug mode. I mean I cannot step over one line each time or step 
into a function. I have to set a lot of breakpoints to stop the program at 
these lines.

> On Aug 5, 2021, at 6:16 PM, Timo Heister  wrote:
> 
> 
> What do you mean by "cannot do step debug"? Are you compiling in debug mode?
> 
>> On Thu, Aug 5, 2021, 18:34 Michael Li  wrote:
>> I put MultithreadInfo::set_thread_limit(1) in main function, but still 
>> cannot do step debug in the function
>> 
>> assemble_neumann_contribution_one_cell. Am I doing something wrong?
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> From: Timo Heister
>> Sent: Thursday, August 5, 2021 1:19 PM
>> To: dealii@googlegroups.com
>> Subject: Re: [deal.II] Debug multithread code
>> 
>>  
>> 
>> Take a look at set_thread_limit:
>> 
>> https://www.dealii.org/current/doxygen/deal.II/classMultithreadInfo.html
>> 
>> As you can see, you can also control it using an environment variable, so 
>> you don't have to recompile.
>> 
>>  
>> 
>> On Thu, Aug 5, 2021, 13:36 Michael Lee  wrote:
>> 
>> Hi,
>> 
>>  
>> 
>> I find it's difficult to debug multithread code on a multiple-core computer. 
>> Sometimes it does not step into a function (I'm using vscode + wsl). Does 
>> deal.II use all the cores available? For the sake of debug, how can I limit 
>> the cores used? Is there a way to debug the code just like series one?
>> 
>>  
>> 
>> Regards,
>> 
>> 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/b123aaf2-8d32-4b43-b818-8d2ae9ffac77n%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/CAMRj59HvBtTTF1D3SnGHgbnub4nNN_6TC0aYPqHJRK3NYoqdVA%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/B6A6B8CA-9E60-4912-BC84-5706D0E86574%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/CAMRj59G5y%3DjGV%3DnOEUrnDtMNy6F9RoU%3D5c4RGs7HJS%3DcjQDLTA%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/53D60D09-BAD7-4F13-96EB-9AE7016E5A23%40gmail.com.

RE: [deal.II] Debug multithread code

[Michael Li]

I put MultithreadInfo::set_thread_limit(1) in main function, but still cannot do step debug in the function assemble_neumann_contribution_one_cell. Am I doing something wrong?    From: Timo HeisterSent: Thursday, August 5, 2021 1:19 PMTo: dealii@googlegroups.comSubject: Re: [deal.II] Debug multithread code Take a look at set_thread_limit:https://www.dealii.org/current/doxygen/deal.II/classMultithreadInfo.htmlAs you can see, you can also control it using an environment variable, so you don't have to recompile. On Thu, Aug 5, 2021, 13:36 Michael Lee <lianxi...@gmail.com> wrote:Hi, I find it's difficult to debug multithread code on a multiple-core computer. Sometimes it does not step into a function (I'm using vscode + wsl). Does deal.II use all the cores available? For the sake of debug, how can I limit the cores used? Is there a way to debug the code just like series one? Regards,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/b123aaf2-8d32-4b43-b818-8d2ae9ffac77n%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/CAMRj59HvBtTTF1D3SnGHgbnub4nNN_6TC0aYPqHJRK3NYoqdVA%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/B6A6B8CA-9E60-4912-BC84-5706D0E86574%40hxcore.ol.

[deal.II] Debug multithread code

[Michael Lee]

Hi,

I find it's difficult to debug multithread code on a multiple-core 
computer. Sometimes it does not step into a function (I'm using vscode + 
wsl). Does deal.II use all the cores available? For the sake of debug, how 
can I limit the cores used? Is there a way to debug the code just like 
series one?

Regards,
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/b123aaf2-8d32-4b43-b818-8d2ae9ffac77n%40googlegroups.com.

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

[Michael Li]

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 PelteretSent: Wednesday, August 4, 2021 12:19 AMTo: dealii@googlegroups.comSubject: 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-PaulOn 2. Aug 2021, at 18:03, Michael Li <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::vector2, dim,NumberType> > 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 PelteretSent: Sunday, August 1, 2021 1:46 PMTo: dealii@googlegroups.comSubject: 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() 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-PaulOn 1. Aug 2021, at 20:05, Michael Lee <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) ). 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

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

[Michael Li]

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::vector2, dim,NumberType> > 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 PelteretSent: Sunday, August 1, 2021 1:46 PMTo: dealii@googlegroups.comSubject: 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() 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-PaulOn 1. Aug 2021, at 20:05, Michael Lee <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) ). 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) .     voidassemble_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,Nu

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

[Michael Lee]

pe >::type = dealii::Tensor<2, 3, 
double>]
The violated condition was: 
static_cast::type)>::type>(derivatives.size()) == 
static_cast::type)>::type>(n_quadrature_points)
Additional information: 
   * Dimension 8 not equal to 4*.

If I use *set Polynomial degree = 2**  set Quadrature order  = 1*
*An error occurred* in line <335> of file 
 in function
void dealii::SparseDirectUMFPACK::factorize(const Matrix&) [with Matrix 
= dealii::SparseMatrix]
The violated condition was: 
status == UMFPACK_OK
Additional information: 
UMFPACK routine umfpack_dl_numeric returned error status 1.

On Sunday, August 1, 2021 at 12:08:37 AM UTC-6 peterr...@gmail.com wrote:

> The return type should be `*Tensor<2,dim,NumberType>*` shouldn't it?
>
> Hope this helps. If not, could describe how the code does not work? It it 
> not compiling? Is the result wrong?
>
> PM
>
> On Sunday, 1 August 2021 at 04:09:45 UTC+2 lian...@gmail.com wrote:
>
>> Dear All,
>>
>> I want to do a surface integration which needs to evaluate the gradients 
>> of the solution on the face. The following code does not work 
>>
>> fe_face_values.*get_function_gradients*(solution, 
>> solution_grads);
>> 
>> 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[f_q_point];*
>> *...*
>>   }
>>
>> Can anybody give a hint on that?
>>
>> 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/3b018015-206e-41f7-9ff3-88c909927af7n%40googlegroups.com.

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

[Michael Lee]

Dear All,

I want to do a surface integration which needs to evaluate the gradients of 
the solution on the face. The following code does not work 

fe_face_values.*get_function_gradients*(solution, 
solution_grads);

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[f_q_point];*
*...*
  }

Can anybody give a hint on that?

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/ca251fdc-527d-48cb-a383-3113f5203b4dn%40googlegroups.com.

RE: [deal.II] Matrix Multiplication

[Michael Li]

Hi Jean-Paul,Thanks for confirming that. I have made the Kirchhoff model with your suggestion. The Physics::Transformations is so convenient for elasticity problems.  In case someone wonders how I did it, I enclose the codes here. SymmetricTensor<4,dim,NumberType>get_Jc(const Tensor< 2, dim, NumberType >  &F) const{  SymmetricTensor<4,dim, NumberType> D = get_stress_strain_tensor(lambda, mu);   return Physics::Transformations::Contravariant::push_forward(D, F);} SymmetricTensor<2,dim,NumberType>get_tau(const Tensor< 2, dim, NumberType >  &F){  // Second Piola Kirchhoff stress  SymmetricTensor<2,dim,NumberType> S = get_stress_strain_tensor(lambda, mu) *Physics::Elasticity::Kinematics::E(F);   return Physics::Transformations::Contravariant::push_forward(S, F);} I just undefine the variable to circumvent the Sacado error.  #define ENABLE_SACADO_FORMULATION   Thanks,Michael   From: Jean-Paul PelteretSent: Monday, July 26, 2021 12:46 AMTo: dealii@googlegroups.comSubject: Re: [deal.II] Matrix Multiplication Hi Michael, I revisited the code gallery example “The deal.II Library: The 'Quasi-Static Finite-Strain Compressible Elasticity' code gallery program (dealii.org)”. 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 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/12217The 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 <lianxi...@gmail.com> 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)”. 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 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: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, 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, 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: 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: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:24:   required from here/home/michael/dealii-9.2.0/examples/code-gallery/Quasi_static_Finite_strain_Compressible_Elasticity/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_compone

RE: [deal.II] Matrix Multiplication

[Michael Li]

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)”. 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 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: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, 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, 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: 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: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:24:   required from here/home/michael/dealii-9.2.0/examples/code-gallery/Quasi_static_Finite_strain_Compressible_Elasticity/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 PelteretSent: Thursday, July 22, 2021 11:03 AMTo: dealii@googlegroups.comSubject: Re: [deal.II] Matrix Multiplication 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-PaulOn 22. Jul 2021, at 17:47, Michael Li <lianxi...@gmail.com> 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 PelteretSent: Wednesday, July 21, 2021 10:45 PMTo: dealii@googlegroups.comSubject: 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.htmlhttps://dealii.org/current/doxygen/deal.II/classSymmetricTensor.htmlThese classes have a 

[deal.II] Matrix Multiplication

[Michael Lee]

Dear dealii users,

I want to construct a matrix [image: E=1/2(F^TF-1)]. 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.

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

[Michael Li]

 Hi Jean-Paul, Thank you for your patience and detailed explanation! It did help me understand the formulations. The only thing after reading the Wikipedia (https://en.wikipedia.org/wiki/Rotation_matrix#Axis_and_angle ) I still have doubts is that the angle should be calculated by ½ mag(curl) and we do not need to do the atan operation. And I think the magnitude of curl has the dimension of radians which actually is dimensionless. Quoted from Wikipedia:“Near multiples of 180°, care is needed to avoid numerical problems: in extracting the angle, a two-argument arctangent with atan2(sin θ, cos θ) equal to θ avoids the insensitivity of arccos; and in computing the axis magnitude in order to force unit magnitude, a brute-force approach can lose accuracy through underflow .” My understanding on the atan above is that it is only used to deal with the case when the angle is near multiples of 180°. So the code I suggest will look like as follows.   const Point<3> curl = …;   const double mag_curl = std::sqrt(curl * curl);   const double  angle = 0.5 * mag_curl; Thank you!Michael  From: Jean-Paul PelteretSent: Monday, July 5, 2021 11:50 PMTo: dealii@googlegroups.comSubject: Re: [deal.II] Questions on Step-18 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 47Holzapfel2007a: 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_angleThere 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 <lianxi...@gmail.com&g

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

[Michael Lee]

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 be
fully convinced of the stuff.




   - To be specific, I want to make sure where I should put the factor of ½
   to make the patch. I.e., which is correct in the following?



   1. const double tan_angle = std::sqrt(0.5 * curl * 0.5 * curl);

or



   1. const double tan_angle = 0.5 * std::sqrt(curl * curl);



   - In my opinion, the code should be as follows.


For 2D,

const double curl = (grad_u[1][0] - grad_u[0][1]);


const double angle = 1.0 / 2.0 * std::sqrt(curl * curl); // Half of the
magnitude of curl is the rotation angle.



For 3D,

const double angle = 1.0 / 2.0 * std::sqrt(curl * curl);

const double angle = std::atan(tan_angle);




Any comments will be of great help.


Best,

Michael

On Mon, Jun 28, 2021 at 2:21 AM Andrew McBride 
wrote:

> My view here is that the problem is quasi-static and hence time serves to
> order events. Hence a displacement increment can be viewed as equivalent to
> the velocity.
>
> For example, let’s fix the number of time-steps to 10. If the total time
> is 1s or 10s we should get the same results (assuming the timing of the
> application of loading is scaled based on the assumption that time simply
> order events).
>
> Best,
> Andrew
>
> On 27 Jun 2021, at 02:19, Michael Li  wrote:
>
> Hi Jean-Paul,
> Thank you for the nice explanation and information! It cleared out my
> concern and helped me understand the related concepts of vorticity and
> rotation. Vorticity (1/2 curl of velocity) stands for the *rotation rate* 
> (angular
> velocity) but the infinitesimal rotation tensor gives the *rotation
> angle *(curl of displacement). Do correct me if I’m wrong.
>
> Now I’m excited to learn how to make my first patch.
>
> - Michael
>
> *From: *Jean-Paul Pelteret 
> *Sent: *Saturday, June 26, 2021 2:57 PM
> *To: *dealii@googlegroups.com
> *Subject: *Re: [deal.II] Questions on Step-18
>
> 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*(Δ*u**n*) 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 Δ*u**n* 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 p

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

[Michael Li]

Hi Jean-Paul,Thank you for the nice explanation and information! It cleared out my concern and helped me understand the related concepts of vorticity and rotation. Vorticity (1/2 curl of velocity) stands for the rotation rate (angular velocity) but the infinitesimal rotation tensor gives the rotation angle (curl of displacement). Do correct me if I’m wrong. Now I’m excited to learn how to make my first patch. - Michael From: Jean-Paul PelteretSent: Saturday, June 26, 2021 2:57 PMTo: dealii@googlegroups.comSubject: Re: [deal.II] Questions on Step-18 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” 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-PaulOn 26. Jun 2021, at 16:14, Michael Lee <lianxi...@gmail.com> 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 <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 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 <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/ContributingBestW.  On Sat, Jun 26, 2021 at 1:48 AM Jean-Paul Pelteret <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 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 <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 bu

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

[Michael Lee]

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 *([image: \vec{v} = \frac{d \vec{u}}{dt}]),
since [image: \vec{\omega} = \frac{1}{2}\nabla \times \vec{v} =
\frac{1}{2}\nabla \times \frac{d\vec{u}}{dt}] ?

Can you check this as well?


Best,
Michael






On Sat, Jun 26, 2021 at 1:48 AM Jean-Paul Pelteret 
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
>
> 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.
>
>
>
On Sat, Jun 26, 2021 at 1:48 AM Jean-Paul Pelteret 
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
>
> 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 vie

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

[Michael Li]

Hi Jean-Paul,Thank you so much for the deliberate suggestions! It seems the code-gallery example is a good starting point for me to implement St-Venant Kirchhoff hyperelastic model with the help of “push-forward” transformations. I need to dig into this example to understand how the geometric stiffness tangent is embedded for free. It’s good to know a tutorial that uses one-filed elasticity will be available. I believe that will help a lot for beginners. AD is an interesting tool for nonlinear FEM. In  an early discussion, Alex shared his similar codes using AD at Integrated material and spatial traction forces on boundary not equal (google.com). But since I’m a deal.II beginner and not familiar with AD, I have not studied his code further. So I am going to study your code-gallery example first as it is well documented. I may ask for your further help and will let you know if I get the code roll. Thank you again for your wonderful help! Best,Michael  From: Jean-Paul PelteretSent: Thursday, June 24, 2021 11:43 PMTo: dealii@googlegroups.comSubject: Re: [deal.II] Questions on Step-18 HI Michael. To be honest, I have a hard time to understand the three-filed formulation in Step 44.  That’s a fair comment, and a known deficit in our current tutorial list. I hope that by the end of the year we will have a tutorial that uses one-field elasticity, and would be a much better starting point for you and others (WIP: https://github.com/dealii/dealii/pull/10394). However, I’m still interested in implementing the pure geometrical large finite deformation model. I believe that will make things simpler and help me understand more complex nonlinear models. Meanwhile, I try to compare the results with a reference which only consider the geometrical nonlinearity. It sounds to me like you’re looking to implement finite strain elasticity with a St Venant-Kirchhoff constitutive law. That is, as far as I understand, the simplest constitutive law for finite strain elasticity.https://en.wikipedia.org/wiki/Hyperelastic_material#Saint_Venant%E2%80%93Kirchhoff_modelIn this model, the elastic tangent looks like that for linear elasticity, but the strain tensor of interest is no longer the linear/small strain tensor, but rather the (nonlinear) Green-Lagrange strain tensor. (Nevertheless, even though the material law is linear, you still have the geometric tangent contribution that appears after linearisation of the residual, which comes from the linearisation of the now nonlinearly deformation-dependent test function “de” in  \int de : \sigma dv .) If this is indeed what you want, then it is possible to swap out the Neo-Hookean constitutive law that is implemented in the code-gallery example with the St-Venant Kirchhoff constitutive law. You’d get “for free” the geometric stiffness contribution to the tangent, and would just have to worry about the material tangent and definition of the stress. I think that the only complication is the default parameterisation for the constitutive law — it was parameterised in terms of the left Cauchy-Green tensor as the whole problem is set up with the Kirchhoff stress (that’s the Cauchy stress, but per unit reference volume). Nevertheless, with the help of these “push-forward” transformations you would be able to use whatever parameterisation you’d like for the constitutive law (e.g. in terms of the Green-Lagrange strain tensor) and transform the resulting stress and material tangent to the correct (i.e. the spatial) configuration as is required for that implementation of the weak forms. The important thing to remember is that, despite all of the transformations involved, you’re still solving the same BVP with the same constitutive law irrespective of which choice of stress-strain (energetic) conjugate pairs you use, and irrespective of whether its expressed in the total or updated Lagrangian form. But anyway, this is just a suggestion. Irrespective of whether or not you choose to go that route, I wish you luck in implementing what you’re needing to. Best,Jean-PaulOn 25. Jun 2021, at 02:32, Michael Li <lianxi...@gmail.com> 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. Jean-Paul, thanks for commenting on my second question. I want to study the pure geometrical nonlinear elasticity (large deformation with linear material). It should be the simplest nonlinear model in elasticity. Step 18 looks like a good start as an updated Lagrangian formulation; but it does not include the nonlinear part of the finite strain. I spent some on Step 44 because “ Quasi-Static Finite-Strain Compressible Elasticity” also mentions it is based on Step 44. To be honest, I have a hard time to understand the three-filed formulation in Step 44. So maybe I should get into “Quasi-Static … Elasticity” first which uses classical one-field formulation. However, I’m still interested in implementing the pure geometrical

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

[Michael Li]

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. Jean-Paul, thanks for commenting on my second question. I want to study the pure geometrical nonlinear elasticity (large deformation with linear material). It should be the simplest nonlinear model in elasticity. Step 18 looks like a good start as an updated Lagrangian formulation; but it does not include the nonlinear part of the finite strain. I spent some on Step 44 because “ Quasi-Static Finite-Strain Compressible Elasticity” also mentions it is based on Step 44. To be honest, I have a hard time to understand the three-filed formulation in Step 44. So maybe I should get into “Quasi-Static … Elasticity” first which uses classical one-field formulation. However, I’m still interested in implementing the pure geometrical large finite deformation model. I believe that will make things simpler and help me understand more complex nonlinear models. Meanwhile, I try to compare the results with a reference which only consider the geometrical nonlinearity. -Michael   From: Andrew McBrideSent: Thursday, June 24, 2021 2:23 PMTo: deal.II User GroupSubject: Re: [deal.II] Questions on Step-18 Hi both, Jean-Paul has addressed the 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,AndrewOn 24 Jun 2021, at 21:03, Jean-Paul Pelteret <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 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 <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 = 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,Mic

RE: [deal.II] Different get_function_gradients

[Michael Li]

Hi Jean-Paul,Thank you so much for your explanation. That totally makes sense. These different functions exist for implementing  different weak forms easily. Though I can get everything using (1), but I would prefer using the others when I try to extract components of the gradient.  Best,Michael From: Jean-Paul PelteretSent: Thursday, June 24, 2021 2:13 PMTo: dealii@googlegroups.comSubject: Re: [deal.II] Different get_function_gradients 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-PaulOn 24. Jun 2021, at 18:20, Michael Lee <lianxi...@gmail.com> 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. 



-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to 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/A647AB72-A22E-46CB-9AF9-06FCEA7C36C4%40hxcore.ol.

[deal.II] Different get_function_gradients

[Michael Lee]

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.

[deal.II] Questions on Step-18

[Michael Lee]

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/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to 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.

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

[Michael Li]

Thanks, W. for confirming that! I reinstalled deal.II after installing Trillinos. Step 31 runs well.   From: Wolfgang BangerthSent: Wednesday, June 16, 2021 4:10 PMTo: dealii@googlegroups.comSubject: Re: [deal.II] Re: Integrated material and spatial traction forces on boundary not equal On 6/16/21 4:07 PM, Michael Lee wrote:> > Is there a way to let deal.II know Trillinos is installed? Do I have to > reinstall deal.ii?> Or, can I compile the code without using Trillinos with some modification? No, you have to re-install deal.II so that at compile time, it knows that Trilinos exists. 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 a topic in the Google Groups "deal.II User Group" group.To unsubscribe from this topic, visit https://groups.google.com/d/topic/dealii/K-lMxbtZUdQ/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/06a30833-0914-ed13-b4e1-dfd9c2c3b72d%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/F7A11E7B-B4F1-4CEA-B54F-01D974A17F04%40hxcore.ol.

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

[Michael Lee]

Hi Alex,
I just got a chance to have Trilinos installed but the same error occurs 
regarding *EnergyFunctional*. I got the following notice when trying to 
test *step-31*:

Error! This tutorial requires a deal.II library that was configured with
  the following options:

  DEAL_II_WITH_TRILINOS = ON

  However, the deal.II library found at /usr/local was configured with these
  options

  DEAL_II_WITH_TRILINOS = OFF

  which conflict with the requirements.


-- Configuring incomplete, errors occurred!  

Is there a way to let deal.II know Trillinos is installed? Do I have to 
reinstall deal.ii?
Or, can I compile the code without using Trillinos with some modification?

Thanks!
Michael

On Friday, June 11, 2021 at 4:04:20 AM UTC-6 alexanderc...@gmail.com wrote:

> Hi Michael,
>
> I think that is the first point in my code that something from the 
> automatic differentiation module is referred to, which is a part of 
> trilinos. Was your version of deal.ii compiled with trilinos, and if so, 
> was your version of trilinos compiled with sacado?
>
> To answer the question I posed, I did some more tests and found that 
> refining in the width and height of the beam has no effect on the 
> convergence of the shear force. I went down to just a single division in z 
> and 2 in y (in other words there are just two faces when looking down the 
> end of the beam), and could get the same level of agreement with beam 
> theory with one order of magnitude fewer degrees of freedom. I guess I am 
> still mildly surprised how refined I had to made the x direction, but 
> perhaps if I also used adaptive refinement things would further improve.
>
> Best,
> Alex
>
> On Thursday, June 10, 2021 at 6:20:58 p.m. UTC+2 lian...@gmail.com wrote:
>
>> Alex, 
>>
>>  
>>
>> Thank you for sharing your codes. I have some compiling errors relating 
>> to “EnergyFunctional’: 
>>
>> solve_ring_nonlinear.cpp:520:43: error: ‘*EnergyFunctional’* in 
>> namespace ‘dealii::Differentiation::AD’ *does not name a template type*
>>
>>   520 | using ADHelper = Differentiation::AD::EnergyFunctional<
>>
>>   |   ^~~~
>>
>> Can you help me with that?
>>
>>  
>>
>> For the large error, I noticed you’re using linear element. I encountered 
>> the same large error when comparing it with Abaqus with FE_Q(1). But the 
>> error came down with less grids when I used higher finite element 
>> FE_Q(2). I remember the deflection of beam is a cubic function of 
>> coordinate. You may try that see if it improves.
>>
>>  
>>
>> Best,
>>
>> Michael
>>
>>  
>>
>> *From: *Alex Cumberworth
>> *Sent: *Wednesday, June 9, 2021 9:54 AM
>> *To: *deal.II User Group
>> *Subject: *[deal.II] Re: Integrated material and spatial traction forces 
>> on boundary not equal
>>
>>  
>>
>> Hello,
>>
>>  
>>
>> I have attached the most recent version of my code here. I have tried to 
>> make setting boundary conditions in the parameter file more convenient for 
>> myself; you can set boundary domains, boundary conditions that use these 
>> domains, and stages if the displacement is large. However, there are not 
>> many comments, so you may want to just remove this part for your own 
>> purposes.
>>
>>  
>>
>> However, I have been a bit surprised in my comparisons at how fine a mesh 
>> is required to achieve convergence with the beam theory result. I am now 
>> using a beam that is 1 x 2 x 20, and using the subdivided rectangle helper 
>> function, I set the number of subdivisions to be 5 and 10 for the width and 
>> height, respectively. I then varied the number of subdivision in the length 
>> between 10 and 1000. The beam theory result is that the shear force has a 
>> magnitude of 0.001 for a displacement on the right side of 0.1. Even at 
>> 1000 subdivisions, the FEM result is 0.00113 (from 0.00129 at 500). The 
>> system has 200 000 degrees of freedom, and the result is still off by 13%. 
>> Is it expected that even to calculate a shear force in this simple problem 
>> that such a large number of degrees of freedom are required?
>>
>>  
>>
>>  
>>
>> Best,
>>
>> Alex
>>
>>  
>>
>> On Monday, June 7, 2021 at 3:39:44 p.m. UTC+2 lian...@gmail.com wrote:
>>
>>
>> Hi Alex,
>>
>> I'm learning deal.ii and trying do the similar verification. If it is 
>> possible for you to share the code with me?
>>
>>  
>>
>> Thank you!
>>
>>

RE: [deal.II] How to define boundary conditions on edges and vertices in 3D?

[Michael Li]

Thanks for confirming that. It saves me from keeping trying to define boundary conditions by setting boundary id on edges or vertices. I was too excited to think it is possible to do that when reading the code line(j)->set_boundary_id(2) in grid_generator.cc. Maybe it is just to distinct the edges with different boundary_ids for other use. There are still many scenarios that we want to fix some points in the domain. I wonder if we can make use of the AffineConstraints class to deal with Dirichlet boundary conditions though it is not possible for Neumman BCs. Best,Michael From: Wolfgang BangerthSent: Thursday, June 10, 2021 10:41 AMTo: dealii@googlegroups.comSubject: Re: [deal.II] How to define boundary conditions on edges and vertices in 3D? On 6/10/21 8:31 AM, Michael Lee wrote:> 1) thin plate under pressure with *four edges simply supported*.> 2) thin plate under pressure with *four corner points simply supported*.> 2021-06-10_082227.png> For the first one, I tried the following code, but it seems boundary condition > only works with face not on edge. That is correct. Mathematically, you can only prescribe boundary conditions on portions of the boundary (i.e., on *faces*) but not on edges in 3d or vertices in 2d/3d. What is easy to do in deal.II matches what is mathematically possible. Now, you will ask why other software packages allow you to do what is not easy in deal.II. The answer is that other packages generally use a fixed mesh, and on a fixed mesh, prescribing boundary conditions on a vertex is roughly equivalent to prescribing boundary conditions on the adjacent faces. That's ok if you keep the mesh fixed, but it means that you are changing the kind of boundary conditions every time you change the mesh if you use software that uses adaptive mesh refinement. So my suggestion would be to think about the physical situation you want to model, and translate that into prescribing boundary conditions on faces instead of edges/vertices. 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/9e09474b-1e3f-7fbf-7527-01f6cdd256ef%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/89FC6FE0-6F24-4447-B995-03F9B36D0E84%40hxcore.ol.

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

[Michael Li]

Alex,  Thank you for sharing your codes. I have some compiling errors relating to “EnergyFunctional’: solve_ring_nonlinear.cpp:520:43: error: ‘EnergyFunctional’ in namespace ‘dealii::Differentiation::AD’ does not name a template type  520 | using ADHelper = Differentiation::AD::EnergyFunctional<  |   ^~~~Can you help me with that? For the large error, I noticed you’re using linear element. I encountered the same large error when comparing it with Abaqus with FE_Q(1). But the error came down with less grids when I used higher finite element FE_Q(2). I remember the deflection of beam is a cubic function of coordinate. You may try that see if it improves. Best,Michael From: Alex CumberworthSent: Wednesday, June 9, 2021 9:54 AMTo: deal.II User GroupSubject: [deal.II] Re: Integrated material and spatial traction forces on boundary not equal Hello, I have attached the most recent version of my code here. I have tried to make setting boundary conditions in the parameter file more convenient for myself; you can set boundary domains, boundary conditions that use these domains, and stages if the displacement is large. However, there are not many comments, so you may want to just remove this part for your own purposes. However, I have been a bit surprised in my comparisons at how fine a mesh is required to achieve convergence with the beam theory result. I am now using a beam that is 1 x 2 x 20, and using the subdivided rectangle helper function, I set the number of subdivisions to be 5 and 10 for the width and height, respectively. I then varied the number of subdivision in the length between 10 and 1000. The beam theory result is that the shear force has a magnitude of 0.001 for a displacement on the right side of 0.1. Even at 1000 subdivisions, the FEM result is 0.00113 (from 0.00129 at 500). The system has 200 000 degrees of freedom, and the result is still off by 13%. Is it expected that even to calculate a shear force in this simple problem that such a large number of degrees of freedom are required?  Best,Alex On Monday, June 7, 2021 at 3:39:44 p.m. UTC+2 lian...@gmail.com wrote:Hi Alex,I'm learning deal.ii and trying do the similar verification. If it is possible for you to share the code with me? Thank you!MichaelOn Tuesday, May 11, 2021 at 4:46:55 AM UTC-6 alexanderc...@gmail.com 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.0694169Right boundary spatial normal force: 0.0724468Right boundary material shear force: 0.152057Right 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

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

[Michael Lee]

Hi Alex,
I'm learning deal.ii and trying do the similar verification. If it is 
possible for you to share the code with me?

Thank you!
Michael
On Tuesday, May 11, 2021 at 4:46:55 AM UTC-6 alexanderc...@gmail.com 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.
> [image: beam.png]
> 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;
> }
> fe_face_values.reinit(cell, face_i);
> std::vector> normal_vectors {
> fe_face_values.get_normal_vectors()};
> std::vector> solution_gradients(
> fe_face_values.n_quadrature_points);
> fe_face_values[displacements].get_function_gradients(
> present_solution, solution_gradients);
> for (const auto q_i: 
> fe_face_values.quadrature_point_indices()) {
> const Tensor<2, dim, double> grad_u 
> {solution_gradients[q_i]};
> const Tensor<1, dim, double> material_normal {
> normal_vectors[q_i]};
>
> const Tensor<2, dim, double> grad_u_T {transpose(grad_u)};
> const Tensor<2, dim, double> green_lagrange_strain {
> 0.5 * (grad_u + grad_u_T + grad_u_T * grad_u)};
> const Tensor<2, dim, double> piola_kirchhoff {
> lambda * trace(green_lagrange_strain) *
> unit_symmetric_tensor() +
> 2 * mu * green_lagrange_strain};
>
> ave_material_normal[boundary_id - 1] += material_normal;
> material_force[boundary_id - 1] += piola_kirchhoff *
>material_normal *
>fe_face_values.JxW(q_i);
>
> const Tensor<2, dim, double> deformation_grad {
> grad_u + unit_symmetric_tensor()};
> const double deformat

Re: [deal.II] Test 4 failed, maybe different installation of MPI? then how to solve this?

[Michael]

Hi Daniel,

Thank you, I used mpicc to compile. Replace NULL by nullptr won't help 
because compiler can not recognize nullptr neither.

On Saturday, October 28, 2017 at 1:21:25 PM UTC-5, Daniel Arndt wrote:
>
> Michael,
>
> are actually compiling with a MPI compiler?
> Does replacing NULL by nullptr help?
>
> Best,
> Daniel
>
> Am Samstag, 28. Oktober 2017 01:52:24 UTC+2 schrieb Michael:
>>
>> Thanks for your reply. I did install mpich_3.2-7_amd64.deb before. When I 
>> tried your simple mpi example, I can not even compile it and the the error 
>> is:
>>
>> hello.c: In function ‘main’:
>> hello.c:3:5: warning: implicit declaration of function ‘MPI_Init’ 
>> [-Wimplicit-function-declaration]
>>  MPI_Init(NULL, NULL);
>>  ^~~~
>> hello.c:3:14: error: ‘NULL’ undeclared (first use in this function)
>>  MPI_Init(NULL, NULL);
>>   ^~~~
>> hello.c:3:14: note: each undeclared identifier is reported only once for 
>> each function it appears in
>> hello.c:7:5: warning: implicit declaration of function ‘MPI_Comm_size’ 
>> [-Wimplicit-function-declaration]
>>  MPI_Comm_size(MPI_COMM_WORLD, _size);
>>  ^
>> hello.c:7:19: error: ‘MPI_COMM_WORLD’ undeclared (first use in this 
>> function)
>>  MPI_Comm_size(MPI_COMM_WORLD, _size);
>>^~
>> hello.c:11:5: warning: implicit declaration of function ‘MPI_Comm_rank’ 
>> [-Wimplicit-function-declaration]
>>  MPI_Comm_rank(MPI_COMM_WORLD, _rank);
>>  ^
>> hello.c:14:25: error: ‘MPI_MAX_PROCESSOR_NAME’ undeclared (first use in 
>> this function)
>>  char processor_name[MPI_MAX_PROCESSOR_NAME];
>>  ^~
>> hello.c:16:5: warning: implicit declaration of function 
>> ‘MPI_Get_processor_name’ [-Wimplicit-function-declaration]
>>  MPI_Get_processor_name(processor_name, _len);
>>  ^~
>> hello.c:19:5: warning: implicit declaration of function ‘printf’ 
>> [-Wimplicit-function-declaration]
>>  printf("Hello world from processor %s, rank %d"
>>  ^~
>> hello.c:19:5: warning: incompatible implicit declaration of built-in 
>> function ‘printf’
>> hello.c:19:5: note: include ‘’ or provide a declaration of 
>> ‘printf’
>> hello.c:24:5: warning: implicit declaration of function ‘MPI_Finalize’ 
>> [-Wimplicit-function-declaration]
>>  MPI_Finalize();
>>  ^~~~
>> : recipe for target 'hello.o' failed
>> make: *** [hello.o] Error 1
>>
>> Not sure if this is because of I didn't install mpi package correctly 
>> which was installed by ubuntu software manager.
>>
>>
>> On Friday, October 27, 2017 at 12:57:55 PM UTC-5, Timo Heister wrote:
>>>
>>> Well, do you have more than one MPI library installed? If yes, you 
>>> need to address that by removing one of them. 
>>>
>>> You can check if a simple hello world MPI program compiles and runs 
>>> correctly. See for example 
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__mpitutorial.com_tutorials_mpi-2Dhello-2Dworld_=DwIBaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw=xqP0pwi1MCtRPItXgJGYSlWmAdkua1-iL_svoI2Icgg=uE9uaCa2RV_G7HtjV6sxyfx9GduRM9wHUH-EOF3VvNM=
>>>  
>>>
>>> On Thu, Oct 26, 2017 at 6:38 PM, Michael <micha...@gmail.com> wrote: 
>>> > Hi, 
>>> > 
>>> > Test 4 failed after make test. I make my research and find the 
>>> following 
>>> > answer: 
>>> > 
>>> > 
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_msg_dealii_mV-2DjuFpnybA_DSBP4DArCQAJ=DwIBaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw=xqP0pwi1MCtRPItXgJGYSlWmAdkua1-iL_svoI2Icgg=b_s_RUQD1qLw_eZ_t42IRcNKemfVWZIUnPr0jIQTF5c=
>>>  
>>> > 
>>> > I guess it may be caused by different version of MPI. And I get the 
>>> > following return of suggested command: 
>>> > 
>>> > 
>>> 
>>>  
>>>
>>> > mpirun -n 2 ./mpi.debug 
>>> >  Hi from 0/1 
>>> >  Hi from 0/1 
>>> > ERROR: process does not see nproc=2! 
>>> > ERROR: process does not see nproc=2! 
>>> > --- 
>>> > Primary job  terminated n

Re: [deal.II] Test 4 failed, maybe different installation of MPI? then how to solve this?

[Michael]

Thanks for your reply. I did install mpich_3.2-7_amd64.deb before. When I 
tried your simple mpi example, I can not even compile it and the the error 
is:

hello.c: In function ‘main’:
hello.c:3:5: warning: implicit declaration of function ‘MPI_Init’ 
[-Wimplicit-function-declaration]
 MPI_Init(NULL, NULL);
 ^~~~
hello.c:3:14: error: ‘NULL’ undeclared (first use in this function)
 MPI_Init(NULL, NULL);
  ^~~~
hello.c:3:14: note: each undeclared identifier is reported only once for 
each function it appears in
hello.c:7:5: warning: implicit declaration of function ‘MPI_Comm_size’ 
[-Wimplicit-function-declaration]
 MPI_Comm_size(MPI_COMM_WORLD, _size);
 ^
hello.c:7:19: error: ‘MPI_COMM_WORLD’ undeclared (first use in this 
function)
 MPI_Comm_size(MPI_COMM_WORLD, _size);
   ^~
hello.c:11:5: warning: implicit declaration of function ‘MPI_Comm_rank’ 
[-Wimplicit-function-declaration]
 MPI_Comm_rank(MPI_COMM_WORLD, _rank);
 ^
hello.c:14:25: error: ‘MPI_MAX_PROCESSOR_NAME’ undeclared (first use in 
this function)
 char processor_name[MPI_MAX_PROCESSOR_NAME];
 ^~
hello.c:16:5: warning: implicit declaration of function 
‘MPI_Get_processor_name’ [-Wimplicit-function-declaration]
 MPI_Get_processor_name(processor_name, _len);
 ^~
hello.c:19:5: warning: implicit declaration of function ‘printf’ 
[-Wimplicit-function-declaration]
 printf("Hello world from processor %s, rank %d"
 ^~
hello.c:19:5: warning: incompatible implicit declaration of built-in 
function ‘printf’
hello.c:19:5: note: include ‘’ or provide a declaration of ‘printf’
hello.c:24:5: warning: implicit declaration of function ‘MPI_Finalize’ 
[-Wimplicit-function-declaration]
 MPI_Finalize();
 ^~~~
: recipe for target 'hello.o' failed
make: *** [hello.o] Error 1

Not sure if this is because of I didn't install mpi package correctly which 
was installed by ubuntu software manager.


On Friday, October 27, 2017 at 12:57:55 PM UTC-5, Timo Heister wrote:
>
> Well, do you have more than one MPI library installed? If yes, you 
> need to address that by removing one of them. 
>
> You can check if a simple hello world MPI program compiles and runs 
> correctly. See for example 
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__mpitutorial.com_tutorials_mpi-2Dhello-2Dworld_=DwIBaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw=xqP0pwi1MCtRPItXgJGYSlWmAdkua1-iL_svoI2Icgg=uE9uaCa2RV_G7HtjV6sxyfx9GduRM9wHUH-EOF3VvNM=
>  
>
> On Thu, Oct 26, 2017 at 6:38 PM, Michael <micha...@gmail.com > 
> wrote: 
> > Hi, 
> > 
> > Test 4 failed after make test. I make my research and find the following 
> > answer: 
> > 
> > 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_msg_dealii_mV-2DjuFpnybA_DSBP4DArCQAJ=DwIBaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw=xqP0pwi1MCtRPItXgJGYSlWmAdkua1-iL_svoI2Icgg=b_s_RUQD1qLw_eZ_t42IRcNKemfVWZIUnPr0jIQTF5c=
>  
> > 
> > I guess it may be caused by different version of MPI. And I get the 
> > following return of suggested command: 
> > 
> > 
> 
>  
>
> > mpirun -n 2 ./mpi.debug 
> >  Hi from 0/1 
> >  Hi from 0/1 
> > ERROR: process does not see nproc=2! 
> > ERROR: process does not see nproc=2! 
> > --- 
> > Primary job  terminated normally, but 1 process returned 
> > a non-zero exit code.. Per user-direction, the job has been aborted. 
> > --- 
> > 
> -- 
> > mpirun detected that one or more processes exited with non-zero status, 
> thus 
> > causing 
> > the job to be terminated. The first process to do so was: 
> > 
> >   Process name: [[18180,1],0] 
> >   Exit code:255 
> > 
> 
>  
>
> >  mpiexec -n 2 ./mpi.debug 
> >  Hi from 0/1 
> >  Hi from 0/1 
> > ERROR: process does not see nproc=2! 
> > ERROR: process does not see nproc=2! 
> > --- 
> > Primary job  terminated normally, but 1 process returned 
> > a non-zero exit code.. Per user-direction, the job has been aborted. 
> > --- 
&

[deal.II] Test 4 failed after installation, no clue

[Michael]

Hi,

Test 4 failed after make test. I make my research and find the following 
answer:

https://groups.google.com/d/msg/dealii/mV-juFpnybA/DSBP4DArCQAJ

And I get the following suggested commands with returns blow:


mpirun -n 2 ./mpi.debug 

 Hi from 0/1
 Hi from 0/1
ERROR: process does not see nproc=2!
ERROR: process does not see nproc=2!
---
Primary job  terminated normally, but 1 process returned
a non-zero exit code.. Per user-direction, the job has been aborted.
---
--
mpirun detected that one or more processes exited with non-zero status, 
thus causing
the job to be terminated. The first process to do so was:

  Process name: [[18180,1],0]
  Exit code:255

 mpiexec -n 2 ./mpi.debug 

 Hi from 0/1
 Hi from 0/1
ERROR: process does not see nproc=2!
ERROR: process does not see nproc=2!
---
Primary job  terminated normally, but 1 process returned
a non-zero exit code.. Per user-direction, the job has been aborted.
---
--
mpiexec detected that one or more processes exited with non-zero status, 
thus causing
the job to be terminated. The first process to do so was:

  Process name: [[18211,1],0]
  Exit code:255

which mpirun

/usr/bin/mpirun

which mpiexec

/usr/bin/mpiexec

ldd /home/superman/usr/dealii/lib/libdeal_II.g.so.8.5.1 | grep mpi

libmpich.so.12 => /usr/lib/x86_64-linux-gnu/libmpich.so.12 
(0x7f884cb3)

ldd /home/superman/usr/trilinos/lib/libepetra.so.12.12.1 | grep mpi

libmpich.so.12 => /usr/lib/x86_64-linux-gnu/libmpich.so.12 
(0x7fd5327f1000)


I have no clue about this, please let me know if you have any suggestion. 
Thanks a lot!

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

Re: [deal.II] Re: Installation error, please help, thx!

[Michael]

Thanks, I did replaced original include/deal.II/lac/sparsity_pattern.h file 
by a new one from github. That was because I got errors during 
installation. 

I've tried again with a clean directory, and get those errors again, please 
take a look at make output file below. And please let me know if anything 
else I can provide or try. Thanks again!

By the way, I also tried to replace both sparsity_pattern.h and 
chunk_sparse_matrix.templates.h by a newer ones from github and there still 
errors happened in chunk_sparse_matrix.templates.h file.

On Wednesday, October 25, 2017 at 8:35:31 PM UTC-5, Wolfgang Bangerth wrote:
>
> On 10/25/2017 06:43 PM, Michael wrote: 
> > 
> /home/superman/software/dealii-8.5.0/include/deal.II/lac/chunk_sparse_matrix.templates.h:
>  
> In instantiation of ‘somenumber 
> dealii::ChunkSparseMatrix::matrix_norm_square(const 
> dealii::Vector&) const [with somenumber = double; number = 
> double]’: 
> > 
> /home/superman/software/dealii-8.5.0/build/source/lac/chunk_sparse_matrix.inst:64:58:
>  
>   required from here 
> > 
> /home/superman/software/dealii-8.5.0/include/deal.II/lac/chunk_sparse_matrix.templates.h:856:56:
>  
> error: cannot convert ‘const std::unique_ptr’ to ‘const 
> size_type* {aka const unsigned int*}’ in initialization 
> > const size_type *colnum_ptr = cols->sparsity_pattern.colnums; 
> >  ^~~ 
>
> Something is rather messed up here. colnums is a std::unique_ptr, but has 
> only 
> been since July 17. But in the same commit that changed colnums to a 
> unique_ptr, I also changed the line in question to 
>const size_type *colnum_ptr = cols->sparsity_pattern.colnums.get(); 
>
> In other words, the files 
>include/deal.II/lac/sparsity_pattern.h 
>include/deal.II/lac/chunk_sparse_matrix.templates.h 
> in your tree are not both at the same state -- one appears to be a 
> development 
> version from after July 17, the other one from before. 
>
> Something must have gotten out of whack when you updated from github. Try 
> again with a clean directory. 
>
> Best 
>   W. 
>
> -- 
>  
> Wolfgang Bangerth  email: bang...@colostate.edu 
>  
> www: http://www.math.colostate.edu/~bangerth/ 
>
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Scanning dependencies of target doxygen_headers
Scanning dependencies of target expand_instantiations_exe
[  0%] Building CXX object 
cmake/scripts/CMakeFiles/expand_instantiations_exe.dir/expand_instantiations.cc.o
Scanning dependencies of target obj_tbb_release
Scanning dependencies of target obj_tbb_debug
[  0%] Built target doxygen_headers
[  0%] Building CXX object 
bundled/tbb41_20130401oss/src/CMakeFiles/obj_tbb_release.dir/rml/client/rml_tbb.cpp.o
[  0%] Building CXX object 
bundled/tbb41_20130401oss/src/CMakeFiles/obj_tbb_debug.dir/rml/client/rml_tbb.cpp.o
Scanning dependencies of target obj_umfpack_GENERIC_release
[  0%] Building CXX object 
bundled/umfpack/UMFPACK/Source/CMakeFiles/obj_umfpack_GENERIC_release.dir/umfpack_global.cc.o
[  1%] Building CXX object 
bundled/tbb41_20130401oss/src/CMakeFiles/obj_tbb_release.dir/tbb/arena.cpp.o
[  1%] Building CXX object 
bundled/tbb41_20130401oss/src/CMakeFiles/obj_tbb_debug.dir/tbb/arena.cpp.o
[  1%] Building CXX object 
bundled/umfpack/UMFPACK/Source/CMakeFiles/obj_umfpack_GENERIC_release.dir/umfpack_tictoc.cc.o
[  1%] Building CXX object 
bundled/umfpack/UMFPACK/Source/CMakeFiles/obj_umfpack_GENERIC_release.dir/umfpack_timer.cc.o
[  1%] Built target obj_umfpack_GENERIC_release
Scanning dependencies of target obj_umfpack_GENERIC_debug
[  1%] Building CXX object 
bundled/umfpack/UMFPACK/Source/CMakeFiles/obj_umfpack_GENERIC_debug.dir/umfpack_global.cc.o
[  1%] Building CXX object 
bundled/umfpack/UMFPACK/Source/CMakeFiles/obj_umfpack_GENERIC_debug.dir/umfpack_tictoc.cc.o
[  1%] Building CXX object 
bundled/umfpack/UMFPACK/Source/CMakeFiles/obj_umfpack_GENERIC_debug.dir/umfpack_timer.cc.o
[  1%] Built target obj_umfpack_GENERIC_debug
Scanning dependencies of target obj_umfpack_DL_SOLVE_release
[  1%] Building CXX object 
bundled/umfpack/UMFPACK/Source/CMakeFiles/obj_umfpack_DL_SOLVE_release.dir/umfpack_solve.cc.o
[  1%] Built target obj_umfpack_DL_SOLVE_release
Scanning dependencies of target obj_umfpack_DL_SOLVE_debug
[  1%] Lin

[deal.II] Installation error, please help, thx!

[Michael]

Hi,

I've installed dealii before using the default step from README. This time, 
I am trying to install dealii with trilinos, but getting the following kind 
of errors during installation:

"
/usr/include/c++/6/tuple:648:21: error: no type named ‘type’ in ‘struct 
std::enable_if’
 bool>::type=false>
 ^
/usr/include/c++/6/tuple:648:21: note: invalid template non-type parameter
/usr/include/c++/6/tuple:636:19: note: candidate: template, 
std::_Placeholder<1>, std::_Placeholder<2>, float*, std::unique_ptr >, 
std::unique_ptr >, 
std::reference_wrapper >, 
std::reference_wrapper >::_NotSameTuple<_UElements 
...>() && std::_TC<(8ul == sizeof... (_UElements)), 
std::reference_wrapper, 
std::_Placeholder<1>, std::_Placeholder<2>, float*, std::unique_ptr >, 
std::unique_ptr >, 
std::reference_wrapper >, 
std::reference_wrapper 
>::_MoveConstructibleTuple<_UElements ...>()) && std::_TC<(8ul == sizeof... 
(_UElements)), std::reference_wrapper, 
std::_Placeholder<1>, std::_Placeholder<2>, float*, std::unique_ptr >, 
std::unique_ptr >, 
std::reference_wrapper >, 
std::reference_wrapper 
>::_ImplicitlyMoveConvertibleTuple<_UElements ...>()) && (8ul >= 1)), 
bool>::type  > constexpr std::tuple<  
>::tuple(_UElements&& ...)
 constexpr tuple(_UElements&&... __elements)
"

I checked the directory /usr/include/c++/6/ which seems being redirected 
from /usr/include/c++/6.2.0/. The date of directory c++/6 is the date when 
I installed BOOST. Not sure if this information could help. Please let me 
know if you want some cmake output files. Any information from you would be 
helpful, thanks a lot.

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

[deal.II] Installation error with c++ lib

[Michael]

Hi,

I've installed dealii before using the default step by README. This time, I 
am trying to install dealii with trilinos, but getting the following kind 
of errors during installation:

"
/usr/include/c++/6/tuple:648:21: error: no type named ‘type’ in ‘struct 
std::enable_if’
 bool>::type=false>
 ^
/usr/include/c++/6/tuple:648:21: note: invalid template non-type parameter
/usr/include/c++/6/tuple:636:19: note: candidate: template, 
std::_Placeholder<1>, std::_Placeholder<2>, float*, std::unique_ptr >, 
std::unique_ptr >, 
std::reference_wrapper >, 
std::reference_wrapper >::_NotSameTuple<_UElements 
...>() && std::_TC<(8ul == sizeof... (_UElements)), 
std::reference_wrapper, 
std::_Placeholder<1>, std::_Placeholder<2>, float*, std::unique_ptr >, 
std::unique_ptr >, 
std::reference_wrapper >, 
std::reference_wrapper 
>::_MoveConstructibleTuple<_UElements ...>()) && std::_TC<(8ul == sizeof... 
(_UElements)), std::reference_wrapper, 
std::_Placeholder<1>, std::_Placeholder<2>, float*, std::unique_ptr >, 
std::unique_ptr >, 
std::reference_wrapper >, 
std::reference_wrapper 
>::_ImplicitlyMoveConvertibleTuple<_UElements ...>()) && (8ul >= 1)), 
bool>::type  > constexpr std::tuple<  
>::tuple(_UElements&& ...)
 constexpr tuple(_UElements&&... __elements)
"

I checked the directory /usr/include/c++/6/ which seems being detected by 
/usr/include/c++/6.2.0/. The date of directory c++/6 is the date when I 
installed BOOST. Not sure if this information could help. Please let me 
know if you want some cmake output files. Any information from you would be 
helpful, thanks a lot.

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

Re: [deal.II] Re: Announcing the deal.II Code Gallery

[Michael Harmon]

Hi Jean-Paul,

Yes, Thanks!  I removed all the CG examples except for 
goal_oriented_electroplasticity and my own and it worked I guess it is 
one of the CG examples.. It takes an painfully long time to write the html 
on my puny macbook air :)

- Mike

On Tuesday, March 7, 2017 at 11:54:42 AM UTC-5, Jean-Paul Pelteret wrote:
>
> Thanks Wolfgang, a slight permutation of that seemed to work! I'll submit 
> a PR in a moment.
>
> Michael, can you tell me if you've built any of the code gallery examples? 
> I think that this might be the issue. If you have, can you go into those 
> examples' directories and run "make distclean", then try to build the 
> documentation again? It looks like this has fixed the problem for me.
>
> FYI. Before cleaning the CG examples completely, this was the last line of 
> doxygen.log:
>
>> input buffer overflow, can't enlarge buffer because scanner uses REJECT
>>
>
> On Tuesday, March 7, 2017 at 5:34:39 PM UTC+1, Wolfgang Bangerth wrote:
>>
>> On 03/07/2017 09:30 AM, Jean-Paul Pelteret wrote: 
>> > 
>> > Matthias, is there any way to disable the deletion of doxygen.log when 
>> a 
>> > build of the documentation fails? 
>>
>> In doc/doxygen/CMakeLists.txt, line ~230, you have 
>>
>> ADD_CUSTOM_COMMAND( 
>>OUTPUT 
>>  ${CMAKE_BINARY_DIR}/doxygen.log 
>>COMMAND ${DOXYGEN_EXECUTABLE} 
>>  ${CMAKE_CURRENT_BINARY_DIR}/options.dox 
>>  > ${CMAKE_BINARY_DIR}/doxygen.log 2>&1 # *pssst* 
>>... 
>>
>> Can you try to change that into something of the form 
>>
>> ADD_CUSTOM_COMMAND( 
>>OUTPUT 
>>  ${CMAKE_BINARY_DIR}/doxygen.log 
>>COMMAND 
>>  (${DOXYGEN_EXECUTABLE} 
>>   ${CMAKE_CURRENT_BINARY_DIR}/options.dox 
>>   > ${CMAKE_BINARY_DIR}/doxygen.log 2>&1 # *pssst* 
>>  ) 
>>  || 
>>  mv ${CMAKE_BINARY_DIR}/doxygen.log ${CMAKE_BINARY_DIR}/doxygen.err 
>>... 
>>
>>
>> The second branch of || is only executed if the first one fails, and 
>> moves the output file to an error file. 
>>
>> If this happens to work, please submit this as a patch in general -- we 
>> should try to preserve error messages. 
>>
>> Best 
>>   W. 
>>
>> -- 
>>  
>> Wolfgang Bangerth  email: bang...@colostate.edu 
>>  
>> www: http://www.math.colostate.edu/~bangerth/ 
>>
>

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

Re: [deal.II] Re: Announcing the deal.II Code Gallery

[Michael Harmon]

Thanks! I am glad it wasn't just me!!

Mike

On Tuesday, March 7, 2017 at 10:26:43 AM UTC-5, Jean-Paul Pelteret wrote:
>
> Hi Michael,
>
> I've just tried to build the documentation with the code gallery and have 
> run into similar problems. I'm going to fiddle around to see if I can work 
> out what the issue might be. I'll post an update if I get anywhere with 
> this.
>
> Best,
> Jean-Paul
>
> On Tuesday, March 7, 2017 at 3:50:46 PM UTC+1, Michael Harmon wrote:
>>
>> I ran "make" again and attached the outputs fm the terminal into make.log
>>
>> I also ran "make install" and attached the outputs from the into 
>> make_install.log
>>
>> It seems they are failing at different points... but I'm not sure whats 
>> going wrong..
>>
>> Thanks,
>>
>> Mike
>>
>> On Monday, March 6, 2017 at 10:58:28 PM UTC-5, Wolfgang Bangerth wrote:
>>>
>>> On 03/06/2017 08:14 PM, Michael Harmon wrote: 
>>> > The doxygen.log file seems to get deleted... but here's the copy of it 
>>> I took 
>>> > right before the error gets thrown and it is deleted. 
>>>
>>> Hm, yes, that is not helpful. Do you get to see more in terms of errors 
>>> if you do 
>>>make VERBOSE=1 
>>> ? At the least, you would get to see which command is being executed, 
>>> and you 
>>> could do so by hand on the command line to possibly get the full 
>>> doxygen.log. 
>>>
>>>
>>> > I'm not sure if it makes a difference, but I'm building this on a mac 
>>> where I 
>>> > am using a terminal that is launched by the deal.II app. 
>>>
>>> That doesn't trigger anything for me :-( 
>>>
>>> Best 
>>>   W. 
>>>
>>>
>>> -- 
>>>  
>>> Wolfgang Bangerth  email: bang...@colostate.edu 
>>> www: 
>>> http://www.math.colostate.edu/~bangerth/ 
>>>
>>>

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

Re: [deal.II] Re: Announcing the deal.II Code Gallery

[Michael Harmon]

I ran "make" again and attached the outputs fm the terminal into make.log

I also ran "make install" and attached the outputs from the into 
make_install.log

It seems they are failing at different points... but I'm not sure whats 
going wrong..

Thanks,

Mike

On Monday, March 6, 2017 at 10:58:28 PM UTC-5, Wolfgang Bangerth wrote:
>
> On 03/06/2017 08:14 PM, Michael Harmon wrote: 
> > The doxygen.log file seems to get deleted... but here's the copy of it I 
> took 
> > right before the error gets thrown and it is deleted. 
>
> Hm, yes, that is not helpful. Do you get to see more in terms of errors if 
> you do 
>make VERBOSE=1 
> ? At the least, you would get to see which command is being executed, and 
> you 
> could do so by hand on the command line to possibly get the full 
> doxygen.log. 
>
>
> > I'm not sure if it makes a difference, but I'm building this on a mac 
> where I 
> > am using a terminal that is launched by the deal.II app. 
>
> That doesn't trigger anything for me :-( 
>
> Best 
>   W. 
>
>
> -- 
>  
> Wolfgang Bangerth  email: bang...@colostate.edu 
>  
> www: http://www.math.colostate.edu/~bangerth/ 
>
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
/usr/local/Cellar/cmake/3.6.0_1/bin/cmake -H/Users/Mike/Desktop/dealii-8.4.1 
-B/Users/Mike/Desktop/dealii-8.4.1/build --check-build-system 
CMakeFiles/Makefile.cmake 0
/usr/local/Cellar/cmake/3.6.0_1/bin/cmake -E cmake_progress_start 
/Users/Mike/Desktop/dealii-8.4.1/build/CMakeFiles 
/Users/Mike/Desktop/dealii-8.4.1/build/CMakeFiles/progress.marks
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/Makefile2 
all
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f 
cmake/scripts/CMakeFiles/expand_instantiations_exe.dir/build.make 
cmake/scripts/CMakeFiles/expand_instantiations_exe.dir/depend
cd /Users/Mike/Desktop/dealii-8.4.1/build && 
/usr/local/Cellar/cmake/3.6.0_1/bin/cmake -E cmake_depends "Unix Makefiles" 
/Users/Mike/Desktop/dealii-8.4.1 /Users/Mike/Desktop/dealii-8.4.1/cmake/scripts 
/Users/Mike/Desktop/dealii-8.4.1/build 
/Users/Mike/Desktop/dealii-8.4.1/build/cmake/scripts 
/Users/Mike/Desktop/dealii-8.4.1/build/cmake/scripts/CMakeFiles/expand_instantiations_exe.dir/DependInfo.cmake
 --color=
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f 
cmake/scripts/CMakeFiles/expand_instantiations_exe.dir/build.make 
cmake/scripts/CMakeFiles/expand_instantiations_exe.dir/build
make[2]: Nothing to be done for 
`cmake/scripts/CMakeFiles/expand_instantiations_exe.dir/build'.
[  0%] Built target expand_instantiations_exe
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f 
doc/CMakeFiles/doxygen_headers.dir/build.make 
doc/CMakeFiles/doxygen_headers.dir/depend
cd /Users/Mike/Desktop/dealii-8.4.1/build && 
/usr/local/Cellar/cmake/3.6.0_1/bin/cmake -E cmake_depends "Unix Makefiles" 
/Users/Mike/Desktop/dealii-8.4.1 /Users/Mike/Desktop/dealii-8.4.1/doc 
/Users/Mike/Desktop/dealii-8.4.1/build 
/Users/Mike/Desktop/dealii-8.4.1/build/doc 
/Users/Mike/Desktop/dealii-8.4.1/build/doc/CMakeFiles/doxygen_headers.dir/DependInfo.cmake
 --color=
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f 
doc/CMakeFiles/doxygen_headers.dir/build.make 
doc/CMakeFiles/doxygen_headers.dir/build
make[2]: Nothing to be done for `doc/CMakeFiles/doxygen_headers.dir/build'.
[  0%] Built target doxygen_headers
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f 
doc/doxygen/code-gallery/CMakeFiles/build_code-gallery_h.dir/build.make 
doc/doxygen/code-gallery/CMakeFiles/build_code-gallery_h.dir/depend
cd /Users/Mike/Desktop/dealii-8.4.1/build && 
/usr/local/Cellar/cmake/3.6.0_1/bin/cmake -E cmake_depends "Unix Makefiles" 
/Users/Mike/Desktop/dealii-8.4.1 
/Users/Mike/Desktop/dealii-8.4.1/doc/doxygen/code-gallery 
/Users/Mike/Desktop/dealii-8.4.1/build 
/Users/Mike/Desktop/dealii-8.4.1/build/doc/doxygen/code-gallery 
/Users/Mike/Desktop/dealii-8.4.1/build/doc/doxygen/code-gallery/CMakeFiles/build_code-gallery_h.dir/DependInfo.cmake
 --color=
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f 
doc/doxygen/code-gallery/CMakeFiles/build_code-gallery_h.dir/build.make 
doc/doxygen/code-gallery/CMakeFiles/build_code-gallery_h.dir/build
make[2]: Nothing to be done for 
`doc/doxygen/code-g

Re: [deal.II] Re: Announcing the deal.II Code Gallery

[Michael Harmon]

The doxygen.log file seems to get deleted... but here's the copy of it I 
took right before the error gets thrown and it is deleted.

I'm not sure if it makes a difference, but I'm building this on a mac where 
I am using a terminal that is launched by the deal.II app.

Thanks,

Mike

On Monday, March 6, 2017 at 6:03:47 PM UTC-5, Wolfgang Bangerth wrote:
>
> On 03/06/2017 03:59 PM, Michael Harmon wrote: 
> > down and I get the error attached as a picture... any ideas on what's 
> > going wrong? 
>
> Not sure -- can you look into doxygen.log see if there are errors? Maybe 
> attach the whole thing? 
> Best 
>   W. 
>
> -- 
>  
> Wolfgang Bangerth  email: bang...@colostate.edu 
>  
> www: http://www.math.colostate.edu/~bangerth/ 
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
/Users/Mike/Desktop/dealii-8.4.1/source/algorithms/operator.cc:54: warning: 
include file operator.inst not found, perhaps you forgot to add its directory 
to INCLUDE_PATH?
/Users/Mike/Desktop/dealii-8.4.1/source/base/time_stepping.cc:32: warning: 
include file time_stepping.inst not found, perhaps you forgot to add its 
directory to INCLUDE_PATH?
/Users/Mike/Desktop/dealii-8.4.1/source/dofs/dof_objects.cc:69: warning: 
include file dof_objects.inst not found, perhaps you forgot to add its 
directory to INCLUDE_PATH?
/Users/Mike/Desktop/dealii-8.4.1/source/fe/fe_values.cc:1809: warning: include 
file fe_values.decl.1.inst not found, perhaps you forgot to add its directory 
to INCLUDE_PATH?
/Users/Mike/Desktop/dealii-8.4.1/source/fe/fe_values.cc:1878: warning: include 
file fe_values.decl.2.inst not found, perhaps you forgot to add its directory 
to INCLUDE_PATH?
/Users/Mike/Desktop/dealii-8.4.1/source/fe/fe_values.cc:1981: warning: include 
file fe_values.decl.2.inst not found, perhaps you forgot to add its directory 
to INCLUDE_PATH?
/Users/Mike/Desktop/dealii-8.4.1/source/grid/tria_objects.cc:467: warning: 
include file tria_objects.inst not found, perhaps you forgot to add its 
directory to INCLUDE_PATH?
/Users/Mike/Desktop/dealii-8.4.1/source/lac/trilinos_vector_base.cc:547: 
warning: include file trilinos_vector_base.inst not found, perhaps you forgot 
to add its directory to INCLUDE_PATH?
/Users/Mike/Desktop/dealii-8.4.1/source/numerics/dof_output_operator.cc:37: 
warning: include file dof_output_operator.inst not found, perhaps you forgot to 
add its directory to INCLUDE_PATH?
/Users/Mike/Desktop/dealii-8.4.1/source/numerics/fe_field_function.cc:35: 
warning: include file fe_field_function.inst not found, perhaps you forgot to 
add its directory to INCLUDE_PATH?
/Users/Mike/Desktop/dealii-8.4.1/source/opencascade/boundary_lib.cc:257: 
warning: include file boundary_lib.inst not found, perhaps you forgot to add 
its directory to INCLUDE_PATH?

[dealii-developers] Re: Announcing the deal.II Code Gallery

[Michael Harmon]

actually, i am having issues... When I build the documentation on my local 
machine without the code-gallery file everything works.  However, with the 
code-gallery, it breaks


<https://lh3.googleusercontent.com/-S7wEGyrweTo/WL3p2fpcAkI/B0c/e1qzh38-39UxUfqMJpbQG-M9rMuq9sVugCLcB/s1600/doxygen_error.png>
down and I get the error attached as a picture... any ideas on what's going 
wrong?

On Wednesday, March 1, 2017 at 12:34:52 AM UTC-5, Jean-Paul Pelteret wrote:
>
> Wolfgang's answer to Michael's question from a duplicate post:
>  
>
>> Just check out the code gallery git repository in a directory parallel to 
>> the 
>> examples/ directory and build the deal.II documentation as described in 
>> the 
>> readme. It will pick up the code gallery and create joint documentation 
>> for 
>> the tutorial and the code gallery. 
>>
>> Best 
>>   W. 
>
>
> On Tuesday, February 28, 2017 at 4:24:31 PM UTC+1, Michael Harmon wrote:
>>
>> Hi, I wanted to submit a example code to the code gallery, but was 
>> wondering is there a tool to see how the page will look before when all the 
>> doxygen comments are taken into account.. like the following:
>>
>> https://dealii.org/developer/doxygen/deal.II/code_gallery_cdr.html
>>
>> On Friday, February 12, 2016 at 2:43:10 PM UTC-5, Wolfgang Bangerth wrote:
>>>
>>>
>>> All, 
>>> at the last deal.II Users and Developers Workshop last August, we had a 
>>> long discussion about ways how we can provide more starting points for 
>>> others to build their codes on. 
>>>
>>> We came up with the "Code Gallery": A place where anyone can deposit 
>>> their codes built on deal.II so that others can take a look, and use it 
>>> as a starting point for their own work. Our goal is to provide a forum 
>>> that allows for the re-use of codes, and leads to more collaboration. 
>>>
>>> Our experience with 16 years of sharing codes is that it brings people 
>>> together: someone who can see that a code you put online might be useful 
>>> to their project will likely want to collaborate with you, jointly 
>>> working on their project, and write papers together. In other words, 
>>> putting codes online doesn't just allow you to get credit for the work 
>>> you have done, but is also likely going to lead to contacts you might 
>>> otherwise never have made. 
>>>
>>> This code gallery is now online, currently with three programs. You can 
>>> find it at 
>>>https://dealii.org/code-gallery.html 
>>>https://dealii.org/developer/doxygen/deal.II/CodeGallery.html 
>>>
>>> The first of these pages also contains instructions on how anyone can 
>>> contribute to the code gallery. The purpose to doing so is purposefully 
>>> simple, and the requirements to uploading a code are minimal. *Please 
>>> consider making your code a component of the gallery!* 
>>>
>>> Best 
>>>   Wolfgang 
>>>
>>>
>>> PS: We have not gone through many versions of submission process yet. If 
>>> there are steps in the instructions at 
>>>https://dealii.org/code-gallery.html#instructions 
>>> that you think are unclear, let us work on them together! 
>>>
>>> -- 
>>>  
>>> Wolfgang Bangerth   email:bang...@math.tamu.edu 
>>>  www: 
>>> http://www.math.tamu.edu/~bangerth/ 
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"deal.II developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Announcing the deal.II Code Gallery

[Michael Harmon]

doh. thanks!

On Wednesday, March 1, 2017 at 12:34:52 AM UTC-5, Jean-Paul Pelteret wrote:
>
> Wolfgang's answer to Michael's question from a duplicate post:
>  
>
>> Just check out the code gallery git repository in a directory parallel to 
>> the 
>> examples/ directory and build the deal.II documentation as described in 
>> the 
>> readme. It will pick up the code gallery and create joint documentation 
>> for 
>> the tutorial and the code gallery. 
>>
>> Best 
>>   W. 
>
>
> On Tuesday, February 28, 2017 at 4:24:31 PM UTC+1, Michael Harmon wrote:
>>
>> Hi, I wanted to submit a example code to the code gallery, but was 
>> wondering is there a tool to see how the page will look before when all the 
>> doxygen comments are taken into account.. like the following:
>>
>> https://dealii.org/developer/doxygen/deal.II/code_gallery_cdr.html
>>
>> On Friday, February 12, 2016 at 2:43:10 PM UTC-5, Wolfgang Bangerth wrote:
>>>
>>>
>>> All, 
>>> at the last deal.II Users and Developers Workshop last August, we had a 
>>> long discussion about ways how we can provide more starting points for 
>>> others to build their codes on. 
>>>
>>> We came up with the "Code Gallery": A place where anyone can deposit 
>>> their codes built on deal.II so that others can take a look, and use it 
>>> as a starting point for their own work. Our goal is to provide a forum 
>>> that allows for the re-use of codes, and leads to more collaboration. 
>>>
>>> Our experience with 16 years of sharing codes is that it brings people 
>>> together: someone who can see that a code you put online might be useful 
>>> to their project will likely want to collaborate with you, jointly 
>>> working on their project, and write papers together. In other words, 
>>> putting codes online doesn't just allow you to get credit for the work 
>>> you have done, but is also likely going to lead to contacts you might 
>>> otherwise never have made. 
>>>
>>> This code gallery is now online, currently with three programs. You can 
>>> find it at 
>>>https://dealii.org/code-gallery.html 
>>>https://dealii.org/developer/doxygen/deal.II/CodeGallery.html 
>>>
>>> The first of these pages also contains instructions on how anyone can 
>>> contribute to the code gallery. The purpose to doing so is purposefully 
>>> simple, and the requirements to uploading a code are minimal. *Please 
>>> consider making your code a component of the gallery!* 
>>>
>>> Best 
>>>   Wolfgang 
>>>
>>>
>>> PS: We have not gone through many versions of submission process yet. If 
>>> there are steps in the instructions at 
>>>https://dealii.org/code-gallery.html#instructions 
>>> that you think are unclear, let us work on them together! 
>>>
>>> -- 
>>>  
>>> Wolfgang Bangerth   email:bang...@math.tamu.edu 
>>>  www: 
>>> http://www.math.tamu.edu/~bangerth/ 
>>>
>>>

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

[dealii-developers] Re: Announcing the deal.II Code Gallery

[Michael Harmon]

Hi, I wanted to submit a example code to the code gallery, but was 
wondering is there a tool to see how the page will look before when all the 
doxygen comments are taken into account.. like the following:

https://dealii.org/developer/doxygen/deal.II/code_gallery_cdr.html

On Friday, February 12, 2016 at 2:43:10 PM UTC-5, Wolfgang Bangerth wrote:
>
>
> All, 
> at the last deal.II Users and Developers Workshop last August, we had a 
> long discussion about ways how we can provide more starting points for 
> others to build their codes on. 
>
> We came up with the "Code Gallery": A place where anyone can deposit 
> their codes built on deal.II so that others can take a look, and use it 
> as a starting point for their own work. Our goal is to provide a forum 
> that allows for the re-use of codes, and leads to more collaboration. 
>
> Our experience with 16 years of sharing codes is that it brings people 
> together: someone who can see that a code you put online might be useful 
> to their project will likely want to collaborate with you, jointly 
> working on their project, and write papers together. In other words, 
> putting codes online doesn't just allow you to get credit for the work 
> you have done, but is also likely going to lead to contacts you might 
> otherwise never have made. 
>
> This code gallery is now online, currently with three programs. You can 
> find it at 
>https://dealii.org/code-gallery.html 
>https://dealii.org/developer/doxygen/deal.II/CodeGallery.html 
>
> The first of these pages also contains instructions on how anyone can 
> contribute to the code gallery. The purpose to doing so is purposefully 
> simple, and the requirements to uploading a code are minimal. *Please 
> consider making your code a component of the gallery!* 
>
> Best 
>   Wolfgang 
>
>
> PS: We have not gone through many versions of submission process yet. If 
> there are steps in the instructions at 
>https://dealii.org/code-gallery.html#instructions 
> that you think are unclear, let us work on them together! 
>
> -- 
>  
> Wolfgang Bangerth   email:bang...@math.tamu.edu 
>  
>  www: http://www.math.tamu.edu/~bangerth/ 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"deal.II developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Announcing the deal.II Code Gallery

[Michael Harmon]

Hi, I wanted to submit a example code to the code gallery, but was 
wondering is there a tool to see how the page will look before when all the 
doxygen comments are taken into account.. like the following:

https://dealii.org/developer/doxygen/deal.II/code_gallery_cdr.html

On Friday, February 12, 2016 at 2:43:10 PM UTC-5, Wolfgang Bangerth wrote:
>
>
> All, 
> at the last deal.II Users and Developers Workshop last August, we had a 
> long discussion about ways how we can provide more starting points for 
> others to build their codes on. 
>
> We came up with the "Code Gallery": A place where anyone can deposit 
> their codes built on deal.II so that others can take a look, and use it 
> as a starting point for their own work. Our goal is to provide a forum 
> that allows for the re-use of codes, and leads to more collaboration. 
>
> Our experience with 16 years of sharing codes is that it brings people 
> together: someone who can see that a code you put online might be useful 
> to their project will likely want to collaborate with you, jointly 
> working on their project, and write papers together. In other words, 
> putting codes online doesn't just allow you to get credit for the work 
> you have done, but is also likely going to lead to contacts you might 
> otherwise never have made. 
>
> This code gallery is now online, currently with three programs. You can 
> find it at 
>https://dealii.org/code-gallery.html 
>https://dealii.org/developer/doxygen/deal.II/CodeGallery.html 
>
> The first of these pages also contains instructions on how anyone can 
> contribute to the code gallery. The purpose to doing so is purposefully 
> simple, and the requirements to uploading a code are minimal. *Please 
> consider making your code a component of the gallery!* 
>
> Best 
>   Wolfgang 
>
>
> PS: We have not gone through many versions of submission process yet. If 
> there are steps in the instructions at 
>https://dealii.org/code-gallery.html#instructions 
> that you think are unclear, let us work on them together! 
>
> -- 
>  
> Wolfgang Bangerth   email:bang...@math.tamu.edu 
>  
>  www: http://www.math.tamu.edu/~bangerth/ 
>
>

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

[deal.II] Re: possible memory leak using TrilinosWrappers direct solver?

[Michael Harmon]

Is your matrix updating at every time step or just the right hand side 
vector?

If its just the right hand side vector is changing, the development version 
of dealii has the ability to factorize the matrix once
and then just do solve(x,b) at every time step. I'm not sure, but it Might 
help.

On Monday, January 30, 2017 at 9:41:47 PM UTC-5, femFluid wrote:
>
> hi, dear all,
>
> i am using trilino's direct solver interface to solve a time-dependent 
> problem. I realized that
> when the number of iterations increases, the memory usage also increases. 
> This increase
> does not arise when turning the solver off, so just assembling the 
> matrices.
>
> At the beginning, i used the following subroutine at every time step,
>
>{
> deallog.push("DirectKLU");
> TrilinosWrappers::SolverDirect::AdditionalData data;
> data.solver_type = "Amesos_Klu";
> SolverControl   solver_control (1000, 1e-10);
> TrilinosWrappers::SolverDirect solver(solver_control, data);
> solver.solve (matrix, solution, rhs);
> thick_constraints.distribute (thick_solution);
> }
>
> then i realized that the memory might be allocated every time when 
> defining TrilinosWrappers::SolverDirect solver(.), which is not 
> released.
>  Then I predefine the solver in a namespace, which is the used by calling 
> solver.solve (matrix, solution, rhs) at each step. Still, the memory 
> leakage 
> occurs.
>
> I also tried to use "Amesos_Mumps", the problem still exists. I tried to 
> see the documentation of Amesos, i realized that when amesos solver
> finished solving, there is a procedure 'delete solver' after. May I ask 
> whether
> such a member function exists in dealII wrappers? Thanks in advance,
>
> best,
> lailai
>

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

[deal.II] cout stiffness matrix in step-3

[Michael Raba]

Hello! I'm trying to cout the stiffness matrix $A_{ij}$ in step-3 for a 
reasonably small domain 2d mesh..is $A_ij$ a function in the FEValues 
class..?
Just trying to learn the basics of dealii..

Thanks in advance,

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

[deal.II] deal.ii workflow question?

[Michael Raba]

W
What is a good way to trace/compile parts of deal.ii code without doing 
cmake/make/makerun? In particular I want to cout matrices to see what their 
entries are 


9:26 PM (7 minutes ago)

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

[deal.II] deal.ii workflow?

[Michael Raba]

What is a good way to trace/compile parts of deal.ii code without doing 
cmake/make/makerun? Just an enthusiastic student wanting to really write 
some deal.ii code!

Thanks! 
Mike 

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

Re: [deal.II] Re: question on doxygen

[Michael Harmon]

Just on my own program. 

On Wednesday, November 16, 2016 at 9:44:59 AM UTC-5, Wolfgang Bangerth 
wrote:
>
> On 11/16/2016 07:41 AM, Michael Harmon wrote: 
> > 
> > I had to change the http from: 
> > 
> > MATHJAX_REPATH = http://cdn.mathjax.org/mathjax/latest/ 
> > 
> > to https: 
> > 
> > MATHJAX_REPATH = http*s*://cdn.mathjax.org/mathjax/latest/ 
> > 
>
> Michael, 
> where did you need to change this? In deal.II somewhere? Or just in your 
> own 
> program? 
>
> Best 
>   W. 
>
> -- 
>  
> Wolfgang Bangerth  email: bang...@colostate.edu 
>  
> www: http://www.math.colostate.edu/~bangerth/ 
>
>

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

[deal.II] Re: question on doxygen

[Michael Harmon]

Thanks Timo! 

I had to change the http from:

MATHJAX_REPATH = http://cdn.mathjax.org/mathjax/latest/

to https:

MATHJAX_REPATH = http*s*://cdn.mathjax.org/mathjax/latest/



On Tuesday, November 15, 2016 at 12:03:55 PM UTC-5, Michael Harmon wrote:
>
> Hi,
>
> I used deal for my phd work, loved using it and wanted to put my code up 
> on github.   I spent a lot of time documenting it with doxygen, but latex 
> equations only work on my local machine and not on github:
>
> https://mdh266.github.io/PECS/index.html
>
> Anyone else have this issue?
>
> Thanks!
>
> Mike
>

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

[deal.II] Re: Publications based on deal.II

[Michael Harmon]

Not sure if its too late for this, but here are some publications thanks to 
deal.ii!


@Article{HaGaRe-JCP2016,
  Title= Numerical algorithms based on Galerkin methods 
for the modeling of reactive interfaces in photoelectrochemical (PEC) solar 
cells},
  Author   = {M. Harmon and I. M. Gamba and K. Ren.},
  Journal  = {Journal of Computational Physics},
  Year = {2016}
}

@phdthesis{Harmon2016,
  Title= Numerical algorithms based on Galerkin methods 
for the modeling of reactive interfaces in photoelectrochemical (PEC) solar 
cells},
  Author   = {Michael Harmon},
  School  = {University of Texas at Austin},
  Year  = {2016}
}
 


On Sunday, January 17, 2016 at 6:09:44 PM UTC-5, Wolfgang Bangerth wrote:
>
>
> All, 
>
> as you may know, we try to list all publications based on deal.II at 
>   http://dealii.org/publications.html 
> <http://www.google.com/url?q=http%3A%2F%2Fdealii.org%2Fpublications.html=D=1=AFQjCNFCMbrX9XZ7uWlZ4QbchtIN51_2KA>
>  
> We use this list to justify the effort we spend on writing this software, 
> both 
> to our universities as well as the funding agencies that support its 
> development. 
>
> In anticipation of the next release, we would like to update this page. If 
> you 
> have (or know of) a publication that uses deal.II for numerical results 
> and 
> that isn't already listed, please let us know so we can put it on there. 
> For 
> this purpose, publications also include MSc, Diploma or PhD theses, or 
> anything else that may seem appropriate. 
>
> Thanks! 
>Wolfgang 
>
> -- 
>  
> Wolfgang Bangerth   email:bang...@math.tamu.edu 
>  
>  www: http://www.math.tamu.edu/~bangerth/ 
>
>

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

[deal.II] question on doxygen

[Michael Harmon]

Hi,

I used deal for my phd work, loved using it and wanted to put my code up on 
github.   I spent a lot of time documenting it with doxygen, but latex 
equations only work on my local machine and not on github:

https://mdh266.github.io/PECS/index.html

Anyone else have this issue?

Thanks!

Mike

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

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

[Michael Harmon]

Nice! Good luck with Gmsh!


On Tuesday, August 23, 2016 at 11:10:46 AM UTC-4, krei wrote:
>
> Thanks for the response. I have a more-or-less working version where the 
> whole thing is solved together by Newton's method, but I bet solving 
> electric field separately gives a good performance boost. I will try to 
> fiddle with it, however, generating multiple meshes with matching boundary 
> for testing is not very trivial (GMSH doesn't let you do this, as far as I 
> know), I have to investigate if I can mark the elements in gmsh and then 
> separate the meshes in deal ii.
>
> On Tuesday, August 23, 2016 at 5:55:32 PM UTC+3, Michael Harmon wrote:
>>
>> Hey,
>>
>> I had a similar problem: PDES in separate domains that are coupled 
>> through an interface as a boundary condition.  You can go about it using 
>> one triangulation; I attempted to do this at first, but ended up using 
>> multiple meshes. The fact you have matching meshes on the boundary is good. 
>>  What you want to do is create two meshes and two dof handlers.  Initially 
>> you need to create a std::map to create a bijection between the faces on 
>> the different meshes that are on the interface/ connecting boundary.  When 
>> you are assembling the coupling terms on the boundary condition you can get 
>> the corresponding face in the other mesh and initialize the fe_values on 
>> that face and get its values on the face to assemble the boundary 
>> conditions.
>>
>> Check out:
>>
>> https://groups.google.com/forum/#!searchin/dealii/multiple$20triangulations%7Csort:relevance/dealii/R64BUBhyFf0/LbbxH9v8GgAJ
>>
>> If it helps I can also send you my code to see how to do this using 
>> deal.ii
>>
>> Best,
>>
>> Mike
>>
>> On Thursday, July 28, 2016 at 2:17:12 PM UTC-4, krei wrote:
>>>
>>>
>>> The problem I am currently having is directly related to my previous 
>>> post [here](
>>> https://groups.google.com/forum/#!searchin/dealii/krei/dealii/eq_zP0jrSJU/SyQXA7A-DAAJ
>>> ).
>>>
>>> The physics are exactly the same as described in that thread: I have a 
>>> two domain system: vacuum and metal, both domains have their own meshes. 
>>> [Here is a picture](http://i.imgur.com/CejXi1y.png). The meshes are 
>>> exactly matching on the boundary. I want to solve the Laplace equation for 
>>> electric fields in the vacuum part (does not depend on anything in the 
>>> metal part) and then use the electric field as a boundary condition to the 
>>> metal part.
>>>
>>> I am currently using VectorTools::point_gradient to evaluate the 
>>> electric field from the Laplace problem in the quadrature points of the 
>>> boundary cell faces of the metal mesh. As a result, it takes over an hour 
>>> to assemble the system (solving takes less than a second). 
>>>
>>> Now, considering that the mesh is exactly matching at the boundary (all 
>>> the quadrature points etc), how could I efficiently evaluate the electric 
>>> field at the boundary?
>>>
>>> And I apologize if I'm mistaken, but there doesn't seem to be any 
>>> tutorials on these kinds of problems where you have multiple domains with 
>>> multiple meshes. Or is it usually done by using a single mesh and somehow 
>>> defining different domains in that mesh? (haven't delved deeply into 
>>> Step-46, but there they do something like this, right?)
>>>
>>

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

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

[Michael Harmon]

Hey,

I had a similar problem: PDES in separate domains that are coupled through 
an interface as a boundary condition.  You can go about it using one 
triangulation; I attempted to do this at first, but ended up using multiple 
meshes. The fact you have matching meshes on the boundary is good.  What 
you want to do is create two meshes and two dof handlers.  Initially you 
need to create a std::map to create a bijection between the faces on the 
different meshes that are on the interface/ connecting boundary.  When you 
are assembling the coupling terms on the boundary condition you can get the 
corresponding face in the other mesh and initialize the fe_values on that 
face and get its values on the face to assemble the boundary conditions.

Check out:
https://groups.google.com/forum/#!searchin/dealii/multiple$20triangulations%7Csort:relevance/dealii/R64BUBhyFf0/LbbxH9v8GgAJ

If it helps I can also send you my code to see how to do this using deal.ii

Best,

Mike

On Thursday, July 28, 2016 at 2:17:12 PM UTC-4, krei wrote:
>
>
> The problem I am currently having is directly related to my previous post 
> [here](
> https://groups.google.com/forum/#!searchin/dealii/krei/dealii/eq_zP0jrSJU/SyQXA7A-DAAJ
> ).
>
> The physics are exactly the same as described in that thread: I have a two 
> domain system: vacuum and metal, both domains have their own meshes. [Here 
> is a picture](http://i.imgur.com/CejXi1y.png). The meshes are exactly 
> matching on the boundary. I want to solve the Laplace equation for electric 
> fields in the vacuum part (does not depend on anything in the metal part) 
> and then use the electric field as a boundary condition to the metal part.
>
> I am currently using VectorTools::point_gradient to evaluate the electric 
> field from the Laplace problem in the quadrature points of the boundary 
> cell faces of the metal mesh. As a result, it takes over an hour to 
> assemble the system (solving takes less than a second). 
>
> Now, considering that the mesh is exactly matching at the boundary (all 
> the quadrature points etc), how could I efficiently evaluate the electric 
> field at the boundary?
>
> And I apologize if I'm mistaken, but there doesn't seem to be any 
> tutorials on these kinds of problems where you have multiple domains with 
> multiple meshes. Or is it usually done by using a single mesh and somehow 
> defining different domains in that mesh? (haven't delved deeply into 
> Step-46, but there they do something like this, right?)
>

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