[David Christopher]

I just noticed that if I write the surface monitor data (as well as plotting) in Fluent 14, the calculations take almost twice as long . I am writing out 5 monitors. Has anyone else noticed this? Any ideas why?

[`e`]

Computers spend a finite length of time on computations: including solving equations and plotting figures and text to your screen. Suppose your plotting routines and monitor calculations take tp = 500 ms per iteration and your solver takes ts = 250 ms per iteration (for a small mesh and few equations). By removing your plotting routines you would save a tp/(tp+ts) portion of time (in this case a reduction of 67 % or a speed-up factor of 2). However, for a larger more complicated simulation where ts = 10 s per iteration then you would only receive a speed-up factor of 1.05 (hardly worth bothering about).

If you're developing a simulation and have not yet reached the stage of running at full resolution then I wouldn't be too concerned about this plotting/monitoring time because they provide key performance metrics. However, if you're running your production version of your case then perhaps you could disable these monitors and plots, or only run them every several iterations.

You can analyse some time performances of your simulation via Parallel > Timer > Usage. If you're super keen on determining the time it takes to plot or otherwise then you could write some UDFs which record these times; but again, these computations would take CPU resources.

[David Christopher]

I have 500,000 elements for turbulent flow with one mass transfer equation, so I would think that writing out 5 numbers for the surface monitors would take much less time than one iteration of all those equations

[`e`]

Printing a value to the screen is not the only task you've employed the surface monitors to carry out. Surface monitors are typically surface integrals over a wall and therefore a number of evaluations are carried out across each boundary face before printing your single number to the screen. If you can think of a more efficient way of determining your surface monitor values than Fluent currently uses, try writing some UDFs and benchmark your results.

[David Christopher]

In this case, I am just looking at the vertex minimum to get the value at a point. I am also plotting the data and that does not take any significant time, but when I write the data to a file, the run time is much slower.

[`e`]

That sounds strange, I've written drag and lift coefficients to files (amongst other data files) and haven't encountered noticeably slower run times. What is your average WCT from Parallel > Timer > Usage?

[David Christopher]

I tried another option and found that if the surface monitor output files are new (small, few entries), the speed is not affected, but if the files are very large (200,000 entries, I need many iterations), then the speed is much slower.
The average WCT are all about the same as are all the other parameters reported there, but the expected total calculational times that are printed at each iteration are very different. Also, just timing the iterations with a stop watch shows that the iterations with large output files are much slower.
Could Fluent be rewriting the entire output file each iteration?

[nvarma]

Monitors are actual operations. They will consume time, but here are somethings you can do:

Try avoiding integration as much as possible. If so use smaller surfaces/volumes.

Reduce reporting intervals, so that fluent doesn't calculate those in every step. an extra 10 iterations won't hurt you compared to minutes or hoours of run time.

[`e`]

I doubt Fluent rewrites the entire output file each iteration. If you re-open Fluent and continue a simulation, Fluent continues appending this monitor file.

Fluent opens and locks the output file; perhaps this file is stored in memory. How large is the file with 200,000 (or similar) entries? Are you restricted by RAM?

[LuckyTran]

Originally Posted by `e`

I doubt Fluent rewrites the entire output file each iteration. If you re-open Fluent and continue a simulation, Fluent continues appending this monitor file.

Fluent opens and locks the output file; perhaps this file is stored in memory. How large is the file with 200,000 (or similar) entries? Are you restricted by RAM?

Fluent opens the file and appends to the EOF. Opening the file and the search for the EOF has to only be done once and should not slow down the simulation. I also think this is possibly a hardware issue or competing resources that results in not enough RAM or you are not able to write to the hard disk fast enough.