Re: [deal.II] Re: if else leading to the same path in step 44

[Jean-Paul Pelteret]

Dear Lucas,

Great! We're looking forward to adding you to the list of contributors 
 to the project :-)

J-P

On Monday, August 28, 2017 at 5:42:30 PM UTC+2, Lucas Campos wrote:
>
> Dear Jean-Paul,
>
> I can definitely do it. 
>
> Lucas
>
> On 28 August 2017 at 17:40, Jean-Paul Pelteret <> wrote:
>
>> Dear Lucas,
>>
>> You're welcome. Thanks for the discussion and your feedback! I've made a 
>> note to myself  to improve 
>> the documentation in this area, but if you want a small side-project then 
>> feel free to propose the amendments yourself with a pull request to the 
>> GitHub repository :-) I'd be happy to help you out if you want / need it.
>>
>> J-P
>>
>> On Monday, August 28, 2017 at 5:35:10 PM UTC+2, Lucas Campos wrote:
>>>
>>> Dear Jean-Paul,
>>>
>>> Thanks again. Now I do understand and it all makes sense. 
>>>
>>> Also, while yes, I agree that the lack of the else could lead to errors 
>>> that quite hard to track down. However, I think adding your comment to that 
>>> part of the tutorial could save someone having the same issues I faced.
>>>
>>> Thanks for your time,
>>> Lucas
>>>
>>> On 28 August 2017 at 17:26, Jean-Paul Pelteret <> wrote:
>>>
 Hi Lucas,

 I see, now I understand to what you were referring. 

 Yes, the specific example that you've shown here is an intentional 
 redundancy. Previous experiences has shown that we all have a tendency to 
 copy-paste the tutorials and work from them (that is their intended use 
 after all :-). I put this in place to ensure that one doesn't accidentally 
 forget the "else" case when refactoring this code. It would be very easy 
 to 
 do, and could be a tricky error to track down. Furthermore, it also 
 reinforces what was discussed in the introductory paragraph above it.

 So I agree fully that this is not required. One could in fact reduce 
 this entire implementation of the constraints to only a few lines. But in 
 the interest of clarity it will remain in its current form for now :-)

 Regards,
 Jean-Paul

 On Monday, August 28, 2017 at 5:14:52 PM UTC+2, Lucas Campos wrote:
>
> Dear Jean-Paul,
>
> Thanks for your answer! Still, I am not sure if I understand the code. 
> The main issue seems to be that both blocks in every if else path are the 
> exactly the same. For instance, 
>
> if (apply_dirichlet_bc == true)
>> VectorTools::interpolate_boundary_values 
>> 
>> (dof_handler_ref,
>> boundary_id,
>> Functions::ZeroFunction 
>> 
>> (n_components),
>> constraints,
>> fe.component_mask 
>> 
>> (x_displacement));
>> else
>> VectorTools::interpolate_boundary_values 
>> 
>> (dof_handler_ref,
>> boundary_id,
>> Functions::ZeroFunction 
>> 
>> (n_components),
>> constraints,
>> fe.component_mask 
>> 
>> (x_displacement));
>>
>
>  What is the use of having if-else in this situation? 
>
> Also, in your answer you mentioned that in the second call (iteration 
> == 1), only homogeneous constrains will be built. I also cannot see this 
> from the code. Perhaps this part is interacting with some other part of 
> the 
> code in a way I cannot see?
>
> Thanks for the help,
> Lucas Campos
>
> On 28 August 2017 at 17:03, Jean-Paul Pelteret <> wrote:
>
>> Hi Lucas,
>>
>> So it sounds as if you've already worked out what's happening here. 
>> We consider 3 cases, namely what to do for newton iteration equal to 0, 
>> equal to 1, and greater than 1.
>>
>> For iteration == 0 and iteration == 1, the early return on line 2468 
>> 
>>  
>> is not satisfied and we have to build some dirichlet constraints. Which 
>> constraints are build is governed by the iteration number: if it is 
>> equal 
>> to zero, then apply_dirichlet_BC 
>> 
>>  
>> is set true and we build non-homogeneous constraints (the "if" case). On 
>> the next visit to this function (iteration == 1) this flag is set to 
>> false 

