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
  • #561

Closed
Open
Created Aug 08, 2017 by Admin@OpenFOAM-adminMaintainer

writeInterval not respected when starting from T != 0

Some context: I am running DES simulations which start from a steady RANS result. This means, I'll run thousands of RANS iterations, and then run a few physical seconds.

In this case I am testing setup scripts, so I'm running 6 RANS iterations, and 0.051 seconds of DES time. So my DES case starts at t=6, does 85 iterations of deltaT=0.0006, ending at t=6.051. I have calculated those values out so that, using a writeInterval of 17, the case writes out exactly 5 times and the last write is exactly at t=6.051.

However, the first write occurs at t=6.0066, which is only 11 iterations in, rather than 17. I think should be writing out at 6.0102, as per deltaT and the writeInterval. It seems to me the writeInterval of 17 is including the t=6 startTime as 6 iterations, which means it writes after 11 DES iterations (0.0006*11 = 0.0066). This shifts the writing to undesired interval, and I think this is a bug. I would assume the correct behaviour would be to always count the writeInterval from the startTime?

I confirmed this by starting from a RANS run with 10 iterations, so startTime = 10. In this case, the first write is at 6.0042, or 7 iterations after the startTime.

Is this a bug? I am able to provide a case, it's a very simple geometry.

Assignee
Assign to
Time tracking