if else leading to the same path in step 44

[Lucas Campos]

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 

[Lucas Campos]

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

[Jean-Paul Pelteret]

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

[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<dim>(n_components),

constraints,

fe.component_mask(x_displacement));

else

VectorTools::interpolate_boundary_values(dof_handler_ref,

boundary_id,

Functions::ZeroFunction<dim>(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

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[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<dim>(n_components),

constraints,

fe.component_mask(x_displacement));

else

VectorTools::interpolate_boundary_values(dof_handler_ref,

boundary_id,

Functions::ZeroFunction<dim>(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

[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,

[Lucas Campos]

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

[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

[Lucas Campos]

Dear Jean-Paul,

I can definitely do it. 

Lucas

[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