date:20180806

Re: [deal.II] How to give dof per each node?

2018-08-06 Thread Jean-Paul Pelteret

Dear Chandra,

Its a little unclear to me as to what you mean when you say 

> to give dof per each element/node

Do you mean that you assign DoFs to the mesh? If so, then what Rakesh has 
sketched out for you gives an outline of the steps needed to do this are. This 
is mirrored in the second tutorial step-2 
. (Have you seen the 
tutorials?)

Ifs that not what you want to do, but rather you want to ask how many DoFs like 
on each finite element cell, then you can simply ask the finite element itself:

const FE_Q  fe (2 /*polynomial order*/);
fe.n_dofs_per_cell() 
;

I hope that this helps you.

Best,
Jean-Paul

> On 03 Aug 2018, at 07:55, chandra sekhar yaswanth devarakonda 
>  wrote:
> 
> hello,
> I am new to dealii.Can anyone tell me how to give dof per each element/node.I 
> want to write fem code to find out mode shapes of a cantilever beam in 1d.I 
> did that in matlab.But i want to use dealii.Can anyone help?
> I watched few lectures but felt little difficult to understand.
> 
> -- 
> The deal.II project is located at http://www.dealii.org/ 
> 
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to dealii+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

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

Re: [deal.II] UMAT subroutine in dealii.

2018-08-06 Thread Jean-Paul Pelteret

Dear Mahesh,

If you browse through both the tutorials 
 and the code-gallery 
contributions , you 
will notice that deal.II is completely agnostic about which finite element 
formulation you wish to implement and the concept of a material model 
(constitutive law) associated with the governing equations. So you have 
complete freedom as to how you would want to implement a material law. There 
are also a few application frameworks based on deal.II (see the “Applications” 
tab at the top of the homepage ) that would presumably 
offer some interface between user defined material models and their framework, 
but if your interest lies in using one of these codes then you would have to 
investigate this more deeply yourself.

If you could give more details as to what the nature of the problem that you’re 
trying to implement is, then maybe someone with experience in this specific 
topic could share some further insights with you.

Best,
Jean-Paul

> On 06 Aug 2018, at 19:08, Mahesh Prasad  wrote:
> 
> Hello everyone,
> 
> I am making a transition from ABAQUS to dealii. But they are many open 
> questions. Among them the most important one is User defined materials.
> I would like to know if anyone has worked / still working in implementing 
> UMAT subroutine within dealii ? 
> 
> Best regards,
> Mahesh Prasad.
> 
> -- 
> The deal.II project is located at http://www.dealii.org/ 
> 
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to dealii+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

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

Re: [deal.II] implemention of periodic boundary condition

2018-08-06 Thread Jean-Paul Pelteret

Hi Chucui,

I’ll try to answer some of your questions quickly:

> 1. Why the source code of function "GridTools::collect_periodic_faces" use 
> "cell_iterator" rather than "active_cell_iterator”?

Because your mesh should be periodic from the coarsest representation all the 
way down to the finest representation. This is important for very large 
problems, as deal.II can then exploit the parent-child relationship to find 
matching DoF pairs rather than traversing the entire fine-scale problem to do 
the same.

> As I need to refine my domain by 
> triangulation.refine_global (7);
> in https://www.mail-archive.com/dealii@googlegroups.com/msg00220.html 
> 
> I find the same problem, what "Periodic boundaries can only have a difference 
> of 1 refinement level between pairs of faces." means?  

Consider a mesh on which boundary with id 0 is considered the periodic match to 
a boundary with id 1. This means that there are faces that have boundary id 0 
that are considered the periodic neighbours to faces with boundary id 1. In the 
simplest view of things, one might wish to ensure that refinement of cells 
along boundary 0 is exactly the same as that along boundary 1, and the number 
of DoFs along boundary 0 exactly matches boundary 1. However, it is possible to 
implement constraints for “hanging nodes” between boundaries 0 and 1, i.e. the 
refinement of cells along boundary 0 is not the same as that along boundary 1, 
and the number of DoFs does not necessarily match either. To accomplish this, 
the same arguments for normal internal hanging nodes applies, and therefore 
periodic neighbours can only have 1 level of refinement difference between them.

> And how can I implement my project for refine global (not in parallel)?

There should be no problem with this. I would suggest looking at step-45 
 if you haven’t done so 
already.

> 2. If I use "Triangulation" rather than 
> "parallel::distributed::Triangulation", shall I use the function 
> "GridTools::collect_periodic_faces"? Or just use only 
> "DoFTools::make_periodicity_constraints"?

I guess that depends on what you’re trying to achieve… Based on your first 
query with your problem statement, DoFTools::make_periodicity_constraints() 
should do what you are wanting.