Re: [deal.II] Re: if else leading to the same path in step 44

[Lucas Campos]

Dear Jean-Paul,

I can definitely do it.

Lucas

On 28 August 2017 at 17:40, Jean-Paul Pelteret  wrote:

> Dear Lucas,
>
> You're welcome. Thanks for the discussion and your feedback! I've made a
> note to myself  to improve
> the documentation in this area, but if you want a small side-project then
> feel free to propose the amendments yourself with a pull request to the
> GitHub repository :-) I'd be happy to help you out if you want / need it.
>
> J-P
>
> On Monday, August 28, 2017 at 5:35:10 PM UTC+2, Lucas Campos wrote:
>>
>> Dear Jean-Paul,
>>
>> Thanks again. Now I do understand and it all makes sense.
>>
>> Also, while yes, I agree that the lack of the else could lead to errors
>> that quite hard to track down. However, I think adding your comment to that
>> part of the tutorial could save someone having the same issues I faced.
>>
>> Thanks for your time,
>> Lucas
>>
>> On 28 August 2017 at 17:26, Jean-Paul Pelteret <> wrote:
>>
>>> Hi Lucas,
>>>
>>> I see, now I understand to what you were referring.
>>>
>>> Yes, the specific example that you've shown here is an intentional
>>> redundancy. Previous experiences has shown that we all have a tendency to
>>> copy-paste the tutorials and work from them (that is their intended use
>>> after all :-). I put this in place to ensure that one doesn't accidentally
>>> forget the "else" case when refactoring this code. It would be very easy to
>>> do, and could be a tricky error to track down. Furthermore, it also
>>> reinforces what was discussed in the introductory paragraph above it.
>>>
>>> So I agree fully that this is not required. One could in fact reduce
>>> this entire implementation of the constraints to only a few lines. But in
>>> the interest of clarity it will remain in its current form for now :-)
>>>
>>> Regards,
>>> Jean-Paul
>>>
>>> On Monday, August 28, 2017 at 5:14:52 PM UTC+2, Lucas Campos wrote:

 Dear Jean-Paul,

 Thanks for your answer! Still, I am not sure if I understand the code.
 The main issue seems to be that both blocks in every if else path are the
 exactly the same. For instance,

 if (apply_dirichlet_bc == true)
> VectorTools::interpolate_boundary_values
> 
> (dof_handler_ref,
> boundary_id,
> Functions::ZeroFunction
> 
> (n_components),
> constraints,
> fe.component_mask
> 
> (x_displacement));
> else
> VectorTools::interpolate_boundary_values
> 
> (dof_handler_ref,
> boundary_id,
> Functions::ZeroFunction
> 
> (n_components),
> constraints,
> fe.component_mask
> 
> (x_displacement));
>

  What is the use of having if-else in this situation?

 Also, in your answer you mentioned that in the second call (iteration
 == 1), only homogeneous constrains will be built. I also cannot see this
 from the code. Perhaps this part is interacting with some other part of the
 code in a way I cannot see?

 Thanks for the help,
 Lucas Campos

 On 28 August 2017 at 17:03, Jean-Paul Pelteret <> wrote:

> Hi Lucas,
>
> So it sounds as if you've already worked out what's happening here. We
> consider 3 cases, namely what to do for newton iteration equal to 0, equal
> to 1, and greater than 1.
>
> For iteration == 0 and iteration == 1, the early return on line 2468
> 
> is not satisfied and we have to build some dirichlet constraints. Which
> constraints are build is governed by the iteration number: if it is equal
> to zero, then apply_dirichlet_BC
> 
> is set true and we build non-homogeneous constraints (the "if" case). On
> the next visit to this function (iteration == 1) this flag is set to false
> and we build only homogeneous constraints (the "else" case). At subsequent
> iterations we use the early return that I previously mentioned to make no
> further changes to the existing constraint matrix. This is because it is
> already filled with the homogeneous constraints, which is what we want for
> all newton iterations > 0.
>
> Does this make sense?
>
> 

Re: [deal.II] Re: if else leading to the same path in step 44

[Jean-Paul Pelteret]

Dear Lucas,

