date:20201012

Re: [deal.II] FullMatrix to SparseMatrix

2020-10-12 Thread Wolfgang Bangerth


On 10/11/20 6:09 PM, Nikki Holtzer wrote:
I was hoping to take the outer product which is formed in a FullMatrix, called 
Kronecker_matrix below, multiply it by a coefficient, and add a matrix to it 
called nonlinear_part_full. This entire operation I have tried to put into a 
Sparse matrix, called Nonlinear_part, because I need to add this term to 
linear_part which is Sparse. I have done this simply because it was the only 
way I could make the addition between linear_part (Sparse) and 
nonlinear_part_full (FullMatrix) work all while trying to make the code as 
efficient as possible.


But if the nonlinear part is a dense matrix, you will necessarily add entries 
into the sparse matrix that are not present in the sparsity pattern. When you 
build a sparse matrix with a certain sparsity pattern, you are saying "these 
are the entries that could possibly be nonzero, please allocate memory for 
them". So when you later add the dense matrix to the sparse one, you're 
breaking this promise.


I don't quite understand why you copy everything into a sparse matrix in your 
code. Couldn't you just keep everything in dense matrices and do the linear 
solve with that?


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/a0cc822e-19a2-9a29-5fd7-5f735e0eeadd%40colostate.edu.

Re: [deal.II] Re: Fluid-Structure interaction

2020-10-12 Thread Ramiro James Rebolledo Cormack

Thanks Bruno, Jean-Paul, and Thomas.

I going to study each answer that you suggest me in detail, looks like it
is exactly what I need.

El dom., 11 oct. 2020 a las 10:41, blais...@gmail.com (<
blais.br...@gmail.com>) escribió:

