CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Running, Solving & CFD

pimpleDyMFoam: When restarting a case, large spike in forces

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree1Likes
  • 1 Post By jvl001

Reply
 
LinkBack Thread Tools Display Modes
Old   January 31, 2014, 10:02
Default pimpleDyMFoam: When restarting a case, large spike in forces
  #1
Senior Member
 
Pete Bachant
Join Date: Jun 2012
Location: NH, USA
Posts: 107
Rep Power: 5
pbachant is on a distinguished road
I am running a case in pimpleDyMFoam, which seems to work well enough, but when I attempt to restart from latestTime, I am getting a large positive, then negative spike in the forces/moments right at the start of the new run. I am using an unsteady dynamicMeshDict, which has a table of 400 omega values. This is regenerated when restarting the solver, so it extends to endTime. My only guess it that the spikes could be caused by a change in the dynamicMeshDict, but that seems unlikely because of the resolution. To be more specific, I'm going from 400 omega values per 0.3 seconds to 400 omega values per 0.4 seconds. Any other ideas on what might be causing this issue?
pbachant is offline   Reply With Quote

Old   February 15, 2014, 11:13
Default
  #2
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,312
Blog Entries: 34
Rep Power: 84
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
Greetings Pete,

It might be due to a bug in the OpenFOAM version you are using.
There have been several bugs fixed related to simulation restarts, for example since OpenFOAM 2.1.0 was released, therefore knowing which OpenFOAM version you are using would make it a bit easier to assess if it's something that has already been fixed.

Best regards,
Bruno
wyldckat is offline   Reply With Quote

Old   February 27, 2014, 08:15
Default
  #3
New Member
 
Jason Lassaline
Join Date: Mar 2012
Posts: 3
Rep Power: 5
jvl001 is on a distinguished road
I had the same problem using v 2.2.x from the git repo. I found that the problem is that 'meshPhi' is not being written at each time step, and thus not read by the appropriate fvMesh constructor.

The pimpleDyMFoam solver does the following before advancing the PIMPLE loop:

fvc::makeAbsolute(phi, U); // This depends on meshPhi
mesh.update(); // This creates the meshPhi field if it doesn't exist, then updates it.
fvc::makeRelative(phi, U) // This depends on meshPhi

If meshPhi is not saved during the last time step, pimpleDyMFoam starts up with a zero-valued meshPhi, causing an immediate difference in the calculations of mesh displacement, U, and p. This probably affects other *DyMFoam solvers.

I'm not certain what the best fix is, other than to force fvMesh::movePoints() to write meshPhi every time it updates the phiPtr_ variable.
In my code, I adjusted the fvMesh::movePoints() function as follows:

- Change 'IOobject::NO_WRITE' to 'IOobject::AUTO_WRITE'
- Added a phi.write() just before the function returns. <-- This isn't good as it creates a new time directory at each time step!

Update:

I just took a look at the source of pimpleDyMFoam.C v2.3.x in git. Looks like it has been modified to fix this problem, though I have not tested it...

Last edited by jvl001; February 28, 2014 at 10:24. Reason: Found a new problem.
jvl001 is offline   Reply With Quote

Old   March 1, 2014, 07:03
Default
  #4
New Member
 
Jason Lassaline
Join Date: Mar 2012
Posts: 3
Rep Power: 5
jvl001 is on a distinguished road
After recompiling v2.3.x I discovered the restart problem still remains. However I did determine how to get meshPhi to be written, if needed. You'll need to modify fvMesh.C so that:

- 'phiPtr_' is registered as an IO object (currently it is not)
- add logic to change phiPtr_ to IOobject::AUTO_WRITE with the current time step if it is modified by fvMesh::movePoints
- add logic to write phiPtr_ if it exists in fvMesh::writeObject

The attached patch should work with v2.2.x (tested) or v2.3.x (not tested).

Apply this patch from the '$WM_PROJECT_DIR':

cd $WM_PROJECT_DIR
patch -p0 < fvMesh.patch
wmake src/finiteVolume
Attached Files
File Type: patch fvMesh.patch (1.3 KB, 37 views)
pbachant likes this.
jvl001 is offline   Reply With Quote

Old   March 1, 2014, 07:43
Default
  #5
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,312
Blog Entries: 34
Rep Power: 84
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
Hi Jason,

I thought this was a bug that was fixed long ago by now.
Thanks for sharing the solution you've found!

Please report this on the official bug tracker, so that the OpenFOAM team can fix this as well: http://www.openfoam.org/mantisbt/ - and please provide them with a test case and details on the issue, so that they can confirm how to reproduce the error.

Best regards,
Bruno
wyldckat is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


LinkBacks (?)
LinkBack to this Thread: http://www.cfd-online.com/Forums/openfoam-solving/129234-pimpledymfoam-when-restarting-case-large-spike-forces.html
Posted By For Type Date
Untitled document This thread Refback October 25, 2014 04:26

Similar Threads
Thread Thread Starter Forum Replies Last Post
Large test case for running OpenFoam in parallel fhy OpenFOAM Running, Solving & CFD 22 September 22, 2009 11:13
Is Playstation 3 cluster suitable for CFD work hsieh OpenFOAM 8 March 12, 2008 05:58
Forces for a sloshing case ogloth OpenFOAM Running, Solving & CFD 8 October 22, 2007 22:15
Free surface boudary conditions with SOLA-VOF Fan Main CFD Forum 10 September 9, 2006 12:24
Post-processing of a large transient case Flav CD-adapco 2 September 28, 2004 06:19


All times are GMT -4. The time now is 05:13.