The one place for your designs
To upload designs, you'll need to enable LFS. More information
Time step restriction by boundary conditions differs between processors
Time step adjustments to boundary condition changes only consider the boundary conditions localized to each processor.
Summary
When executing DORiE in parallel on multiple processors, the BoundaryConditionManager reads all boundary condition, but only stores the ones that will be applied on its local boundary segments. Therefore, the values returned by BoundaryConditionManager::max_time_step() will differ between processes if a certain boundary condition change is not "visible" to all processes. This leads to different processes having different time step sizes. The current behavior does not generally result in an error message but led to hanging processes in one occasion.
Steps to reproduce
Execute example case below with
dorie run -p 2 config.iniWhat is the current bug behaviour?
- Time step is not adjusted to BC change.
- Processes hang when boundary condition changes.
What is the expected correct behaviour?
- Time step is adjusted to BC change.
- Program completes successfully like in sequential execution.
Relevant logs, screenshots, files...?
Time step adjustment to time 345600 fails:
Reproducing input
Note: Input data requires features of !187 (merged).
| Input data | |
|---|---|
| Simulation Case | VZJ 2D extended testing phase run |
| Boundary Condition file | richards_bc.yml |
| Parameterization file | richards_param.yml |
| Run config file | config.ini |
| Initial condition | field_cor0101_var05_seed2.h5 |
Ideas how to fix this?
Communicate minimal max_time_step() between all processes. Note that BoundaryConditionManager has no means of communicating because it does not know the GridView.