[deal.II] Problem with Debugging step-26 program

[pushkar...@gmail.com]

Deal deal.II community

In my attempt to simulate the additive manufacturing process, I modified 
the step-26 program to reproduce the results in which I ran into an error 
which produces the output as :

$ make run
Consolidate compiler generated dependencies of target step-26
[ 66%] Built target step-26
[100%] Run step-26 with Debug configuration
***Time step 0 at t=0

===
Number of active cells: 1024
Number of degrees of freedom: 99



An error occurred in line <367> of file 
 in function
T* dealii::SmartPointer::operator->() const [with T = const 
dealii::SparsityPattern; P = dealii::SparseMatrix]
The violated condition was: 
t != nullptr
Additional information: 
(none)

Stacktrace:
---
#0  ./step-26: Step26::HeatEquation<2>::assemble_system()
#1  ./step-26: Step26::HeatEquation<2>::run()
#2  ./step-26: main


make[3]: *** [CMakeFiles/run.dir/build.make:71: CMakeFiles/run] Aborted 
(core dumped)
make[2]: *** [CMakeFiles/Makefile2:116: CMakeFiles/run.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:123: CMakeFiles/run.dir/rule] Error 2
make: *** [Makefile:137: run] Error 2
I tried to debug with gdb but coudnt make track the error. So any help in 
this regard to debug the code  will prove beneficialMoreover,I have 
attached step-26.cc file which was modified.

Sincerely
Pushkar



-- 
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/8afa57b5-ba7a-4f82-90c8-c37a01354513n%40googlegroups.com.
/* -
 *
 * Copyright (C) 2013 - 2017 by the deal.II authors
 *
 * This file is part of the deal.II library.
 *
 * The deal.II library is free software; you can use it, redistribute
 * it, and/or modify it under the terms of the GNU Lesser General
 * Public License as published by the Free Software Foundation; either
 * version 2.1 of the License, or (at your option) any later version.
 * The full text of the license can be found in the file LICENSE at
 * the top level of the deal.II distribution.
 *
 * -

 *
 * Author: Wolfgang Bangerth, Texas A University, 2013
 */


#include 
#include 
#include 
#include 
//#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include"Point_Comparison_Operator.hpp"

#include 
#include 


namespace Step26
{
  using namespace dealii;


  template 
  class HeatEquation
  {
  public:
HeatEquation();
void run();

  private:
void create_coarse_grid();
void part_height_measure();
bool cell_is_in_metal_domain(const typename hp::DoFHandler::cell_iterator );
bool cell_is_in_void_domain(const typename hp::DoFHandler::cell_iterator );
void set_active_fe_indice();
void setup_system();
void store_old_vectors();//Need to define a map to store old solution
void transfer_old_vectors();//Uses the map filled by store_old_vector()
void assemble_system();
void solve_time_step();
void output_results() const;
void refine_mesh (const unsigned int min_grid_level,
  const unsigned int max_grid_level);

Triangulation   triangulation;
hp::FECollectionfe_collection;
hp::DoFHandler  dof_handler;
hp::QCollection quadrature_collection;
hp::QCollection face_quadrature_collection;

ConstraintMatrix constraints;

SparsityPattern  sparsity_pattern;
SparseMatrix mass_matrix;
SparseMatrix laplace_matrix;
SparseMatrix system_matrix;
SparseMatrix boundary_matrix;

Vector   solution;
Vector   old_solution;
Vector   system_rhs;

double   time;
double   time_step;
unsigned int timestep_number;

const double theta;

const double 		 edge_length;
const double		 layerThickness;
const double 		 number_layer;
const double 		 heat_capacity;
const double 		 heat_conductivity;
const double 		 convection_coeff;
const double		 Tamb;
double		 		 part_height;
std::map,double> map_old_solution;
  };

  template
  class InitialCondition : public Function
  {
  public:
	  InitialCondition():Function(){}
	  virtual double value (const Point ,const unsigned int component = 0) const;
  };

  template
 

Re: [deal.II] Re: Problem related to make_hanging_nodes_constraints in the hp cases

[chong liu]

Dear Bruno


Thank you for your reply.


I think I did not express my problem well. To be clear, I used the
FE_Enriched for assigning these two finite elements and combined them using
FE_System:

FE_Enriched fe_type_1(FE_Q(1,true), nullptr);

FE_Enriched fe_type_2(FE_Q(1), enriched_function);

FESystem hp_FE(fe_type_1, fe_type_2).


I would like to use fe_type_2 with an enriched_function to approximate the
local behavior of materials. The local behavior can be captured by the
extra dofs created by fe_type_2 ( note that fe_type_1 just generates the
standard dofs since the FE_Nothing is used). However, *I found that the
extra dofs are constrained when I used the make_hanging_nodes_constraints()
function*. The reason why I used this function is the local refinement.


My questions are

(1) Is there a way to keep the extra dofs introduced by fe_type_2
unconstrained when applying the make_hanging_nodes_constraints() function?


(2) If the extra dofs require to constrain when the
make_hanging_nodes_constraints() function is utilized, can I remove these
extra dofs from the AffineConstraints container generated by the function?


Hope I express my problems clearly. Thank you for any suggestions.


Best wishes,

Chong

Bruno Turcksin  于2021年5月5日周三 上午2:21写道：

> Chong Liu,
>
> On Tuesday, May 4, 2021 at 12:06:39 PM UTC-4 liuch...@gmail.com wrote:
>
>>
>> Question:
>>
>> *How can I only constrain the hanging nodes for fe_type_1*?
>>
>
> Why do you want to do that? If you don't constrain fe_type_2, the solution
> won't be continuous. If you have more dofs in one side of the edge than in
> the other side, you need to constrain some of the dofs. It doesn't matter
> if the reason you have more dofs is because the cell has been refined or if
> it's because the fe degree is higher.
>
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/f29a2020-7916-4d74-b9ed-aae271a5479fn%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/CAKCBbH-kCgMS1UhNzN-nApLY_4sXoMA0F5KjYPxm4v47u6X3cg%40mail.gmail.com.

Re: [deal.II] using VectorTools::project_boundary_values_curl_conforming_l2 with FEsystem fe(FE_Nedelec<3>(0), 2)

[Abbas Ballout]

I am running my code in Debug using the latest 9.3 release. 
I have attached a minimal code and what it does it that it prints the 
constraints.

   - If BCs are applied for both parts of the system ,my output for the 
   constraint is:


   1. 0 = 0
   2. 1 = 0
   3. 2 = 0
   4. 3 = 0
   5. 4 = 1.0
   6. 5 = 0
   7. 6 = 1.0
   8. 7 = 0


   - If BCs are applied for the first part of the system, my output for the 
   constraint is:


   1. 0 = 0
   2. 2 = 0
   3. 4 = 1.0
   4. 6 = 1.0


