[deal.II] Re: Problem with postprocessor

Dear Thomas, Would you be so kind to tell me how am I able to create the load-displacement curves like in your paper? Did you use gnuplot? And does deal.II have a built-in function that allows one to output the necessary data directly to gnuplot or to a textfile? Thank you in advance. Kind reg

[deal.II] Re: Problem with postprocessor

Thanks, that helps a lot. So the QGaussLobatto or QIterated (from the compute_cod_array() function) stay unchanged? In how far does changing them affect the computation? Best, Seyed Ali -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://gro

[deal.II] Re: Problem with postprocessor

I did another trick: Increasing G_c has the same effect to achieve purely elastic behavior. So, I chose a high enough G_c value and it works! I obtain the same results and the duh values grow correctly. Still I cannot understand fully why when cracking is initiated, there is no increase of the

[deal.II] Re: Problem with postprocessor

Hi again, Nice words, indeed. Thank you. I will follow your advice :) But to get back to the topic: Unfortunately, you misunderstood my problem. The issue is with the displacement gradient values stored in "duh" which is computed by deal.II and given as input for the postprocessing tasks to be

[deal.II] Re: Problem with postprocessor

Dear Thomas, I already run the example with uniform mesh, hence global refinement with 0 refinement cycles. The problem is, a specimen with 100 or 1000 elements is difficult to check due to the terminal output being flooded. I could just output the result for one element, but then wheres the di

[deal.II] Problem with postprocessor

Dear Thomas Wick, Dear Timo Heister, I wrote an additional postprocessor in your existing phase-field code to allow postprocessing of strain, stress or elastic energy. Unfortunately, it seems like the STRAIN_XX and STRAIN_XY is not increasing in each step while the STRAIN_YY increases correctly

[deal.II] Re: Crack propagation

Dear Denis Davydov, I am trying to implement the pack_values() and unpack_values() functions for a FullMatrix, but the function itself in quadrature_point_data.h is defined using a vector of double values only. Nevertheless, my initial approach would be the following: struct MyQData: public Tr

[deal.II] Re: Crack propagation

Dear Thomas, Sure, my bad. I am sorry for the inconvenience it may have caused you and Timo. Unfortunately, I was just paying attention to the input text file and oversaw the changes I actually made. Won't happen again. ;) Regarding the speedup, I just figured out how to make use of the CellDa

[deal.II] Re: Crack propagation

Hi, I just figured out how to make use of the CellDataStorage function which has been recently implemented within deal.II. First of all, I want to thank Denis Davydov and Jean-Paul Pelteret for implementing it so nice and stable. :) Without your recent work, I probably would have to find a way

[deal.II] Re: Crack propagation

Dear Thomas, I found the problem. Your version works exactly like discussed in your paper, even faster with my Intel i7, namely around 1400 s. The timeconsuming part is the computation of my B-operator. The B-operator computation is implemented inside* assemble_system (bool residual_only):*

[deal.II] Re: Crack propagation

Hi, > Each Core i7 CPU has maximum 4 physical cores. So, in MPI mode, solving > the simulation using 4 core is faster than 8 cores in your computer. > This is not true. I checked it, it is slower. Best, Seyed Ali -- The deal.II project is located at http://www.dealii.org/ For mailing list/

[deal.II] Re: Crack propagation

Dear Thomas, 1. Do you compute on the same mesh? > Yes, it is exactly the same mesh which is illustrated within your paper: 16384 cells (50115 DoFs). You can observe the same value also in the terminal output. I selected 4 global pre-refinement steps and 2 adaptive refinement cycles. > 2. d

[deal.II] Re: Crack propagation

Dear Thomas, I was wondering, why my computation is rather slow compared to your results within your paper. For instance regarding the shear test you mention that for global refinement the total time amounts to 5036 s. In my case each step takes around 200 s which would result in a total time o

[deal.II] Re: Crack propagation

Dear Thomas, Thank you. I checked the values and they are similar. Within your predictor-corrector approach, I assume that you somehow exchange data between each step in order to be able to interpolate the old solution. Am I able to use the same functions to store energy data in each Gauss poi

[deal.II] Re: Crack propagation

Dear Thomas, Exactly, I did that already. It seems it is identical, but I would like to see, if your energy variable psi_e is identical to mine. This is quite cumbersome for 500 elements or more to check. I mean the computation in the first steps is anyway independent from the phase-field value

[deal.II] Re: Crack propagation

