Function apply_boundary_values()

[Xuefeng Li]

Hi, there!

I have a question concerning the use of the function apply_boundary_values():

   MatrixTools::apply_boundary_values(boundary_values,

                                     system_matrix,

                                     solution,

                                     system_rhs);

Iteration is used to find a numerical solution. We know that

  system_matrix is independent of the iterate and remains unchanged during the iteration

  system_rhs depends on the iterate so it changes during the iteration 

Below is the pseudo-code of the program.

  initialize iterate u;

  assemble system_matrix; //Just once

  assemble system_rhs; //1st time

  call apply_boundary_values(); //Apply bdry 1st time

  while ( not converged ) {

    solve FEM to get new iterate u;

    assemble system_rhs; // repeated 

    call apply_boundary_values(); // repeated

  }

My question is: will the repeated call to function apply_boundary_values() inside the loop

alter the system_matrix that is meant to be constant (independent of iterate u)?

If the answer is no, then the above code will be fine, I guess.

If the answer is yes, I guess I'll need to assemble system_matrix inside the loop repeatedly

even though it is independent of the iterate u.

Thanks for any assistance.

[Wolfgang Bangerth]

On 9/25/20 3:07 PM, Xuefeng Li wrote:
>
> My question is: will the repeated call to function apply_boundary_values()
> inside the loop
> alter the system_matrix that is meant to be constant (independent of iterate u)?

It doesn't change it any further than it was changed the first time around.
But it doesn't do the appropriate modifications: you need the original matrix
for this to work.

> If the answer is no, then the above code will be fine, I guess.
>
> If the answer is yes, I guess I'll need to assemble system_matrix inside the
> loop repeatedly
> even though it is independent of the iterate u.

Right. Or do what step-26 does -- gosh darn, there seems to be a tutorial
program for everything ;-) (It's Friday afternoon and I'm already having a
drink -- the joster in me is shining through...)

Cheers
W.
--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/

[Jean-Paul Pelteret]

To add to what Wolfgang already said, there’s also the constrained_linear_operator() that may be of use in this scenario.

Best,

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+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/87651284-e7f5-1476-8c5a-5da7cd05c2c3%40colostate.edu.

[Xuefeng Li]

On Fri, Sep 25, 2020 at 4:29 PM Wolfgang Bangerth <bang...@colostate.edu> wrote:

On 9/25/20 3:07 PM, Xuefeng Li wrote:
>
> My question is: will the repeated call to function apply_boundary_values()
> inside the loop
> alter the system_matrix that is meant to be constant (independent of iterate u)?

It doesn't change it any further than it was changed the first time around.
But it doesn't do the appropriate modifications: you need the original matrix
for this to work.



> If the answer is no, then the above code will be fine, I guess.
>
> If the answer is yes, I guess I'll need to assemble system_matrix inside the
> loop repeatedly
> even though it is independent of the iterate u.

Right. Or do what step-26 does -- gosh darn, there seems to be a tutorial
program for everything ;-) (It's Friday afternoon and I'm already having a
drink -- the joster in me is shining through...)

Yes, step-26 assembles system_matrix and system_rhs inside the loop exactly because they depend on time and time_step.

Time and time_step change during the iteration.

For step-26, because system_rhs depends on time and time_step, we need to assemble system_rhs in the loop. We therefore

need to call apply_boundary_values() inside the loop. Here is my question. If system_matrix were independent of time and time_step

(such as in the case of uniform time_step), do we still need to assemble system_matrix inside the loop? 

--

Stay put, practice social distancing, and be safe!

Best,

--Xuefeng Li, (504)865-3340(phone)
   Like floating clouds, the heart rests easy
   Like flowing water, the spirit stays free

      Loyola University New Orleans

   New Orleans, Louisiana (504)865-2051(fax)

[Wolfgang Bangerth]

On 9/25/20 4:15 PM, Xuefeng Li wrote:
>
> For step-26, because system_rhs depends on time and time_step, we need to
> assemble system_rhs in the loop. We therefore

> need to call apply_boundary_values() inside the loop. Here is my question. *If
> system_matrix were independent of time and time_step*
> *(such as in the case of uniform time_step), **do we still need to assemble
> system_matrix inside the loop? *

Yes. The problem is that apply_b_v() modifies the system matrix during its
operation, but it needs the original matrix to do its operations. That means
that once you've run apply_b_v(), you can't run it again because the original
matrix is no longer available.

Whether you get the original matrix through assembly (expensive) or by saving
the unmodified state from before you called apply_b_v() the first time around
(cheap) does not matter.

Best

[Xuefeng Li]

On Sun, Sep 27, 2020 at 10:33 PM Wolfgang Bangerth <bang...@colostate.edu> wrote:

On 9/25/20 4:15 PM, Xuefeng Li wrote:
>
> For step-26, because system_rhs depends on time and time_step, we need to
> assemble system_rhs in the loop. We therefore
> need to call apply_boundary_values() inside the loop. Here is my question. *If
> system_matrix were independent of time and time_step*
> *(such as in the case of uniform time_step), **do we still need to assemble
> system_matrix inside the loop? *

Yes. The problem is that apply_b_v() modifies the system matrix during its
operation, but it needs the original matrix to do its operations. That means
that once you've run apply_b_v(), you can't run it again because the original
matrix is no longer available.

Whether you get the original matrix through assembly (expensive) or by saving
the unmodified state from before you called apply_b_v() the first time around
(cheap) does not matter.

Thanks a lot. The above answered my original question!!! Have a great week!