> Dear Ramiro,
> You could also take a look at step-70 by Luca and I. It deplays a very
> prototype-ish fluid-structure interaction framework using immersed
> boundaries. I am sure Luca has progressed a lot on this issue since then.
> You can also look at software derived from Deal.II. Our group develops a
> full Navier-Stokes solver (https://github.com/lethe-cfd/lethe) based on
> deal.II. Extending it to a fluid-structure software could be done
> relatively simply if you want to use a non-monolithic coupling.
> Best
> Bruno
>
>
> On Wednesday, October 7, 2020 at 10:29:02 a.m. UTC-4 ramrebol wrote:
>
>> Hi everyone.
>>
>> I'm looking for a solver to solve a fluid-structure problem, like a heart
>> valve: the valve is an elastic material, and the blood could be considered
>> as an incompressible fluid (evolutionary incompressible Navier--Stokes
>> equations).
>>
>> In step-46 I see a Fluid-Structure interaction implemented in dealii
>>
>> https://www.dealii.org/current/doxygen/deal.II/step_46.html
>>
>> but I'm not sure if it is appropiate to a more realistic problem.
>>
>> I know that the first thing is to know what is the numerical method that
>> we want implement, but I'm not sure what is the appropiated numerical
>> method to solve this strong coupled problem.
>>
>> My goal is to implement a model of a valve oppening and close due blood
>> pressure (a cilindrical tube with an elastic obstacle in the middle). Do
>> you think dealii could be an appropiate code to model this? Or is a too big
>> problem?
>>
>> The other possibility is to use commercial software (COMSOL or ANSIS),
>> but due we don't know what they do to solve the problem, I could prefer to
>> program "my own" solver, for example with dealii.
>>
>> I suppose there must be many papers proposing algorithms for these types
>> of coupled problems, but I have not found anyone explaining the
>> mathematical aspects behind it. So I am very confused about how to
>> implement this coupled problem.
>>
>> I don't know if is too much to ask here,  if so, I apologize in advance.
>>
>> In concrete, my questions are the following:
>>
>> - what is the numerical algorithm to solve this coupled problem.
>> - and, is it possible to solve this with dealii? Or is a too big problem.
>>
>>
>>
>>
>> --
>> Ramiro
>>
> --
> 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/c5a55124-992b-4bec-8135-92bdd60e7c85n%40googlegroups.com
> 
> .
>


-- 
Ramiro

-- 
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/CALsG1Z9DkEHq9jjnwecpoOhAP%2B729zX_pDUux_czworCP3O3hg%40mail.gmail.com.

Re: [deal.II] Re: APPLY BOUNDARY CONDTION ON INTERNAL FACE

2020-10-12 Thread Daniel Arndt

Xiang,

Adding to Bruno's response: If the interface you want to apply Dirichlet
boundary conditions to stays the same through the whole simulation, then
treating the corresponding faces as disjoint while creating your mesh might
be a better option.
Setting constraints yourself requires you to know how the degrees of
freedom map to function values (which depends on the finite element you are
using). FE_Q elements are nodal, though, so you can simply constrain the
degrees of freedom to the desired function value at the corresponding
support points.

Best,
Daniel


Am Mo., 12. Okt. 2020 um 09:21 Uhr schrieb Bruno Turcksin <
bruno.turck...@gmail.com>:

> Xiang,
>
> You cannot apply a boundary condition on an internal face. You need to use
> the AffineConstraint
> 
> class to impose the constraints yourself. This is what we use internally to
> apply Dirichlet boundary condition.
>
> Best,
>
> Bruno
>
>
>
> On Monday, October 12, 2020 at 2:10:15 AM UTC-4 shya...@gmail.com wrote:
>
>> Hi, I want to model injecting heat fluid into a tiny fracture which is
>> inside a block. The fracture is modeled as an interface which is an
>> internal face shared by two hex elements. Is it possible for us to apply
>> the Dirichlet boundary condition on the interface? If not, how should I do
>> it?
>>
>> Best,
>>
>> Xiang
>>
> --
> 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/3840f39f-e3ae-4d76-886b-c3658bcade13n%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/CAOYDWbK9x9i0CjYxuAK2Hu3dKHULXz07%2BOHDLv8yLJ7uLLX1bQ%40mail.gmail.com.

Re: [deal.II] Issue with MeshWorker::InegrationInfo.values

2020-10-12 Thread Timo Heister

You will need to tell the MeshWorker to compute the values with something like

info.cell_selector.add("solution", true, ..., ...);

On Mon, Oct 12, 2020 at 8:18 AM Gregor Pfau  wrote:
>
> Dear Timo,
>
> first of all thank you for your reply and advice.
>
> As you suspected,  info.values[0][0] and info.values[0] are both of size 
> zero. I have tried this with the example given in my previous question, as 
> well as with the original code.
>
> Since the original problem is time dependent, the goal was to get the 
> solution values of the previous timestep at the quadrature points.
> Could it be, that I need to use a different approach, at least for the first 
> time step ?
>
> I have tried get_function_values, but even with the workaround proposed here: 
> https://groups.google.com/g/dealii/c/pjUBPbaZgxg/m/lSPLgiTtAgAJ , I still get 
> the same error.
>
> To be honest, I am not shure how to tackle either apporach.
>
> Thank you very much.
>
> Best regards,
> Gregor
>
>
>
>
>
>
>
>
> Timo Heister schrieb am Samstag, 26. September 2020 um 21:44:05 UTC+2:
>>
>> Hi Gregor,
>>
>> I would suggest that you grab a debugger (inside an IDE like
>> QtCreator, VS Code, etc.) or gdb directly and inspect the types and
>> content of "info", "info.values", and "info.values[0]" in that order
>> to see if they are all valid objects and have a non-zero size. From
>> the error message, it sounds like that this is not the case.
>>
>> Best,
>> Timo
>>
>> On Sat, Sep 26, 2020 at 8:25 AM Gregor Pfau  wrote:
>> >
>> > Dear Deal.II community,
>> >
>> > currently I am trying to solve a nonlinear problem with Newtons Method 
>> > using MeshWorker.
>> >
>> > However during this, I encounter an error while using the public attribute 
>> > value of
>> > MeshWorker::IntegrationInfo.
>> > I get a segmentation fault, whenever I call it. (A concrete example will 
>> > be given)
>> >
>> > My current code is heavily based on Step-12( Version 9.1.1). To exclude as 
>> > many errors as possible, as an experiment I decided to modify Step-12 and 
>> > see, wether I could reprodue the error. It turns out I can.
>> >
>> > The modification of Step-12 is just three lines of code added in 
>> > integrate_cell_term, where values is called analogously to Step-39 
>> > (version 9.1.1).
>> >
>> > template 
>> > void AdvectionProblem::integrate_cell_term(DoFInfo & dinfo,
>> > CellInfo )
>> > {
>> > const FEValuesBase & fe_values = info.fe_values();
>> > FullMatrix & local_matrix = dinfo.matrix(0).matrix;
>> > const std::vector  = fe_values.get_JxW_values();
>> >
>> > std::cout << "Checkpoint1" << std::endl;
>> > const std::vector  = info.values[0][0];
>> > std::cout << "Checkpoint2" << std::endl;
>> >
>> > for (unsigned int point = 0; point < fe_values.n_quadrature_points; 
>> > ++point)
>> > {
>> > const Tensor<1, dim> beta_at_q_point =
>> > beta(fe_values.quadrature_point(point));
>> >
>> > for (unsigned int i = 0; i < fe_values.dofs_per_cell; ++i)
>> > for (unsigned int j = 0; j < fe_values.dofs_per_cell; ++j)
>> > local_matrix(i, j) += -beta_at_q_point * //
>> > fe_values.shape_grad(i, point) * //
>> > fe_values.shape_value(j, point) * //
>> > JxW[point];
>> > }
>> > }
>> >
>> >
>> >
>> > Usually the compiler just shuld give me a warning, that uh is an unused 
>> > variable, but the program itself should run smoothly.
>> > However when I run the program, I get the following message:
>> >
>> > Checkpoint1Checkpoint1
>> > Checkpoint1
>> > CMakeFiles/run.dir/build.make:57: recipe for target 'CMakeFiles/run' failed
>> > make[3]: *** [CMakeFiles/run] Segmentation fault (core dumped)
>> > CMakeFiles/Makefile2:131: recipe for target 'CMakeFiles/run.dir/all' failed
>> > make[2]: *** [CMakeFiles/run.dir/all] Error 2
>> > CMakeFiles/Makefile2:138: recipe for target 'CMakeFiles/run.dir/rule' 
>> > failed
>> > make[1]: *** [CMakeFiles/run.dir/rule] Error 2
>> > Makefile:144: recipe for target 'run' failed
>> > make: *** [run] Error 2
>> >
>> > Double checking this with gdb I get the following:
>> >
>> > Thread 3 "step-12" received signal SIGSEGV, Segmentation fault.
>> > [Switching to Thread 0x7fffe0553700 (LWP 2417)]
>> > 0x556864d2 in std::vector> > std::allocator >, std::allocator> > std::allocator > > >::operator[] (
>> > this=0x0, __n=0) at /usr/include/c++/7/bits/stl_vector.h:798
>> > 798 return *(this->_M_impl._M_start + __n);
>> >
>> > when trying to run the program beyond
>> > const std::vector  = info.values[0][0]
>> >
>> > In both cases the program was run in debug-mode.
>> >
>> > I feel it helps with identifying the problem, that Step-39 runs perfectly 
>> > smooth on my computer.
>> >
>> > I hope this is enough information to find the error in my approach.
>> >
>> > Thank you very much.
>> >
>> > Best regards,
>> > Gregor
>> >
>> > --
>> > 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

[deal.II] Re: APPLY BOUNDARY CONDTION ON INTERNAL FACE

2020-10-12 Thread Bruno Turcksin

Xiang,

You cannot apply a boundary condition on an internal face. You need to use 
the AffineConstraint 
 
class to impose the constraints yourself. This is what we use internally to 
apply Dirichlet boundary condition.

Best,

Bruno



On Monday, October 12, 2020 at 2:10:15 AM UTC-4 shya...@gmail.com wrote:

> Hi, I want to model injecting heat fluid into a tiny fracture which is 
> inside a block. The fracture is modeled as an interface which is an 
> internal face shared by two hex elements. Is it possible for us to apply 
> the Dirichlet boundary condition on the interface? If not, how should I do 
> it?  
>
> Best,
>
> Xiang
>

-- 
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/3840f39f-e3ae-4d76-886b-c3658bcade13n%40googlegroups.com.

Re: [deal.II] Application of the non-homogeneous boundary conditions in Finite Elasticity (Compressible case)

2020-10-12 Thread Animesh Rastogi IIT Gandhinagar

Hi Jean,

Thanks a lot for your detailed answer to my questions. Now I am able to run 
my program and the newton method is converging. I completely misunderstood 
the documentation. Also, thank you for opening up the issue. It would 
really be helpful if the complications involved in making constraints can 
be removed. 

Thanks again!

Animesh

On Monday, October 12, 2020 at 11:20:32 AM UTC+5:30 Jean-Paul Pelteret 
wrote:

> Hi Animesh,
>
> Here are some answers to your questions:
>
>
> Essentially, I will have to apply the homogeneous boundary condition at 
> the zeroth and first Newton's step, and Non-homogeneous BC only at the 
> zeroth step, as mentioned in the documentation 
> 
> .
>
> 1. Why would I need to give the homogeneous boundary conditions twice?
>
>
> No, I’m afraid you’ve misunderstood what’s written there. Here’s the 
> important part of the documentation:
> “”"
> However, since we are dealing with an iterative Newton method, it should 
> be noted that any displacement constraints should only be specified at the 
> zeroth iteration and subsequently no additional contributions are to be 
> made since the constraints are already exactly satisfied.
> “””
>
> You only apply (inhomogeneous) displacement constraints at the zeroth 
> Newton iteration. Because this tutorial uses an incremental formulation, 
> and the constraints are applied to the increment itself, you want to make 
> sure that you apply the correct implement only once per timestep. This is 
> because you effectively displace your boundary from its position at the 
> previous tilmestep to the one at the current tilmestep using this single 
> update. After this update is done, you want to make sure that the boundary 
> doesn’t move away from that location, so you apply homogeneous constraints 
> on the same displacement components for each subsequent Newton step. That 
> is the other part of the logic that’s laid out in 
> step-44’s Solid::make_constraints().
>
> 2. Is it correct the way I am applying the constraints? I am copying the 
> part of the code in red? The major concern that I have is that if I do 
> constraints.clear(), then it will also clear my non-homogeneous constraint 
> applied at the zeroth Newton step. How should I handle this?
>
>
> Not quite. You do want the inhomogeneities cleared, but you still only 
> want to fix the displacement components that you originally applied 
> inhomogeneous constraints to. You’ll want to duplicate the logic applied in 
> the other branches of the make_constraints() function. So something like 
> this:
>
> // Apply Non-homogeneous B.C.
> {
>  const int boundary_id = 5;
>   if (apply_dirichlet_bc == true)
> VectorTools::interpolate_boundary_values(dof_handler_ref,
>  boundary_id,
>  ConstantFunction(dim 
> == 3 ? std::vector { -0.0001, 0.0, 0.0 } : std::vector { 
> -0.0001, 0.0 }), constraints, fe.component_mask(x_displacement));
>
> else
>
> VectorTools::interpolate_boundary_values(dof_handler_ref,
>  boundary_id,
>  ZeroFunction(), 
> constraints, fe.component_mask(x_displacement));
>
> }
>
>
> I must admit that this code is overly complicated, and it can be 
> simplified so that extending it to the case of inhomogeneous constraints is 
> easier. I’ve opened up an issue for this task here 
>  and I’ll update the 
> tutorial in the coming weeks.
>
> I hope that this helps you in understanding the logic and resolving your 
> issue!
>
> Best,
> Jean-Paul
>
>
> On 10 Oct 2020, at 19:05, Animesh Rastogi IIT Gandhinagar <
> animesh...@alumni.iitgn.ac.in> wrote:
>
> Hi All, 
>
> I am working on hyper-elastic beam buckling problem. I wish to apply 
> non-homogeneous Dirichlet Boundary condition on the right hand side of the 
> beam (to compress the beam). I was reading the step-44 
> 
>  
> where they have mentioned about how to apply non-homogeneous boundary 
> condition.  Essentially, I will have to apply the homogeneous boundary 
> condition at the zeroth and first Newton's step, and Non-homogeneous BC 
> only at the zeroth step, as mentioned in the documentation 
> 
> .
>
> I have following two questions regarding this - 
>
> 1. Why would I need to give the homogeneous boundary conditions twice?
> 2. Is it correct the way I am applying the constraints? I am copying the 
> part of the code in red? The major concern that I have is that if I do 
> constraints.clear(), then it will also clear my non-homogeneous constraint 
> applied at the zeroth Newton step. How

Re: [deal.II] Issue with MeshWorker::InegrationInfo.values

2020-10-12 Thread Gregor Pfau

Dear Timo, 

first of all thank you for your reply and advice. 

As you suspected,  info.values[0][0] and info.values[0] are both of size 
zero. I have tried this with the example given in my previous question, as 
well as with the original code. 

Since the original problem is time dependent, the goal was to get the 
solution values of the previous timestep at the quadrature points.
Could it be, that I need to use a different approach, at least for the 
first time step ?

I have tried get_function_values, but even with the workaround proposed 
here: https://groups.google.com/g/dealii/c/pjUBPbaZgxg/m/lSPLgiTtAgAJ , I 
still get the same error.

To be honest, I am not shure how to tackle either apporach. 

Thank you very much. 

Best regards, 
Gregor








Timo Heister schrieb am Samstag, 26. September 2020 um 21:44:05 UTC+2:

> Hi Gregor,
>
> I would suggest that you grab a debugger (inside an IDE like
> QtCreator, VS Code, etc.) or gdb directly and inspect the types and
> content of "info", "info.values", and "info.values[0]" in that order
> to see if they are all valid objects and have a non-zero size. From
> the error message, it sounds like that this is not the case.
>
> Best,
> Timo
>
> On Sat, Sep 26, 2020 at 8:25 AM Gregor Pfau  wrote:
> >
> > Dear Deal.II community,
> >
> > currently I am trying to solve a nonlinear problem with Newtons Method 
> using MeshWorker.
> >
> > However during this, I encounter an error while using the public 
> attribute value of
> > MeshWorker::IntegrationInfo.
> > I get a segmentation fault, whenever I call it. (A concrete example will 
> be given)
> >
> > My current code is heavily based on Step-12( Version 9.1.1). To exclude 
> as many errors as possible, as an experiment I decided to modify Step-12 
> and see, wether I could reprodue the error. It turns out I can.
> >
> > The modification of Step-12 is just three lines of code added in 
> integrate_cell_term, where values is called analogously to Step-39 (version 
> 9.1.1).
> >
> > template 
> > void AdvectionProblem::integrate_cell_term(DoFInfo & dinfo,
> > CellInfo )
> > {
> > const FEValuesBase & fe_values = info.fe_values();
> > FullMatrix & local_matrix = dinfo.matrix(0).matrix;
> > const std::vector  = fe_values.get_JxW_values();
> >
> > std::cout << "Checkpoint1" << std::endl;
> > const std::vector  = info.values[0][0];
> > std::cout << "Checkpoint2" << std::endl;
> >
> > for (unsigned int point = 0; point < fe_values.n_quadrature_points; 
> ++point)
> > {
> > const Tensor<1, dim> beta_at_q_point =
> > beta(fe_values.quadrature_point(point));
> >
> > for (unsigned int i = 0; i < fe_values.dofs_per_cell; ++i)
> > for (unsigned int j = 0; j < fe_values.dofs_per_cell; ++j)
> > local_matrix(i, j) += -beta_at_q_point * //
> > fe_values.shape_grad(i, point) * //
> > fe_values.shape_value(j, point) * //
> > JxW[point];
> > }
> > }
> >
> >
> >
> > Usually the compiler just shuld give me a warning, that uh is an unused 
> variable, but the program itself should run smoothly.
> > However when I run the program, I get the following message:
> >
> > Checkpoint1Checkpoint1
> > Checkpoint1
> > CMakeFiles/run.dir/build.make:57: recipe for target 'CMakeFiles/run' 
> failed
> > make[3]: *** [CMakeFiles/run] Segmentation fault (core dumped)
> > CMakeFiles/Makefile2:131: recipe for target 'CMakeFiles/run.dir/all' 
> failed
> > make[2]: *** [CMakeFiles/run.dir/all] Error 2
> > CMakeFiles/Makefile2:138: recipe for target 'CMakeFiles/run.dir/rule' 
> failed
> > make[1]: *** [CMakeFiles/run.dir/rule] Error 2
> > Makefile:144: recipe for target 'run' failed
> > make: *** [run] Error 2
> >
> > Double checking this with gdb I get the following:
> >
> > Thread 3 "step-12" received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 0x7fffe0553700 (LWP 2417)]
> > 0x556864d2 in std::vector std::allocator >, std::allocator std::allocator > > >::operator[] (
> > this=0x0, __n=0) at /usr/include/c++/7/bits/stl_vector.h:798
> > 798 return *(this->_M_impl._M_start + __n);
> >
> > when trying to run the program beyond
> > const std::vector  = info.values[0][0]
> >
> > In both cases the program was run in debug-mode.
> >
> > I feel it helps with identifying the problem, that Step-39 runs 
> perfectly smooth on my computer.
> >
> > I hope this is enough information to find the error in my approach.
> >
> > Thank you very much.
> >
> > Best regards,
> > Gregor
> >
> > --
> > The deal.II project is located at http://www.dealii.org/
> > For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> > ---
> > You received this message because you are subscribed to the Google 
> Groups "deal.II User Group" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to dealii+un...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dealii/74a514ed-87de-4df1-a639-4b93b54c100cn%40googlegroups.com
> .
>
>
>
> -- 
> Timo Heister

