View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003135||OpenFOAM||Bug||public||2018-12-17 21:08||2018-12-19 11:48|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Fixed in Version||dev|
|Summary||0003135: Wall boundary condition not respected|
|Description||In tutorial case: $FOAM_TUTORIALS/multiphase/interFoam/laminar/wave:|
I tried to change the bottom into wall boundary condition to wall, but the results show non zeros values, instead it show value order of 2e-3.
|Steps To Reproduce||Step 1: go to laminar wave case:|
Step2: change in blockMeshDict:
(0 1 5 4)
Step 3: in: 0/U.orig:
2 implementation have been tested:
value uniform (0 0 0);
In both case, the velocity in bottom patch is not zero.
|Tags||No tags attached.|
||How are you seeing the results? Please provide the specific steps you are using to see the results, because it's all too easy to see the values on the cells rather than the values on the patches.|
Step to view the result:
Step 1: load data using paraView, so I just lauch:
Step2: deactive internal mesh and active "bottom"
Step3: chose to color with U, either magnitude or X or Y
Side note: I tried to run the same setup with small modifications using OpenFoam-plus and the results seem to respect the boundary imposed: around 10^-30 as velocity magnitude.
We can't reproduce the issue with your instructions. That's why your previous report got closed. See https://bugs.openfoam.org/rules.php.
setWaves does overwrite fixedValue conditions. This is necessary due to some boundary conditions requiring a physical initialisation. The DTCHull case fails due to a floating point error in the outlet boundary if the alpha patch field is not set properly. This is very unlikely to be necessary on walls, however, so I have changed setWaves in dev so that it doesn't override values on walls when the boundary condition is of fixed-value type.
I'm assuming that this issue is resolved by the change, but as I couldn't reproduce it in the first place I'm not completely sure. Open another report if the problem persists.
|2018-12-17 21:08||mqnguyen||New Issue|
|2018-12-18 10:59||wyldckat||Note Added: 0010223|
|2018-12-18 15:26||mqnguyen||Note Added: 0010226|
|2018-12-19 11:48||will||Assigned To||=> will|
|2018-12-19 11:48||will||Status||new => resolved|
|2018-12-19 11:48||will||Resolution||open => fixed|
|2018-12-19 11:48||will||Fixed in Version||=> dev|
|2018-12-19 11:48||will||Note Added: 0010232|