Dear Thomas, I would like to check the elastic energy you compute and compare it to my results. For a single element the computation in an elastic regime should be independent from the phase-field approach in primary steps. BR, Seyed Ali -- The deal.II project is located at http://www.dealii

[deal.II] Re: Crack propagation

Dear Thomas, I tried what you suggested and it works. Thank you :) There is a slight problem though when I try to compute the same example with the same boundary conditions for the unit_square_4.inp file. I am trying to run a one element test using your phase-field approach. It works, but there

[deal.II] Re: Crack propagation

Dear Thomas Wick, I see. So I should change it manually everywhere. I thought the degree variable will do this automatically, but why did you then implement it like this? Is it for another purpose? Kind regards, S. A. Mohseni -- The deal.II project is located at http://www.dealii.org/ For mai

[deal.II] Crack propagation

Dear Timo Heister and Thomas Wick, I am trying to run your phase-field crack propagation example, namely the single edge notched tension test, with less than 9 Gauss points. Hence, the fe variable is initialized using FE_Q(degree) where degree cannot be 0. This means degree should always be >1

[deal.II] Re: Interaction with the boundary description for a parallel distributed triangulation

I solved the problem. The following line had to be fixed in order to prevent the error due to the changing size of the vectors which were passed to MPI_Allreduce: int disp_size = dof_handler.n_dofs()/dim; Nevertheless, I wonder, if there are any commands like dof_handler.n_dofs() which also u

[deal.II] Re: Interaction with the boundary description for a parallel distributed triangulation

I think I found the problem regarding the mesh refinement issue in parallel mode. Probably, it is not even related to the boundary indicators. From what I understood, there is a problem with the MPI_Allreduce function I mentioned in the previous post: https://groups.google.com/forum/#!topic/dea

[deal.II] Re: Interaction with the boundary description for a parallel distributed triangulation

Dear Jean-Paul, > Yes, this looks like a copy-paste error in the documentation. Would you > like to submit a patch to correct it? > Sure. How and where can I submit a patch? When you refine cells at a boundary, the child cell's faces will inherit > the boundary and manifold ID's of the pa

[deal.II] Interaction with the boundary description for a parallel distributed triangulation

Hi, I assume there is a mistake within the documentation of parallel::distributed::Triangulation class. Below the "detailed description" part within the second box there is written &MyGeometry. Doesn't it have to be &MyClass? With regard to the same topic: I would like to know, if it is possib

[deal.II] Re: Access specific element within a distributed triangulation

Dear Bruno, Thanks. That's even better and even in just a single line of code. ;) MPI_Bcast(&position, 1, MPI_DOUBLE, max_rank, mpi_com); Best, Seyed Ali -- 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

[deal.II] Re: Access specific element within a distributed triangulation

Dear Bruno, Thanks. That's even better and even in just a single line of code. ;) MPI_Bcast(&position, 1, MPI_DOUBLE, max_rank, mpi_com); Best, Seyed Ali -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?

[deal.II] Re: Access specific element within a distributed triangulation

Dear Bruno, Thanks. That's even better and saves us the unnecessary loop. ;) Best, Seyed Ali -- 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

[deal.II] Re: Access specific element within a distributed triangulation

Dear all, I was able to solve the MPI variable problem. For the users who may have the same issue once: if ( this_mpi_process == max_rank ) { for (unsigned int i = 0; i < n_mpi_processes; ++i) { if ( i != max_rank ) MPI_Send(&position, 1, MPI_DOUBLE, i, 0, mpi_com); } }

[deal.II] Re: Access specific element within a distributed triangulation

Dear all, I was able to solve the MPI variable problem. For the users who may have the same issue once: if ( this_mpi_process == max_rank ) { for (unsigned int i = 0; i < n_mpi_processes; ++i) { if ( i != max_rank ) MPI_Send(&position, 1, MPI_DOUBLE, i, 0, mpi_com); } }

[deal.II] Re: Access specific element within a distributed triangulation

@Daniel: - n_vertices() only gives you the number of vertices for one process, not > the global one. In particular, you can't rely on the fact that this is the > same for all processes. Furthermore, you (probably) don't initialize all > the values of your struct. This might be the reason for th

[deal.II] Re: Access specific element within a distributed triangulation

@Prof. Bangerth: I will try to learn debugging parallel code and also to follow your words of advice. Please do not apologize since I don't think you ever became rude. I mean, after 1 emails I would definitely not be as calm as you. Thank you. :) @Daniel: Thumbs up. From your words I real

[deal.II] Re: Access specific element within a distributed triangulation