You're welcome. Thanks for the discussion and your feedback! I've made a 
note to myself  to improve 
the documentation in this area, but if you want a small side-project then 
feel free to propose the amendments yourself with a pull request to the 
GitHub repository :-) I'd be happy to help you out if you want / need it.

J-P

On Monday, August 28, 2017 at 5:35:10 PM UTC+2, Lucas Campos wrote:
>
> Dear Jean-Paul,
>
> Thanks again. Now I do understand and it all makes sense. 
>
> Also, while yes, I agree that the lack of the else could lead to errors 
> that quite hard to track down. However, I think adding your comment to that 
> part of the tutorial could save someone having the same issues I faced.
>
> Thanks for your time,
> Lucas
>
> On 28 August 2017 at 17:26, Jean-Paul Pelteret <> wrote:
>
>> Hi Lucas,
>>
>> I see, now I understand to what you were referring. 
>>
>> Yes, the specific example that you've shown here is an intentional 
>> redundancy. Previous experiences has shown that we all have a tendency to 
>> copy-paste the tutorials and work from them (that is their intended use 
>> after all :-). I put this in place to ensure that one doesn't accidentally 
>> forget the "else" case when refactoring this code. It would be very easy to 
>> do, and could be a tricky error to track down. Furthermore, it also 
>> reinforces what was discussed in the introductory paragraph above it.
>>
>> So I agree fully that this is not required. One could in fact reduce this 
>> entire implementation of the constraints to only a few lines. But in the 
>> interest of clarity it will remain in its current form for now :-)
>>
>> Regards,
>> Jean-Paul
>>
>> On Monday, August 28, 2017 at 5:14:52 PM UTC+2, Lucas Campos wrote:
>>>
>>> Dear Jean-Paul,
>>>
>>> Thanks for your answer! Still, I am not sure if I understand the code. 
>>> The main issue seems to be that both blocks in every if else path are the 
>>> exactly the same. For instance, 
>>>
>>> if (apply_dirichlet_bc == true)
 VectorTools::interpolate_boundary_values 
 
 (dof_handler_ref,
 boundary_id,
 Functions::ZeroFunction 
 
 (n_components),
 constraints,
 fe.component_mask 
 
 (x_displacement));
 else
 VectorTools::interpolate_boundary_values 
 
 (dof_handler_ref,
 boundary_id,
 Functions::ZeroFunction 
 
 (n_components),
 constraints,
 fe.component_mask 
 
 (x_displacement));

>>>
>>>  What is the use of having if-else in this situation? 
>>>
>>> Also, in your answer you mentioned that in the second call (iteration == 
>>> 1), only homogeneous constrains will be built. I also cannot see this from 
>>> the code. Perhaps this part is interacting with some other part of the code 
>>> in a way I cannot see?
>>>
>>> Thanks for the help,
>>> Lucas Campos
>>>
>>> On 28 August 2017 at 17:03, Jean-Paul Pelteret <> wrote:
>>>
 Hi Lucas,

 So it sounds as if you've already worked out what's happening here. We 
 consider 3 cases, namely what to do for newton iteration equal to 0, equal 
 to 1, and greater than 1.

 For iteration == 0 and iteration == 1, the early return on line 2468 
 
  
 is not satisfied and we have to build some dirichlet constraints. Which 
 constraints are build is governed by the iteration number: if it is equal 
 to zero, then apply_dirichlet_BC 
 
  
 is set true and we build non-homogeneous constraints (the "if" case). On 
 the next visit to this function (iteration == 1) this flag is set to false 
 and we build only homogeneous constraints (the "else" case). At subsequent 
 iterations we use the early return that I previously mentioned to make no 
 further changes to the existing constraint matrix. This is because it is 
 already filled with the homogeneous constraints, which is what we want for 
 all newton iterations > 0.

 Does this make sense?

 Regards,
 Jean-Paul

 On Monday, August 28, 2017 at 4:14:31 PM UTC+2, Lucas Campos wrote:
>
> > This calculation does not happen anyway, because of the early return 
> 

Re: [deal.II] Re: if else leading to the same path in step 44

[Jean-Paul Pelteret]

Hi Lucus,

To add to what I just said (and to try to answer your question more fully / 
properly), this particular problem admittedly only has homogeneous 
constraints. See some of the code-gallery examples 
, e.g. this one 
,
 
