Add per particle dbcs

[georghammerl]

Description and Context

Extracted the per particle Dirichlet boundary condition from #1881 into a separate PR.
The first review comments are already included from the original PR.

• New optional keyword DIRICHLET_FUNCT in particle definitions (e.g., "TYPE pdphase POS ... DIRICHLET_FUNCT 1")
• Particles with DIRICHLET_FUNCT 1 are subject to a Dirichlet boundary condition prescribed by FUNCT1
• Enables to apply Dirichlet boundary conditions on subsets of particle phases (works for any particle phase)
• Activated via this new "flagged" condition for several phases

PARTICLE DYNAMIC/INITIAL AND BOUNDARY CONDITIONS:
  DIRICHLET_BOUNDARY_CONDITION_FLAGGED: [pdphase]

Related Issues and Pull Requests

(#1881)

Interested parties

@alhermann

[ppraegla]

Very nice feature!

[slfuchs]

I also like this feature a lot! This enables not only simple moving boundaries in SPH but more complex examples

[ppraegla]

One question and some nitpicking

[ppraegla]

Out of interest, why do you use the lazy cache instead of filling the map during setup? Do you expect some performance savings in case one processor does not own particles of a type subjected to a dirichlet function?
My understanding of lazy initialization is that it is used when it is expensive to create objects that are rarely used. Though, getting the functions is not that expensive and they will definitely be used at some point during the simulation. But maybe I'm missing something.

[georghammerl]

As funct_id is only known on the processor which owns/ghost a particle during setup, I expect the cache to be filled "locally". Assuming a phase with per particle dbc is not present on a processor, I expect that proc not to fill the cache properly.
While writing these lines, I see the solution: A brief MPI communcation is necessary to fill the cache with all possible functs that are present one any proc. Then every proc has a complete cache and if a particle arrives newly on this proc, it immediately uses the proper cache.

My previous concern was that a check is necessary whether the cache does not contain a certain FUNCT on a certain proc and need to be filled in that moment after a partile transfer. This sounds like lazy init which I chose.

Will change to do communication and set it up during setup. Then, no check is necessary on the fly.
@ppraegla Thanks for your question.

[slfuchs]

Good catch, I would also do a communication during setup.

[ppraegla]

At the point where the setup of the dirichlet_bc is called, there should still be all particles on proc 0. The distributing happens in distribute_load_among_procs. However, it is probably better to include the communication in case the order of the functions is changed.

[slfuchs]

Are you sure? When reading particles from the input file this is true. But when generating particles with the particle generator in the code I think every proc generates particles that are to be located within its processor domain.

[ppraegla]

@slfuchs you are right. If one implements some particle generation logic in the code, it will generate particles per process. I only considered the reading from the input file.

[georghammerl]

setup() is too early (particle container not yet populated). MPI_Comm needs to be availble. I prefer to have no distinction between restart and standard startup. Therefore, starting point is particle_algorithm now. Maybe not overwhelmingly beautiful but definitly obvious and clear what happens.

@ppraegla @slfuchs Please check this carefully.