View Issue Details

IDProjectCategoryView StatusLast Update
0000909OpenFOAMBugpublic2013-10-11 15:30
Reportersantiagomarquezd Assigned Tohenry  
PriorityhighSeveritymajorReproducibilitysometimes
Status resolvedResolutionfixed 
PlatformLinuxOSFedora 
Summary0000909: rhoPimpleDyMFoam error in EEqn in terms of enthalpy
DescriptionHoracio 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.
TagsNo tags attached.

Activities

henry

2013-07-03 10:08

manager   ~0002300

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.

santiagomarquezd

2013-07-03 14:13

reporter   ~0002301

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.

henry

2013-07-03 14:25

manager   ~0002302

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.

henry

2013-10-11 15:30

manager   ~0002542

Resolved by commit 159650d98081b9780bd24e83b8d6c6406b07d7bb

Issue History

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