[megs]

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 i5-6600K 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

[sufjanst]

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 steady-state 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.

[megs]

What is your desired flow time after 57h of calculating?

The flow time is only 10000s (around 3h) which is why I am so uncertain about the time it takes to run

Maybe you can speed things up by running a steady-state simulation with a developed flow field and then switching to your transient solve

I have absolutely no experience in OpenFOAM so I really wouldn't even know where to start

[taalf]

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 counter-productive. Did you vary the number of partitions to see what is the best?

[megs]

- why IHFoam ?

The porous cylinder I am modelling is a fish farm so I was going to add a tidal component and my supervisor (who set up the simulation for me) chose that, I think because of the tidal component

- what is the time step?

the time step is 0.001s. Is this too small?

- how long does it take to compute one iteration?

from extrapolation, when I print out each 10s, it takes +- 3min between files, so probably around 0.018s give or take between timestep?

checking the Courant Number

I have a line in my controlDict:

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

[taalf]

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 steady-state 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 pseudo-steady 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.52779e-05 max: 8.88719
deltaT = 0.000632561
Time = 0.00833413

PIMPLE: iteration 1
smoothSolver: Solving for alpha.water, Initial residual = 3.21608e-06, Final residual = 3.7308e-12, No Iterations 2
(...)


Hope this helps :-)