   - If BCs are applied for he first partof the system my output for the 
   constraint is:


   1. 1 = 0
   2. 3 = 0
   3. 5 = 0
   4. 7 = 0




On Monday, May 3, 2021 at 8:22:58 PM UTC-4 Wolfgang Bangerth wrote:

> On 5/3/21 7:43 AM, Abbas Ballout wrote:
> > *The right hand side of the second equation isn't being updated when I 
> apply 
> > BCs even though the system matrix is.
> > *
> > 1) Hints on what I might be missing in my code?
> > 2) Any suggested workarounds in case that there is an actual bug?
>
> That's too far downstream. You have a suspicion that a function isn't 
> working 
> as expected (which is totally plausible), so let's check that right after 
> that 
> function is called. Dealing with the right hand side happens much later in 
> your program, and many other things could have gone wrong in the meantime. 
> I 
> would just print the constraints right after they were computed and check 
> that 
> first.
>
> Best
> W>
>
> -- 
> 
> Wolfgang Bangerth email: bang...@colostate.edu
> www: http://www.math.colostate.edu/~bangerth/
>
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/14582a5f-b419-481b-8129-dee84f4601d2n%40googlegroups.com.
#include 

#include 

#include 
#include 
#include 

#include 
#include 

#include 

#include 

//You will want to set this 
#include "/home/abbas/deal.ii-candi/dealii/dealii/tests/tests.h"

using namespace dealii; 

  class BC_class: public Function<3>
  {
  public:
BC_class(): Function<3>(3)  
{}

void vector_value_list(const std::vector> ,
  std::vector> &  values) const override;
  };

  void BC_class::vector_value_list(const std::vector> ,
  std::vector> &  values) const 
 {
for (unsigned int i = 0; i < points.size(); ++i)
  {
values[i][0] = 1.0;
values[i][1] = 0.0;
values[i][2] = 0.0;
  }
  }
  

int main()
{ Triangulation<3> triangulation ; 
  
  GridGenerator::hyper_cube(triangulation); 
  triangulation.begin_active()->face(4)->set_boundary_id(1);  //set the 4th boundary id to 1 to apply dirichlet BC

  DoFHandler<3>  dof_handler(triangulation);
  FESystem<3>fe(FE_Nedelec<3>(0),2);  
  dof_handler.distribute_dofs(fe);


  AffineConstraints constraints;
  constraints.clear();
  BC_class new_BC; 

  //Apply BC on the first part of the system
  VectorTools::project_boundary_values_curl_conforming_l2(
dof_handler,
0,  //the first 3 compenents
new_BC,
1,  //face ID1
constraints,
StaticMappingQ1<3>::mapping);
//Apply BC on the second part of the system
  VectorTools::project_boundary_values_curl_conforming_l2(
dof_handler,
3,  //the second 3 components 
new_BC,
1,   //face ID1
constraints,
StaticMappingQ1<3>::mapping);

 constraints.close();

initlog();
constraints.print(deallog.get_file_stream());
  
}

Re: [deal.II] AffineCostraints and MPI

[Wolfgang Bangerth]

Alberto,


Basically, I would like to rephrase The step-11 tutorial program
for parallel::shared matrices, as in step 18. If I am not wrong the "condense" 
methods do not apply to MPI::SparseMatrix and I guess I should use the methods 
of the family distribute_local_to_global,


Correct. For matrices that are stored in parallel, after-the-fact modification 
is very expensive and the way to deal with constraints is to take care of them 
during the copy-to-local phase.


but I am a bit confused and cannot 
connect the strategy in step 11


mean_value_constraints.add_line(first_boundary_dof);
for (unsigned int i = first_boundary_dof + 1; i < dof_handler.n_dofs(); ++i)
if (boundary_dofs[i] == true)
mean_value_constraints.add_entry(first_boundary_dof, i, -1);

with any distribute_local_to_global.


These lines build a ConstraintMatrix object with a single constraint. You can 
then call

  mean_value_constraints.distribute_local_to_global (...)
in the assembly phase.

But I might just not know what your problem is in detail. Can you explain what 
doesn't 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 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/27c40b58-770f-c19c-0703-97a8062a8afa%40colostate.edu.

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

[Wolfgang Bangerth]

On 5/4/21 12:15 PM, Simon Wiesheier wrote:


I looked up the Implementation of the mentioned function. Basically the 
function loops over all active cells and compares those global vertices with 
the one passed as second argument, so far so good.


But is there a similar function which accepts a cell_iterator (the given 
vertex is located on that cell)  so that inside the function body only the 
neigbor and the neighbor's neighbor are possible cells on which the given 
vertex can be located?
So I'd like to tell the function where it should begin its "search", in order 
to avoid looping over all cells (worst case).
There is a function which is doing this for a patch of neighbor_cells 
(element-patch), but I didn't find a function for the problem description from 
above.


Is such a function not yet implemented or is there already one available?


I don't think so, but it shouldn't be very hard to add an argument to the 
function that by default is simply a default-constructed cell iterator 
indicating "no initial guess given" but if not at its default value indicates 
to start search on this cell and its neighbors.


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/47cadef0-3287-db4f-27e4-a4923757374a%40colostate.edu.

[deal.II] Re: Problem related to make_hanging_nodes_constraints in the hp cases

[Bruno Turcksin]

Chong Liu,

On Tuesday, May 4, 2021 at 12:06:39 PM UTC-4 liuch...@gmail.com wrote:

>
> Question:
>
> *How can I only constrain the hanging nodes for fe_type_1*? 
>

Why do you want to do that? If you don't constrain fe_type_2, the solution 
won't be continuous. If you have more dofs in one side of the edge than in 
the other side, you need to constrain some of the dofs. It doesn't matter 
if the reason you have more dofs is because the cell has been refined or if 
it's because the fe degree is higher.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/f29a2020-7916-4d74-b9ed-aae271a5479fn%40googlegroups.com.

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

[Simon Wiesheier]

Thanks for all answers!

I've got a similar question:

I looked up the Implementation of the mentioned function. Basically the
function loops over all active cells and compares those global vertices
with the one passed as second argument, so far so good.

But is there a similar function which accepts a cell_iterator (the given
vertex is located on that cell)  so that inside the function body only the
neigbor and the neighbor's neighbor are possible cells on which the given
vertex can be located?
So I'd like to tell the function where it should begin its "search", in
order to avoid looping over all cells (worst case).

There is a function which is doing this for a patch of neighbor_cells
(element-patch), but I didn't find a function for the problem description
from above.

Is such a function not yet implemented or is there already one available?

Best
Simon

luca.heltai  schrieb am Mo., 3. Mai 2021, 09:47:

