Encyclopaedia Index

EXTERNAL AIRFLOWS - SILSOE STRUCTURES BUILDING

(Richard Chown)

1. Introduction

A series of test cases have been created using PHOENICS 3.0.1 VR Editor to simulate wind flow around a real building that has good full-scale test data available from previous experiments. This building (the Silsoe Building) is rectangular in plan and has a pitched roof. Figure 1 shows the building geometry.

The Silsoe Structures Building was specifically constructed for the purpose of external surface pressure measurements and so provides a means of comparing calculated and full-scale results. Robertson et al (1988) describe the construction and instrumentation details of the building.

Osmond (1997) describes the calculation of external pressures over the Silsoe Building using FLOW3D (Release 3.2.1), a commercially available computational fluid dynamics software written using body-fitted finite difference code. The results from this show good agreement with the full-scale external pressure data. (Figures 2, 3 and 4).

Results from the PHOENICS CFD experiments have been compared against results from both the full-scale data and the FLOW3D calculations.

2. Test cases

2.1 Silsoe 3.q1

This is a q1 file to simulate wind flow at 90º to the Silsoe Building. Figure 5 shows the geometry of this problem. The domain size was set at 200m x 200m x 22m.

The building was set up as a BLOCKAGE made from Brick material with a roughness of 2mm on all surfaces. The pitched roof was made up of two wedge-shaped BLOCKAGES, set up as WEDGET shapes from the CLIPART library. Each wedge was installed back to back along the centre-line of the building, thus forming the pitch. The roof was modelled as Tile Hanging/Roof-tile material with a roughness of 2mm in each direction.

An INLET wind profile was set up 93.5m upstream of the building. The profile was made up of 34 INLET objects across the full width of the domain boundary. Each INLET object has a separately defined velocity calculated from equation 1.

The elements are of varying height and are more concentrated near to the ground.

The velocity is a function of the distance above ground according to equation 1:

Fig. (1)

Where U = wind speed (m/s)

z = distance above ground (m)

z0 = ground roughness parameter (m)

h = reference above ground (m)

The subscripts z & h represent wind speed at a distance z & h above ground respectively.

Equation 1 defines the velocity profile measured at full-scale tests at the Silsoe Structures Building and reported by Hoxey et al (1993).

In these experiments the values of h, Uh and z0 are defined as 2m, 10m/s and 0.01m respectively.

An identical wind profile was set up 93.5m downstream of the building to model Outlet conditions.

The GROUND domain boundary was set up as a PLATE with a roughness of 10mm in each direction.

2.2 Silsoe5.q1

This test case is identical to that of Silsoe3.q1 except for the way in which the pitched roof is generated. In this case the roof is made up of 23 thin (50mm high) elements modelled as Tile hanging/roof-tile BLOCKAGES. Each element has a roughness of 2mm in every direction. The width of each element decreases proportionately with height above the building walls to form the pitch. See Figure 6.

2.3 Silsoe6b.q1

This test case is similar to Silsoe5.q1. However, the downstream wind profile is set as a fixed pressure boundary to improve flow through the domain. The solution options were chosen as 60 (NX) x 30 (NY) x 50 (NZ). This problem was submitted to CHAM and run on their remote server.

2.4 Silsoe8.q1

This test case is similar to Silsoe5.q1. The wind flow in this case is at 45º to the building. The resultant wind profile (Uh = 10m/s) at 45º to the building is generated using identical INLET wind profiles along the North and East domain boundaries. Equation 1 is used to calculate each of the 34 INLET object velocities. The OUTLET conditions are set as fixed pressure boundaries to improve the flow through the domain. See Figure 7.

2.5 Silsoe10.q1

This test case is similar to Silsoe8.q1. The only difference in this calculation is that crude NULL objects have been placed either side of the building in an attempt to improve the grid.

2.6 Silsoe7.q1

This test case is identical to Silsoe6b.q1. However, in order to refine the grid size around the building NULL objects were inserted adjacent to the upstream and downstream walls. Further NULL objects were installed throughout the domain in an attempt to reduce the redundancy of cells. This test case was used as a benchmark case for four other derivatives (silsoe7a, 7b, 7c & 7d). Silsoe7.q1 was run on the remote CHAM server.

2.7 Silsoe7a.q1

This test case is identical to Siloe7.q1 except the ground roughness was set at 5mm in all directions.

2.8 Silsoe7b.q1

This test case is identical to Siloe7.q1 except the ground roughness was set at 10mm in all directions.

2.9 Silsoe7c.q1

