好色先生TV

鈥淩ubbish in, rubbish out鈥� is a phrase referring to the inaccurate results that a computer will generate when equally inaccurate data is entered. In building performance terms it could mean predicted energy use is wildly different from actual energy use so it is critical to get it right. But what is the scale, scope and cause of this type of error?

I have personally been using computer software to design and simulate the performance of building services for nearly 35 years. Having trained many people how to use thermal analysis software I have seen many errors in input data. Sometimes it is due to a lack of engineering understanding and other times it is 鈥渏ust a mistake鈥�.

Where does input go wrong?

The trouble with the growth in internet use and easily accessible data is a lack of clarity over the accuracy of the data being used. One problem I have seen many times is with the units of a quantity. It could be that information is needed for a U-value in W/m²K is reported in W/ft²F, a different unit. The software may require pressure to be entered in Bar but the user inputs this in PSI. The combination of inputting inaccurate data using the wrong units produces vast errors.

Just last week I went to a meeting in London where the location鈥檚 dimensions were printed on their official documentation in millimetres rather than centimetres

Then there are the simple typing errors that aren鈥檛 picked up. When writing computer software, there is always a requirement to make the inputting of data easy. This can lead to default values being used or help systems within the program that provides 鈥渢ypical鈥� values. Many users don鈥檛 change these defaults for the actual data - it is really amazes me how many buildings have been analysed using default or typical input data, again this leads to inaccurate predictions of performance.

A building鈥檚 floor area or volume of a space must be one of the easiest values to ascertain, but how often is this value entered incorrectly? In my view, good software will always have error and warning limits to indicate a value that is just not acceptable; while also containing additional warnings that flag if an input parameter is on the small or large side. Inbuilt data checking in my view is vital for good quality software. Good help facilities can also reduce inaccurate values being used.

When we are in a hurry to get data into software it is easy to make the simplest of typing mistakes. Just last week I went to a meeting in London where the location鈥檚 dimensions were printed on their official documentation in millimetres rather than centimetres. This was wrong 鈥� the official version of the room size was a tenth of the actual size. This is an easy mistake to make!

Interrogation of the output results from the software should also enable easy checking and this should also indicate if the results contain very high or low values when compared with typical benchmark values.

In conclusion, you should always review your input data and get a second person to check them as well. We all need to treat the results from software with care and check that the values are sensible otherwise we risk being blamed for a badly performing building just because a slip on the keyboard.