Re: [deal.II] Tools for parallel debugging

2020-10-12 Thread Konrad Simon

Thank you, Wolfgang and Daniel. Seems like I will go with the command line 
then. I was just wondering if people here use Eclipse's PTP which sounded 
like a good graphical tool. In my case it frequently crashes or simply gets 
stuck.

Best,
Konrad

On Sunday, October 11, 2020 at 11:35:34 PM UTC+2 Wolfgang Bangerth wrote:

> On 10/11/20 3:26 PM, Daniel Arndt wrote:
> > 
> > have a look at 
> > 
> https://github.com/dealii/dealii/wiki/Frequently-Asked-Questions#how-do-i-debug-mpi-programs
>  
> > <
> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdealii%2Fdealii%2Fwiki%2FFrequently-Asked-Questions%23how-do-i-debug-mpi-programs=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7Cab82fabba6ff45f8e49708d86e2c6359%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637380484218698974=jECVtixHfq%2BTSXkb1xww9SYWSyGwOonjWg%2Fqug7zLPk%3D=0>.
>  
>
> > For me, the "mpiexec -np n gdb ./executable" approach normally works 
> fairly well.
> > 
>
> There is also an interactive demonstration of this in lecture 41.25:
> https://www.math.colostate.edu/~bangerth/videos.676.41.25.html
>
> 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/3ed1b810-e78e-4cf0-9712-70aec571875en%40googlegroups.com.

