View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000909 | OpenFOAM | Bug | public | 2013-07-03 04:42 | 2013-10-11 15:30 |
| Reporter | santiagomarquezd | Assigned To | henry | ||
| Priority | high | Severity | major | Reproducibility | sometimes |
| Status | resolved | Resolution | fixed | ||
| Platform | Linux | OS | Fedora | ||
| Summary | 0000909: rhoPimpleDyMFoam error in EEqn in terms of enthalpy | ||||
| Description | Horacio Aguerre and me were studyng rhoPimpleDyMFoam and found an error in the Energy Equation formulation in terms of enthalpy, the equation is missing the term of transport due mesh moving as Horacio explained in: http://www.cfd-online.com/Forums/openfoam-programming-development/118406-study-eeqn-h-rhopimpledymfoam.html the solution is also there. The inclusion of this term solves the problem in the cases we've tested. | ||||
| Tags | No tags attached. | ||||
|
|
Thank you for your bug-report and detailed analysis. It would be very helpful if in future you provide the complete bug-reports here so that we can deal with them more efficiently and keep track of them all in one place. I will consider the options for resolving the issue with the pressure work term in moving mesh cases and look for the most elegant solution. |
|
|
Hi, thanks for the answer. We uploaded the question in the forum in order to check if we weren't missing an user option. After a while without answers we decided to upload it here. Horacio proposed and tested a solution that seems to be working. The new EEqn reads, volScalarField& he = thermo.he(); fvScalarMatrix EEqn ( fvm::ddt(rho, he) + fvm::div(phi, he) + fvc::ddt(rho, K) + fvc::div(phi, K) + ( he.name() == "e" ? fvc::div ( fvc::absolute(phi/fvc::interpolate(rho), U), p, "div(phiv,p)" ) : -dpdt + fvc::div(fvc::meshPhi(U),p) ) - fvm::laplacian(turbulence->alphaEff(), he) == fvOptions(rho, he) ); note the extra term in the the -dpdt option line. Regards. |
|
|
Your proposal is correct for your purpose but is only appropriate for solvers with mesh-motion. Ideally I would like a formulation which is correct and efficient for both fixed mesh and moving mesh solvers and cases. I am considering the options at the moment. |
|
|
Resolved by commit 159650d98081b9780bd24e83b8d6c6406b07d7bb |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-07-03 04:42 | santiagomarquezd | New Issue | |
| 2013-07-03 10:08 | henry | Note Added: 0002300 | |
| 2013-07-03 14:13 | santiagomarquezd | Note Added: 0002301 | |
| 2013-07-03 14:25 | henry | Note Added: 0002302 | |
| 2013-10-11 15:30 | henry | Note Added: 0002542 | |
| 2013-10-11 15:30 | henry | Status | new => resolved |
| 2013-10-11 15:30 | henry | Resolution | open => fixed |
| 2013-10-11 15:30 | henry | Assigned To | => henry |