for a case where non-homogeneous boundary conditions are applied. This 
better illustrates that the discussion in this part of the tutorial is 
about.

Regards,
Jean-Paul

On Monday, August 28, 2017 at 5:26:08 PM UTC+2, Jean-Paul Pelteret wrote:
>
> Hi Lucas,
>
> I see, now I understand to what you were referring. 
>
> Yes, the specific example that you've shown here is an intentional 
> redundancy. Previous experiences has shown that we all have a tendency to 
> copy-paste the tutorials and work from them (that is their intended use 
> after all :-). I put this in place to ensure that one doesn't accidentally 
> forget the "else" case when refactoring this code. It would be very easy to 
> do, and could be a tricky error to track down. Furthermore, it also 
> reinforces what was discussed in the introductory paragraph above it.
>
> So I agree fully that this is not required. One could in fact reduce this 
> entire implementation of the constraints to only a few lines. But in the 
> interest of clarity it will remain in its current form for now :-)
>
> Regards,
> Jean-Paul
>

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

Re: [deal.II] Re: if else leading to the same path in step 44

[Jean-Paul Pelteret]

Hi Lucas,

I see, now I understand to what you were referring. 

Yes, the specific example that you've shown here is an intentional 
redundancy. Previous experiences has shown that we all have a tendency to 
copy-paste the tutorials and work from them (that is their intended use 
after all :-). I put this in place to ensure that one doesn't accidentally 
forget the "else" case when refactoring this code. It would be very easy to 
do, and could be a tricky error to track down. Furthermore, it also 
reinforces what was discussed in the introductory paragraph above it.

So I agree fully that this is not required. One could in fact reduce this 
entire implementation of the constraints to only a few lines. But in the 
interest of clarity it will remain in its current form for now :-)

Regards,
Jean-Paul

On Monday, August 28, 2017 at 5:14:52 PM UTC+2, Lucas Campos wrote:
>
> Dear Jean-Paul,
>
> Thanks for your answer! Still, I am not sure if I understand the code. The 
> main issue seems to be that both blocks in every if else path are the 
> exactly the same. For instance, 
>
> if (apply_dirichlet_bc == true)
>> VectorTools::interpolate_boundary_values 
>> 
>> (dof_handler_ref,
>> boundary_id,
>> Functions::ZeroFunction 
>> 
>> (n_components),
>> constraints,
>> fe.component_mask 
>> 
>> (x_displacement));
>> else
>> VectorTools::interpolate_boundary_values 
>> 
>> (dof_handler_ref,
>> boundary_id,
>> Functions::ZeroFunction 
>> 
>> (n_components),
>> constraints,
>> fe.component_mask 
>> 
>> (x_displacement));
>>
>
>  What is the use of having if-else in this situation? 
>
> Also, in your answer you mentioned that in the second call (iteration == 
> 1), only homogeneous constrains will be built. I also cannot see this from 
> the code. Perhaps this part is interacting with some other part of the code 
> in a way I cannot see?
>
> Thanks for the help,
> Lucas Campos
>
> On 28 August 2017 at 17:03, Jean-Paul Pelteret <> wrote:
>
>> Hi Lucas,
>>
>> So it sounds as if you've already worked out what's happening here. We 
>> consider 3 cases, namely what to do for newton iteration equal to 0, equal 
>> to 1, and greater than 1.
>>
>> For iteration == 0 and iteration == 1, the early return on line 2468 
>> 
>>  
>> is not satisfied and we have to build some dirichlet constraints. Which 
>> constraints are build is governed by the iteration number: if it is equal 
>> to zero, then apply_dirichlet_BC 
>> 
>>  
>> is set true and we build non-homogeneous constraints (the "if" case). On 
>> the next visit to this function (iteration == 1) this flag is set to false 
>> and we build only homogeneous constraints (the "else" case). At subsequent 
>> iterations we use the early return that I previously mentioned to make no 
>> further changes to the existing constraint matrix. This is because it is 
>> already filled with the homogeneous constraints, which is what we want for 
>> all newton iterations > 0.
>>
>> Does this make sense?
>>
>> Regards,
>> Jean-Paul
>>
>> On Monday, August 28, 2017 at 4:14:31 PM UTC+2, Lucas Campos wrote:
>>>
>>> > This calculation does not happen anyway, because of the early return 
>>> in line 2466. 
>>>
>>> Just a minor correction for the previous sentence: The guard on line 
>>> 2466 will be true only on the second iterations. The else paths will still 
>>> be taken at least once.
>>>
>>> On Monday, 28 August 2017 16:02:01 UTC+2, Lucas Campos wrote:

 Dear all,

 First of all, thanks for the great library! I spent the last few days 
 reading your (very!) extensive 
 documentation and I think it will be really useful for me in the near 
 future. 

 Right now I am struggling a bit on understanding some things on 
 step-44. Most pressing right 
 now is that, in Section Solid::make_constraints of the tutorials, we 
 have 

 > 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.

 However, reading the code underneath, 