Re: [deal.II] Tools for parallel debugging

2020-10-12 Thread Konrad Simon

Oh, seems like I missed that. Thanks you!

Konrad

On Sunday, October 11, 2020 at 11:35:34 PM UTC+2 Wolfgang Bangerth wrote:

> On 10/11/20 3:26 PM, Daniel Arndt wrote:
> > 
> > have a look at 
> > 
> https://github.com/dealii/dealii/wiki/Frequently-Asked-Questions#how-do-i-debug-mpi-programs
>  
> > <
> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdealii%2Fdealii%2Fwiki%2FFrequently-Asked-Questions%23how-do-i-debug-mpi-programs=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7Cab82fabba6ff45f8e49708d86e2c6359%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637380484218698974=jECVtixHfq%2BTSXkb1xww9SYWSyGwOonjWg%2Fqug7zLPk%3D=0>.
>  
>
> > For me, the "mpiexec -np n gdb ./executable" approach normally works 
> fairly well.
> > 
>
> There is also an interactive demonstration of this in lecture 41.25:
> https://www.math.colostate.edu/~bangerth/videos.676.41.25.html
>
> 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/3af7489d-9b56-4796-af4c-498291829c2an%40googlegroups.com.

[deal.II] APPLY BOUNDARY CONDTION ON INTERNAL FACE

2020-10-12 Thread 孙翔

Hi, I want to model injecting heat fluid into a tiny fracture which is 
inside a block. The fracture is modeled as an interface which is an 
internal face shared by two hex elements. Is it possible for us to apply 
the Dirichlet boundary condition on the interface? If not, how should I do 
it?  

Best,

Xiang

-- 
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/d0973d99-ff31-4339-be1f-02f253e35284n%40googlegroups.com.

Re: [deal.II] FullMatrix to SparseMatrix

Re: [deal.II] Re: Fluid-Structure interaction

Re: [deal.II] Re: APPLY BOUNDARY CONDTION ON INTERNAL FACE

Re: [deal.II] Issue with MeshWorker::InegrationInfo.values

[deal.II] Re: APPLY BOUNDARY CONDTION ON INTERNAL FACE

Re: [deal.II] Application of the non-homogeneous boundary conditions in Finite Elasticity (Compressible case)

Re: [deal.II] Issue with MeshWorker::InegrationInfo.values

Re: [deal.II] Tools for parallel debugging

Re: [deal.II] Tools for parallel debugging

[deal.II] APPLY BOUNDARY CONDTION ON INTERNAL FACE

10 matches

Site Navigation

Mail list logo

Footer information