Style and Detail in Design Calculations? 1

[Amphoteric]

At work I get passed around to different bosses and even departments, and one point of contention is the "calculation record" - also called a design brief or design calculation. Datasheets and technical drawings have a really defined structure, but calc. records do not. It seems that everyone has their own opinions on how to do it right! How much information and explanation put down, how much to reference, and so forth.

Put down too little, and you're confusing. Put down too much, and you're wasting everyone's time.

Please discuss: What is your personal "style" or "philosophy" when it comes to writing design briefs?

I wrote some questions for consideration (you don't have to answer them, they're just thought-stimulator's):

1) Who is the target audience? Do you write as if you'll be hit by a train tomorrow, and new-hire-Tim has to pick up your calculation? Or do you write the bare minimum to save time for you, and the person checking your work?

2) How do you show the development of your work? Do you write equations symbolically, define and reference the terms, and show all the gory detail? Or do you write a quick blurb on what you're doing and program the equations into Excel?

3) If someone tells you a number, do you reference the person by name? Some people say that's offensive: that you should "Company ABC said..." instead of "Joe said..."

4) If something is a "rule of thumb" or a number "based on my experience" do you reference it?

5) If you are using third-party software (e.g. simulators, CFD tools, etc.) how do you do the brief? How do you keep track of the what/why of your inputs? How do you make sure your results are valid?

6) How is checking done at your office, and to what level of detail? Is it done properly or does it fall by the wayside?

7) How do you like to check work, your own or someone else's? Do you go over everything with a fine toothed comb, or do you eyeball the numbers, or do the calc a second way and see if the results match?


I realize that the answers all depend on the complexity/novelity/stage of the design cycle you're in.

Thanks in advance.

 

[gwynn]

1) Who is the target audience? Do you write as if you'll be hit by a train tomorrow, and new-hire-Tim has to pick up your calculation? Or do you write the bare minimum to save time for you, and the person checking your work?

I write for someone with slightly lesser ability than myself. The new hire will not be checking my (or really anyone's) work.

2) How do you show the development of your work? Do you write equations symbolically, define and reference the terms, and show all the gory detail? Or do you write a quick blurb on what you're doing and program the equations into Excel?

I write out any equation the first time I use it for any division of a project. I define any terms that may not be commonly used (not what fy or f'c stand for). If I use a spreadsheet I include sample calculations showing exactly what the spreadsheet is doing. I think this is a must as it should also catch most errors in the spreadsheet.

3) If someone tells you a number, do you reference the person by name? Some people say that's offensive: that you should "Company ABC said..." instead of "Joe said..."

Most numbers from third parties come in a report or at least written form. Either comes with a file name and number. I will reference the company, file name and file number.

4) If something is a "rule of thumb" or a number "based on my experience" do you reference it?

Rules of thumb are generally used in preliminary design and the results are verified by design checks later on. I do not justify or reference rules of thumb, as I subsequently show the results are correct in my design checks.

5) If you are using third-party software (e.g. simulators, CFD tools, etc.) how do you do the brief? How do you keep track of the what/why of your inputs? How do you make sure your results are valid?

a) Not sure what you mean
b) By writing the reasons down as input is entered
c) By checking results by hand. At a bare minimum, checking critical members and those which are readily solved by statics.

6) How is checking done at your office, and to what level of detail? Is it done properly or does it fall by the wayside?

It depends on the checker and the project being checked. Anything out of the ordinary or complex is checked number by number.

7) How do you like to check work, your own or someone else's? Do you go over everything with a fine toothed comb, or do you eyeball the numbers, or do the calc a second way and see if the results match?

For something complex or out of my ordinary expertise, I will come up with a different method of analysing the structure (if possible). This eliminates the issue of thinking your own mistakes are correct because the numbers look similar to the original ones. Something simple will mean either a number check or eyeball if it's something I do often.

 

[MikeHalloran]

I've worked in only a few places that had anyone else who would know what to do with such records, and no place that required them.

But I generated records anyway, so I wouldn't be relying completely on my memory.

