As mentioned in a previous post, Engineering Equation Solver (EES, pronounced ‘ease’) is one of the most useful tools in my toolbox. Let’s describe in more detail how access to this tool changes the way you think about solving engineering calculations and how systems behave. For several reasons, this software is my ‘secret weapon’ at work, and I think engineers that don’t have access to something like this, or have never learned to think in a way that users of it can, are at a bit of a disadvantage. We should move more people to the ‘enhanced capabilities’ camp if we can. Here are advantages to consider, if you haven’t picked up capabilities with EES through your education or work already.

A Badger Product

First, the briefest of primers

The method EES uses to solve engineering calculations is different than how you might approach by hand or with a calculator. Envision that you are faced with the simple task of determining the value of x from the system of equations below:

x=1

You cry out “this is trivial; the value of x is 1”. You could confirm this with your calculator, I suppose. Press ‘1’, press ‘=’. So in the EES mind, what would happen instead (to reach this same conclusion), is that the program would consider the following:

  1. How many equations are we dealing with here? (1)
  2. How many variables are we dealing with here? (1)
  3. Conclusion – this set of equations and variables appears solvable, since the quantities of each are matched.
  4. EES sets up some sort of complex matrices in the background that I can’t pretend to understand.
  5. EES assumes a ‘guess value’ for each variable as a starting point to search for legitimate solutions.
  6. EES carries out this matrix algebra and provides the answer. (x=1)

One (let’s call him Direct Dan) might review this complicated list and snort “that’s a lot of work for such a simple solution”. Perhaps. But let’s consider another example.

x²=1

Direct Dan might tap in ‘1’ and ‘square root’ on his calculator (as I did), and get the result 1, write it down, and declare “problem solved”.

Another (Indirect Ida) might set up the equation in EES, tap the F2 key to solve the set of (single) equation, and get the same result; 1.

Where you end often depends on where you start – developing your intuition

Direct Dan may not be known for deep, pensive thought on the structure of mathematics. He is content with getting a solution and walking away.

Indirect Ida had to go through more steps, consciously or unconsciously, to formuate her query. She had to recognize that the multistep process described above had to be followed, where the number of equations and variables must be matched. She had to recognize that the methodology relies on initial guess values to carry out its ‘search’ for solutions.

If Indirect Ida is so inclined, she might have suspected that this simple equation set is not one with a single solution. If she feels that there is another valid solution that may lie in another area, perhaps she steers the initial ‘guess values’ within EES in that direction (say, negative numbers), and then is able to calculate another potential solution: -1, that is equally legitimate. Thus she is discovering something about the process of solving systems of equations, and the nature of this particular one, that Direct Dan may overlook.

For systems that must be described by combinations of hundreds or more equations, it can often cause problems with EES if the standard guess value of 1 is used for every parameter, though that is a useful default, if it works. Thus, it frequently helps convergence of EES if guess values for variables (‘independent’ or ‘dependent’), or bounds on them, are set to more realistic values. The engineer must be armed with more of an intuitive expectation, and this hones our skills to anticipate these reasonable regions for our solutions. For example, EES, if not given better direction, might search over the entire – to + infinity space to solve for an isentropic turbine efficiency, or dry bulb temperature. That’s silly, you say: we know turbine efficiency is bounded by 0 to 1, and ambient temperature by perhaps -60 to +60 C (giving oneself considerable margins). So set those bounds and/or a reasonable guess in the midpoint. The act of assigning reasonable values means the engineer is not a blind calculator, but rather interpreting and anticipating each variable.

Implicit versus Explicit Perspectives

The traditional, fundamental approach to equation solving is to formulate the parameter you wish to calculate (say, kW output of a power plant) cleanly in terms of all the independent variables that influence it (resource conditions, equipment parameters and efficiencies, environmental conditions, etc). To do this may take a great deal of effort to manipulate every equation so it is solvable in an explicit formula. For example, take the following equation by Colebrook for determining the friction factor of pipe (f) as a function of relative roughness (e/D), if the latter is known.

Solve away, Dan

Direct Dan looks at that and scratches his head for a while, then gets a drink. Indirect Ida recognizes that this can be set up simply enough – she has two equations and two variables, if separately she assigns e/D as a parameter and gives its value. It doesn’t matter to her or EES if they are organized with the variable to be solved for (f) isolated on one side, in some artificial restructuring, or whether it appears on both sides. She types in two equations, solves, and moves on.