> Dear Simon,
>
> one solution you have is to pass a *Triangulation*, and then generate the
> dof cell accessors using the constructor
>
> typename DoFHandler::cell_iterator cell1(*tria_iterator, dh1);
> typename DoFHandler::cell_iterator cell2(*tria_iterator, dh2);
>
>
> Best,
> Luca.
>
> > On 30 Apr 2021, at 18:37, Simon Wiesheier 
> wrote:
> >
> > Hello Wolfgang,
> >
> > I actually have a Time Measurement in my code implemented.
> > For my current computations the difference (one call vs two calls per
> vertex) is neglible. But my model will become much bigger and therefore I'd
> like to avoid unnecessary calls to that function.
> >
> > Since I can pass only one dof_handler to that function, I guess there is
> no "obvious" way to make only one call, is it?
> >
> > -Simon
> >
> > Wolfgang Bangerth  schrieb am Fr., 30. Apr.
> 2021, 18:16:
> > On 4/30/21 10:13 AM, Simon wrote:
> > >
> > > auto cells_ref =
> GridTools::find_cells_adjacent_to_vertex(dof_handler_ref,
> > > /*vertex*/);
> > > auto cells_tmp =
> GridTools::find_cells_adjacent_to_vertex(dof_handler_tmp,
> > > /*vertex*/);
> > >
> > > I am not sure how "expensive" this function actually is. I have to
> call this
> > > function for all vertices of my triangulation, so currently I call it
> > > "2*n_vertices()" times.
> > >
> > > I´d like to call this function only once for a given vertex, i.e.
> > > "n_vertices()"times.
> > > Is there a way to realize this in combination with two different
> dof_handlers?
> >
> > There are probably ways to work around this, but I'd like to repeat a
> point
> > Bruno made the other day on this very mailing list:
> >
> > "Unless you have measured that this is a bottleneck in you code, you
> should
> > use what's the more readable. If there is a difference between these two
> > codes, it would need to be in a hot loop to matter. My advice is to
> write easy
> > to understand code and once you have made sure that the code works, then
> use a
> > profiler to find the bottleneck and optimize the code."
> >
> > I think this is good advice!
> >
> > Best
> >   W.
> >
> > --
> > 
> > Wolfgang Bangerth  email: bange...@colostate.edu
> > www:
> http://www.math.colostate.edu/~bangerth/
> >
> > --
> > The deal.II project is located at http://www.dealii.org/
> > For mailing list/forum options, see
> https://groups.google.com/d/forum/dealii?hl=en
> > ---
> > You received this message because you are subscribed to the Google
> Groups "deal.II User Group" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to dealii+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/966f38ec-5ce2-f879-c9c4-2df21ab1110b%40colostate.edu
> .
> >
> > --
> > The deal.II project is located at http://www.dealii.org/
> > For mailing list/forum options, see
> https://groups.google.com/d/forum/dealii?hl=en
> > ---
> > You received this message because you are subscribed to the Google
> Groups "deal.II User Group" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to dealii+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/CAM50jEtCWSTAhzEi7uPmgvkC94DMGJnP43AAhOuJw_97KCVT7g%40mail.gmail.com
> .
>
> --
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see
> https://groups.google.com/d/forum/dealii?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/361A39F3-3974-4B3E-B467-369FDC5902BE%40gmail.com
> .
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 

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

[Jean-Paul Pelteret]

Hi Alex,

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

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

Best,
Jean-Paul

> On 4. May 2021, at 12:36, Alex Cumberworth  
> wrote:
> 
> Hello,
> 
> I would like to calculate traction/stress vectors for the deformed 
> configuration. I have solved for a non-linear elasticity problem and am 
> dealing with the Green-Lagrange strain tensor and the second Piola-Kirchoff 
> stress tensor. I thought the simplest way to get the traction vectors would 
> be to first calculate them in the material reference frame (by calculating 
> the stress tensor and applying it to normal vectors in the material 
> reference), and then using a pushforward operation (by applying the 
> deformation gradient) to produce the stress vectors in the spatial reference 
> frame (and also dividing by the determinant of the deformation vector to take 
> care of the change in area).
> 
> However, the results do not appear as expected. To understand what was going 
> on, I first decided to apply the pushforward operation to the normal vectors. 
> I used the following code to carry this out.
> 
> template 
> class SpatialNormalVectorPostprocess: public DataPostprocessorVector {
>   public:
> SpatialNormalVectorPostprocess();
> virtual void evaluate_vector_field(
> const DataPostprocessorInputs::Vector& input_data,
> std::vector>& computed_quantities) const;
> };
> 
> template 
> SpatialNormalVectorPostprocess::SpatialNormalVectorPostprocess():
> DataPostprocessorVector(
> "spatial_normal",
> update_gradients | update_normal_vectors) {}
> 
> template 
> void SpatialNormalVectorPostprocess::evaluate_vector_field(
> const DataPostprocessorInputs::Vector& input_data,
> std::vector>& computed_quantities) const {
> 
> for (unsigned int i {0}; i != input_data.normals.size(); i++) {
> Tensor<2, dim, double> grad_u {};
> Tensor<2, dim, double> identity_tensor {};
> for (unsigned int d {0}; d != dim; d++) {
> grad_u[d] = input_data.solution_gradients[i][d];
> identity_tensor[d][d] = 1;
> }
> const Tensor<2, dim, double> deformation_grad {
> grad_u + identity_tensor};
> const Tensor<1, dim, double> material_normal_vector {
> input_data.normals[i]};
> const Tensor<1, dim, double> spatial_normal_vector_t {
> deformation_grad * material_normal_vector};
> Vector spatial_normal_vector(dim);
> for (unsigned int d {0}; d != dim; d++) {
> spatial_normal_vector[d] = spatial_normal_vector_t[d];
> }
> computed_quantities[i] = spatial_normal_vector;
> }
> }
> 
> However, as seen below, the resulting vectors are not normal to the surfaces:
> 
> 
> Contrast this with if I instead update the mesh and directly output the 
> normal vectors:
> 
> 
> Any input would be greatly appreciated.
> 
> Best wishes,
> Alex
> 
> -- 
> The deal.II project is located at http://www.dealii.org/ 
> 
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to dealii+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dealii/2e3fcd85-f799-419b-b66b-097513328f46n%40googlegroups.com
>  
> .
> 

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/46B64689-DE75-4FCE-9FA8-59157848FBAA%40gmail.com.

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

[Daniel Arndt]

Farzin,

https://www.dealii.org/current/doxygen/deal.II/namespaceDoFTools.html#a03324e6e060c6a55191b2c60ad871eab
shows that the signature of the function you want to call is

void DoFTools::make_periodicity_constraints(
  const DoFHandlerType &   dof_handler,
  const types::boundary_id   b_id1,
  const types::boundary_id   b_id2,
  const unsigned int   direction,
  AffineConstraints< number > &   constraints,
  const ComponentMask &   component_mask = ComponentMask(),
  const number   periodicity_factor = 1.)