This test case is identical to Siloe7.q1 except the ground roughness was set at 50mm in all directions.

2.10 Silsoe7d.q1

This test case is identical to Siloe7.q1 except the ground roughness was set at 100mm in all directions

2.11 Silsoe7e.q1

This test case is identical to Siloe7b.q1 except for a number of NULL objects being deleted to reduce the number of grid cells well below 100 000.

2.12 Silsoe7f.q1

This test case is identical to Siloe7d.q1 except for a number of NULL objects being deleted to reduce the number of grid cells well below 100 000.

3. Modelling options

All of the test cases have been set up using library options. The Domain material is set as AIR, using the ideal gas law at standard temperature and pressure. The air flow through the Domain was modelled as TURBULENT using the library REYNOLDS number model.

All of the PC based test cases were carried out to familiarise the user with the PHOENICS VR interface and to get an appreciation of CFD techniques. Several different cases were generated to assess the capabilities of the package and to develop a suitable model for the validation exercise.

4. Solution options

All of the locally run simulations have been performed on an Oakwood P100 PC with 64Mb of memory.

4.1 Silsoe3

The mesh dimensions were set as 47 (NX) x 10 (NY) x 59 (NZ). 10 iterations were carried out with the relaxation set at 0.5.

The calculations took 9½ minutes.

4.2 Silsoe5

The mesh dimensions were set as 47 (NX) x 10 (NY) x 59 (NZ). 10 iterations were carried out with the relaxation set at 0.5.

The calculations took 10½ minutes.

4.3 Silsoe6b

These calculations were carried out by CHAM on their remote server.

The mesh dimensions were set as 60 (NX) x 30 (NY) x 50 (NZ). 500 iterations were carried out with the relaxation set at 1.0.

4.4 Silsoe8

The mesh dimensions were set as 47 (NX) x 10 (NY) x 59 (NZ). 10 iterations were carried out with the relaxation set at 0.5.

The calculations took 11 minutes.

4.5 Silsoe10

The mesh dimensions were set as 77 (NX) x 10 (NY) x 59 (NZ). 10 iterations were carried out with the relaxation set at 0.5.

The calculations took 16¾ minutes.

4.6 Silsoe7

The mesh dimensions were set as 78(NX) x 14(NY) x 74(NZ). 100 iterations were carried out with the relaxation set at 10. The run time was in the region of 2400 seconds.

4.7 Silsoe7a

The mesh dimensions were set as 78(NX) x 17(NY) x 74(NZ). 100 iterations were carried out with the relaxation set at 10. The run time was in the region of 3600 seconds.

4.8 Silsoe7b

The mesh dimensions were set as 78(NX) x 17(NY) x 74(NZ). 100 iterations were carried out with the relaxation set at 10. The run time was in the region of 3700 seconds.

4.9 Silsoe7c

The mesh dimensions were set as 78(NX) x 17(NY) x 74(NZ). 100 iterations were carried out with the relaxation set at 10. The run time was in the region of 3700 seconds.

4.10 Silsoe7d

The mesh dimensions were set as 78(NX) x 17(NY) x 74(NZ). 100 iterations were carried out with the relaxation set at 10. The run time was in the region of 3700 seconds.

4.11 Silsoe7e

The mesh dimensions were set as 78(NX) x 14(NY) x 74(NZ). 100 iterations were carried out with the relaxation set at 10. The run time was in the region of 3700 seconds.

4.12 Silsoe7f

The mesh dimensions were set as 78(NX) x 14(NY) x 74(NZ). 100 iterations were carried out with the relaxation set at 10. The run time was in the region of 3700 seconds.

5. Silsoe7

A standard building case consisting of a wind flow at 90 degrees to the building was chosen for the validation exercise. A considerable amount of information (both from full-scale tests and from Flow-3D calculations) was available for this type of problem. In order to assess the sensitivity of the package and its potential use in a commercial environment several cases were to be submitted each with varying degrees of ground roughness (from 1mm to 100mm). Ground roughness plays an impor tant role in design wind loading, affecting peak gusts. A commercial design package must therefore show considerable sensitivity to changes in ground roughness.

This case was set up as a benchmark case for validation of the PHOENICS VR CFD package. The details and material properties of this case are described in Sections 2, 3 and 4 above.

The case was sent to CHAM on 23 March 1998 for analysis, the results returning on 25 March 1998. The results showed that the pressure distribution across the building (in the direction of flow and perpendicular to the flow, Figures 8 & 9) to be approximately correct.

