Software & Hand calculations 2

[Lijantropo]

Good morning,

When I was at the university, I always heard about the use of simulators as a method to verify hand calculations. Now, in my job, I see that hand calculations are used to verify the simulators.

What do you think about it? Which do you believe must be the first step in the design process?

Bye,
Lij.

 

[SNORGY]

Lijantropo:

I am currently heading up an effort to verify a lot of our in-house design tools, mostly EXCEL-based. For small software applications such as those, it is my opinion that you first perform a hand calculation and then build the tool to verify it. In other words, once having done the manual calculation correctly, the software tool is verified if it produces the same result. More correctly, the software tool is verified if it produces the same results as a series of manual calculations that cover a spectrum of scenarios and inputs.

For larger, more complicated software applications (say commercial software such as HYSIS, CII, etc.) the reverse approach is true. Run the simulator and then use hand calculations to check the results. For example, if a sustained load case without thermal expansion effects in CII outputs a mid-span pipe deflection of 4 mm, then a hand calculation should confirm that wL^4/384EI <= 4 mm <= 5wL^4/384EI. Similarly, the axial displacement computed at some point 50 metres away from a line stop should agree closely with what a*L*(T2-T1) would give you, as long as restraints and friction are handled the same way.

Most commercial simulators are proven to the point where the only verification required is the input (correct units, etc.).

Regards,

SNORGY.

 

[zdas04]

We don't confirm the spacing of the marks on a ruler before every use, we just use it.

When I get a new piece of software, I build a case (or model) that is simple enough to solve by hand and if the software doesn't match the hand calculation (and I can get certain of my hand calculation) then I reject the software out of hand. If the simple case passes, then I build a real-world case where I know the answer (for example a pipeline model generally has source-node flow rate as an input and pressure as an output, but both can be measured in the field) and see if the software can predict the known values with reasonable accuracy. If it can do this calibration successfully then I will rely on the software without checking distance between the marks every time.

So, back to the OP's basic question--I think the idea of using something like HySys or PipePhase to verify hand calculations is laughable. There are far too many independent inputs and equations embedded in the software to ever replicate with hand calculations (even using something like MathCad).

For example, last week I was doing a staged compression vs. centralized compression analysis in MathCad for a client. As a first approximation, I just assumed that the ratio of density at standard conditions to density are actual conditions was "close enough" for this project and I didn't recalculate density for each compression step. Then I lowered suction pressure 10% and saw the hp requirements went down (not possible). Had I not known the physics I would have looked like an idiot sending that result on. Then I went back and calculated actual density at every step and the results matched the physics. Had I been working with a green engineering pad, a slide rule, and a compressor wheel the cumulative error would have made the result nearly meaningless and I never would have known it.

David

 

[Lijantropo]

Well, I do not think that verify hand calculation with software like HySys is laughable. I mean, the idea here is to compare only KEY POINTS on the whole process.

You can select a really important factor(s) and use MathCad to get an answer, maybe using your experience to improve the results. Then, you use the software to confirm your outputs.

Lij.

 

[SNORGY]

We all trust CAESAR II, I assume...

I discovered recently something interesting that had somewhat of a domino effect throughout everything else we do around here. When inputting ASTM A-234 for elbows via the CII drop-down menu and running subsequent analyses, everything was fine. Then a change was made in the same piping to low temperature (ASTM A333-Grade 6 / ASTM A-420-WPL6) materials, whereupon it was discovered that the default materials database in CII does not include ASTM A-420-WPL6. The stress engineer input the appropriate values from ASME Section II Part A, and suddenly a warning message was produced in the CII runs that stated that the wall thicknesses were less than the minimum required by B31.3 Code. Hand calculations in accordance with the Code verified this to be true, so we looked into the differences between ASTM A-234-WPB and ASTM A-420-WPL6. Confused by the fact that we could not find a difference that would give rise to the error, we looked at the CII database for ASTM A-234. It turns out that the values therein are the higher ones for ASTM A-234-WPC, not ASTM A-234-WPB. So, of course, we reviewed all of our piping specifications - which for years have been written to specify ASTM A-234-WPB elbows - and discovered, sadly, that in a large number of cases they didn't meet the B31.3 Code minimum thickness for the design conditions listed. So, now we are specifying WPC where applicable and are trying to figure out the best way to deal with the WPL6 issue - which, also sadly, in a number of cases also leaves us short of Code requirements.

We are adding the specific materials to the CII database, as the software has provisions for us to do that, but for such common materials we just didn't expect to find this. So, sometimes indeed you really do need to carefully check even the best software.

Regards,

SNORGY.

 

[dcasto]

You may not do complete hand calculations on a Hysys et al simulation, but you better understand what you are inputting is real and what the simulator is saying real. There are some sytems that won't solve and you must understand the limits of tolerences in the program when you relax them.

If you call for a distillation column pressure and an overhead spec on that tower in a range that the overhead product is above it's critcle point, the tower should not converge, but every once in awhile it will. The simulator doesn't know that the thermosphyon reboiler you spec out has such a huge boil up rate that you can't find aphysical piece of equipment that will work without a 30 foot shirt or a 60" vapour line.

The simulator can't judge your effiencies of equipment you set and it's up to the operator to know just what those efficencies do. How do you know temperature approaches, does the exchanger have internal temperature crosses, is their a pump that can do 2000 feet of head with 200 gpm and is seal-less and achieve the 70% eff you inputted. All these are post output questions that require some "hand" work.

 

[PaoloPemi]

I work with gas compressors and I use Excel plus a tool for calculating gas properties, I think this is the best combination of accuracy, flexibility and direct control over all formulations, it's easy to understand when something is going wrong (a temperature, a pressure, condensate flow...). Nowadays there are several little software tools which extend Excel capabilities by providing fluid properties, phase equilibria etc. and it would be useful to consider this combination when solving little portions of plants (not speaking of columns here),
Paolo