Thus, Indirect Ida can write equations in a recognizable format without restructuring them for the particular variable she needs to solve for, and can toggle between studies of equation sets far faster than Direct Dan. Sometimes she wants to know kW output as a function of ambient temperature – so set the latter, and solve for the former. Perhaps then she wants to know what ambient temperature corresponds to a specific kW output – she switches which is set, without rearranging the equations. She understands that depending on the nature of the design, parameters may need to be viewed as independent or dependent depending on the questions, and the equations she writes can be explicit or implicit – it doesn’t matter, if properly structured. She has a better vision of the interrelationships of the system of equations, rather than fighting each every time a different question must be asked of the model.

Properties in a Can

EES has a sizeable library of fluids and properties available built-in. While someone with Excel can tie in other program such as WinSteam or Refprop, it’s a bit more complicated, and may require multiple licenses. To a student, it means that after you understand well the method of determining physical properties (and indeed, this is something that one should spend a good deal of time on), then after that one can dispense with tasks like interpolation and spend more time on more complex analysis. For a professional armed with EES, Ida can be in a sweaty jungle somewhere, and still be able to access a psychrometric function, or determine the viscosity of a  refrigerant, without tables from textbooks, reference handbooks, or even access to the Internet. While this feature may not profoundly change how you think about solving problems, having built-in properties and functions is handy.

Don’t Trust the Experts

It is frequent in engineering companies to use fairly complex (and costly) software to model piping, equipment, and systems: thermodynamic performance, piping stress, electrical circuits, steel design. These often have graphical user interfaces (GUI) with drop-in, prebuilt modules that simulate the performance of equipment like pumps, exchangers, transformers, etc. When used properly, they allow more complex analysis to be performed more swiftly, precisely and accurately than hand, Excel, Mathcad, or even EES methodologies.

 – However –

In my experience, placing complex tools in the hands of young engineers, while they have a certain ‘WOW/FUN’ factor, is more often a way to generate errors rapidly. One gains a more fundamental understanding of the behavior of complex systems by building up your own systems of equations – in Excel or EES – slowly and painfully, and by understanding how each property is determined, how each piece of equipment behaves. In EES, you are forced to see and formulate properly the cloud of equations. If there are errors, you are forced to troubleshoot your formulations. All too often young engineers such as Direct Dan handed a complex tool drag a bunch of icons together, connect them with some lines, hit the solve key, get an error, and then are frustrated with ‘the program’. If they had worked through that type of problem once before, using a tool like Excel or EES, they would understand the steps better; what key inputs are required, what relationships are important.

Even if he does get a solution, Direct Dan all too often proudly present the set of results unquestioningly, which X% of the time are garbage (errant would be the polite term), because they don’t reflect a physical reality. Indirect Ida, who has previously proceeded through all the thorough steps of modeling a system, and understands what reasonable values are for intermediate parameters, can better understand how the system  should behave and what the results should be. Perhaps the EES model is not as comprehensive, or describe complex equipment or fluid combinations perfectly, as the GUI software package with the $20,000/year license fee might. Even in that case, Ida understands the behavior and limitations of the system of equations, and can still anticipate the region in which the true solution should fall, if not the precise answer.

One can over years, accumulate a ‘reference library’ of key EES (or Excel) models that describe commonly encountered scenarios. When reviewing the work of other modelers using different tools, help them out by tuning and running your (perhaps more simplistic) models in parallel as a cross check using another methodology.

Many people perceive that checking others’ work is a form of unwelcome critique or that it is a matter of trust or mistrust (“I don’t need to check that Dan, I trust you”). Checking work is an essential service and a form of protection for that person, your company, and your client. Using methods different from the primary means of calculation are a way to detect blind spots in the modeler or program. Leveraging software such as EES/Excel with prebuild models from your experience as comparison are a way to cost-effectively help people out, and deliver a higher quality product.

Summary

I’ve been using EES for over thirty years, and find it is as useful as any engineering tool I’ve come across. Many universities use it in their curriculums or for research projects, and I feel bad for engineers who come out of school without having had the opportunity to learn it, especially those in the process/thermodynamics field.

Can you be a success never having touched EES? Certainly. Is it essential for all fields, and can it give perfect answers for all system models? Certainly not. Might you have a particular advantage over others, having a flexible tool in your pocket, having a better understanding about how sets of equations to describe a system must be set up from first principles, and gaining a better intuitive feel for system behavior and anticipated results? Absolutely.

For this reason, I use EES at my work as my ‘secret weapon’ to perform side calculations or check work, and encourage people to get experience in using it, if they are at an organization that provides access. I wish it were more widespread, and try not to be a zealot about pushing everyone to use it. But if building a library of applications with EES would be useful in your line of work, and you get the opportunity to learn about this tool, consider seizing it.