In days of yore, I'd write it down with sketches and units on paper, complete but not usually neat. (This was before calculators).

Now I use Excel for calculations, with a column for numbers, a column for units, a column for symbols, and a column for explanations. I try not to do more than two or three operations in a cell, so there may be many rows of intermediate values, typically at least one for each term in a polynomial.

I'm not real religious about recording sources for information, unless it came from a book I don't own. I rarely put much effort into formatting a spreadsheet, except to structure it so that alternatives can be considered by copying columns.
Rules of thumb are usually marked as such.

I usually keep a chron file in Notepad that may refer to various spreadsheets.

At one place, I went so far as to document how the spreadsheets I wrote worked, and where the equations and constants came from. A lot of my work there involved learning 'lore' from long time tradesmen and reverse- engineering it to find the science underneath, then using the science to optimize the product.

The records I left behind comprised a pretty good start on a small textbook dedicated to that particular business. I'm sure my successor appreciated it.

It wasn't complete because I didn't plan on having a successor anytime soon.







Mike Halloran
Pembroke Pines, FL, USA

 

[GregLocock]

If I'm doing a job where the calculation is the important thing then I'll annotate and reference to the extent that I could repeat the work very quickly, or someone equally skilled could check it.

If I'm working in a new area then I'll add more annotation so that I know exactly what I did and why. I'll also do that if I'm trying to get someone to do a similar analysis, or if I'm trying to persuade them to build something a bit odd.

However most of my work is building computer models, so quite simply we just archive them in toto.




Cheers

Greg Locock

SIGlease see FAQ731-376 for tips on how to make the best use of Eng-Tips.

 

[corus]

Like Greg, when it comes to calculations I always include the references and formulas so the work can be repeated, or checked. I've found that keeping the full formula in the calculation is important as I was told that one manager had exclaimed that with the number of brackets and square roots I had included showed it must be correct! You have to laugh.

For modelling work though I have a little piece of home made software that summarizes and prints out the important pieces of the input data so I have a physical record of it, and a physical record that I've checked it.

corus

 

[IRstuff]

Not necessarily pushing Mathcad, but PTC has been making a big deal of provenance, i.e., where do the numbers come from. Each and every input, ideally, should show traceability to datasheet or specified values, including units. Each equation should be annotated as to the source. Empirical equations that do not use units should be carefully documented to ensure that future users will get the same answers.

One additional plus of programs like Mathcad is its ability to mix units within numerical calculations, thus allowing lb-force*micrometer to result in 4.45 uJ without doing any off-line conversions. This also allows empircal equations to use unitized inputs and still get meaningful results when a different unit system is used.

Finally, ideally, your calculation tools should be all live, thus allowing someone later on to simply run the worksheet to get the same ansqwers. Dead copies like PDF require transcription, and disencourages people from using the original calculations. They wind up entering their own calculations, opening the possibility of entry and calculation errors. The downside, of course, is that you have to keep the calculation tool running in perpetuity.

TTFN

FAQ731-376

 

[abusementpark]

I mainly think about the person I know will be checking it. I also TRY to reference this that aren't very apparent. However, i think there is a fine line between neat,organized calcs and inefficient calcs.

 

[msquared48]

I try to lay out the calcs for the plans checker. He is the one that has to approve and understand them, not the contractor or the owner. I served as a checker for a large jurisdiction for a short time, and was thouroughly confused by many of the presentations, having to ask for further clarification through phone calls or written channels which delays the construction process.

In particular, I include copies of the plans in the calcs as a reference as to what I am looking at and my methodology. Plus, it assures the checker that the plans you analyzed as the structural engineer are the ones that were submitted for approval. I have seen the reverse happen in other offices where the plan reverences were not included.

Mike McCann
McCann Engineering

 

[MikeHalloran]

I tried MathCad a couple of times. Went through the tutorial, more than once, but then couldn't remember how to drive it the next day.

Later, I took it home to do some important stuff over the weekend, then remembered I didn't have a math coprocessor. The only one I could find at retail on a weekend was a non-Intel version, and MathCad didn't like it.

