
[Sponsors] 
August 31, 2019, 05:17 
Optimizing OpenFOAM simulation

#1 
New Member
Meghan Kennealy
Join Date: Aug 2019
Posts: 3
Rep Power: 3 
I am extremely new to OpenFOAM (and using v1706) and CFDs in general. I am currently running a simple simulation of two porous cylinders in a stationary velocity field (inlet velocity of 0.08m/s). The grid is 500x500, I am doing my final runs for my Master's (on a different topic) but for 10 000s of computation, the simulation is taking 57h to run on my machine.
I am running it in parallel, with a i56600K CPU @ 3.50GHz and I am using ihfoam as a solver. Is this realistic? Or is there something I can do to optimize the simulation, because I need to run various orientations of the two cylinders (and possibly more cylinders) and at 57h and then the flow isnt yet developed, it seems like that may be a pipe dream (hehe) unless I run it on Azure or Gcloud 

September 2, 2019, 03:30 

#2 
Member
Join Date: Mar 2016
Posts: 73
Rep Power: 7 
That's a lot of computation time for a 500x500 mesh. What is your desired flow time after 57h of calculating? Maybe you can speed things up by running a steadystate simulation with a developed flow field and then switching to your transient solver.
A common mistake on parallel computations is to use all virtual cores via hyperthreading of your machine which slows down the simulation. Make sure you are using only the 'real' cores. 

September 2, 2019, 09:33 

#3  
New Member
Meghan Kennealy
Join Date: Aug 2019
Posts: 3
Rep Power: 3 
Quote:
Quote:
Last edited by megs; September 2, 2019 at 14:48. 

September 2, 2019, 09:55 

#4 
Member
William Tougeron
Join Date: Jan 2011
Location: Czech Republic
Posts: 70
Rep Power: 12 
Hi,
Unsteady simulations can be long enough to compute. Few questions:  why IHFoam ?  what is the time step?  how long does it take to compute one iteration? You can control if time step is relevant by checking the Courant Number (indicated at end of each iteration in the solver output). If it's below one, you can increase the time step. You say you compute it in parallel. For such a light mesh, it's possible you reached the max. number of partitions. Putting too much cores on a computation can be counterproductive. Did you vary the number of partitions to see what is the best? 

September 2, 2019, 14:47 

#5  
New Member
Meghan Kennealy
Join Date: Aug 2019
Posts: 3
Rep Power: 3 
Quote:
Quote:
Quote:
Quote:
Code:
maxCo 0.45; In terms of the parallel, before I ran it in parallel, the 250x250 grid took aroun 12h, I'm not sure what the time scaling is in terms of increased grid size 

September 3, 2019, 03:50 

#6 
Member
William Tougeron
Join Date: Jan 2011
Location: Czech Republic
Posts: 70
Rep Power: 12 
Hi @megs,
An iteration time of 0.018s seams reasonable. So, given a time step of 0.001s, we have indeed: it time * total time / time step = 0.018s * 10,000s / 0.001s = 180,000s = 50h Everything is consistent. About the number of partitions, you can find it in the system/decomposeParDict file. You can vary this number ("numberOfSubdomains") to see effect on it time. Some suggestions (that can be irrelevant since we don't know much what exactly you need to simulate in fine): I don't know IHFoam but I understand it's based on interFoam, which is basically an unsteady solver. But what you described is a steadystate case ("I am currently running a simple simulation of two porous cylinders in a stationary velocity field"). If you are interested only in the final state of your simulation (once the flow is stabilized), so the Courant Number (which is a function of the time step) mustn't be so low. A Courant Number <=1 is relevant only when you want to catch precisely unsteady phenomenons. Else, you can increase it much (I would say, infinitely). The only limitation will be residuals (a too high Courant number will prevent the solver to converge). You also have a way to make interFoam (IHFoam as well I guess) a pseudosteady solver, by changing the time discretization scheme (if not yet). In your file system/fvSchemes, in "ddtSchemes", you can try to change "default Euler;" to "default localEuler;". Just about the "maxCo" you found, this value is read by OF only if you have also: "adjustTimeStep yes;" in your controlDict file. In this case, the time step is calculated by OF. Else, it takes the "deltaT" value (still in controlDict file) and the Courant Number can move freely. In any case you can read the actual Courant Number in the log (output from OF when it runs): (...) PIMPLE: converged in 2 iterations ExecutionTime = 1600.94 s ClockTime = 1621 s Courant Number mean: 0.00183079 max: 19.7787 Interface Courant Number mean: 1.52779e05 max: 8.88719 deltaT = 0.000632561 Time = 0.00833413 PIMPLE: iteration 1 smoothSolver: Solving for alpha.water, Initial residual = 3.21608e06, Final residual = 3.7308e12, No Iterations 2 (...) Hope this helps :) Last edited by taalf; September 3, 2019 at 05:05. 

Tags 
cylinder, ihfoam, openfoam, optimization 
Thread Tools  Search this Thread 
Display Modes  


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
OpenFoam: time averaging velocity of a URANS Simulation  andreic  OpenFOAM PostProcessing  1  August 22, 2019 09:40 
OpenFoam 4.1: interDyMFoam LES Simulation for hydro turbine in river  pi__sec  OpenFOAM Running, Solving & CFD  13  July 19, 2017 04:08 
Map of the OpenFOAM Forum  Understanding where to post your questions!  wyldckat  OpenFOAM  9  March 30, 2017 05:19 
diesel Engine simulation in OpenFOAM  karam  OpenFOAM Running, Solving & CFD  1  March 1, 2011 09:46 
Crosscompiling OpenFOAM 1.7.0 on Linux for Windows 32 and 64bits with Mingww64  wyldckat  OpenFOAM Announcements from Other Sources  3  September 8, 2010 06:25 