|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
No. Computers |
2 |
3 |
6 |
12 |
~26,000 cells |
1.90 |
2.70 |
4.55 |
7.31 |
~100,000 cells |
1.95 |
2.86 |
5.31 |
9.30 |
Fig 2 - Speed up of computational jobs compared to the speed of a single computer.
This increase in speed vastly increases the amount of work that can be achieved by the fire engineer. The ~100,000 cell case required some 54hrs 10min to run. With 12 processors this job was completed within 5hrs 50mins - well within a working day - allowing the fire engineer to set up the problem, run the problem, analyse the results and start the next simulation, all within a single working day.
A number of heterogeneous network configurations were also studied and are summarised below. In order to take advantage of a heterogeneous network of PCs a dynamic load balancing scheme was devised to determine the relative computational power of each processor. The relative computational performance of the processors obtained from running serial SMARTFIRE are listed below in table 2. Entry (b, ii) indicates the relative performance of a dual processor PC when both processors are utilised.
Table 2 – Relative computational performance of processor compared to 733MHz Intel Pentium III
|
CPU |
k |
(a) |
Intel PIII 733 |
1.0 |
(b, i) (b, ii) |
Intel PII 450 2 x Intel PII 450D |
0.63 1.08 |
(c) |
Intel P200 MMX |
0.23 |
Table 3 - Speedup for heterogeneous network configurations using dynamic load balancing
Network Config |
CPUs |
Ideal |
Actual 26K |
Actual 100K |
1 |
(a) + (b) |
1.63 |
1.64 |
1.64 |
2 |
(a) + (c) |
1.23 |
1.19 |
1.21 |
3 |
(a) + (b) + (b) |
2.08 |
2.07 |
2.07 |
4 |
(a) + (b) + (c) |
1.86 |
1.69 |
1.84 |
5 |
(a) + (a) + (b) + (b) |
3.08 |
2.85 |
2.91 |
6 |
(a) + (b) + (b) + (c) |
2.31 |
2.12 |
2.24 |
7 |
(a) + (b) + (c) + (a) |
2.86 |
2.34 |
2.67 |
From table 3 it can be seen that good computational performance can be obtained from a variety of heterogeneous networks. It can be seen that most of the potential speedup performance was obtained from all the configurations. For network configuration 2 the performance is better than anticipated. This could be due to effects such as better cache/CPU utilisation.
As parallel SMARTFIRE is designed to be used on a conventional LAN of PCs some provision for other users using the same PC on the LAN had to be undertaken. This was necessary for two reasons, first the parallel SMARTFIRE job would be held up if just a single node became busy with another process, and secondly the other user’s process would be detrimentally affected by parallel SMARTFIRE. To mitigate both of these effects parallel SMARTFIRE monitors the workloads on all of its parallel computers. If a computer is found to have an additional computational load then the problem is redistributed amongst the processors so that only a small amount of processing, about 5% of the original load, is placed on the ‘busy’ processor for parallel SMARTFIRE.
The parallel implementation of SMARTFIRE allows the efficient solution of large fire field modelling problems. Furthermore this is achieved on non-specialised PC equipment which may typically exist in many fire safety engineering offices.
Reference:
Parallel CFD based Fire Modelling on Conventional Office Based PCs, Grandison A.J., Galea E.R., Patel M.K., Ewer J., Proceedings of the Joint DCABES and ICPACE Meeting, ISBN 1-904521-27-4, CMS Press, University of Greenwich, UK, 2005, pp43-46
The Development of Parallel Implementation for a CFD based fire field model utilising conventional office based PCs. Grandison A.J;, Galea E.R., Patel M.K., Ewer J. Journal of Applied Fire Science, Vol 12(2) 137-157, 2003-2004
E R Galea, N Hoffmann and D Berhane. Large-Scale Fire Field Modelling - the Route to General Use via Parallel Processing. Proceed INTERFLAM '93, Oxford, 1993.
See publications # 56, 55, 50, 44, 43, 184,185.
Copyright © 2003- University of Greenwich | Privacy and cookies | Accessibility | Contact the Webmaster |