Dear all, With MPI_Allreduce it works like a charm. Thank you very much everyone. Especially Prof. Bangerth and Daniel. Kind regards, S. A. Mohseni -- 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 --

[deal.II] Re: Access specific element within a distributed triangulation

I think I figured it out ;) After thinking about your suggestion, Prof. Bangerth. It came to my mind, that the result of my max_rank variable is stored on a specific processor due to MPI_Reduce. That means I cannot access these data parts without being currently at the correspinding processor ra

[deal.II] Re: Access specific element within a distributed triangulation

Dear Prof. Bangerth, MPI_Reduce computes exactly what I want. I checked the values and they are correct. The value higher than 1e10 is probably a MPI bug while trying to find the maximum value. But this problem has nothing to do with my max_rank problem. I thought maybe you are MPI experts and

[deal.II] Re: Access specific element within a distributed triangulation

Dear Daniel, Thanks a lot. I tried the MPI_MAXLOC approach and it works. Unfortunately though, there is a slight problem I wasn't able to understand yet fully. int disp_size = triangulation.n_vertices(); struct { double value; int rank; } in[disp_size], out[disp_size]; typename DoFHandler::act

[deal.II] Re: Access specific element within a distributed triangulation

Dear Daniel, Thanks a lot. I understand now. Example 3 is exactly what I need, I try the MPI_MAXLOC approach. But is it necessary to #include ? Since deal.II won't recognize functions such as MPI_Comm_rank (MPI_COMM_WORLD, &myrank) fo

[deal.II] Re: Access specific element within a distributed triangulation

Dear Daniel, Thank you. Does your approach also apply to MPICH? Since I am using MPICH, I wonder, if this command can be used there also. This struct variable, is there an example within deal.II steps? Or do you have an example in C++ I can learn from. To be honest I am not yet very familiar w

[deal.II] Re: Access specific element within a distributed triangulation

Dear Prof. Bangerth and Jean-Paul, What I understood so far is, that the Utilities::MPI::max() function computes the maximum between all processors for each row of my vector. This means if I have a vector of 20 entries, each entry has 8 values distributed on 8 cores for instance. As a result, I

[deal.II] Re: Access specific element within a distributed triangulation

> > Seyed -- no, that's exactly the opposite of what you can do. "Locally > owned" > means precisely that this is the kind of data the current processor has > access > to. You cannot access data that is *not locally owned* (with the exception > of > ghost elements). > @ Prof. Bangerth: Wow

[deal.II] Re: Access specific element within a distributed triangulation

Thank you everyone. I understand your suggestions. From what I learned now in deal.II is, that each cell is owned by a specific processor which means I cannot access the information within a locally owned cell. That's why I have to loop over all cells and work with distributed data without using

[deal.II] Re: Access specific element within a distributed triangulation

Thank you everyone. I understand your suggestions. From what I learned now in deal.II is, that each cell is owned by a specific processor which means I cannot access the information within a locally owned cell. That's why I have to loop over all cells and work with distributed data without using

[deal.II] Re: Access specific element within a distributed triangulation

Thanks for your suggestions. Generally, in FEM you number elements like in the below picture: I understand of course, that the cells (elements) in deal.II are para

[deal.II] Access specific element within a distributed triangulation