In order to assess the results compared to full-scale results and Flow-3D results pressure coefficients were determined at various locations across the building surface (Figure 10). These showed that in areas of separated flow (from the base of the upward wall to a point just downstream of the ridge; measured across the building surface) that there was poor correlation between the pressure coefficients obtained using PHOENICS VR and full-scale results. However, in regions of attached fl ow the pressure coefficients showed reasonable agreement.

There are several possible reasons for this. Firstly the sensitivity of flow predictions to grid density and geometry is well known, particularly near building surfaces and edges. Although NULL objects were used upstream of the building to improve grid density and geometry they appear to have not refined the grid sufficiently. Secondly the values of pressure taken at various probe locations appeared to be highly conjectural when placed at or very close to building surfaces. Although t his was improved by moving the probe slightly away from the building surface it proved very difficult to determine definitive values of pressure close to the building.

5.1 Comparisons with Silsoe7e & 7f

Results for Silsoe7, Silsoe7e & Silsoe7f show considerable similarity (Figures 11, 12 & 13). This suggests that although the ground roughness varied between 1mm and 100mm it had very little effect on the PHOENICS VR calculations. The similarity in results suggests that in changing the ground roughness from 1mm through 100mm the ground level was also raised by an equivalent amount. Hence the effect of changing the ground roughness had no aerodynamic effect whatsoever on the problem in hand.

Because ground roughness is of considerable importance in determining design wind loading on a structure, the failure of PHOENICS VR to show any significant variation in the test results of Silsoe7, 7e & 7f is of particular concern.

6. Results

6.1 PC based

The results from PC based calculations appear crude and of limited use. The PC results from Silsoe6b indicate that there are a number of wasted cells in regions well away from the building. It also appears that the grid cells adjacent to the building are far too big. Hence information from cells close to the building is not sensitive enough and the data from cells away from the building is too sensitive. In Release 3.0.1 cell sensitivity can be improved by incorporating NULL objects close to the building.

6.2 Remote server calculations

Significant difficulties were experienced when using the remote analysis package attached to the VR interface. Although cases were easy to submit through the internet link, the quality of material returned following analysis showed considerable variation. Appendix 1 lists the cases submitted and their status once remote processing had taken place.

All of the cases submitted to CHAM were derived from Silsoe7.q1 which was submitted once. The results from Silsoe7.q1 showed similar results to those obtained using Flow3D and from the experimental building. However, when this case was resubmitted as Silsoe7a.q1 (with the ground roughness changed from 1mm to 5mm) the results showed pressure and velocity profiles that were clearly inaccurate. Several more submissions of this case were generated, the results returning either as wildly in accurate or as files that were inaccessible. This was also the case with Silsoe7b, Silsoe7c and Silsoe7d.

In cases where the VR VIEWER would not access the results it became evident that at some stage during transfer or calculation, the grid size had been regenerated to give a grid containing more than 100 000 cells. In these cases it has been found that Phoenics 3.1 will not allow the result files to be accessed, however, this faux pas is not defined at any stage to the user through the information manual or through POLIS.

It would also appear that the reason for the inaccurate results is due to cell numbers within the domain approaching 100 000. This value appears to be an arbitrary ceiling applied to the grid size.

Eventually after deleting some of the NULL objects within the domain to keep the cell numbers well below 100 000, modified cases of Silsoe7b and Silsoe7d (re-titled Silsoe7e & Silsoe7f) were successfully submitted and run on the remote server.

PHOENICS sells itself as ‘providing the design engineer with all the information that is needed, presenting a comprehensive insight, which aids imagination and promotes understanding’. Whilst allowing the expert to do this, the occasional CFD user may find that his work is easily flattered, producing results that appear to be realistic but are in fact wildly inaccurate.

On a positive note the often-complex task of setting up a calculation grid is removed. This considerably speeds up calculations and lets the engineer focus on the design problem in hand. However, coarse grids at critical locations have a tendency to mask information. The user must be able to easily refine the grid size to suit the problem. At present this is not available in Release 3.0.1.

The single largest problem may lie within the marketed target area of the software. In the hands of an expert the software is powerful, timesaving, and may well prove to be an extremely valuable office tool. However, PHOENICS 3.0.1 constantly requires engineering judgement to be applied. For example, each OBJECT must have a material type and 3-dimensional roughness selected for it. The engineer must also enter MODELLING & SOLUTION options. Whilst the selection of appropriate param eters is rewarded with success, wide of the mark choices potentially have a large implication on the results. In the hands of an inexperienced Architect or Engineer it is easy to see how this may lead to disaster.