Actually, "didn't like it", considerably understates the case. It never complained about the coprocessor; it just crashed, badly, and took out a lot of other stuff with it. Software like that I don't need.

I wasn't so pissed about it needing a 387, or even a _particular_ 387, but I _was_ pissed about it not failing gracefully.

Still later, I followed Jack Crenshaw's love/hate relationship with successive releases. Software like that I don't need.

One other thing. MathCad would have been a much easier sell as a productivity booster if the Solution Pacs were cheap or free. I think the a la carte pricing was a major marketing blunder.

If I have to set up the problems or templates myself, why bother with MathCad? Excel or OOCalc is widely available, and mostly works.



Mike Halloran
Pembroke Pines, FL, USA

 

[GregLocock]

I agree with IRstuff, mathcad is great for producing traceable neat calculations. But, my upgrade path for MathCad stopped many versions back, and I remember the 387 debacle.

The advantage is that all the formulae are out there in the open, ready to be checked, in a syntax that most engineers would recognise.

Matlab also has much the same virtue, although it is a lot uglier to look at, and the syntax can be impenetrable to anyone who is not used to it. If matlab is too pricy try Scilab.

Personally, although I use Excel a lot I would be scared that one cell could contain some sneaky logic or bad logic that doesn't get caught in a standard test case.



Cheers

Greg Locock

SIGlease see FAQ731-376 for tips on how to make the best use of Eng-Tips.

 

[IRstuff]

I didn't get Mathcad until M4, which I think was past the incidents you refer to. For many people, M11, or even M6, is as far as they need to go. One of the biggest problems is that the newer the version, the slower the basic mathematical operations get.

ExcelCalcs supposedly will generate mathematically readable equations:

http://www.excelcalcs.com/,

so Excel might still be an option. If Excel had a Mathcad GUI and handled units, that would pretty much end it for Mathcad. The installed base of Excel is much larger and the file formats are more stable than Mathcad's.

TTFN

FAQ731-376

 

[Twoballcane]

“Datasheets and technical drawings have a really defined structure, but calc. records do not. It seems that everyone has their own opinions on how to do it right! How much information and explanation put down, how much to reference, and so forth.

Put down too little, and you're confusing. Put down too much, and you're wasting everyone's time.”

All of my analysis starts with hand calcs and then I go to a FEA software to verify and make pretty pictures for the report. I do make JPEGs of my hand calcs with my rational and references (laid out nice and neat) and add it to the report as an addendum. In the report I just mention how I did the calcs and finale answer with pics of FEA plots and then reference the addendum if need be. So that management will just get the answer and the engineers has the calcs at the end of the report for their inspection.

Our work will get a sanity check by a person at the next level up.

IMO you should keep your design and analysis report stream lined as in try not to make it a science project. You don’t want to make a book about your findings or design. All you want to do is get past your critical design review to a prototype and test stage, because all of your analysis will go out the door if you don’t correlate with test data.


Tobalcane
"If you avoid failure, you also avoid success."

 

[pierdesign]

I used to review calculations and reports at a large engineering company.

The first thing I always looked for was a purpose; ideally a one sentence explanation.

The second thing I always looked for was a conclusion that accurately answered the purpose.

Of 70 or 80 calculations and reports I reviewed about 3 or 4 met these criteria, all from the same engineer. It got so bad I would review with the engineer asking him to read the purpose, or make it up if it wasn't written there, then read the conclusion / results / summary, if it was actually written there, and then ask him to explain how it went so out of focus.

Other things you ask about were fairly standard procedure: list all formulas, with descriptions of each operator, and source, CAD programs, etc.

 

[Gymmeh]

Oddly enough I go way back to my basic Mechanical engineer 101 class in college.

I normally have a cover page with, Purpose, Known valves, governing equations, see pages 1-n for Calculations, conclusion.

for calculations which I frequently do or I know I will have to Iterate to find a value, I will make an excel file.

I assume the people reading my work will be just under my level, ie. BSME with some understanding of my industry.

Regards

 

[HgTX]

