I’ve been on the road a lot lately. Aside from attending company meetings, I’ve been out meeting our customers. This is perhaps the most enjoyable part of my job – meeting engineers who’ve been using our products to solve real-life problems. In this day and age of tight budgets, we all have learned to do a lot remotely – we send email, speak on the phone, videoconference and watch demos via webex etc. But nothing beats meeting live and in person. Getting a picture of a product via email is cool but it doesn’t come anywhere near what you feel when you walk around a manufacturing plant and watch a product come off the assembly line. It is to sum it in one word awesome.
I will share some of these stories with you over the coming months (some of the products haven’t even been introduced to the market yet so I can’t exactly talk about them but there’s some cool stuff coming down the pipeline). But today’s topic came from a conversation that I had with one of our customers last week. He said that new engineers, those fresh out of engineering schools, put too much faith in software tools. He was concerned that engineers are becoming so far removed from “formulas” and the essence of fluid flow that they are forgetting what engineering is all about. So I thought this would be a good topic for us today. After all, how can you justify spending money on software tools if they’re making you less effective at doing your jobs?
This conversation made me think back at the late 1800s … when we started using tractors to plow the fields. I’m sure many farmers thought that the use of machines would cause catastrophic crop failure because pretty soon the farmer would be so far removed from the dirt that he’d forget about the basics of farming. But that was not true then, and it still is not true now.
When developing FloEFD, our group had a vision. We wanted to democratize the use of fluid flow analysis. After all, much like stress analysis, fluid flow analysis can be used early in the design process to identify trends, problem areas etc. And just because a discipline can be used earlier in the design process it doesn’t mean that its use later in the design process becomes unnecessary. There is room for both.
The thought behind FloEFD was a simple one: all existing tools were too difficult to use by non-specialists. So the development team which consisted of fluid flow experts started with a blank slate. They created a wizard driven tool which used simple English. Instead of having to remember esoteric terms, the user had to tell the software what type of liquid and in what type of setting. In short, the development team wanted to create a tool that an engineer could use to find answers to real engineering problems without having to dig thru reams of manuals to figure out which formula would be the most appropriate for a specific condition. The fact that this tool had to be used by a subject-matter expert was a given – after all, how can you optimize the design of a valve if you don’t know anything about a valve? Would you ask a chef to give you a haircut? Didn’t think so. And thus FloEFD was born. From the word go it caught the attention of the engineering community. Many specialists who had struggled to use traditional CFD tools moved to FloEFD – mind you they didn’t do it blindly … engineers never do anything without investigating it thoroughly first. They solved many verification problems to put their minds to rest. And once FloEFD was proven “good enough” it was adopted by them.
I guess what I’m trying to say is that automation and software tools are here to make your life easier. They help you get the most from the foundation that you already have (your engineering education and expertise) by automating the labor-intensive tasks so you can focus on what you do best: design cool products.
I’m curious to hear from you. What do you think?
Until next time,