Hi, Is it possible to access a specific element within a parallel distributed triangulation by means of the following procedure for instance: typename DoFHandler::active_cell_iterator cell = dof_handler.begin_active(), endc = dof_handler.end(); for (; cell != endc; ++cell) { if (cell->is_

[deal.II] Re: Synchronization issue for parallel computation of material forces

@Daniel: Thanks. I just tried Jean-Paul's approach again, but with a new procedure. It worked. If I could, I would mark both of your comments as the best answer. Thank you everyone, again :) I will not forget your kind assistance and hopefully help you also soon, if possible.

[deal.II] Re: Synchronization issue for parallel computation of material forces

Maybe this helps: How do you compute "reaction forces" within deal.II? Did you ever compute reaction forces and write them as output within a parallel framework? Best, Seyed Ali -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.g

[deal.II] Re: Synchronization issue for parallel computation of material forces

Is it possible to output a MPI vector with pcout for different ranks/cores? Within the constructor I define the following: pcout(std::cout, (Utilities::MPI::this_mpi_process(mpi_com) == 0)), Hence, when I replace 0 with 1 or 2 it should output for the second or third core, but it doesnt work an

[deal.II] Re: Synchronization issue for parallel computation of material forces

I tried the procedure from step-40 and these are the results: *DEAL.II:* *C++ CODE:*

[deal.II] Re: Synchronization issue for parallel computation of material forces

I tried the procedure exactly like shown in step-40 and these are the results: *DEAL.II:* *C++ CODE:*

[deal.II] Re: Synchronization issue for parallel computation of material forces

Thanks, Jean-Paul. I was thinking maybe something in the same way like step-40. I tried your approach, but can I just set it equal to each other? I did the following: *Main class* LA::MPI::Vector configurational_forces; LA::MPI::Vector local_configurational_forces; *setup_system() class* confi

[deal.II] Re: Synchronization issue for parallel computation of material forces

I realized my vector is not an MPI Vector and I am trying to use the compress function. This won't work I assume. So I changed my global variable to LA::MPI::Vector configurational_forces; This means I have to initialize it by the following command: configurational_forces.reinit(locally_owned_

[deal.II] Re: Synchronization issue for parallel computation of material forces

I am using a procedure similar to step-40. DataOut data_out; data_out.attach_dof_handler(dof_handler); // [ CONFIGURATIONAL FORCES ]== std::vector configurational_forces_magnitude(dim, "config_forces"); std::vector configurational_forces_interp

[deal.II] Re: Synchronization issue for parallel computation of material forces

And this is the procedure how I output them: DataOut data_out; data_out.attach_dof_handler(dof_handler); std::vector configurational_forces_magnitude(dim, "config_forces"); std::vector configurational_forces_interpretation(dim, DataComponentInterpretation::component_is_part_of_vector); data_

[deal.II] Synchronization issue for parallel computation of material forces

local_dof_indices, configurational_forces); } } configurational_forces.compress(VectorOperation::add); For a single core computation it is validated and correct. What could be possibly wrong when going to parallel? Best regards, Seyed Ali Mohseni -- The deal.II project is located at http://w

[deal.II] Re: Assembly of material forces

The last piece of the puzzle is solved. The small problem I mentioned was due to the problem discussed here: https://groups.google.com/d/msg/dealii/5YXHbjPs3ls/bsGMAPwXBQAJ Thank you everyone. The material force computation is now working 100% correctly for any case. Kind regards, S. A. Mohsen

[deal.II] Re: Shape function derivatives

@Prof. Bangerth: Thank you very much :) Finally, I understand how the stiffness matrix in step-18 is constructed. Your shape function derivatives are basically already the B-operator. Kind regards, S. A. Mohseni -- The deal.II project is located at http://www.dealii.org/ For mailing list/foru

[deal.II] Shape function derivatives

Hi, I found some issue when constructing the FE B-operator for multiple elements. In a single element it works perfectly. My approach is the following: template FullMatrix get_b_operator (const FEValues &fe_values, const unsigned int dofs_per_cell, const unsigned int q) { FullMatrix tmp(dim, Ge

[deal.II] Re: Assembly of material forces

@Prof. Bangerth: The upper one where pseudocolor is written, is from VisIt and deal.II. Below as a reference I showed my results from the C++ code. Both simulations are done using Q4 quadrilateral elements. There are no triangular elements here and the meshes are identical. They are intentional

[deal.II] Re: Assembly of material forces

@Prof. Bangerth: The upper one where pseudocolor is written, is from VisIt and deal.II. Below as a reference I showed my results from the C++ code. Both simulations are done using Q4 quadrilateral elements. There are no triangular elements here and the meshes are identical. They are intentional

[deal.II] Re: Assembly of material forces

First of all, thank you for all your suggestions. They helped me a lot, especially from Prof. Bangerth and Jean-Paul. Many thanks ;) I solved the assembly by listening to Prof. Bangerth's advice that I should try to implement things in a deal.II way. And after Jean-Paul told me to take a look a

[deal.II] Re: Assembly of material forces

First of all, thank you for all your suggestions. They helped me a lot, especially from Prof. Bangerth and Jean-Paul. Many thanks ;) I somehow figured the assembly out by listening to Prof. Bangerth's advice that I should try to solve it the deal.II way. And after Jean-Paul told me to take a lo

[deal.II] Re: Assembly of material forces

@Daniel: So you have a FESystem<2>(FE_Q<2>(1),2) element, i.e. linear continuous > elements with two components, and the vector represents corresponding local > DoF values? > Exactly. I defined first FESystem fe; and then template SolidMechanics::SolidMechanics(): ..., fe(FE_Q(1), dim), .