Re: [deal.II] Re: if else leading to the same path in step 44

[Lucas Campos]

Dear Jean-Paul,

Thanks for your answer! Still, I am not sure if I understand the code. The
main issue seems to be that both blocks in every if else path are the
exactly the same. For instance,

if (apply_dirichlet_bc == true)
> VectorTools::interpolate_boundary_values
> 
> (dof_handler_ref,
> boundary_id,
> Functions::ZeroFunction
> 
> (n_components),
> constraints,
> fe.component_mask
> 
> (x_displacement));
> else
> VectorTools::interpolate_boundary_values
> 
> (dof_handler_ref,
> boundary_id,
> Functions::ZeroFunction
> 
> (n_components),
> constraints,
> fe.component_mask
> 
> (x_displacement));
>

 What is the use of having if-else in this situation?

Also, in your answer you mentioned that in the second call (iteration ==
1), only homogeneous constrains will be built. I also cannot see this from
the code. Perhaps this part is interacting with some other part of the code
in a way I cannot see?

Thanks for the help,
Lucas Campos

On 28 August 2017 at 17:03, Jean-Paul Pelteret  wrote:

> Hi Lucas,
>
> So it sounds as if you've already worked out what's happening here. We
> consider 3 cases, namely what to do for newton iteration equal to 0, equal
> to 1, and greater than 1.
>
> For iteration == 0 and iteration == 1, the early return on line 2468
> 
> is not satisfied and we have to build some dirichlet constraints. Which
> constraints are build is governed by the iteration number: if it is equal
> to zero, then apply_dirichlet_BC
> 
> is set true and we build non-homogeneous constraints (the "if" case). On
> the next visit to this function (iteration == 1) this flag is set to false
> and we build only homogeneous constraints (the "else" case). At subsequent
> iterations we use the early return that I previously mentioned to make no
> further changes to the existing constraint matrix. This is because it is
> already filled with the homogeneous constraints, which is what we want for
> all newton iterations > 0.
>
> Does this make sense?
>
> Regards,
> Jean-Paul
>
> On Monday, August 28, 2017 at 4:14:31 PM UTC+2, Lucas Campos wrote:
>>
>> > This calculation does not happen anyway, because of the early return in
>> line 2466.
>>
>> Just a minor correction for the previous sentence: The guard on line 2466
>> will be true only on the second iterations. The else paths will still be
>> taken at least once.
>>
>> On Monday, 28 August 2017 16:02:01 UTC+2, Lucas Campos wrote:
>>>
>>> Dear all,
>>>
>>> First of all, thanks for the great library! I spent the last few days
>>> reading your (very!) extensive
>>> documentation and I think it will be really useful for me in the near
>>> future.
>>>
>>> Right now I am struggling a bit on understanding some things on step-44.
>>> Most pressing right
>>> now is that, in Section Solid::make_constraints of the tutorials, we
>>> have
>>>
>>> > 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.
>>>
>>> However, reading the code underneath, the code under the if-else blocks
>>> are the same (around
>>> line 2490 of step-44.cc). That is to say, we would run the same
>>> computation whether the condition
>>> is true or false. This calculation does not happen anyway, because of
>>> the early return in line 2466.
>>> If we disregard this early return, would this code be wrong, or is there
>>> something I am not seeing?
>>>
>>> Bests,
>>> Lucas
>>>
>> --
> 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/TSUwtKqcotY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> dealii+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
The deal.II project is located at