I got used to MathCad in school and then went to an office that didn't have it. Most people there used pencil and paper (in 2002).

I used string functions in Excel to generate what looked like a calculation line for each result cell I had in my sheet. So if I input length 2 and width 3, next to the cell showing area as 6 there was a string "2x3". This gets very ugly with complex formulae, but it made it a lot easier for me to follow my own spreadsheet and for a printout of it to mean anything to anyone else.

Hg

Eng-Tips policies: faq731-376

 

[whyun]

When I perform any calculations, whether by hand or using computer tools, I demonstrate my thought process (with code references, sketches, bried summary of intent of each calc section) such that when I get back to those calculations years down the road, I will be able to remember what I did. It takes a little extra effort up front, but in the long run, it may save a lot more.

In addition to potentially saving my time in the future, it makes it easier for the plan reviewers and any other engineers in the future who may take over future design changes, etc.

Oh... I also put units when possible, or where not having one may create an ambiguity.

 

[SylvestreW]

1) Typically most of our stuff has to done via known standard so I provide the known values. For things not standardized, I'll usually provide final equations (and some explanation as to why I used that eqn) and the input.

2) Rarely do I derive anything at all. I'll at most explain why I chose one method over another but that's about it. I almost always write a sample calculation down.

3) That I go into gory detail in, but only because I'm covering my back. I'll include the note or email or letter etc. in the appendix of the report

4) Don't use that jargon at all; everything's referenced regardless.

5) Input table (e.g. FEA would be just material properties, drawings & dimensions) and output would be results. In the report I'd only state the input/output of the final run, not the intermediates. In other words, I put enough there for someone to know my results are accurate, but not to re-build my model from scratch.

6 & 7) Detail unfortunately depends on the reviewer, and ppl vary. Personally I re-calc almost everything, check the governing assumptions and use a bit of common sense to see if the answer is right.



-
Syl.

 

[cvg]

I think it also comes down to "industry standard" each industry and field has different standards and so does each firm and office. Best to stick relatively close to what the expected standard is for your industry and your firm. However I agree with many that for calcs to be useful, you need to be able to read and understand them now and maybe 5 years from now. Others may also need to understand them. If you ever get dragged into court, the attorneys need to understand them. So clarity, simplicity, logical presentation and listing appropriate references are all essential.

 

[rtmote]

It is an ongoing and critical issue within the structural engineering profession, so I am keen to hear of your well-founded frustrations.

Over the years the standards of calculations and records has fallen by the wayside. Engineers have delegated the responsibility for quality to third party applications such as MAthCAD and STAADpro.

I agree with everything MikeHalloran says, he's on my wavelength. I use Excel heavily and concatenation to show the numbers. The calculations serves several purpose throughout its lifetime.

I benchmark the progress. In the first place, the engineer sketches the concept(10% completion), create and formalise a basis for design that is approved, before proceeding(25% completion). The structural model is built and reported (50% completion). The calculation is then checked (75% completion), backdrafting to finalise the calculation (90%). When the drawings are issued, minor design changes are reported on a single page summary at the end of the job (100% completion).

The calculation always serves to educate and help the checker prove conformance to client specifications.

Engineers fall into two camps. One camp believes the calculation should be exhaustive, accurate, detailed and mirror the final design faithfully. This leads to voluminous calculations and time-consuming checking. I call this the quantitative approach. This seems typical of the mainstream engineers, probably 90%.

The second camp is the calculation is a minimum basis for design, reasonable, practicable and measures the final design against the original assumptions. I call this the qualitative approach. It is one that I advocate.

I have been writing and checking calculations forever and I am constantly amazed by the lack of thinking engineers disply in their calculations.

Push for the highest standard wherever you can.

Robert Mote

http://www.motagg.com

 

[Twoballcane]

I kinda agree with you Robert. But I think it depends on the cost for both human and money. If the project is the shuttle for NASA for example, up front analysis and design are pretty intense. However, if your talking about a DVD player in your house, you can almost design it on the back of an envelope and then send it off to manufacturing.

Tobalcane
"If you avoid failure, you also avoid success."