[deal.II] Re: Assembly of material forces

@Daniel: So you have a FESystem<2>(FE_Q<2>(1),2) element, i.e. linear continuous > elements with two components, and the vector represents corresponding local > DoF values? > Exactly. I defined first FESystem fe; and then template SolidMechanics::SolidMechanics(): ..., fe(FE_Q(1), dim), .

[deal.II] Re: Assembly of material forces

My problem is not the theory. I am just not a deal.II expert and therefore it is still quite difficult for me to implement my approach. Going in to theoretical detail would take maybe much longer. Maybe it is better instead, if I reformulate my question like this: There is a vector called cell_

[deal.II] Re: Assembly of material forces

Dear Prof. Bangerth, It fails, because I tried to use the same procedure for the standard assembly such as in step-18 or step-40 and I received some awkward contour plots which won't match with what I showed from the C++ code. Hence, fails is refered to my own failure in understanding the core

[deal.II] Re: Assembly of material forces

Dear Prof. Bangerth, It fails, because I tried to use the same procedure for the standard assembly such as in step-18 or step-40 and I received some awkward contour plots which won't match with what I showed from the C++ code. Hence, fails is refered to my own failure in understanding the core

[deal.II] Assembly of material forces

Dear deal.II experts, I have a question regarding the assembly of material forces also known as configurational forces. First of all, I have constructed my own solid mechanics code within deal.II which I already validated with our own C++ code. Hence, the deal.II code works until here.

[deal.II] Re: Postprocessing using the same variable twice

Thank you, Daniel. I solved my problem already in the following way before reading your post: DataOut data_out; data_out.attach_dof_handler(dof_handler); // [ DISPLACEMENT COMPONENTS ]= std::vector displacement_components; switch (dim) { case 1:

[deal.II] Postprocessing using the same variable twice

Dear all, Is it possible to output the magnitude of displacements and its components all together? std::vector data_component_interpretation(dim, DataComponentInterpretation:: component_is_part_of_vector); The above allows me to output the displacements as a vector field and shows one variabl

[deal.II] Re: Elastic energy computation

Thanks, I understand now. I just deleted the post, because I misunderstood what you meant earlier. I thought you are refering to the left eps_phi_i (first) and right eps_phi_j (second). But you were talking about: template inline SymmetricTensor<2,dim> get_strain (const std::vector > &grad

[deal.II] Re: Elastic energy computation

I checked the second one. It doesn't coincide with the strain tensor I obtain from the energy computation after I solve the system, e.g. - in GAUSS point 1 - ASSEMBLY STRAIN TENSOR 0 0.105662 0.105662 0.211325 ENERGY STRAIN TENSOR 0.001081 -0.000738 -0.000738 -0.008525 ... etc. H

[deal.II] Re: Elastic energy computation

Hi, Is it possible to compute the elastic energy for a simple 2D cube before we solve the system? Because I checked the displacement gradients and they are 0 due to having no solution probably. Hence, I wonder how would someone be able to compute the elastic energy with the following formula:

[deal.II] Elastic energy computation

Hi, Is it possible to compute the elastic energy for a simple 2D cube before we solve the system? Because I checked the displacement gradients and they are 0 due to having no solution probably. Hence, I wonder how would someone be able to compute the elastic energy with the following formula:

[deal.II] Re: Strain tensor and displacement gradients

I checked the Gauss points within my normal computation using FEValues and compared them with the evaluation points from the DataPostprocessor: GAUSS POINT COORDINATES 0.211325 0.211325 0.788675 0.211325 0.211325 0.788675 0.788675 0.788675 EVALUATION POINTS 0.00 0.00

[deal.II] Re: Strain tensor and displacement gradients

>From what I learned, all information we obtain from FEValues is automatically mapped from the unit cell to the physical space/coordinates. By patch vertices you mean the nodes of each element, hence DataPostprocessor gives me the gradients with respect to the mapped gauss points to the nodes o

[deal.II] Re: Strain tensor and displacement gradients

>From what I learned, all informtion we obtain from FEValues is aoutomatically mapped from the unit cell to the physical space/coordinates. By patch vertices you mean the nodes of each element, hence DataPostprocessor gives me the gradients with respect to the mapped gauss points to the nodes o

[deal.II] Re: Examples makefile

Hi Victor, I would check first of all, if you compiled Trilinos with the correct settings, e.g. mkdir build cd build cmake \ -DCMAKE_C_COMPILER=/path_to_your_installation/mpich-3.2/bin/mpicc \ -DCMAKE_CXX_COMPILER=/path_to_your_installation/mpich-3.2/bin/mpicxx \ -DCMAKE_For

[deal.II] Re: Strain tensor and displacement gradients

Hi, Using the postprocessor approach according to step-33 I have computed the strain tensor successfully by means of the Postprocessor::compute_derived_quantities_vector function and its displacement gradient duh. Unfortunately, within an arbitrary function called right after I solve the syst

[deal.II] Re: Strain tensor and displacement gradients

Hi, Using the postprocessor approach according to step-33 I have computed the strain tensor successfully by means of the Postprocessor::compute_derived_quantities_vector function and its displacement gradient duh. Unfortunately, within an arbitrary function called right after I solve the syst

[deal.II] Strain tensor and displacement gradients

Hi, Using the postprocessor approach according to step-33 I have computed the strain tensor successfully by means of the Postprocessor::compute_derived_quantities_vector function and its displacement gradient duh. Unfortunately, within an arbitrary function called right after I solve the syst

[deal.II] Re: Relationships between material parameters

Your ideas are very constructive and useful, I didn't think it would be so complex to make it general in deal.II. I am not an expert still, but how about we make it something similar to the FEValues class where you just specify the necessary parameters and the desired conversion. @ Jean-Paul: I

[deal.II] Relationships between material parameters

Hi everyone, I am just implementing some material parameter relationships such as lambda = E * v / (1 + v) / (1 - 2 * v) for instance. There is a table for such conversion of quantities. Would it be beneficial to have such a library that computes and converts these quantities automatically

[deal.II] Relationship between material parameters

Hi everyone, I am just implementing some material parameter relationships such as lambda = E * v / (1 + v) / (1 - 2 * v) for instance. There is a table for such conversion of quantities. Would it be beneficial to have such a library that computes and converts these quantities automatically

Re: [deal.II] Boundary ID in a parallel distributed triangulation & Neumann boundary conditions

I found the problem. :) The problem were Dirichlet boundary conditions... I just realised how constraints in deal.II work. I defined the boundary IDs in the following way now: // Boundary: Definition of boundary IDs const double tol_boundary = 1e-6; typename parallel::distributed::Triangulation