The VR COMMANDER is not as user-friendly as it could be. There are several features that either mislead or frustrate the user. Careful re-programming would significantly improve the function of the CFD VR interface. Appendix 2 lists some of the most obvious shortcomings of PHOENICS 3.0.1.

When extracting the results from the VR VIEWER it is noticeable that pressure values taken on the surface of the building are considerably lower than expected. However, if the probe is moved slightly away from the building more realistic values are achieved. This makes the accurate determination of definitive pressure values difficult to achieve.

Other useful features that could be included in the package are the ability to vary the sensitivity of the variables so that the contour plots and vector plots are more usable. It would also be useful to define a given line/section across an object over which values of pressure could be displayed (i.e. the lines of pressure across the building shown in figures 2, 3 & 4).

The final feature is the incorporation of error messages for common faults (like the number of cells in the domain exceeds 100 000 and will not therefore be accessible using the VR VIEWER). This would save endless amounts of time spent searching for the cause of poor calculations or non-functionality of the VR interface.

8. Conclusions

A series of preliminary parametric calculations has been carried out using PHOENICS 3.0.1 with the new VR Editor virtual reality user interface. Such commercial CFD greatly simplify the task of setting up calculations and are, therefore, becoming increasingly popular with non-expert users.

The calculations have illustrated that for external turbulent flows around buildings this approach of simplification may lead to inaccurate flow predictions. One of the areas of greatest concern is grid generation. The sensitivity of flow predictions, particularly near building surfaces and edges, to grid density and geometry is well known. Near-wall velocity profiles, for example, are particularly sensitive to the height of the near wall cell. Unlike Flow-3D, Phoenics 3.0.1 does not use body fitted griding and does not give the user sufficient freedom to specify the grid to the required complexity, even through the use of NULL objects. This may be a dominant factor in the poor modelling of pressures in the separated flow regions across the building.

It would appear that for safety critical issues (e.g. design wind loading) the PHOENICS VR Interface is not currently developed enough to be used as a non-expert design tool. Whilst it satisfactorily predicts pressures in areas of attached flow it is found to poorly predict pressures in regions of separated flow. This is of considerable concern and in our opinion at present prevents this package from being used as a commercial design tool.

9. References

Osmond, S. D., (1997). (Personal communication). A CFD study of external building aerodynamics. Building Research Establishment, Watford, UK.

Robertson, A. P. & Glass, A. G., (1988). The Silsoe Structures Building-its design, instrumentation & research facilities. Divisional Note DN 1482, AFRC Institute of Engineering Research, Silsoe, UK.

Appendix 1

Appendix 2

MICA validation exercise - Phoenics 3.0.1 review

1. When using the Phoenics on-line information system (POLIS) it can be quite difficult to read the white dialogue on the light blue background. It would be better to darken the background or use a bolder colour for the text.
2. The descriptions given in the CHAM manual (page 28) of each of the special purpose programs (SPPs) appear to need some expanding to give an idea of the difference between them. Doing this can only benefit the user because he must be able to decide on which model best suits the problem and gives the best results. What are the differences between the models?
3. When running VR Viewer each of the control buttons (Streamlines/contours/grid display etc) once activated cannot be interrupted until the task has been completed. This can be time-consuming especially if a button is pressed by mistake.
4. As an aid to 3 above it would be useful if a ‘flagging’ system was available whereby each time a button is activated the user can clearly see which buttons have been turned on. i.e. a shadow around the button or change the colour of the writing/icon on the button once the button has been pressed.
5. In the modelling options display of the Domain box there are several decisions to be taken (material type and turbulence model). Even to a non-CFD user these decisions seem to carry a high degree of importance and yet there is no specific guidance, other than looking at library cases, on which to base a decision. Some form of guidance is required either in the user manual or within POLIS.
6. In VR Editor when you click on the New Object Icon the Object Dialogue box comes up. If you now cancel this operation you would expect the operation to be cancelled. However, a default object has been generated at the origin. This object if it is not required must then be deleted from the set-up. This operation is very clumsy.
7. When using VR library shapes, such as cylinders and wedges, there are several types of Generic shape to choose from. Other than using a trial and error solution to view these shapes there is no indication of what the specific types of shape are or when they are best used. One solution would be a quick view screen incorporated into the VR editor so that the shapes can be seen quickly and easily.
8. When rotating default objects from the geometry library it is difficult to know the precise location of the object (in terms of its coordinated origin) and in what orientation the object will appear. This is complicated by the fact that depending on which rotation is chosen the origin about which the rotation occurs seems to also change. This is very confusing even when trial cases are carried out.
9. Saving data appears to be long-winded and confusing. When exiting the VR Editor you are asked if you want to save the data. On replying yes you would think that the data would be saved under the appropriate project and case name overwriting previous work. However it does not do this until you ‘Save As’ in the File directory of the commander main menu. The intermediate save operation therefore seems redundant and unnecessary.
10. Also when using the Save As prompt there is no second check box that asks you whether you wish to overwrite existing work. This is a standard operation in many programmes.
11. A common fault when running EARTH is the failure to execute the programme due to errors in the .exe files. This appears to be due to the size of the default grid that is selected. The calculations appear to be too large for the computer to handle. Running at a satellite workstation will cure this. However, instead of error messages flashing up during locally run calculations, often quite near to the end of the calculation run, it would be better to simply inform the user at an early stage that the parameters are out of the range for the computer. This will ultimately save considerable time, effort and annoyance.
12. The manual input of all data is time consuming. If there was an interface available to import data from say an excel spreadsheet this would prove a useful function and save considerable time.

