Modifying field values for neighboring cells inside a postprocessor

[Danial.Khazaeipoul]

Hello Adrian,

When defining a global data structure in OpenLB, is it possible to use a custom type such as one given below with the TYPED_FIELD_BASE:

struct BubbleInfo {
  CellID bubbleID = CellID(0);
  double volume = 0.0;
};

struct BUBBLE_FIELD : public descriptors::TYPED_FIELD_BASE<BubbleInfo,1> {};

[Adrian]

Yes, in principle this should be possible (I experimented with this before, if I remember right there were only some small issues due to the value types being used in vectors). However, this approach is not really intended, I recommend using individual fields (and e.g. use some additional functions to operate on them if they belong together).

[Danial.Khazaeipoul]

Hi Adrian,

Thank you! I tested it and didn’t encounter any obvious issues. Nonetheless, I followed your suggestion and switched back to using separate fields for each variable. I have a question about how priority works in custom tasks to improve my understanding of OpenLB’s core. Consider the following scenario:

(1) freeSurfacePostProcessor3D schedules its custom tasks at the PostStream stage, consisting of five local stages with assigned priorities (e.g., 1, 2, 3, 4, 5).

(2) Another post-processor schedules its own custom tasks at the PostStream stage with different local stages and assigned priorities (e.g., 1, 2, 3, 4).

What would be the expected execution order of these tasks? How are priorities handled when multiple post-processors add tasks at the same stage?

[Adrian]

On the post processor scheduling: Post processor don’t schedule themselves, i.e. they are not tied to any stage. The stage is assigned by the call to SuperLattice::addPostProcessor(the default being PostStream). You can also (in principle) assign the same post processor to multiple stages. The priority however is declared by the post processor structs (a pragmatic choice, I would prefer this to also be handled by the assignment call but for the actual implementations the current approach seemed better).

The core is allowed to execute post processor assigned to the same stage and priority in parallel. Whether this actually happens depends on the platform (e.g. on CPU without OpenMP they will be executed in some sequence while on CPU OpenMP / GPU CUDA they will be scheduled in parallel to some degree).

For your example: Each stage is executed when it is called, inside each stage the priorities are executed in sequence, inside each priority everything is parallel (potentially).

[Danial.Khazaeipoul]

Just to confirm that I understood you clearly, the different post processors do not interleave their tasks based on the order they were added; rather, the tasks are globally ordered by their stage (here, PostStream) and then by their declared priority. Am I correct?

[Adrian]

What do you mean by “their tasks”? What is meant by a post processor in OpenLB is a struct that defines its application scope and priority together with a apply template method that implements the actual computations. If some model such as free surface splits its algorithm into multiple tasks these tasks are realized as individual post processor assigned to one or more stages and priorities.

The order in which post processors are added (meaning the calls to addPostProcessor) does not matter for the execution. The execution is ordered first by stage and then by priority. Post processors (or “tasks”) that share the same stage and priority are executed in parallel, platform permitting.

[Danial.Khazaeipoul]

What do you mean by “their tasks”?

The order in which post processors are added (meaning the calls to addPostProcessor) does not matter for the execution. The execution is ordered first by stage and then by priority. Post processors (or “tasks”) that share the same stage and priority are executed in parallel, platform permitting.

I understand that, for instance, the freeSurfacePostProcessor3D includes five individual post-processors, each of which must define a priority and implement the apply method. I just wanted to confirm that my understanding of your previous answer was correct. In doing so, I used the terms task and post-processor interchangeably.

Thank you for your clear and detailed explanation.

[Adrian]

Good to hear! This also explains my confusion, I did not have that detail of the FS code in my mind. We should change the naming, it is quite confusing in this case.

[Danial.Khazaeipoul]

For anyone interested, if you encounter an issue where custom tasks added via addCustomTask<stage::> in SuperLattice are not executed, it’s because the SuperLattice<T, DESCRIPTOR>::collideAndStream() method only calls executeCustomTasks(PostStream()), meaning tasks scheduled for other stages are not automatically executed.

To resolve this, you need to explicitly invoke executeCustomTasks() for your specific stage. You can do this by modifying collideAndStream() to include the call for your stage or by calling it manually from anywhere appropriate in your application using a SuperLattice object. For example:

executeCustomTasks(PreCollide())

• This reply was modified 4 months, 1 week ago by Danial.Khazaeipoul.

[Author]

Posts