Re: [deal.II] Boundary ID in a parallel distributed triangulation & Neumann boundary conditions

I found the problem. :) The problem were Dirichlet boundary conditions... I just realised how constraints in deal.II work. I defined the boundary IDs in the following way now: // Boundary: Definition of boundary IDs const double tol_boundary = 1e-6; typename parallel::distributed::Triangulation

Re: [deal.II] Boundary ID in a parallel distributed triangulation & Neumann boundary conditions

For a cube discretized with 4 elements, I receive the following output: CELL NUMBER: 0_1:0 CELL CENTER X: 0 CELL CENTER Y: 0.25 CELL CENTER X: 0.25 CELL CENTER Y: 0 CELL NUMBER: 0_1:1 CELL CENTER X: 1 CELL CENTER Y: 0.25 CELL CENTER X: 0.75 CELL CENTER Y: 0 CELL NUMBER: 0_1:2 CELL CENTER X: 0 CE

Re: [deal.II] Boundary ID in a parallel distributed triangulation & Neumann boundary conditions

Thanks. Works like a charm. ;) *Hidden question: Why can you respond to my recent post, although I deleted it a while ago since I solved my problem already shortly afterwards?* Additional question: if ( std::abs(cell->face(i)->center()[0] - 1.0) < tol_boundary ) cell->face(i)->set_boundary

[deal.II] Boundary ID in a parallel distributed triangulation & Neumann boundary conditions

Hi, Sorry to disturb again, I have a problem. :) The following line gives me a headache: std::cout << cell->face(face_number)->boundary_id() << std::endl; ... since I cannot see anything. It outputs strange symbols such as � or some 0001 cube. My aim is to somehow write my RHS for distribu

[deal.II] Re: Running Step-40 with eclipse PTP

Hi Kartik, I am not 100% sure what you are trying to achieve, but I tried once to debug step-40 inside eclipse. I would suggest you to read the following: http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.ptp.doc.user%2Fhtml%2F06parDebugging.html

[deal.II] Re: Running Step-40 with eclipse PTP

Hi Kartik, I am not 100% sure what you are trying to achieve, but I tried once to debug step-40 inside eclipse. I would suggest you to read the following: http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.ptp.doc.user%2Fhtml%2F06parDebugging.html and also http://help.eclipse.org/k