Fig.

Figure 2 Pressure Coefficients along line 0.46 m from centre-line

Fig.

Figure 3 Pressure Coefficients along line 8.46 m from centre-line

Fig.

Figure 4 Pressure Coefficients along line 11.46 m from centre-line

Figure 6 Cross section of roof profile (PHOENICS VR model)

Figure 7 Layout for Silsoe8.q1 calculations

Fig.

Figure 8. Pressure contours in direction of wind flow (along centre-line; Silsoe 7)

Fig.

Figure 9. Pressure contours perpendicular to wind flow. (along centre-line; Silsoe 7)

Figure 10a Pressure coefficients along line 0.46m from centre-line

Figure 10b Pressure coefficients along line 8.46m from centre-line

Figure 10c Pressure coefficients along line 11.46m from centre-line

Fig.

Figure 11. Pressure contours in direction of wind flow (along centre-line; Silsoe7)

Fig.

Figure 12. Pressure contours in direction of wind flow (along centre-line; Silsoe7e)

Fig.

Figure 13. Pressure contours in direction of wind flow (along centre-line; Silsoe7f)

EXTERNAL AIRFLOWS - FREE STANDING WALLS

(Roger Harrison)

Test cases have been set up using the VR Editor of PHOENICS 3.1, to simulate a wind flow at 900 and 450 to a freestanding wall. These test cases were originally set up using PHOENICS 3.0 and have been updated using improved features in PHOENICS 3.1. The test cases are described below as well as general comments about the VR Commander, VR Editor and result viewing in the VR environment.

Problem specification in the VR environment

wall90a.q1

This is a .q1 file to simulate a wind flow at 900 to a freestanding wall. Figure 1 illustrates the geometry. The dimensions of the wall are 18 m long by 0.215 m wide by 2 m high. It is made up of nine sections, each 2 m long by 0.215 m wide by 2 m high. The wall has been set up as a BLOCKAGE with a timber flooring/wooden block material.

A series of 18 null objects each 1 m long by 0.2 m wide by 2 m high were situated around the wall to improve the resolution of the grid around the wall (see Figure 2).

A wind profile was established by an INLET object across the west domain boundary. The inlet was positioned 140 m upstream of the wall. The wind profile is described by a logarithmic law. The velocity is a function of the distance above ground according to the following formula.

Fig.

where U = wind speed (m s-1)

z = distance above ground (m)

z0 = ground roughness parameter (m)

h = reference(free-stream distance) above ground (m)

the subscripts z and h represent wind speed at a height z and h above ground respectively.

In this case the values of h, Uh and z0 have been defined as 22 m, 14.526 ms-1 and 0.01 m respectively.

The low domain boundary has been set up as a PLATE with a roughness of 10 mm.

The east and high domain boundaries have been set up as an OUTLET with zero pressure and ambient temperature characteristics.

Fig.

Figure 1 Geometry for wall90a.q1

Fig.

Figure 2 Wall geometry with array of null objects in the VR environment

wall90b.q1

This is a .q1 file identical to wall90a.q1 but with a gap within the wall. One section was 10 m long by 0.215 m wide by 2 m high, and the other section was 6m long by 0.215 m wide by 2 m high. There was a 2 m gap between each section. This would highlight the effect of a gap on the flow patterns produced.

wall45.q1

