1 on 1 with: Sebastian Dewhurst

 

 

 

 

 

 

This Rev-Sim Industry Experts Interview features Sebastian Dewhurst of EASA Corporation.

 

READ THE INTERVIEW BELOW OR WATCH IT HERE.

Thank you for joining us Seb. Before we get too far into things, can you briefly give us a quick overview of your role at EASA – how long you’ve been there, your background and so forth?

DEWHURST: Sure. Well, my background – I guess you could say I’m a recovering engineer! My doctorate is in experimental fluid mechanics, I did my doctorate over in Oxford in the UK. I moved over to the States twice – once for my internship, which was with NASA Glenn – and then I came back permanently in ‘93 to work for what was then CFX – now part of ANSYS.

It was quite interesting using my academic background in fluids and heat transfer to be able to help customer solve real-world problems with CFD. It was a lot of fun; I really enjoyed it and had a great few years. But actually, that experience directly led to the concept of EASA because back in those days – late ‘90s – the major CFD companies like CFX and Fluent were trying to find ways of making it easier to use what was clearly a very “expert only” technology. I mean we found ourselves selling literally to people with PhDs in fluid mechanics, and that’s a limited market! In many cases we found companies wanted to be able to execute the process more efficiently – so it’s not just about intimate knowledge of the modeling technology – it’s about the process of applying the technology to a problem. We like to think in terms of processes here at EASA – it’s not just about that underlying (simulation) technology.

So, a lot of companies like CFX and Fluent were coming up with “vertical applications” – apps that have been built for a very specific industrial application like say mixing vessels, or combustors or pumps, or something of that nature – where clearly the CFD engine was applicable, but you wanted to wrap it in a very application-specific graphical user interface. So that was beginning to happen, there were tools like MixSim and TurboGrid – one that we had in the CFX family of products.

The thing is, building these tools was very expensive, and most customers wanted a slightly different variant of that vertical application. You’d build a mixing vessel simulation tool and the folks at DuPont would be absolutely wild for it, and then you’d go and visit the guys at Exxon, and they’d say “No, no, no, our mixing vessels are slightly different”. And so, that was not a particularly viable approach from a business point of view.

So, we came up with the idea of EASA. It was to be a more economical way of building these custom applications. You could think of it as a low-code application development platform – well before low-code was a thing. I think Gartner or Forester coined the phrase “low-code application development” only a few years ago, but here at EASA we’ve been doing this for 15 years, and we have customers who’ve been using it that long as well. So you can think of EASA as a low-code application development platform designed specifically with engineers and scientists in mind. It’s a way to enable companies to very quickly and easily to create custom wrappers that sit on top of processes – they might be CAE or hard-core engineering design-type applications; they might be preliminary design tools like Excel or MATLAB; and very often it’s actually in that world between engineering and finance – where “engineering meets dollars” – where you’d really like to be able to make life easier for the folks that are actually talking to customers. In many cases we find that spreadsheets are being used here to form a link between engineering knowledge accumulated over many years and how that converts to a dollar amount. For example, the customer wants this, so the metal needs to be this thick here and we have to make it like this. If you have a highly customizable product or service, often we find that the roadblock to making the process as smooth as possible is not a CAE application – more often than not it’s Excel and quite frankly Excel is the reason we’ve seen some pretty significant growth recently.

You mentioned Excel – I think I might be surprised at how widely it’s still being used in today’s digital world. Can you talk a little bit about that?

SEBASTIAN DEWHURST: Yeah. I think it’s fascinating – we engineers don’t like to admit that we use Excel – because we are rocket scientists! We use complicated stuff that nobody else understands! We don’t use Excel! Everybody else uses Excel!

I do detect at various conferences from some people that they feel like “Oh, well, maybe we use Excel but it’s a dirty little secret and we don’t talk about it that much”. But in fact, NAFEMS have done a superb job of really shining a light on this “dirty little secret”. They’ve done a pretty extensive survey and are in the process of publishing this information hopefully at this summer’s session. The fact of the matter is that the use of Excel is growing, even though computer aided engineering software has grown in leaps and bounds – not least of which is the pure processing power we have available on a desktop that 20 years ago you would have needed a Cray! So that has made a lot of calculations more feasible.

But despite all that, there’s still a need to do these “back of the envelope calculations” – does it violate the laws of thermodynamics? will it fly? will it break? – before we start getting into detail design which does need advanced simulation tools that produces all the wonderful graphics we love. But 9 times out of 10, a lot of the preliminary design has been done with tools like Excel and maybe MATLAB and other things like home-grown scripts. The research from NAFEMS shows that the use of Excel is actually increasing.

Taking a step back from the engineering world – by virtue of our interaction with Excel we have quite a few customers in Financial Services. They use Excel almost exclusively as their modeling technology. Although we are seeing a bit of python emerging now, Excel is still the dominant modeling tool of choice. And it’s getting better and better – if you look just at the last couple of years, we’ve seen the release of the lambda function, and the ability to embed Java instead of VB. So, we are seeing Microsoft pour millions of dollars into this already very capable tool, which is one of the most widely used software applications on the planet. I think it would be very foolish to ignore it; if you’re responsible for the software tools used within your organization – why wouldn’t you treat Excel as a fully-fledged citizen? You should not be ignoring it – there’s a lot of money and knowledge and intellectual property wrapped up in these spreadsheets, and you should be treating Excel as a true enterprise application – which when it’s paired with EASA, it can be.

Earlier you spoke of low-code development and touched on web apps. Can you talk a little bit about how these translate well into the democratizing simulation theme and maybe also while you’re on the topic – why EASA thinks it’s important to participate in RevSim?