> 3. If use "DoFTools::make_periodicity_constraints" only, my code is
>   template 
>   void StokesProblem::setup_dofs ()
>   {
> 
> std::vector block_component (4);
> block_component[0] = 0;
> block_component[1] = 1; 
> block_component[2] = 2;
> block_component[3] = 3;
> 
> 
> dof_handler.distribute_dofs (fe);
> //DoFRenumbering::component_wise (dof_handler);
> DoFRenumbering::component_wise (dof_handler, block_component);
> 
>  
> constraints.clear ();
> const unsigned int n_dofs_per_face = fe.dofs_per_face;
> FullMatrix rotation_matrix(n_dofs_per_face);
> for (unsigned int d=0; d  {
>rotation_matrix[d][d]=1.;
>  }
> 
> 
> Tensor<1,dim> offset;
> const ComponentMask component_mask = ComponentMask();
>
>std::vector first_vector_components;
>first_vector_components.push_back(0);
>first_vector_components.push_back(1);
>first_vector_components.push_back(2);
>first_vector_components.push_back(3);
>
>  const typename DoFHandler::active_face_iterator face_0; 
>  const typename DoFHandler::active_face_iterator face_1;
>  const typename DoFHandler::active_face_iterator face_2;
>  const typename DoFHandler::active_face_iterator face_3;
> 
>  for (typename DoFHandler::active_cell_iterator cell = 
> dof_handler.begin_active();
>   cell != dof_handler.end();
>   ++cell)
>{ 
> 
>  for (unsigned int i = 0; i < GeometryInfo::faces_per_cell; ++i)
>{
>  const typename DoFHandler::active_face_iterator face = 
> cell->face(i);
>  
>  if (face->at_boundary() && face->boundary_id() == 0)
>{
> const typename DoFHandler::active_face_iterator face_0 = 
> face; 
>}
>  
>  else if (face->at_boundary() && face->boundary_id() == 1)
>{
>  const typename DoFHandler::active_face_iterator face_1 
> = face; 
>}
>  else if (face->at_boundary() && face->boundary_id() == 2)
>{
> const typename DoFHandler::active_face_iterator face_2 = 
> face; 
>}
>  
> else if (face->at_boundary() && face->boundary_id() == 3)
>{
>  const typename DoFHandler::active_face_iterator face_3 
> = face; 
>}   
>
>}
>  
>

[deal.II] UMAT subroutine in dealii.

2018-08-06 Thread Mahesh Prasad

Hello everyone,

I am making a transition from ABAQUS to dealii. But they are many open 
questions. Among them the most important one is User defined materials.
I would like to know if anyone has worked / still working in implementing 
UMAT subroutine within dealii ? 

Best regards,
Mahesh Prasad.

-- 
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] implemention of periodic boundary condition

2018-08-06 Thread Jean-Paul Pelteret

Dear Chucui,

Since you haven’t provided a minimal working example, I could only speculate 
what might be the issue. From the incomplete example that you’ve shown here, I 
would guess that this might be the problem:

> On 05 Aug 2018, at 09:28, chucui1...@gmail.com wrote:
> 
>   GridTools::collect_periodic_faces(dof_handler,
>   /*b_id1*/ 0,
>   /*b_id2*/ 1,
>   /*direction*/ 0,
>   periodicity_vector);
>   GridTools::collect_periodic_faces(dof_handler,
>   /*b_id1*/ 2,
>   /*b_id2*/ 3,
>   /*direction*/ 0,   <——— Should be a "1"
>   periodicity_vector);

For the unit cube coarse face pairs {0,1} should have their normal in the 
x-direction, and coarse face pairs {2,3} would then have their normal vectors 
orientated in the y-direction.

If not then it *might* be that your coarsest grid needs to have more than one 
cell. However, looking at the documentation to step-45 
 (specifically the 
introduction), I don’t believe this to be the case. You can try to take the 
coarsest grid, refine it globally once, and then use the 
GridTools::flatten_triangulation() 

 function to make this the new coarsest grid.

I hope that this helps you solve the problem.

Best,
Jean-Paul

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

[deal.II] Re: current state of XFEM implementation in dealii

2018-08-06 Thread Bruno Turcksin

Alex,

On Monday, August 6, 2018 at 11:24:53 AM UTC-4, Loylick wrote:
>
> I'd like to ask about the current state of XFEM methode support in the 
> Dealii library. I'm going to solve a crack detection problem in 2D. 
> Is it possible to solve the problem by presently existing tools in Dealii 
> or it will require some substatial extension and I'd better find another 
> library
> for this kind of problem?
>
This is not my area of expertise but you deal.II supports XFEM. See 
https://groups.google.com/d/msg/dealii/cFPPH1igZqA/6eLIsOOCBQAJ

Best,

Bruno

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

[deal.II] Re: implemention of periodic boundary condition

2018-08-06 Thread chucui1016

Hi All,

I am working on this project and find some problems new:

1. Why the source code of function "GridTools::collect_periodic_faces" use "
cell_iterator" rather than "active_cell_iterator"? As I need to refine my 
domain by 
triangulation.refine_global (7);
in https://www.mail-archive.com/dealii@googlegroups.com/msg00220.html
I find the same problem, what "Periodic boundaries can only have a 
difference of 1 refinement level between pairs of faces." means?  And how 
can I implement my project for refine global (not in parallel)?

2. If I use "Triangulation" rather than 
"parallel::distributed::Triangulation", shall I use the function 
"GridTools::collect_periodic_faces"? Or just use only 
"DoFTools::make_periodicity_constraints"?

3. If use "DoFTools::make_periodicity_constraints" only, my code is
  template 
  void StokesProblem::setup_dofs ()
  {

std::vector block_component (4);
block_component[0] = 0;
block_component[1] = 1; 
block_component[2] = 2;
block_component[3] = 3;


dof_handler.distribute_dofs (fe);
//DoFRenumbering::component_wise (dof_handler);
DoFRenumbering::component_wise (dof_handler, block_component);

 
constraints.clear ();
const unsigned int n_dofs_per_face = fe.dofs_per_face;
FullMatrix rotation_matrix(n_dofs_per_face);
for (unsigned int d=0; d offset;
const ComponentMask component_mask = ComponentMask();
   
   std::vector first_vector_components;
   first_vector_components.push_back(0);
   first_vector_components.push_back(1);
   first_vector_components.push_back(2);
   first_vector_components.push_back(3);
   
 const typename DoFHandler::active_face_iterator face_0; 
 const typename DoFHandler::active_face_iterator face_1;
 const typename DoFHandler::active_face_iterator face_2;
 const typename DoFHandler::active_face_iterator face_3;

 for (typename DoFHandler::active_cell_iterator cell = 
dof_handler.begin_active();
  cell != dof_handler.end();
  ++cell)
   { 

 for (unsigned int i = 0; i < GeometryInfo::faces_per_cell; 
++i)
   {
 const typename DoFHandler::active_face_iterator face = 
cell->face(i);
 
 if (face->at_boundary() && face->boundary_id() == 0)
   {
const typename DoFHandler::active_face_iterator face_0 
= face; 
   }
 
 else if (face->at_boundary() && face->boundary_id() == 1)
   {
 const typename DoFHandler::active_face_iterator 
face_1 = face; 
   }
 else if (face->at_boundary() && face->boundary_id() == 2)
   {
const typename DoFHandler::active_face_iterator face_2 
= face; 
   }
 
else if (face->at_boundary() && face->boundary_id() == 3)
   {
 const typename DoFHandler::active_face_iterator 
face_3 = face; 
   }   
   
   }
 
 DoFTools::make_periodicity_constraints (face_0, face_1, 
constraints, component_mask, true, false, false, rotation_matrix, 
first_vector_components);
 DoFTools::make_periodicity_constraints (face_2, face_3, 
constraints, component_mask, true, false, false, rotation_matrix, 
first_vector_components);
   }
[...]

but get the error:
Linking CXX executable Problem13-2
/.../13-4-pbc-for-run/together-pbc.cc:647: error: undefined reference to 
'void 
dealii::DoFTools::make_periodicity_constraints, false> > 
>(dealii::TriaActiveIterator, false> > const&, 
dealii::identity, false> > >::type const&, 
dealii::ConstraintMatrix&, dealii::ComponentMask const&, bool, bool, bool, 
dealii::FullMatrix const&, std::vector > const&)'
/.../13-4-pbc-for-run/together-pbc.cc:648: error: undefined reference to 
'void 
dealii::DoFTools::make_periodicity_constraints, false> > 
>(dealii::TriaActiveIterator, false> > const&, 
dealii::identity, false> > >::type const&, 
dealii::ConstraintMatrix&, dealii::ComponentMask const&, bool, bool, bool, 
dealii::FullMatrix const&, std::vector > const&)'
collect2: error: ld returned 1 exit status
make[3]: *** [Problem13-2] Error 1
make[2]: *** [CMakeFiles/Problem13-2.dir/all] Error 2
make[1]: *** [CMakeFiles/run.dir/rule] Error 2
make: *** [run] Error 2


I wander what is the reason for this issue.

Thanks very much!

Best,
Chucui

在 2018年8月5日星期日 UTC+8下午3:28:01，chucu...@gmail.com写道：
>
> Hi All,
>
> I am having a problem of implementing periodic boundary condition, I have 
> 4 variables to solve, and I make them into a blockvector:
>
>
> 
>
> each component of it is a scalar. All of them have periodic boundary 
> condition: 
>
>
>

[deal.II] current state of XFEM implementation in dealii

2018-08-06 Thread Loylick

Hello!
 
I'd like to ask about the current state of XFEM methode support in the 
Dealii library. I'm going to solve a crack detection problem in 2D. 
Is it possible to solve the problem by presently existing tools in Dealii 
or it will require some substatial extension and I'd better find another 
library
for this kind of problem?

Alex

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

Re: [deal.II] How to give dof per each node?

Re: [deal.II] UMAT subroutine in dealii.

Re: [deal.II] implemention of periodic boundary condition

[deal.II] UMAT subroutine in dealii.

Re: [deal.II] implemention of periodic boundary condition

[deal.II] Re: current state of XFEM implementation in dealii

[deal.II] Re: implemention of periodic boundary condition

[deal.II] current state of XFEM implementation in dealii

8 matches

Site Navigation

Mail list logo

Footer information