In particular, the AffineConstraints object comes before the ComponentMask
object (which can actually be omitted in your case).

Best,
Daniel

Am Di., 4. Mai 2021 um 10:18 Uhr schrieb Farzin Mozafari <
mozafari.far...@gmail.com>:

> Dear Daniel,
> Thank you for your reply.
>
> As per your recommendation, I followed step-45 for applying PBC. As far as
> I realized, since I am not using parallel meshing, the second and third
> steps are not necessary for my case. Thus, I just used steps 1 and 4 as
> follows:
>
>
> DoFTools::make_periodicity_constraints(dof_handler,10,11,0,ComponentMask(),constraints,1);
>
> But, I am getting the following error:
>
> error: no matching function for call to
> ‘make_periodicity_constraints(dealii::DoFHandler<3, 3>&, int, int, int,
> dealii::ComponentMask, dealii::AffineConstraints&, int)’
>   188 |
>  
> DoFTools::make_periodicity_constraints(dof_handler,10,11,0,ComponentMask(),constraints,1);
>   |
>  
> ~~^~~
>
> Are there any further steps that need to be taken?
>
> Regards,
> Farzin
>
> On Friday, 30 April 2021 at 00:44:48 UTC+3 d.arnd...@gmail.com wrote:
>
>> Farzin,
>>
>> std::vector> GridGenerator::Triangulation::cell_iterator>>
>> periodicity_vector;
>>
>> should be
>>
>> std::vector> Triangulation::cell_iterator>>
>> periodicity_vector;
>>
>> In general, I would recommend looking into step-45 (
>> https://www.dealii.org/current/doxygen/deal.II/step_45.html) for an
>> example using periodic boundary conditions.
>>
>> Best,
>> Daniel
>>
>> Am Do., 29. Apr. 2021 um 14:33 Uhr schrieb Farzin Mozafari <
>> mozafar...@gmail.com>:
>>
>>> Dear Daniel,
>>>
>>> Thank you for your reply.
>>> I tried to follow your solution, but I am encountering an error. To what
>>> follows, I will post my code and error as well. I will be thankful if you
>>> give me a piece of advice to get rid of this error.
>>> As I mentioned, my domain is a linear elastic cube that I am going to
>>> impose PBCs on opposite facec.
>>>
>>> My code is:
>>>
>>>
>>> template 
>>> void CubeVector::meshing()
>>> {
>>> const Point LL(0, 0, 0);
>>> const Point RH(0.1, 0.1, 0.1);
>>> std::vector repetition(dim);
>>> repetition[0] = 1;
>>> repetition[1] = 1;
>>> repetition[2] = 1;
>>> GridGenerator::subdivided_hyper_rectangle(triangulation, repetition, LL,
>>> RH);
>>> std::string mesh_name = "Rectangle-mesh";
>>> std::ofstream outputmeshfile(mesh_name);
>>> GridOut gridout;
>>> gridout.write_eps(triangulation, outputmeshfile);
>>> std::cout << " Mesh file output to "
>>> << mesh_name
>>> << std::endl;
>>>
>>> // Boundary indicator // Assign name to every face. This indicators will
>>> be used for defining periodic faces.
>>> double Lenght_x = RH[0] - LL[0];
>>> double Lenght_y = RH[1] - LL[1];
>>> double Lenght_z = RH[2] - LL[2];
>>> for (auto& face : triangulation.active_face_iterators()){
>>> if (face->at_boundary())
>>> {
>>> if (face->center()[0] == 0) { face->set_boundary_id(10);}
>>> if (face->center()[0] == Lenght_x) { face->set_boundary_id(11);}
>>> if (face->center()[1] == 0) { face->set_boundary_id(20);}
>>> if (face->center()[1] == Lenght_y) { face->set_boundary_id(21);}
>>> if (face->center()[2] == 0) { face->set_boundary_id(30);}
>>> if (face->center()[2] == Lenght_z) { face->set_boundary_id(31);}
>>>
>>>
>>> }
>>> }
>>> std::vector>> GridGenerator::Triangulation::cell_iterator>>
>>> periodicity_vector;
>>>
>>> GridTools::collect_periodic_faces(triangulation,
>>> 10,
>>> 11,
>>> 0,
>>> periodicity_vector);
>>>
>>> }
>>>
>>>
>>> And the error is :
>>>
>>> /mnt/d/research/deal_ii_projects/3d_elasticity/step-1.cc: In member
>>> function ‘void CubeVector::meshing()’:
>>> /mnt/d/research/deal_ii_projects/3d_elasticity/step-1.cc:179:19: error:
>>> ‘Triangulation’ is not a member of ‘dealii::GridGenerator’
>>>   179 |GridGenerator::Triangulation::cell_iterator>>
>>>   |   ^
>>> /mnt/d/research/deal_ii_projects/3d_elasticity/step-1.cc:179:19: note:
>>> suggested alternatives:
>>> In file included from
>>> /usr/local/include/deal.II/grid/tria_description.h:23,
>>>  from /usr/local/include/deal.II/grid/tria.h:28,
>>>  from
>>> /mnt/d/research/deal_ii_projects/3d_elasticity/step-1.cc:2:
>>> /usr/local/include/deal.II/grid/cell_id.h:37:7: note:
>>>  ‘dealii::Triangulation’
>>>37 | class Triangulation;
>>>   |   ^
>>> In file 

Re: [deal.II] Gmsh unexpected behaviour - axes directions swapped

[Daniel Arndt]

Vachan,

It is difficult to say what goes wrong here with the information you
provided. How does the msh file created by gmsh look like. Is the boundary
information correct there?
Which gmsh version are you using? Can you post a complete minimal example
of your code?

Best,
Daniel

Am Di., 4. Mai 2021 um 05:56 Uhr schrieb vachanpo...@gmail.com <
vachanpotluri1...@gmail.com>:

> Dear all,
>
> I have encountered a strange problem while dealing with physical boundary
> ids. I have a simple cube mesh (annexure 1) which I am exporting to msh4
> format for reading through GridIn. The mesh is constructed by extruding a
> square 2D mesh in x-y plane to 3D.
>
> I was facing problems with using collect_periodic_faces()
> 
>  on
> this mesh. So I mimicked the function by writing my own test function
> (annexure 2). It loops over faces with ids 2*direction and 2*direction+1
> (with direction=2) which lie on a boundary and prints the boundary id.
>
> According to the construction of the mesh (see geo file) face1 must have
> boundary id 4 and face 2 must have boundary id 5 in the test function
> (coincidentally, matching with the cell-local id). However, when I execute
> the test, the output shows both faces have a boundary id 0.
>
> More interestingly, if I uncomment the lines in geo file and set boundary
> ids for all boundaries (in the trailing lines), then the code execution
> shows boundary ids of y-normal and z-normal faces swapped; i.e.; face1 and
> face2 show boundary id 3 which was assigned to y-normal faces (see the
> output below).
>
> Found face1 of local id 4 at boundary with bid 3
> Found face2 of local id 5 at boundary with bid 3
>
> If I instead define face1 and face2 with direction=1 using
>
> const auto face_1 = cell->face(2);
> const auto face_2 = cell->face(3);
>
> in the test function and modify the local id in print statements, then the
> boundary ids printed are 4 and 5 which were assigned to z-normal faces.
>
> Found face1 of local id 2 at boundary with bid 4
> Found face2 of local id 3 at boundary with bid 5
>
> The x normal faces lying on boundary have the correct boundary id. So it
> looks like y and z axes are getting swapped?
>
> Am I doing something wrong? Has anyone experienced this before? I am
> unable to find an explanation for this behaviour.
>
> Thanking in anticipation
> Vachan
>
> *Annexure 1*
> 
> // cube.geo file
> SetFactory("OpenCASCADE");
>
> // Simple cube geometry
> lc=0.1;
> l=1;
>
> // 2D geometry
> p1=newp; Point(p1) = {0,0,0,lc};
> p2=newp; Point(p2) = {l,0,0,lc};
> p3=newp; Point(p3) = {l,l,0,lc};
> p4=newp; Point(p4) = {0,l,0,lc};
>
> l1=newl; Line(l1) = {p1,p2};
> l2=newl; Line(l2) = {p2,p3};
> l3=newl; Line(l3) = {p3,p4};
> l4=newl; Line(l4) = {p4,p1};
>
> Transfinite Curve{l1,l2,l3,l4} = 10;
>
> ll1=newll; Curve Loop(ll1) = {l1,l2,l3,l4};
> s1=news; Plane Surface(s1) = {ll1};
> Transfinite Surface{s1} = {p1,p2,p3,p4};
> Recombine Surface{s1};
>
> // 3D extrusion
> out[] = Extrude {0,0,l} {
> Surface{s1}; Layers{10}; Recombine;
> };
>
> // Physical entities
> Physical Volume(1) = {out[1]};
> // Physical Surface(2) = {out[3],out[5]}; // x dir faces
> // Physical Surface(3) = {out[2],out[4]}; // y dir faces
> Physical Surface(4) = {s1}; // z- dir face
> Physical Surface(5) = {out[0]}; // z+ dir face
>
> *Annexure 2*
> --
> // snippet from test function mimicking collect_periodic_faces()
> for(auto cell: problem.triang.active_cell_iterators()){
> const auto face_1 = cell->face(4);
> const auto face_2 = cell->face(5);
> if(face_1->at_boundary()){
> std::cout << "Found face1 of local id 4 at boundary with bid " <<
> face_1->boundary_id()
> << "\n";
> }
> if(face_2->at_boundary()){
> std::cout << "Found face2 of local id 5 at boundary with bid " <<
> face_2->boundary_id()
> << "\n";
> }
> }
>
> --
> 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/97ddd5ab-18be-4ce2-8ecf-b0d77cd70f9dn%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 

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

[Farzin Mozafari]

Dear Daniel,
Thank you for your reply.

As per your recommendation, I followed step-45 for applying PBC. As far as 
I realized, since I am not using parallel meshing, the second and third 
steps are not necessary for my case. Thus, I just used steps 1 and 4 as 
follows:


DoFTools::make_periodicity_constraints(dof_handler,10,11,0,ComponentMask(),constraints,1);

But, I am getting the following error:

error: no matching function for call to 
‘make_periodicity_constraints(dealii::DoFHandler<3, 3>&, int, int, int, 
dealii::ComponentMask, dealii::AffineConstraints&, int)’
  188 |
 
DoFTools::make_periodicity_constraints(dof_handler,10,11,0,ComponentMask(),constraints,1);
  |
 
~~^~~

Are there any further steps that need to be taken?

Regards,
Farzin 

On Friday, 30 April 2021 at 00:44:48 UTC+3 d.arnd...@gmail.com wrote:

> Farzin,
>
> std::vector GridGenerator::Triangulation::cell_iterator>>
> periodicity_vector;
>
> should be
>
> std::vector Triangulation::cell_iterator>>
> periodicity_vector;
>
> In general, I would recommend looking into step-45 (
> https://www.dealii.org/current/doxygen/deal.II/step_45.html) for an 
> example using periodic boundary conditions.
>
> Best,
> Daniel
>
> Am Do., 29. Apr. 2021 um 14:33 Uhr schrieb Farzin Mozafari <
> mozafar...@gmail.com>:
>
>> Dear Daniel,
>>
>> Thank you for your reply.
>> I tried to follow your solution, but I am encountering an error. To what 
>> follows, I will post my code and error as well. I will be thankful if you 
>> give me a piece of advice to get rid of this error. 
>> As I mentioned, my domain is a linear elastic cube that I am going to 
>> impose PBCs on opposite facec.
>>
>> My code is:
>>
>>
>> template 
>> void CubeVector::meshing()
>> {
>> const Point LL(0, 0, 0);
>> const Point RH(0.1, 0.1, 0.1);
>> std::vector repetition(dim); 
>> repetition[0] = 1;
>> repetition[1] = 1;
>> repetition[2] = 1;
>> GridGenerator::subdivided_hyper_rectangle(triangulation, repetition, LL, 
>> RH);
>> std::string mesh_name = "Rectangle-mesh";
>> std::ofstream outputmeshfile(mesh_name);
>> GridOut gridout;
>> gridout.write_eps(triangulation, outputmeshfile);
>> std::cout << " Mesh file output to "
>> << mesh_name
>> << std::endl;
>>
>> // Boundary indicator // Assign name to every face. This indicators will 
>> be used for defining periodic faces.
>> double Lenght_x = RH[0] - LL[0];
>> double Lenght_y = RH[1] - LL[1];
>> double Lenght_z = RH[2] - LL[2];
>> for (auto& face : triangulation.active_face_iterators()){
>> if (face->at_boundary())
>> {
>> if (face->center()[0] == 0) { face->set_boundary_id(10);}
>> if (face->center()[0] == Lenght_x) { face->set_boundary_id(11);}
>> if (face->center()[1] == 0) { face->set_boundary_id(20);}
>> if (face->center()[1] == Lenght_y) { face->set_boundary_id(21);}
>> if (face->center()[2] == 0) { face->set_boundary_id(30);}
>> if (face->center()[2] == Lenght_z) { face->set_boundary_id(31);}
>>
>>
>> }
>> }
>> std::vector> GridGenerator::Triangulation::cell_iterator>>
>> periodicity_vector;
>>
>> GridTools::collect_periodic_faces(triangulation,
>> 10,
>> 11,
>> 0,
>> periodicity_vector);
>>
>> }
>>
>>
>> And the error is :
>>
>> /mnt/d/research/deal_ii_projects/3d_elasticity/step-1.cc: In member 
>> function ‘void CubeVector::meshing()’:
>> /mnt/d/research/deal_ii_projects/3d_elasticity/step-1.cc:179:19: error: 
>> ‘Triangulation’ is not a member of ‘dealii::GridGenerator’
>>   179 |GridGenerator::Triangulation::cell_iterator>>
>>   |   ^
>> /mnt/d/research/deal_ii_projects/3d_elasticity/step-1.cc:179:19: note: 
>> suggested alternatives:
>> In file included from 
>> /usr/local/include/deal.II/grid/tria_description.h:23,
>>  from /usr/local/include/deal.II/grid/tria.h:28,
>>  from 
>> /mnt/d/research/deal_ii_projects/3d_elasticity/step-1.cc:2:
>> /usr/local/include/deal.II/grid/cell_id.h:37:7: note:  
>>  ‘dealii::Triangulation’
>>37 | class Triangulation;
>>   |   ^
>> In file included from /usr/local/include/deal.II/distributed/tria.h:27,
>>  from /usr/local/include/deal.II/fe/fe_tools.h:30,
>>  from /usr/local/include/deal.II/fe/fe_system.h:28,
>>  from 
>> /mnt/d/research/deal_ii_projects/3d_elasticity/step-1.cc:11:
>> /usr/local/include/deal.II/distributed/tria_base.h:302:9: note:  
>>  ‘dealii::parallel::Triangulation’
>>   302 |   using Triangulation DEAL_II_DEPRECATED = TriangulationBase> spacedim>;
>>   | ^
>> In file included from /usr/local/include/deal.II/fe/fe_tools.h:30,
>>  from /usr/local/include/deal.II/fe/fe_system.h:28,
>>  from 
>> /mnt/d/research/deal_ii_projects/3d_elasticity/step-1.cc:11:
>> /usr/local/include/deal.II/distributed/tria.h:1403:11: note:  
>>  

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

[Farzin Mozafari]

Dear Daniel,
Thank you for your reply.

As per your recommendation, I followed step-45 for applying PBC. As long as 
understand, since I am not using parallel meshing, the second and third 
step are necessary for my case. Thus, I just used steps 1 and 4 as follows:


DoFTools::make_periodicity_constraints(dof_handler,10,11,0,ComponentMask(),constraints,1);

But, I am getting the following error:

error: no matching function for call to 
‘make_periodicity_constraints(dealii::DoFHandler<3, 3>&, int, int, int, 
dealii::ComponentMask, dealii::AffineConstraints&, int)’
  188 |
 
DoFTools::make_periodicity_constraints(dof_handler,10,11,0,ComponentMask(),constraints,1);
  |
 
~~^~~

Are there any further steps that need to be taken?

Regards,
Farzin 


On Friday, 30 April 2021 at 00:44:48 UTC+3 d.arnd...@gmail.com wrote:

> Farzin,
>
> std::vector GridGenerator::Triangulation::cell_iterator>>
> periodicity_vector;
>
> should be
>
> std::vector Triangulation::cell_iterator>>
> periodicity_vector;
>
> In general, I would recommend looking into step-45 (
> https://www.dealii.org/current/doxygen/deal.II/step_45.html) for an 
> example using periodic boundary conditions.
>
> Best,
> Daniel
>
> Am Do., 29. Apr. 2021 um 14:33 Uhr schrieb Farzin Mozafari <
> mozafar...@gmail.com>:
>
>> Dear Daniel,
>>
>> Thank you for your reply.
>> I tried to follow your solution, but I am encountering an error. To what 
>> follows, I will post my code and error as well. I will be thankful if you 
>> give me a piece of advice to get rid of this error. 
>> As I mentioned, my domain is a linear elastic cube that I am going to 
>> impose PBCs on opposite facec.
>>
>> My code is:
>>
>>
>> template 
>> void CubeVector::meshing()
>> {
>> const Point LL(0, 0, 0);
>> const Point RH(0.1, 0.1, 0.1);
>> std::vector repetition(dim); 
>> repetition[0] = 1;
>> repetition[1] = 1;
>> repetition[2] = 1;
>> GridGenerator::subdivided_hyper_rectangle(triangulation, repetition, LL, 
>> RH);
>> std::string mesh_name = "Rectangle-mesh";
>> std::ofstream outputmeshfile(mesh_name);
>> GridOut gridout;
>> gridout.write_eps(triangulation, outputmeshfile);
>> std::cout << " Mesh file output to "
>> << mesh_name
>> << std::endl;
>>
>> // Boundary indicator // Assign name to every face. This indicators will 
>> be used for defining periodic faces.
>> double Lenght_x = RH[0] - LL[0];
>> double Lenght_y = RH[1] - LL[1];
>> double Lenght_z = RH[2] - LL[2];
>> for (auto& face : triangulation.active_face_iterators()){
>> if (face->at_boundary())
>> {
>> if (face->center()[0] == 0) { face->set_boundary_id(10);}
>> if (face->center()[0] == Lenght_x) { face->set_boundary_id(11);}
>> if (face->center()[1] == 0) { face->set_boundary_id(20);}
>> if (face->center()[1] == Lenght_y) { face->set_boundary_id(21);}
>> if (face->center()[2] == 0) { face->set_boundary_id(30);}
>> if (face->center()[2] == Lenght_z) { face->set_boundary_id(31);}
>>
>>
>> }
>> }
>> std::vector> GridGenerator::Triangulation::cell_iterator>>
>> periodicity_vector;
>>
>> GridTools::collect_periodic_faces(triangulation,
>> 10,
>> 11,
>> 0,
>> periodicity_vector);
>>
>> }
>>
>>
>> And the error is :
>>
>> /mnt/d/research/deal_ii_projects/3d_elasticity/step-1.cc: In member 
>> function ‘void CubeVector::meshing()’:
>> /mnt/d/research/deal_ii_projects/3d_elasticity/step-1.cc:179:19: error: 
>> ‘Triangulation’ is not a member of ‘dealii::GridGenerator’
>>   179 |GridGenerator::Triangulation::cell_iterator>>
>>   |   ^
>> /mnt/d/research/deal_ii_projects/3d_elasticity/step-1.cc:179:19: note: 
>> suggested alternatives:
>> In file included from 
>> /usr/local/include/deal.II/grid/tria_description.h:23,
>>  from /usr/local/include/deal.II/grid/tria.h:28,
>>  from 
>> /mnt/d/research/deal_ii_projects/3d_elasticity/step-1.cc:2:
>> /usr/local/include/deal.II/grid/cell_id.h:37:7: note:  
>>  ‘dealii::Triangulation’
>>37 | class Triangulation;
>>   |   ^
>> In file included from /usr/local/include/deal.II/distributed/tria.h:27,
>>  from /usr/local/include/deal.II/fe/fe_tools.h:30,
>>  from /usr/local/include/deal.II/fe/fe_system.h:28,
>>  from 
>> /mnt/d/research/deal_ii_projects/3d_elasticity/step-1.cc:11:
>> /usr/local/include/deal.II/distributed/tria_base.h:302:9: note:  
>>  ‘dealii::parallel::Triangulation’
>>   302 |   using Triangulation DEAL_II_DEPRECATED = TriangulationBase> spacedim>;
>>   | ^
>> In file included from /usr/local/include/deal.II/fe/fe_tools.h:30,
>>  from /usr/local/include/deal.II/fe/fe_system.h:28,
>>  from 
>> /mnt/d/research/deal_ii_projects/3d_elasticity/step-1.cc:11:
>> /usr/local/include/deal.II/distributed/tria.h:1403:11: note:  
>>  

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

[Wolfgang Bangerth]

On 5/4/21 12:43 AM, Farid Mehri Sofiani wrote:

CMake Error at CMakeLists.txt:8 (FIND_PACKAGE):

   Could not find a package configuration file provided by "deal.II"

   (requested version 8.3.0) with any of the following names:

     deal.IIConfig.cmake

     deal.ii-config.cmake

   Add the installation prefix of "deal.II" to CMAKE_PREFIX_PATH or set

   "deal.II_DIR" to a directory containing one of the above files.  If

   "deal.II" provides a separate development package or SDK, be sure it has

   been installed.


Farid -- did you provide a path to a deal.II installation as suggested here?

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/a9064359-2566-5279-a887-519828a6116e%40colostate.edu.

[deal.II] Re: make install fails with ld signal 9

[Bruno Turcksin]

Vachan,


On Tuesday, May 4, 2021 at 2:45:30 AM UTC-4 vachanpo...@gmail.com wrote:

> Dear all,
>
> I am trying to do a new installation of dealii. `make install` exits while 
> compiling libdeal_II.g.so with ld signal 9. I had a look at this question 
>  and 
> noted that this might be due to RAM shortage, but my device has >2 gb RAM. 
> The output of `free -h` is:
>   totalusedfree  shared  buff/cache  
>  available
> Mem:  3.7Gi   652Mi   2.4Gi   116Mi   733Mi  
>  2.7Gi
> Swap: 2.0Gi   838Mi   1.2Gi
>
> What can I do to solve this issue? Are there any fixes or is higher RAM is 
> required?
>

Unfortunately, I think that nowadays you need 3gb of RAM to compile 
deal.II. I think that the release build requires less RAM so you could 
compile the release version alone without the debug version and see if that 
fixes your problem.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/4aba425e-7d5c-486a-980a-9f5bba02479en%40googlegroups.com.

[deal.II] Gmsh unexpected behaviour - axes directions swapped

[vachanpo...@gmail.com]

Dear all,

I have encountered a strange problem while dealing with physical boundary 
ids. I have a simple cube mesh (annexure 1) which I am exporting to msh4 
format for reading through GridIn. The mesh is constructed by extruding a 
square 2D mesh in x-y plane to 3D.

I was facing problems with using collect_periodic_faces() 

 on 
this mesh. So I mimicked the function by writing my own test function 
(annexure 2). It loops over faces with ids 2*direction and 2*direction+1 
(with direction=2) which lie on a boundary and prints the boundary id.

According to the construction of the mesh (see geo file) face1 must have 
boundary id 4 and face 2 must have boundary id 5 in the test function 
(coincidentally, matching with the cell-local id). However, when I execute 
the test, the output shows both faces have a boundary id 0.

More interestingly, if I uncomment the lines in geo file and set boundary 
ids for all boundaries (in the trailing lines), then the code execution 
shows boundary ids of y-normal and z-normal faces swapped; i.e.; face1 and 
face2 show boundary id 3 which was assigned to y-normal faces (see the 
output below).

Found face1 of local id 4 at boundary with bid 3
Found face2 of local id 5 at boundary with bid 3

If I instead define face1 and face2 with direction=1 using

const auto face_1 = cell->face(2);
const auto face_2 = cell->face(3);

in the test function and modify the local id in print statements, then the 
boundary ids printed are 4 and 5 which were assigned to z-normal faces.

Found face1 of local id 2 at boundary with bid 4
Found face2 of local id 3 at boundary with bid 5

The x normal faces lying on boundary have the correct boundary id. So it 
looks like y and z axes are getting swapped?

Am I doing something wrong? Has anyone experienced this before? I am unable 
to find an explanation for this behaviour.

Thanking in anticipation
Vachan

*Annexure 1*

// cube.geo file
SetFactory("OpenCASCADE");

// Simple cube geometry
lc=0.1;
l=1;

// 2D geometry
p1=newp; Point(p1) = {0,0,0,lc};
p2=newp; Point(p2) = {l,0,0,lc};
p3=newp; Point(p3) = {l,l,0,lc};
p4=newp; Point(p4) = {0,l,0,lc};

l1=newl; Line(l1) = {p1,p2};
l2=newl; Line(l2) = {p2,p3};
l3=newl; Line(l3) = {p3,p4};
l4=newl; Line(l4) = {p4,p1};

Transfinite Curve{l1,l2,l3,l4} = 10;

ll1=newll; Curve Loop(ll1) = {l1,l2,l3,l4};
s1=news; Plane Surface(s1) = {ll1};
Transfinite Surface{s1} = {p1,p2,p3,p4};
Recombine Surface{s1};

// 3D extrusion
out[] = Extrude {0,0,l} {
Surface{s1}; Layers{10}; Recombine;
};

// Physical entities
Physical Volume(1) = {out[1]};
// Physical Surface(2) = {out[3],out[5]}; // x dir faces
// Physical Surface(3) = {out[2],out[4]}; // y dir faces
Physical Surface(4) = {s1}; // z- dir face
Physical Surface(5) = {out[0]}; // z+ dir face

*Annexure 2*
--
// snippet from test function mimicking collect_periodic_faces()
for(auto cell: problem.triang.active_cell_iterators()){
const auto face_1 = cell->face(4);
const auto face_2 = cell->face(5);
if(face_1->at_boundary()){
std::cout << "Found face1 of local id 4 at boundary with bid " << 
face_1->boundary_id()
<< "\n";
}
if(face_2->at_boundary()){
std::cout << "Found face2 of local id 5 at boundary with bid " << 
face_2->boundary_id()
<< "\n";
}
}

-- 
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/97ddd5ab-18be-4ce2-8ecf-b0d77cd70f9dn%40googlegroups.com.

Re: [deal.II] Inhomogeneous periodic boundary constraints

[Alex Cumberworth]

I ended up getting it working, so in case anyone else is interested in 
doing something similar, I have attached updated versions of the previous 
scripts. I further modified set_periodicity_constraints so that it can take 
a function to set the inhomogeneity based on the values of the two support 
points associated with the two degrees of freedom that are being tied 
together, although it would need to be modified for more general use (the 
functions works on the difference of the two points, and further it uses 
only the absolute value of the difference in the x-component). I have also 
not made changes to allow for adaptive mesh refinement. I think this is a 
pretty ugly solution to the general problem of inhomogeneous periodic 
boundary constraints, but I couldn't see how to do it without modifying 
these functions without largely replicating them.

The issues mentioned in the previous post regarding 
distribute_local_to_global() and AffineConstraints::distribute() stemmed 
from a misunderstanding of exactly what these functions were doing, and 
have been fixed. It does seem that with these constraints, SolverCG does 
not work as a solver (I suppose the matrix is not symmetric anymore?), but 
either SolverGMRES or the direct solver SparseDirectUMFPACK work.

The script has also been improved based on other tutorials, and now 
includes parsing for a parameter file. I tried to include an example 
parameter file but I guess the mailing list has a restriction on allowable 
file types.

Best,
Alex

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/0c692129-a363-4d67-98a7-8c7e04ba3892n%40googlegroups.com.
#ifndef modded_periodic_functions_h
#define modded_periodic_functions_h

#include 
#include 
#include 
#include 

#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 

using namespace dealii;

template 
void set_periodicity_constraints(
const FaceIterator& face_1,
const typename identity::type& face_2,
const FullMatrix& transformation,
AffineConstraints& affine_constraints,
const std::vector> dofs_to_supports,
Function& boundary_function,
const ComponentMask& component_mask,
const bool face_orientation,
const bool face_flip,
const bool face_rotation,
const number periodicity_factor) {
static const int spacedim = FaceIterator::AccessorType::space_dimension;

// we should be in the case where face_1 is active, i.e. has no children:
Assert(!face_1->has_children(), ExcInternalError());

Assert(face_1->n_active_fe_indices() == 1, ExcInternalError());

// TODO: the implementation makes the assumption that all faces have the
// same number of dofs
//AssertDimension(
//face_1->get_fe(face_1->nth_active_fe_index(0)).n_unique_faces(),
//1);
//AssertDimension(
//face_2->get_fe(face_2->nth_active_fe_index(0)).n_unique_faces(),
//1);
//const unsigned int face_no = 0;

// If face_2 does have children, then we need to iterate over these
// children and set periodic constraints in the inverse direction:
if (face_2->has_children()) {
Assert(face_2->n_children() == GeometryInfo::max_children_per_face,
   ExcNotImplemented());

const unsigned int dofs_per_face =
face_1->get_fe(face_1->nth_active_fe_index(0))
.n_dofs_per_face();
FullMatrix child_transformation(dofs_per_face, dofs_per_face);
FullMatrix subface_interpolation(dofs_per_face, dofs_per_face);

for (unsigned int c = 0; c < face_2->n_children(); ++c) {
// get the interpolation matrix recursively from the one that
// interpolated from face_1 to face_2 by multiplying from the left
// with the one that interpolates from face_2 to its child
const auto& fe = face_1->get_fe(face_1->nth_active_fe_index(0));
fe.get_subface_interpolation_matrix(fe, c, subface_interpolation);
subface_interpolation.mmult(child_transformation, transformation);

set_periodicity_constraints(
face_1,
face_2->child(c),
child_transformation,
affine_constraints,
dofs_to_supports,
boundary_function,
component_mask,
face_orientation,
face_flip,
face_rotation,
periodicity_factor);
 

[deal.II] make install fails with ld signal 9

[vachanpo...@gmail.com]

Dear all,

I am trying to do a new installation of dealii. `make install` exits while 
compiling libdeal_II.g.so with ld signal 9. I had a look at this question 
 and noted 
that this might be due to RAM shortage, but my device has >2 gb RAM. The 
output of `free -h` is:
  totalusedfree  shared  buff/cache  
 available
Mem:  3.7Gi   652Mi   2.4Gi   116Mi   733Mi  
 2.7Gi
Swap: 2.0Gi   838Mi   1.2Gi

What can I do to solve this issue? Are there any fixes or is higher RAM is 
required?

Thanking in anticipation
Vachan

-- 
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/c9268c58-9e47-429c-9f48-7e6eafc54d6en%40googlegroups.com.

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

[Farid Mehri Sofiani]

Dear Jean-Paul,

I am trying to use PRISMS-PF (an open-source software) which is built on
top of dealii library. As I wanted to compile, I faced the following error:

$ cmake .

CMake Deprecation Warning at CMakeLists.txt:5 (CMAKE_MINIMUM_REQUIRED):

  Compatibility with CMake < 2.8.12 will be removed from a future version of

  CMake.



  Update the VERSION argument  value or use a ... suffix to tell

  CMake that the project does not need compatibility with older versions.





CMake Error at CMakeLists.txt:8 (FIND_PACKAGE):

  Could not find a package configuration file provided by "deal.II"

  (requested version 8.3.0) with any of the following names:



deal.IIConfig.cmake

deal.ii-config.cmake



  Add the installation prefix of "deal.II" to CMAKE_PREFIX_PATH or set

  "deal.II_DIR" to a directory containing one of the above files.  If

  "deal.II" provides a separate development package or SDK, be sure it has

  been installed.





-- Configuring incomplete, errors occurred!


Kind regards,

Farid

On Mon, May 3, 2021 at 10:22 PM Jean-Paul Pelteret 
wrote:

> Hi Farid,
>
> Would you care to share more details about what the exact problem is? Are
> you trying to use the MacOS package, or building from source? If the latter
> then a full build log would be very useful. I’m not sure if any of the
> developers has a Mac that runs Big Sur (or if our CI testers run it), so it
> might be that we’d need some help in testing any possible fixes.
>
> Best,
> Jean-Paul
>
> On 3. May 2021, at 21:57, Farid Mehri Sofiani 
> wrote:
>
> Hi! It seems that dealii doesn't work on Big Sur mac OS. Is there any way
> to address this issue?
>
>
> kind regards,
> Farid
>
> --
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see
> https://groups.google.com/d/forum/dealii?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/d5a952af-d070-4333-84f9-9abe13f2102en%40googlegroups.com
> 
> .
>
>
> --
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see
> https://groups.google.com/d/forum/dealii?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/dealii/AMC6zTgybL0/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/1AE0F61C-EDF3-4394-80DC-5DC99C95CD71%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/CAEF-cZRGAFVMa7s_KEcdB31riOy%2BGx_Mg-WrzG-%2BuYS%3DDSpJog%40mail.gmail.com.