DEWHURST: Sure. First of all, it’s our heritage – obviously the software these days is being used by customers not just in the engineering and manufacturing sector, but also in other areas. But engineering is our heritage and the whole concept of democratization is what originally drove EASA. To take a step back – looking at ways to democratize simulation – one way is to take simulation tools and simplify them and embed them in CAD packages. And we’ve seen that approach from CFDesign, for example. That approach has its place.

Often, though, the problem is the level of simulation – suppose you need to do a multiphase simulation – trying to make that available with that level of complexity within a general-purpose design tool is a recipe for disaster. So, I think what we see emerging in democratization – and both approaches are valid – one is the simplification of simulation tools so that they can be embedded into design tools and designers can do some preliminary simulation to make sure they are on the right track before it’s handed to the simulation group to do a more in-depth simulation. That’s perfectly valid.

EASA represents the other approach – the “templatization” approach. Take the model in all its complexity – it might be a process that has multiple steps – so you have a process. The only way to simplify a process like that is with an approach like EASA’s and templatize that entire process – if it’s possible – and put a fit-for-purpose, highly task-specific GUI on top of that. In order to do that cost-effectively, you’ve got to have a low-code platform like EASA. Building something like that from scratch is going to be cost-prohibitive.

This approach has become a lot easier as many of the solver technologies have become more “automatable” and we’ve things like the folks at Aras developing the ability to drive processes automatically make sure that they don’t break. This is great from EASA’s point of view, because it’s now easier to build an app that sits on top of that process and drive the process from beginning to end and make it “democratized”.

So, two very valid approaches to democratization – EASA obviously is an example of the templatization of your underlying model rather than the simplification of it – but they are both valid. One of the hidden aspects of the templatization approach is that there’s often much more to the modeling process. It’s not just about running a grid generator, running a solver, and getting a result – it’s about how you use that, how you apply that.

So, it’s casting the entire process into an app that allows the audience – a designer, a marketing person – to design something that fits the requirements, based on an engineering model.

Coming back to the final part of your question – we see RevSim as an important organization. NAFEMS as an organization to look at simulation and modeling is an excellent organization. But democratization is a fledgling movement and more and more people are recognizing it’s the way of the future.

Things have come a long way in a short time. What challenges or barriers do you see still being in front of us as far as the more widespread adoption?

DEWHURST: I honestly think the biggest barriers aren’t technical. I think they are psychological. What I mean by that is resistance to change. We’ve got some forward-thinking customers who have been applying EASA since the early 2000s, still today using the software to automate and accelerate these processes that would otherwise be “expert only”.

But I think the biggest obstacle is that it’s just too easy to get caught up in the status quo. We engineers like to think we are forward-thinking, but we are really quite careful about moving forward and delegating technologies to people. There’s this overriding concern that I hear from industry leaders; they all agree that democratization is a good thing – we ought to do it – but when push comes to shove, they want their simulation to be done by people who have been doing it for years. It’s a complex subject – you can get it wrong. And if you get it wrong things will break or crash, and people will die.

I think then we need to help industry leaders to understand how they can apply democratization safely to those parts of the process that can be safely delegated to junior designers rather than a senior modeling person running simulations manually each time

So, companies are able to focus CAE experts on the more complex projects?

DEWHURST: Yeah. We have a simple pie chart we use. If this “pie” is all of the modeling and simulation that you do within your organization, then only a slice of that pie – maybe 10% – is “templatizable” and appropriate to be democratized and delegated to people other than your elite simulation guys. So, there’s a small subset of your simulation that fits into that category.

I think a lot of CAE leaders know that – most simulation needs an expert, and for a few percent of our simulation, is it really worth looking at a democratization platform like EASA?

But if you look at companies that have said, OK, let’s give it a try, what happens is that 10% starts growing. Because once it’s democratized, people can start running more simulations, finding better solutions, more quickly, more cheaply, than would have been possible without appropriate democratization strategies in place.

That 10% starts gaining “weight”. You’re now getting quite a lot of simulation being done by people who are not experts, therefore taking some of the pressure off your experts, and you’re getting good results. You’re finding solutions you would not otherwise have found. What was 10 % becomes more than 50% (of your simulation effort).

What we are saying is that companies are coming up with solutions – by virtue of democratizing some of their processes – which they would not otherwise have come up with.

I want to circle back to something you brought up earlier – the template approach – can you talk about some of the results – what your customers have achieved?

DEWHURST: Well, one of the downsides of working with customers is that they don’t always like to share what they do with the software! EASA is a tool for building tools that are completely focused on the workflow at your particular company. So, you might talk a Boeing or a Ford and get them to admit they use Fluent or ANSYS and make a few general statements. But when we get to what customers do with EASA they keep it close to their chest! These are proprietary applications – literally their “secret sauce” – it’s what makes them competitive.

Having said that, we do have a few case studies on our website – www.easasoftware.com – there are some great case studies there from the likes of Ingersoll Rand, and General Electric, and some talks from Schneider Electric and Pfizer, where they dive into the benefits. In some cases, they quantify the benefits, but it is very, very dependent on the kind of apps that are built.

If anyone has questions or wants to get a hold of you how do you recommend they go about that?

DEWHURST: Just drop us a drop us a line at info@easasoftware.com or head over to www.easasoftware.com. There’s a contact page there with phone numbers for the US and the UK. We have offices in Tampa, Florida and Pittsburgh, Pennsylvania and also over in Oxford in the UK.