Strategy for efficiently calculating face flux in time evolution problems

18 views
Skip to first unread message

vachan potluri

unread,
Nov 22, 2019, 12:32:36 AM11/22/19
to deal.II User Group
Hello all,

This question is a general one, may not be specific just to deal.II. I am writing a code to solve the compressible Navier-Stokes equations. Every time step requires calculation of numerical flux on every face. There can be three cases in a distributed triangulation. I am not considering a dynamic mesh.
  1. Internal face, not shared between domains. Here, the flux is calculated and RHS of both the concerned cells is updated.
  2. Internal face, shared between domains. Flux is calculated and only the RHS of owned cell is updated.
  3. Boundary face. Flux is calculated (boundary conditions come to play) and RHS of cell is updated.
To identify these cases, if conditions can be used. But since every face can only be of one of the three types, it is redundant to check its type for every time step. Does this significantly effect the performance? If yes, then the following question is relevant.

Is there any better way? I once had the following idea.
  1. Assign a user id for every face:
    1. If face is a boundary face (type 3), user id = boundary id
    2. For type 1 face, user id = maximum boundary id + 1
    3. For type 2 face, user id = maximum boundary id + 2
  2. Construct an array of lambdas, one for each user id of face. This probably requires capturing everything by reference in the lambda
  3. Call the lambda corresponding to a face user id for every face to update the contribution of numerical flux to RHS
I would like to know opinions about feasibility and efficiency of this method. And also, any other approaches that somebody might have used or are aware of.

Thank you
Vachan

Wolfgang Bangerth

unread,
Nov 22, 2019, 5:40:46 PM11/22/19
to dea...@googlegroups.com

Vachan,

> This question is a general one, may not be specific just to deal.II. I
> am writing a code to solve the compressible Navier-Stokes equations.
> Every time step requires calculation of numerical flux on every face.
> There can be three cases in a distributed triangulation. I am not
> considering a dynamic mesh.
>
> 1. Internal face, not shared between domains. Here, the flux is
> calculated and RHS of both the concerned cells is updated.
> 2. Internal face, shared between domains. Flux is calculated and only
> the RHS of owned cell is updated.
> 3. Boundary face. Flux is calculated (boundary conditions come to play)
> and RHS of cell is updated.
>
> To identify these cases, if conditions can be used. But since every face
> can only be of one of the three types, it is redundant to check its type
> for every time step. *Does this significantly effect the performance?*

There is a general rule in software design, often attributed to Donald
Knuth but actually by Tony Hoare (both among the greats of computer
science), that states:
Premature optimization is the root of all evil.
What the quote likes to convey is that one should not optimize a program
*unless there is concrete evidence that a part of the program is slow*.

In your case, you are wondering how one would best optimize an 'if'
statement on each face. But do you have evidence that that is actually
something that is slow?

I'll give you my opinion: No, it doesn't matter at all. But to
concretely find out, why don't you copy the logic you currently have, namely

unsigned int n_faces_1=0;
unsigned int n_faces_2=0;
unsigned int n_faces_3=0;
for (cell=...)
if (cell->is_locally_owned())
for (face=...)
if (condition_1)
++n_faces_1;
else if (condition_2)
++n_faces_2;
else
++n_faces_3;

(I've put something into the body of the if-clauses so that the compiler
doesn't optimize it away.) Then you put the whole thing into a timed
section and measure how long all of this takes, and compare against the
total run-time of your program.

I bet it doesn't take any noticeable amount of time. I'm sure we'd all
love to see the results of this little experiment reported here :-)

Cheers
W.


--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/
Reply all
Reply to author
Forward
0 new messages