Hand Calculations

Hand Calculations – How To and How Not To – Rev 2

File: PVE-3285, Last Updated: Sept 15, 2016, LRB

At PVEng we use hand calculations when we do not have a program or spreadsheet or when we want to create a spreadsheet and need verification. Hand calculations are respected more than programs for audits or code submission but in my opinion, they are much more likely to be wrong.

The ideas presented here are designed to reduce the most common causes of hand calculation problems:

• Sources not referenced and therefore not checkable
• Calculations not showing intermediate steps – how was the final number reached
• Inputs not explained
• Units not shown and wrong (ft vs inches etc.)
• Results not double checked (numerical mistakes)
• Results not presentable
• Results not reviewed

It is interesting to note that this is the same list of issues when reviewing computer programs or spreadsheets.  The illustration of the person falling through a trap door in the scans below is taken from the book “Code Complete” by Steve McConnell, a very useful guide to writing better software in less time with fewer errors.  In his book the person falling through a trapdoor represents coding horrors – things to avoid.  It is used here for the same meaning.

Show References

Without references it is not possible to check if the equations are sourced right.

The correct equation is t = PR/(2SE+0.4P) not as shown above. With the references listed it is possible to go back and find this copying problem.

Show Intermediate Steps

The illustrated intermediate step allows the reviewer to see what numbers were used for the variables. It is not possible to check what is not known.

Where Do the Numbers Come From?

How was the first answer calculated? What values were used for P,R,S and E and why is the first answer wrong?

Here we are assuming that the reader/reviewer understands what P, R, S and E mean, probably a good assumption. However, it would be a better assumption if the reference for the equation was included. There is no reason to provide further explanation for something that is easily looked up.

Include Units!

The equation should read specific gravity, not density. Without the units, it is not verifiable.

Also Consider

• Double check your calculations! Running the numbers through your calculator one more time can reduce surprises.
• Work in pencil.  You are human, fix your mistakes.
• Add a sketch or copy an illustration.  Illustrations copied from code books can be very useful.
• Get someone else to review your calculations.
• Use proper paper.

Simple hand calculations on appropriate paper ready for review.

Computer Programs

These requirements are also very applicable to computer program report and user interface design.  Meeting the requirements of the above check list does not guarantee a good program but it is a good starting point.

This commercial program produces results that are very hard to review, but they meet almost all of the above requirements for hand calculations.

• Sources are referenced.  If in doubt Appendix 1-4(c) can be looked up and reviewed. There is no need to add more detail. However, if the user reviews Appendix 1-4(c) they will find that the equation has been changed from the code (2*S*E*t)/(K*D+0.2*t).  This change allows the program to calculate based on the OD instead of ID which is convenient for the user. However, where code equations are referenced, they need to be used! Another line calculating the ID from the Do and the t would have removed this confusion.
• Intermediate steps are shown. The first line shows the full equation, the second the substituted values, the third the results. If the results are not what you need you can review the inputs and decide which ones you need to change.
• Most inputs are explained, but unfortunately, the explanation is found ten pages earlier where the user inputs are echoed. Other inputs magically change from descriptive to variable form – for example “Element Thickness” magically becomes “t”.
• Units are provided.
• Results checked – here the computer results have a clear edge. Once you know the program is working, the users checking is limited to review of the inputs vs the source material and results vs required outcomes. Most computer programs give a detailed list of all errors generated. There is no need to do any intermediate checking on the computers math which the computer can do much more accurately than a human.
• Results are presentable but not optimal – here the user has to review the inputs and results from two different sections of the report.

The idea of a computer program or spreadsheet is that it gets written once and used many times.  Following a simple checklist of requirements only gets you part way there.  Extensive study of how a user interacts with your program, and how they make mistakes using the results is required to refine a program. Unfortunately this step is seldom done.

Here is the same calculation in spreadsheet form based on years of observing how people make mistakes using these code rules.

Effort has been put into this spreadsheet to reduce user errors.  The inputs are logically grouped and the inputs and outputs easy to review.  The spreadsheet checks that the users goal has been met.  Basing the input on the outside diameter instead of the inside diameter is easier for the user to visualize, especially when the head and shell end up at different thicknesses.  The outside diameter (Do) is translated to an inside diameter (D) as an intermediate step, allowing the code equation to be used without modification.

Downloads:

• Calculation Paper Form (pdf format)
• Calculation Paper Form (Excel format)