This is a .q1 file to simulate a wind flow at 450 to a freestanding wall. Figure 3

illustrates the geometry. The dimensions and characteristics of the wall were identical to those used in wall90a.q1.

A series of 18 null objects each 1 m long by 0.2 m wide by 2 m high were situated around the wall to improve the resolution of the grid around the wall as in wall90a.q1.

A wind profile was established by identical INLET objects across the west and south domain boundaries. The wind profile is described by the same logarithmic law used in wall90a.q1. In this case, positive velocity components in both in both the x and y directions were used with values of h, Uh and z0 defined as 22 m, 10.271 ms-1 and 0.01 m respectiv ely. The resultant wind component produced is at 450 to the wall with a velocity of 14.526 ms-1 at a height of 22 m.

The north, east and high domain boundaries have been set up as an OUTLET with zero pressure and ambient temperature characteristics.

The low domain boundary has been set up as a PLATE with a roughness of 10 mm.

Fig.

Figure 3 Geometry for wall45.q1

The VR Editor

The VR Editor is similar to the previous version and is easy to use. There are some improved features such as the definition of INLET profiles which can now be simply defined according to a uniform, logarithmic or power law. The previous version required an array of INLET objects to be created to achieve the required profile, which was much more time consuming. Other main comments are listed below.

It still seems necessary to save a file from the VR Commander after exiting from the VR Editor from which a save command had already been completed. There should be another request to save the data before exiting from the VR Commander (or loading another case) to ensure that any edits are not lost.

When the VR Editor and VR Commander windows are activated after previously being minimised, the screen resolution within the window is such that the screen often appears to be empty, this can usually be resolved by double clicking the mouse within the window.

It does not seem possible to set the roughness for each surface of a BLOCKAGE.

There is an inconsistency in the units when assigning a roughness. When assigning a roughness height in an INLET profile the units are in metres, however, when assigning a roughness height to a PLATE the units are in millimetres. Perhaps the units of roughness height should be consistent to avoid confusion.

Data conversion to PHOENICS input format

It was necessary to modify the .q1 files before job submission to enable a plausible result to be obtained. Extra coding was needed at the end of the .q1 file to initialise the velocity components used in the INLET wind profiles in addition to the relaxation values.

It was also necessary to include an array of null objects around the wall to improve the resolution of the grid to ensure that the solution converged.

CFD Simulation

Once convergence of the cases described above were obtained, plausible airflow patterns around the freestanding walls for each test cases were obtained. These air flow patterns are shown in the following figures.

Fig.

Figure 4 Velocity vectors for a horizontal slice in wall90a.q1

Fig.

Figure 5 Pressure contour for a horizontal slice in wall90a.q1

Fig.

Figure 6 Velocity vectors for a horizontal slice in wall90b.q1

Fig.

Figure 7 Pressure contour for a horizontal slice in wall90b.q1

Fig.

Figure 8 Velocity vectors for a horizontal slice in wall45.q1

Fig.

Figure 9 Pressure contour for a horizontal slice in wall45.q1

Figures 4, 6 and 8 show that the magnitude and direction of the airflow patterns in each test case are plausible. The re-circulation of flow on the leeward side of the wall is highlighted in Figures 4 and 6 for an airflow at 900 to a free standing wall as expected. This behaviour is also shown in Figure 8 when the air flow is at 450 to the wall, however, the re-circulation is more pronounced at the end of the wall nearest the north domain boundary.

Figures 5, 7 and 9 show that the pressure contours produced for each test case are also plausible, with the general characteristic of high pressure on the windward side of the wall and low pressure on the leeward side. Figure 5 shows that for test case wall90a.q1 the pressure contour produced is reasonably symmetric, with two areas of low pressure at each end of the wall on the leeward side. This is also shown in Figure 7, however, the presence of the gap within the wall is also hi ghlighted in this pressure contour. Figure 9 shows that areas of high and low pressure occur at one end of the wall on the windward and leeward sides respectively due to the wind being at 450 to the wall..

Data retrieval

The data retrieved was always of the nature and format requested in this case. The results were returned reasonably speedily after the job had been sent.

Result viewing

The speed of result viewing was often very slow, especially when changing the viewpoint within the VR environment. The speed was particularly slow when velocity vectors or pressure contours were activated within the VR Viewer.

Changing the position of the probe in the VR Viewer was also very slow at times. It would be useful if a dialogue box could be activated to re-position the probe by inputting new co-ordinates (rounded to the nearest cell), instead of using the arrows in the VR Viewer.