View Issue Details

IDProjectCategoryView StatusLast Update
0001988OpenFOAM[All Projects] Bugpublic2016-02-04 20:31
ReportersantiagomarquezdAssigned Tohenry 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformGNU/LinuxOSUbuntuOS Version12.04
Product Version 
Fixed in Version 
Summary0001988: Not null effect of fvOptions
DescriptionIn driftFluxFoam, particularly UEqn.H, commenting fvOptions line is not equal to have this line but without fvOptions set in dictionaries (no fvOptions file).
Steps To Reproduce1. Run dahl example from the distro saving the log
2. Edit UEqn.H from driftFluxFoam like this:

    // Solve the Momentum equation

    fvVectorMatrix UEqn
    (
        fvm::ddt(rho, U)
      + fvm::div(rhoPhi, U)
      + fvc::div(UdmModel.tauDm())
      + turbulence->divDevRhoReff(U)
// ==
// fvOptions(rho, U)
    );
3. Compile and run dahl example again saving the log
4. Compare both logs using diff, results will be different. I think that they should be equal, if not, Which is the correct one?

TagsNo tags attached.

Activities

henry

2016-02-04 20:31

manager   ~0005922

Both results are correct but slightly different because of the order in which terms are evaluated and boundary conditions updated. However the dependency on the location or presence of the fvOptions term is unsatisfactory.

The trailing fvOptions causes a zero fvMatrix construction which in tern causes the U boundary conditions to be updated before the explicit part of the divDevRhoReff stress term. Note that in C++ expressions are evaluated right-to-left.

I have reordered the terms in divDevRhoReff to ensure that the U boundary conditions to be updated before the explicit part removing the dependency on the presence or location of the fvOptions term in the equation.

Resolved in OpenFOAM-dev by commit 8e04a529d9edcc35a927be97b6995f9c6d776413

Issue History

Date Modified Username Field Change
2016-02-04 18:24 santiagomarquezd New Issue
2016-02-04 20:31 henry Note Added: 0005922
2016-02-04 20:31 henry Status new => resolved
2016-02-04 20:31 henry Resolution open => fixed
2016-02-04 20:31 henry Assigned To => henry