Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • openfoam openfoam
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 393
    • Issues 393
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 13
    • Merge requests 13
  • Deployments
    • Deployments
    • Releases
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • Development
  • openfoamopenfoam
  • Issues
  • #1332

Closed
Open
Created Jun 04, 2019 by Admin@OpenFOAM-adminMaintainer

Forced physical solutions through solver

Functionality to add/problem to solve

Solvers return solutions that are obviously non-physical. At the moment, only advanced discretization schemes are used to (mainly) secure physical values of alpha, T, k, epsilon and similar. This could be improved by deliberately removing obvious non-physical solutions through solvers.

Target audience

Those that use multiphase solver or turbulence or similar in their cases.

Proposal

It could be solved by adding IF blocks in solvers: IF (alpha<0) alpha=0; IF (alpha>1) alpha=1; Maybe some will see this as a feature that reduces the quality or the beauty of the calculations, but I think that the point of the calculations is to get the results that are as close to the real ones as possible and from that standpoint, I think that this feature would be good. Maybe because of that viewpoint, some lines for enabling this feature could be added to fvSolution dictionary: forcePhysical { turnOn yes; alpha.greaterThan 0; alpha.smallerThan 1; } so that those that do not want to use this feature could not use it.

I think that this could be viewed as usual practise. During my studies, when I used one well-known software environment, in some calculations that should return real numbers, the result used to be, for example, ...+i*1e-20, so I deliberately used the IF blocks to remove those numerical errors, something like: IF (imaginaryPart(number)<1e-10) {number=realPart(number)};

What does success look like, and how can we measure that?

Test cases could be the already present tutorials. This way there is the possibility that even Gauss linear could be used, what could be good in some cases when some value changes drastically. Error margins do not exist because no errors should be made if this is implemented correctly.

Links / references

No links to literature.

Funding

The functionality does not exist, but IF blocks exist and I think that the implementation should be relatively quick. I don't know who would sponsor this, but maybe some of the present sponsors would be interested because this would make the calculations more stable, what sounds as important for industry.

Assignee
Assign to
Time tracking