View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003888 | OpenFOAM | Bug | public | 2022-09-18 10:35 | 2022-09-20 09:04 |
| Reporter | tniemi | Assigned To | will | ||
| Priority | normal | Severity | major | Reproducibility | sometimes |
| Status | resolved | Resolution | fixed | ||
| Product Version | dev | ||||
| Fixed in Version | dev | ||||
| Summary | 0003888: compressible::alphatJayatillekeWallFunction sigFpe issue | ||||
| Description | After the recent commit https://github.com/OpenFOAM/OpenFOAM-dev/commit/f2b6c550faa2e823d9dcb7c61b37d69d701628b7 I started to get crashes due to sigFpe in alphatJayatillekeWallFunction. After a little debugging it seems that the "sign(B)*vSmall" stabilisation is not enough for zeroGradient walls where A=B=0 but C is finite. Changing vSmall to eg. rootVSmall seems to solve the issue. | ||||
| Steps To Reproduce | To reproduce, change "walls" to use alphatJayatillekeWallFunction in tutorials/modules/fluid/angledDuct/ | ||||
| Tags | No tags attached. | ||||
|
|
Thanks for the report. Fixed by this commit: https://github.com/OpenFOAM/OpenFOAM-dev/commit/a23937d86effce7b7f6a8cfffba9bc94f7af0424 A little backstory... We changed this function to a non-lagged form because we think that this is more consistent when dealing with fixed temperature boundary conditions. In that case, the new form recovers the modelled alphat exactly without any iteration. However, with fixed-gradient- or heat-flux-type boundary conditions, the old form was arguably more correct in that it uses exactly the heat flux that the temperature boundary condition calculated using the old alphat. However, in this case all the alphat condition is doing is trading diffusivity for temperature gradient. The heat flux is the same, so the affect on the simulation is minimal (there is potentially *no* effect). So, we judged the fixed-temperature case to be more important. It seemed to us that there was little need to run this boundary condition on zero-gradient or heat-flux boundaries. Though, as you point out, there should be no harm either, and the implementation should be robust to application anywhere. Hence being very happy to accept your change. As for generalisation... It is probably possible to mix these two options based on the matrix coefficients in the temperature/energy boundary condition. If the temperature condition is fixed value, then use the new version. If fixed gradient, use the old. If mixed, mix the two. If someone comes up with an example where this approach is needed then we will do just this. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2022-09-18 10:35 | tniemi | New Issue | |
| 2022-09-20 09:03 | will | Assigned To | => will |
| 2022-09-20 09:03 | will | Status | new => resolved |
| 2022-09-20 09:03 | will | Resolution | open => fixed |
| 2022-09-20 09:03 | will | Fixed in Version | => dev |
| 2022-09-20 09:03 | will | Note Added: 0012744 | |
| 2022-09-20 09:04 | will | Note Edited: 0012744 |
