|
[Sponsors] |
Calculational speed is much slower with monitors |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
April 21, 2015, 21:32 |
Calculational speed is much slower with monitors
|
#1 |
New Member
Dave Christopher
Join Date: Dec 2009
Posts: 26
Rep Power: 16 |
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?
|
|
April 21, 2015, 21:46 |
|
#2 |
Senior Member
Join Date: Mar 2015
Posts: 892
Rep Power: 18 |
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. |
|
April 22, 2015, 01:35 |
|
#3 |
New Member
Dave Christopher
Join Date: Dec 2009
Posts: 26
Rep Power: 16 |
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
|
|
April 22, 2015, 04:40 |
|
#4 |
Senior Member
Join Date: Mar 2015
Posts: 892
Rep Power: 18 |
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.
|
|
April 22, 2015, 21:34 |
|
#5 |
New Member
Dave Christopher
Join Date: Dec 2009
Posts: 26
Rep Power: 16 |
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.
|
|
April 22, 2015, 22:11 |
|
#6 |
Senior Member
Join Date: Mar 2015
Posts: 892
Rep Power: 18 |
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?
|
|
April 24, 2015, 02:56 |
|
#7 |
New Member
Dave Christopher
Join Date: Dec 2009
Posts: 26
Rep Power: 16 |
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? |
|
April 24, 2015, 16:19 |
|
#8 |
Senior Member
nm
Join Date: Mar 2013
Posts: 100
Rep Power: 13 |
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. |
|
April 27, 2015, 04:58 |
|
#9 |
Senior Member
Join Date: Mar 2015
Posts: 892
Rep Power: 18 |
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? |
|
April 27, 2015, 21:22 |
|
#10 | |
Senior Member
Lucky
Join Date: Apr 2011
Location: Orlando, FL USA
Posts: 5,676
Rep Power: 66 |
Quote:
|
||
Tags |
fluent, speed, write monitor data |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
AMI speed performance | danny123 | OpenFOAM | 21 | October 24, 2020 04:13 |
calculate flame speed using reactingFoam | IColin | OpenFOAM Running, Solving & CFD | 0 | February 4, 2014 15:14 |
Train Speed | yeo | FLUENT | 5 | February 14, 2012 08:38 |
Apparent wind Speed (moving object) | Solo Sails | OpenFOAM Running, Solving & CFD | 11 | December 13, 2011 08:34 |
low speed compressible two phase flow?? | cat | CFX | 0 | November 15, 2005 07:59 |