Hi, and welcome to the Neil Ashton
podcast. In each episode, we explain
some of the fascinating ways that
science and engineering are changing the
world around us.
We talk to leading engineers from elite
level sports like cycling and Formula 1
to some of the world's top academics to
understand how fluid dynamics, machine
learning, supercomputing are bringing in
a new era of discovery.
We also hear some of their life stories,
their career advice,
and lessons they've learned on the way
that I hope will be helpful to you, too.
So, sit back and enjoy this episode.
Welcome back to the Neil Ashton podcast.
This episode is with Professor Juan
Alonso, somebody who has
really been a pioneer in the area of
aeronautics and computational fluid
dynamics.
I thought this was a good person to
speak to because, as I've discussed in a
couple of previous episodes, I'm always
fascinated by the
by the link between academia and
industry and the roles that that both
play and the sort of merits of both and
and Juan is someone who really
epitomizes both. He's a professor at
Stanford University, but um recently
also founded a innovative new startup
called Luminary Cloud.
And we talk in the episode today
firstly about his his career, how he got
into engineering. I I'm I always love to
know what motivated people, what drove
them. I think it's so interesting to
hear different experiences. So, we talk
a little bit about how, you know, his
early days, about becoming a professor,
about, you know, leading a research
group.
Some of his early observations,
um
you know, he mentioned something like,
"Oh, at the beginning I was didn't
really I hadn't matured my thinking. I
was still doing a little bit of what my
supervisor had done. And I think that's
true if you're an assistant professor
straight out of your PhD, maybe you
haven't fully, you know, got your own
vision for everything.
But even though he said that, if you
look, he he was one of the first people
to be doing a lot around high
performance computing, looking at
merging methods. Obviously, one of his
big focus was on
aircraft design.
We didn't talk about too much. He he
also spent some time in
NASA headquarters. Although, as in any
of these episodes, I feel we could have
gone on for hours more cuz these people
have done so much
in their careers to date that it's hard
to cover everything.
But we we really get into some core
topics around where where CFD going?
What's the future of CFD? And one of the
things we talk around is the CFD Vision 2030
report.
This was a report that Juan was one of
the authors on, which was commissioned
by NASA to set out
by 2030, where do we see CFD going? And
essentially, it talked about some grand
challenges that need to be completed.
So, we talked to we talked about his
opinion on that, whether
we already have completed some of them.
And and so, I asked him, what would be
the 2050 vision?
We talked about machine learning, his
opinion on
you know, the hype around machine
learning and where it's suitable and
where it's not suitable.
Uh and we talk about the interesting
debate around when is open-source the
right what can open-source codes
achieve?
And where
do you need to have commercial codes?
And I think he's uniquely placed to
answer that question because of his work
to help found SU2, one of the you know,
largest open-source code that is used
for CFD in particularly in the
aerospace.
And then now with Luminary Cloud, which is
most definitely one of the disruptors in
the CFD market, their philosophy of, you
know, cloud first, their automated,
super fast GPU solver is something that
is, as we discussed, long been spoken
about in academia,
but only recently have their methods
matured to be suitable for for
commercial um code. And so he talks
about that the motivation behind behind
Luminary Cloud, what what made him think
about that, the rise of cloud computing
and HPC, the commoditization of compute.
So we go through we go through all of it
and I I found him a fantastic person to
speak to. I always enjoy um seeing I
don't see him that often because he's in
Stanford, I'm in the UK, but whenever I
do see him I I really
value his judgments and his ideas and I
hope that you also take something out of
of of this conversation. So So I really
hope you enjoy this episode uh too and
if you do, make sure you, you know,
subscribe and follow to to wherever
you're listening to this podcast or or
looking at it on YouTube or Spotify and
Apple.
Uh but yeah, sit back and enjoy this
conversation with Professor Juan Alonso.
First of all, thank you for doing this.
I um
I know it's hard to find time to speak
to people. I'm sure with everything
you've got now. I can only imagine how
you're sort of juggling
um things cuz
I would argue that as a
professor at Stanford,
now a, you know, a founder of a
pretty innovative, forward-thinking,
potentially cutting-edge,
groundbreaking, you know, software
company,
most people would say that's a pretty
good life. How do I get to that?
So
did you always want to go into
engineering and sort of aerospace
engineering or is this one of these
things you just fell into it?
Well, I've always been interested in
space and aircraft. So, my father worked
for the Spanish airline company Iberia.
Oh, yeah.
And I I tell people until the sweet age
of eight I wanted to be an astronaut and
then I realized A, I wear glasses and B,
I live in a country Spain that didn't
have a space program.
So,
So, very quickly I decided astronaut was
not the thing for me
and
I've always had a an interest in
technology but also aesthetics. So, I
thought of becoming an architect uh
in Spain much like in the UK I think you
have to select the major before you go
into college.
But I thought I didn't have enough
artistic talent to be a good architect
and I loved airplanes and I loved the
shape and function of them and the
engineering of it. Yeah. kind of fell
into it but I had an interest before I
got there.
That you know that's so interesting you
said that cuz I often joke with some of
my friends that I wanted to you know
being from the UK to be an astronaut and
yeah, one of them was definitely the
Oh, hold on.
Well, the UK technically has a space
program but
I'm not sure I would I won't get into
that sort of issue but
Um but for me it was more the um I'm not
very good with roller coasters. So,
I kind of realized that actually
you you have the most of them are
fighter pilots, aren't they? So, I
thought you have to kind of be used to
um
I love taking the G's.
Oh, do you? Oh, there you go.
Especially the ones that go upside down.
Well, okay. So, you you are definitely
closer. Maybe you should you could still
do it. Do you think? Private tourism
maybe?
Maybe. Maybe. Someday. I hope so.
Somebody offered me the chance to go
into more, I'll take the the right
anytime.
Yeah, if you'd have asked me that
probably 15 years ago, like when I was a
teenager, I absolutely said yes. I think
now coming from an engineering side and
going, "Hmm, how often are those
tested?" I'm
I'm not sure.
Um
but okay, so you you got in more through
the love of
aircraft and space. So, is that what
drove you to then go down from an
engineering at university? Was that
always what pushed you, you know,
ignoring architecture, but you wanted to
go down the engineering route?
Yeah, I I I was analytically good,
mathematically good. I I think I had a
knack for physical intuition of things,
physics. And I wanted to solve problems.
So, I I think I thought at the time, and
I I think it's panned out that an
engineering career was a good career. I
was kind of interested in airplanes and
spacecraft, so I thought aerospace
engineering would be good.
And then my my career early on was a
little bit funny. I I did my freshman
year of college in Spain, in Madrid,
where I'm from.
And then I had the opportunity to come
to the States as a sophomore, so a
second-year student in the East in the
States, and
and I I ended up at MIT for my second
year with a plan
of trying it out for 1 year.
And if I liked it, I would stay. If not,
I would go back to Spain and finish my
career there. And that was 1988, and I
have been here ever since. So, so it was
a great experience as an undergraduate.
I got to learn a lot of things. I got to
try a lot of things.
Um both in building things and testing
things, but also I started doing
computations.
Took a class from Mike Giles, who was at
MIT at the time when I was an
undergraduate. My first CFD class I
think the year or two before he went
back to Oxford. So this is must have
been 1990 1991.
Yeah. And
I was sort of hooked on on the valley of
computation and it's potential
as it develops into the tools that you
know we have today to really solve
groundbreaking aerospace engineering
problems and by extension engineering
problems in other disciplines. So So
Yes, there's always there's a problem
solver in me and I thought the
engineering profession was a good match
to my skills.
It always amazed me how small world I
that Mike Giles I can't confess to know
Mike that well but I would seem to be
around people
who know I was actually just having
coffee this morning with um
with somebody in Oxford and he he he was
like working with him during the PhD
years and uh
Yeah, it's kind of funny how it works
isn't it that you everyone seems to like
have some connection
to these people.
It's a small world. He was a remarkable
teacher and you know I I credit him for
putting me on to CFD as as something
that I would do as a professional later
on. So
But then did you So that was at MIT.
What cuz
I suppose one of the things I'm always
interested in is
as you finish your undergrad you
obviously have an option to go into
industry
or academia. Was that ever a decision
which way you were going to go?
Oh absolutely. So you know everybody
thinks when they see somebody who's had
a 30 year 40 year career
that they planned it all out. But no I I
I was set on going back to Spain when I
finished my studies in the US.
And at the time when I started college
Spain's engineering programs were six
years six year programs. This was before
the
like the I think it's called the Bologna
treaty or something where they the
European Union and homogenized all of
the engineering and educational
programs. So So I knew I had to do at
least a masters in order to be able to
go back to Spain and just work as a
practicing aerospace engineer.
Yeah. So I went to grad school with that
idea.
Um
I'd done a lot of engineering things,
but I'd done little research, a little
bit during the summers. I did not know
that I wanted to be a researcher. In
fact, my idea going into grad school is
I was going to get a masters and
potentially what I wanted to do was to
go design airplanes in industry.
Mhm.
But the masters exposed me to research.
You know, I worked with Antony Jameson at
Princeton
who also, you know, like Mike Giles was
an inspiring
Yeah. pioneer of CFD and numerical
analysis. And
I stayed on for the PhD and I was still
thinking I was going to go back to
industry and actually design airplanes.
And And then the opportunity to come to
Stanford as a faculty member came up and
I thought, well, I can do that for a
couple years. If I
If I don't like it, I can still go and
design airplanes. If not, it'll be very
difficult to go the other way around. So
So, you know, in in your career, like I
imagine in yours, you take these make
these decisions here and there and they
they lead you to where you are now, but
it was never calculated or planned out.
Was there any of that
of the um
Cuz I I actually found after my PhD
almost
the opposite.
I was kind of sick of academia in a way,
you know, like it it felt like I wanted
a change.
Did you ever
get down there? Or was there something
also about moving to Stanford? Was there
Was there or the location, living in Was
there anything else that sort of
did it for you?
For me it's not as much as location. I
It's beautiful weather here, I would
tell you. And And it's one of the best
weather
sort of patterns in the world.
Um
to me, the thing that made me stay in
academia, even though I have a bent
towards solving real problems, which I
mentioned before,
is sort of the
the being at the edge of the precipice
type feeling in research when you
actually don't know whether you're going
to be able to find a solution for a
problem and you're trying to do it in
better ways than anybody's done it
before. That was very motivating to me.
I Yeah.
Yeah. I think the ability to also work
on the problems that I thought were
important throughout my career,
the ability to work with amazing young
people who are far more talented than I
am and then with whom, you know,
together you end up doing some or or
creating some key contributions, you
know, to the field, that was very
attractive to me.
Um Mhm. I knew in an industry I could
contribute in different ways, but I
think my personality was better suited
for academics and and and and to sort of
go a little bit more into the unknown
rather than into things that are or tend
to be a little bit more incremental.
Yeah.
But So You know, if I may, in in my
career, I've always tried to get my
students to do something new in research
but applied to something that is quasi
realistic without doing the job of
industry, of course, right? Uh Yeah.
So it there there's been
a constant tug-of-war between doing
advanced new ivory tower type things and
sort of having them be applied to
something else and I I found that
Stanford allowed me the opportunity to
thrive in that sort of
tension between the two worlds and and I
I've enjoyed it ever since. I couldn't
I think of myself
Yeah, I must admit I I kind of I look up
to you as as somebody who has done that
very well. I think as someone Thank you.
myself who
feels a little bit caught between the
two worlds that I I think what you're
doing is actually very important because
on one hand
there is real value in fundamental
science and fundamental, you know,
theorems and and all the rest, but
sometimes I see the sort of cynical side
of it just, you know, for publication's
sakes and I sometimes find myself going,
"Yeah, but why?
How is that going to make a difference?"
sort of thing and Right. But if you go
too applied, it's almost there's not the
academic rigor and it feels like
what you're doing different than
industry is doing. So, it's it's a
difficult spot I feel you're in the
middle, isn't it?
Yeah, so I I do think that
you know, academia comes up with
fundamental new ideas and sometimes they
pan out, sometimes they don't. But any
advanced society that already covers
their needs for like food and shelter,
etc., etc., goes next to trying to deal
with knowledge and that's the creation
and the propagation and I would say the
perpetuation of the knowledge that has
been acquired. So, so at the very least
academia has value in creating the
knowledge and perpetuating the knowledge
by training people. I think there's much
more value created in academia than just
that.
Yeah.
But but for me in particular, it's all
my academic ideas over 20, 30 years,
perhaps we'll speak about this today.
Mhm. Uh
you know, have led to what I'm doing
today in in sort of the entrepreneurial
world, right? I would not have thought
that that would happen, but without the
academic experiences, the interactions
with students and amazing colleagues
that, you know, started creating
languages so you could program in a GPU,
for example, 20 plus years ago, you
know, the the the company we created now
would not have happened. So, so I I do
think you have to navigate that balance
and I think there are academics of all
kinds. Um but I I think societies that
don't have the ability to do academic
thinking,
innovation, creation of new ideas, and
knowledge for the sake of knowledge,
they end up dying. Yeah. Yeah. So, what
was your
you know, as I'm interested to see how
you kind of how you've got to where
you've got now and some of the
route, I guess.
So, when you were doing you were
starting at Stanford,
what was your core
sort of um
aims or sort of
30-year goal, you know, what were what
was your group trying to do? Cuz I feel
like looking at some of your early
papers, there were still things around
high-performance computing
very early on, arguably, in the sort of
Sure. high-performance computing trend
that we're in now.
Well, so you assume there was a 30-year
plan.
I at the time I was very young still.
So, I I came to Stanford straight out of
my PhD and I had not had the opportunity
to establish my own independence of
thought in terms of research program.
So, I I've been heavily influenced by my
my PhD advisor.
But, I also love the notion of of
modeling the real world
uh with mathematics and physics
and then implementing it usefully in a
uh
in a digital computer in order to be
able to to have simulators that were
more effective than than the experiments
and that was very early on.
Um
I was also smitten by the fact that I
could see very early on that if you have
the analysis capability, you could do
optimization on top of the analysis to
have tremendous potential. So, my early
career was very much focused on getting
the analysis in place and that was in
numerical methods, high-performance
computing, flow physics, etc. etc. But,
also doing optimization on top of that.
So, you know, I inherited
thoughts of adjoint methods and you
know, optimization whether single
objective, multi-objective, etc. etc.
And that that meant that the research
had to grow to encompass a pretty broad
ecosystem of various different elements.
And I pursued some of those elements
throughout my career. You know, some
more successfully than others, I would
say. But uh
but but the plan was always to design. I
mentioned I thought of being an aircraft
designer.
For for me um
computational methods have always been a
means to an end.
And they still are.
It's just that sometimes you have to
invent, generate, or improve the tools
in order for them to be a good means to
an end. And and as you know, since
you've been around for quite a bit of
time as well, um these tools were not
ready to be used in what I call the
outer loops, right? You could do a
single simulation. You could spend weeks
and months trying to get that single
simulation, but automatically running a
hundred, a thousand, ten thousand
simulations to do whatever outer loop,
let's say optimization, but there are
many others. That was not anything that
could be done at the time. So, I mean,
we were trying supersonic airplanes with
uh Euler methods. You know, we were
trying genetic algorithms. We were
trying all kinds of interesting things
to see
what would work or what methods would
work in which applications. And that was
my early career. And the idea was I
wanted to get everything ready so I
could do optimization.
Based design as I can understand and and
simulation-based optimization.
So, that that that was what motivated me
in the early days.
And there was a lot of America houses
and a lot of parallel computing. Yeah.
How do you think it's changed then? So,
if you look back when in when was it
night well, no, early 2000s.
Yeah.
Um
if you were to go to an aircraft
manufacturer,
look at their design process then,
and fast forward it to now,
what would you see as being the sort of
big
differences?
Um
I don't want this to sound critical of
the aerospace industry cuz this safety
critical industry that requires
very careful attention paid to to large
steps, large changes in design
processes, and manufacturing process
control systems, whatever the heck.
Um I think the use of computation
from when I got out of grad school, so
in '97, until now,
it's gotten more automated and it's
gotten faster,
but it's not gotten substantially
different. There are a few companies
around the world who try to do some of
the outer loops, sometimes more
successfully than others,
seldom in production, I would say, most
often than not in their R&D centers,
sort of informing studies and various
other things. So
So
surprisingly, we've come up with a
number of technologies to accelerate the
simulations,
and we come up, I would say, with a
number of technologies when you're doing
the same thing over and over again to
automate, script, link things together,
which is one big part of engineering,
don't take me wrong, but I I don't think
we fundamentally talked about changing
the way in which we either design
systems or use the computational tools
to design those systems. And I think in
academia we we have more freedom to
think about these things, and I tried to
devote a lot of my academic experience
to how do you reimagine the way you do
design,
and and more recently in in Luminary,
the the small startup that we created
about 4 and 1/2 years ago or so, it's
it's it's been about saying, "Okay, we
know what we need to do,
but we got to put it together, right?"
And it's it's
it's interesting. I I don't know what
you think about this, and I don't mean
to interview you in your own podcast,
but
but it's been very clear to me from the
beginning that what engineers need is
that inner loop, you know, going from
geometry to output of simulation to be
very fast, guaranteed level of accuracy,
whatever is requested,
very robust, meaning it always runs
without worrying about this mesh or that
mesh or this parameter, and very
scalably, so you can sometimes run five
or 10 at a time and sometimes 100 at a
time, right? And that's end to end.
So so it's become very clear over the
years that if you had that capability,
if you could put a geometry and you get
an answer fast, accurately, reliably,
you know, and scalably, you'd be able to
then put all these outer loops,
optimization, uncertainty
quantification, parameter studies, you
know, AI, ML, so on and so forth. The
essence is that inner loop. The way we
do the outer loops is is relatively well
known at the moment, and and we just
need to make it work and make it work
fast. So So I would say I've I've
devoted a lot of my career and more
recently, you know, Luminary, my time
and effort to make sure that we get
those inner loops nailed down,
so all the outer loops become possible.
I don't know if that makes sense to you,
but
No, no, no.
I think um
I I I think the bit that I'm interested
in it does seem as if the CFD, I mean,
fast forwarding a little bit to now,
Yeah.
the CFD world, it did feel in a way was
almost a little bit static. And I know
some people would say, "No, that's not
true." But it felt
it was a period,
let's say before COVID,
where if I was to look at the codes that
were coming out and everything, it was
mainly CPU-based,
mainly
still RANS-
based, unstructured grids, and
people were tweaking things, but if if
you looked
from the early 2000s until like the
2020s, people were using models still
published in the 1990s.
There wasn't that much. And it well,
maybe that were happening were in
academia, but they weren't in like
industry production. Where if you fast
forward
to now,
I'm seeing
companies like yours,
and to be fair, a broader sort of like
emergence
of these new companies.
What
What do you think is driving that? Like
what made you do it? What made it
possible for you to do it in,
you know, now in the past 4 years versus
50 years ago? Like what what what's made
the conditions right for it to happen?
I I So, I would agree with you. You
know, up to about 5 6 7 years ago,
except in academia, where we were all
trying all kinds of crazy interesting
things, Mhm. nothing much had happened
other than more cores,
same code, more MPI ranks, you know,
a few automations here and there, mesh
generation for unstructured methods, you
know, becoming a more mature discipline,
although, you still in in need of lots
of
sort of interesting improvements, I
would say. And and and very stagnated
field. Um
To me, and I if I switch now to my
non-academic and and more
entrepreneurial Luminary career,
um in the 2019
time frame, when I was talking to the
person who'll become my co-founder here
at Luminary,
it become very clear that a number of
the key technologies that were needed to
realize the vision were now mature
enough that you could actually have a
chance of getting it done in a
short amount of time. I put short in
between quotes, right? So,
um
we started looking at sort of GPU
computing at Stanford. You know, these
are colleagues in CS that were
participating these ASCII programs for
full jet engine simulations.
In in the early 2000s, this is prior to
CUDA, etc. etc. In fact, it was a
student of Pat Hanrahan's I met I I
remember Ian Buck, who's now at NVIDIA,
who had done something called BrookGPU
where the texture memory of the existing
GPUs of the time was used as memory for
computations. And and Ian then got hired
at NVIDIA and and became the main
architect of CUDA, right? And of course,
at the same time NVIDIA started changing
the hardware of the GPUs in order to
enable computing. So, so back in the
early 2000s, we were already doing these
things. In fact, I remember with another
colleague from Stanford, who's also at
NVIDIA now, Massimiliano Fatica, in
2004, we published two papers in the
AIAA Aerospace Sciences Meeting, one
called Stream Flow and the other one was
Stream FEM.
The The GPU computing name back then was
coined by Bill Dally, who's now a chief
scientist at NVIDIA, at the time a
professor in CS as well, and electrical
engineering, I think.
Um the trea- the term was coined stream
computing, right? So, or stream
supercomputing, so.
So,
back then, those ideas were germinating
and now they were ready in let's say the
2018-2019 timeframe.
Cloud was unheard of in the early 2000s.
You know this better than I do. But you
may remember grid computing, right? Or
very different supercomputing. So, the
the idea of the cloud was germinating
back then as well, but you know, the
costs, the high availability, the
security, and various other, you know,
virtualization layers that came from
many of those early research projects,
you know, were also panning out. The
infrastructure wasn't place, so you
could actually run a calculation at data
center in the middle of the US and sort
of visualize it in real time from a
browser, you know, in the Bay Area. So,
all of these things were coming together
and it was clear that it was possible to
do something different.
Um
Yeah, it it became very clear that that
was the solution. That eventually most
of the high-performance computing in the
world will go away from on-prem clusters
and and just go into the cloud. And and
I know you work for one such cloud
service provider, so I I know you're
going to agree with me, but the
competition between the major cloud
service providers over the next 10 years
is going to be fierce, which means
prices will come down, capabilities will
go up, and additional differentiators
will will be attempted by various
different places. So, so there'll be a
continuous drive for innovation. So, to
to me it became very clear. I've been
doing some things in the cloud earlier
on in my research program and saw how
good it was.
So, it became very clear that a
combination of GPU computing native from
zero, you know, the beginning, and cloud
computing native from the beginning
was the way to have that sort of step
function in terms of improvement of how
computational simulations could be used
for analysis and design, right? So, So,
that's a long-winded answer to your
question, but but that's precisely what
was happening. It was very clear there
was a confluence of things
happening that will make this possible.
And
go ahead.
No, I was going to say
and it's not like we had a, you know,
crystal ball and everything was
perfectly crystal clear, you know. There
was con- There were concerns about
companies putting their IP in the cloud,
you know, data security issues,
performance issues, you know,
the the level of differentiation that
one could achieve versus existing
software providers, uh and and whether
we could be successful, and frankly, how
long it would take to redevelop
everything from scratch. Not just for
solver technology, meshing, adaptation,
visualization, AI machine learning,
right? CAD ingestion, CAD cleanup, um
you know, interpretations of results,
creation of databases, scaling to large
numbers of users, you know, scaling to
large numbers of GPU resources in the
cloud. Those were all unknowns that one
needed to come up with solutions for
that were less in the academic realm and
more in the, I would say, creativity and
innovation realm, right?
How important do you think it
it is
that you are where you are in the world?
Like, do you think you could have
attracted the investment on the idea if
you weren't in the Bay Area? Is there
something about the Bay Area that helps,
or
Yeah.
Yeah. Yeah, I
I
I mean,
I don't have
proof that the following statement is
true or factual, but I have a strong
inclination to say that it would have
been almost impossible anywhere in the
world.
You know,
um you know, how
how much work goes into just doing a
solver. So, now try to do solvers for
compressible and incompressible. Try to
add porous media. Try to add multi-phase
flows, thermal solvers, aeroacoustics,
etc., etc., eventually structures. It's
a massive amount of effort, and it
requires a very large number of people
by academic standards. So, it requires
funding because these things don't get
done in 6 months, right? We're not I I
remind people, we're not putting
together an online calendaring
application.
You know it's going to work, right?
You
you're trying to do something that's
never been done before and you want to
make sure it's accurate, it's fast, it
is robust, it works all the time, right?
Etc. etc. So, so that requires a certain
level of investment that would have been
hard to find anywhere else but in the
Bay Area.
Also in Luminary, unlike in my academic
research, there are two parts of the
company.
One
are software developer computer
scientists
that are highly concentrated in this
area of the world and that are essential
to the success of the company.
The other are people like you and me,
sort of trained as computational
scientists, visualization experts, AI
machine learning, meshing, geometry,
etc. etc.
Um and those exist all over the world.
And in fact, you have to attract them to
a place
where they want to be. And the Bay Area
is a nice place to attract people
despite the housing costs.
Um
but but yes, I think it would have been
very difficult to do anywhere else
because of the magnitude of the
investment, the time that it takes and
sustain level that it requires to
actually get there. And I would say
because you're going to have to attract
talented people from across the world.
We have a good pool of software
developers, but everybody else has to
come from wherever they are. So, they're
the best in what they do and and
attracting them here versus
other places in the world is is a little
bit easier, right? Yeah.
How much
do you
I don't know how to phrase this.
Do you have more respect now
not that you were disrespecting for some
of the large ISV companies. Like I
always got this sense in academia that
sometimes it was easy to
criticize large commercial companies and
be like, oh, you know, their codes are
not very good. You know, what we've
developed in our paper is better. Having
to do what you've done, do you suddenly
go, hmm, actually now I see it's
actually quite hard to build up these
big code bases and
validate them, etc. Yeah, um
Yes and no. So, two things, of course,
um
Yes, producing a product that can be
applied to many different types of
applications and that are willing to pay
for because it's it's addressing pain
that they have in the current processes
is very hard.
It's much harder than writing an open
source software solver and and making
sure that, you know, academics with a
lot of patience and and some industry
and and government people are able to
use it and and they ask questions and
it's okay they didn't pay anything for
it. So, you know, if it doesn't work as
advertised, it's all right. So, gain a
tremendous amount of respect for
companies that put good, high-quality
products together
because that means there's a tremendous
amount of thinking about the features,
how they're exposed to the users, how
they're implemented, what type of
regression testing you do, you know,
what type of user testing you do, how do
you make sure that you're doing
something for the sake of improving
processes. So, so that takes an
inordinate amount of time. You know, if
you develop something in academia and
you think you're done, you've done about
10% of what it is required to actually
put together a viable product. So,
So, in that sense, yes, I I I have a
tremendous amount of respect for those
companies that actually do this
properly.
Yeah.
Um
The converse is also true.
You know, some of these companies, I
mean, they're around for a long, long
time.
And while their solver technology has
improved over the years, they missed
opportunities over time
to really do much more significant
improvements.
And
you know, as an an academic, I seen the
ways of technology that eventually I'm
taking advantage of as an entrepreneur.
Um
I seen them come by and and I I seen
that they've been largely ignored by
many of the the larger companies and and
for that I think we should fault them.
I I think as engineers,
you know, and developers, when we have
the resources to do what needs to be
done and it's not done, that that's just
slowing everybody down. And I I think
there's a little bit of that in the
legacy vendors to be completely honest.
One of the things I observed uh I've
been trying to to see
if it's going to change or why it's the
case.
If you look at
the automotive sector,
Mhm. it's largely
ISV
or things like OpenFOAM or commercial
versions of OpenFOAM. Whereas, if you
look at the aerospace sector, it's a lot
of homegrown code.
Why do you think that is and you think
it will always be that case in the
aerospace or do you think there's this
slow
move and I'm not not because I'm not
trying to blame you but but because some
people are maybe going, "You know what?
I want to have I
I want to leave that company and go and
join an exciting startup and do it." Do
you Do you think eventually there will
be a move to a more sort of private
codes and commercial codes and
So, I
I witnessed a lot of things through my
career that lead me to the following
comments that I'll make about your
question. So,
um
the aerospace industry invested heavily
in computational fluid dynamics from the
beginning as an alternative to internal
testing.
To the point that the major aerospace
corporations in the '70s, '80s, and
'90s, even into the early 2000s,
would have, you know, teams of 50, 60 to
100 people working on the development of
these methods that were used throughout
their corporations. That changed in the
early 2000s and the maturity of some of
the commercial tools became to be so
high
that even aerospace companies started
reducing the size of the teams that were
doing new method development, new code
development in favor of sort of
commercial offerings and options, right?
Uh
Um
that happened more quickly, I think, uh
particularly the transition to transient
flow uh calculations in the automotive
industry.
They they recognized the advantages of
the technology. They
they knew they have tools that were
almost ready. They some of them invested
in improving, you know, existing
solvers, OpenFOAM type uh things, right?
Uh
uh there were a number of smaller
companies that were formed around the
open-source code, OpenFOAM, in order to
do further improvements that are needed
by industry. And largely there's there's
a lot of penetration, you know, of
existing commercial vendors and
open-source-based commercial vendors
because they seem, you know, the the
advantages. I
I I think aerospace industry is going in
the same direction.
Um there may be some esoteric
applications,
you know, in stealth aircraft and, you
know, various other things that may
still be in the realm of what the
aerospace companies want to do, but the
vast majority of the simulation
workflows are ones that commercial
software can do.
And that commercial companies that are
reinventing the way this gets done can
do way better and way faster. So,
eventually it's going to go in that
direction. The the value added by the
companies is not going to be in the
development of yet another unstructured
polyhedral, you know, finite volume
solver, but rather in how you use it in
the outer loops. And the inner loops are
going to be taken for granted if
companies like ours and others start
making sure that you can get them
accurately fast and scalable as as we
were discussing before. So, So, my take
is the aerospace industry will go mostly
commercial, mostly I would say
modern computing type approaches and
they'll be building or rebuilding some
other processes on top of these units of
computation that are going to be
effectively taken for granted.
Yeah, just seem almost ironically that
it's a
a credit to CFD if it does become that
way because almost it feels
like it had to be developed by your own
cuz you were the only people who knew
how to do it where almost now not
commoditized, but you know, it's
becoming able to be created and made
automated that you don't need that to be
a special team
within your company.
Well, in the early days of the aerospace
industry, Neil, it was a competitive
advantage to have a team of experts
developing that capability that nobody
else had.
At this point, the the individual
solution capability is is not something
that's going to be differentiating
across these companies, but how you use
it in tens or hundreds or thousands of
times, right?
And then how do you embed it into
processes and raise other things. So,
yes, I I think it's it's a credit to the
success of CFD as a discipline
that 30, 40, 50 years after it was
created, it's now becoming something
that people believe, trust, and they can
use in that inner loop without giving it
much thought. And actually relinquishing
it to to companies like ours, for
example, and trusting
that those companies are doing all the
due diligence enough to make sure that
the accuracy, performance trade-offs are
are well understood.
Yeah, almost feels a way a bit like
um
HPC and the cloud. And obviously, I am
slightly biased. I work for AWS, but I I
would say this even if I wasn't working.
And I think others have made these
comments that it used to be the fact
that HPC was a very specialist topic,
required specialist hardware,
but now
even if somebody built their own
machine, they're just using nodes and
types that are widely used by anybody
else. They're not really specific, so
why would you need to build your own
if you can just get it
from a cloud vendor. It's because it's
become more normalized,
um
you don't need to have this special
system in-house.
I I think you said the keyword before,
you know, high-performance computing has
become commoditized.
You know, no longer do we have
custom-made chips, custom-made operating
systems as was the case when I was a
grad student, you know, custom-made
interconnects if you have that. This is
all commoditized. And, you know, the
cloud service providers are building
these data centers with the best in
class of those commoditized components,
and then they're putting the software
infrastructure infrastructure together
so you can actually use them in a
dynamic way. So,
um
it it's hard to believe
that individual companies are going to
be able to recreate
the value that's being added by these
cloud-based companies at much larger
scale.
And, of course, it's hard to believe
that individual companies are going to
be able to buy at the scale that's
needed in order to burst in capacity.
It's It's hard to believe that
individual companies are going to be
able to have access to the GPUs, the
most modern GPUs, as early as the large
cloud service providers are having
access to them. So, and and it's hard to
believe that
that companies are going to reproduce
all of the software services
that come from a cloud infrastructure
that that are not there in the
on-premises clusters. So, yeah, I I
mean, the the only drawback of at some
point or drawbacks were the cost and you
know, the perception of security.
I mean, the security one is essentially
gone away and the costs are coming down
over time. So, different companies have
different appetites,
you know, for understanding how much
they spend internally to achieve similar
or lower levels of of, you know,
reliability, you know, credibility,
security, etc., etc. And and different
people will jump into the bandwagon at
steps. But as you have seen, the
engineering profession was lagging
behind sort of the financial systems
that sort of migrated to the cloud 5, 6,
7 years ago completely and engineering
is going in that direction right now.
It's happening.
Yeah.
Yeah, it's it seems to be a um
an interesting transition point where
there's still I guess like anybody, you
know, if you say, "Hey, use this new
turbulence model." No, no, "No, I have to
use that one." It's it's everybody gets
in a certain mindset of doing it the way
they've done it forever.
Um
So, it it is hard
to sometimes convince and even in my
4 years as it is now with cloud, what it
was at the beginning to what it is now
is already a major difference. The
conversations I was having at the
beginning, it was being told to sort of
get lost and I had to
try, you know, and I'm not a sort of
salesperson in that sense. Like, I pride
myself in not selling stuff to people,
but it it was quite a different People
didn't I Well, although, would you not
say that
you and I in some way
working in a more cloud or closer to the
cloud companies, working at a cloud
company, your company that uses cloud
resources,
I still wonder if we're a little bit
um
not fully aware of still how much people
don't even know what the cloud is. You
know, if you go to some companies, you
know, like
does that surprise you still that when
you're like, "Oh, do you not realize how
I know it sounds like I'm selling it
now, but you know how good it is or how
much potential there is?"
Some people don't even know what it is,
yeah.
I'm not surprised
that
people have
a lack of understanding of the potential
of the cloud for their engineering
simulations because there's so many ways
of using the cloud and I think it's
cluttering
their perception of what the cloud does.
I mean, I I talked to a number of people
over the last 4 years while we were
building Luminary
who really have very little idea
of what we were saying we were doing at
Luminary cuz they Again, they had a
mixture of ideas. They're like, "You
mean, you're hosting my data there and I
never have to have something here or is
it a virtual private cloud or am I just
using the cloud for when I don't have
resources in my company?" So, there's
many ways in which people have done it.
I I have to tell you, Neil, that the
best way
to make sure that people understand how
we think the cloud should be used for
engineering simulations is to show them
a demo.
Oh, yeah. Right. Yeah. It It's when it
clicks for people. I can see that all
the time. They have all these questions
in their minds of, "What do you mean
this, that, that?" When you finally show
a demo and you upload a CAD file to the
cloud and it takes, you know, 2 seconds
and then you run a transient simulation
that generates multiple terabytes and
immediately you can actually see and
you've never transferred a single file
or done anything, that's when people see
it and and I I think it's it's companies
like ours and others who are beginning
to do this
that can give people the more clear
understanding of what it is and what the
potential it has of becoming
and and that's when it clicks for people
I think normally. Mhm.
But yes, there's many different ways as
of you know of using the cloud and and I
think that's confused a lot of people
who who've been around simulation over
the years but have not paid close
attention to the cloud.
Well, I'm I'm kind of um
glad in a way that um it has turned out
the way it does because I remember I
was giving a
talk.
I think it was in about May of 2020,
something like that. I think it was like
a remote thing at um at NASA. They do
this seminar series and I gave a talk on
like how the cloud
you know, will transform CFD and I I
remember the I mean admittedly okay, for
people who know I was doing at NASA's
supercomputing division which probably
is not the right place to be pitching.
Sure.
Um but anyway, I remember saying some of
the stuff and I
I genuinely thought it was going to be
the case but um there was not as many
other people truly believing in it and
it was interesting that
in that
even before that your company was
brewing and it it it showed that it
takes time for things to happen but it
I kind of
at least I'm happy that it it kind of
has I wasn't telling people a bunch of
lies and
has kind of come to be true.
You were one of the pioneers of this. I
remember you and I we met at
I think it was an international CFD
conference in Strathclyde.
Oh, yeah. A few years few years before
that, maybe in 2016-17.
And you were beginning to talk about
these things and and I was paying
attention.
And yes, I I think
you know, going to people who own
supercomputers and that are very
interested in sort of the hero
calculations where you're going to be
using 1 and 1/2 million, you know, CPUs
or something. It It That's the right the
wrong crowd, right? Uh
But But as you very well know, you know,
from the early days in the early '90s of
MPI,
you know, 4 6 8 16 processors,
eventually 200 400, then Blue Gene L
with 100,000 cores or racks, and then
eventually some of the 1.5 million
simulations. We all thought that for
supercomputing to keep going, we're
going to get into the millions of cores,
yeah, yeah, heterogeneous, etc., etc.,
right?
Uh and everybody was talking about MPI
plus X. We didn't know how the future of
software development was going to
happen. It turns out that for some of
the most demanding supercomputing
calculations for engineering, I'm not
going to talk about basic science at the
moment, but for engineering,
we can do really well with 256 A100 GPUs
in the cloud. So,
so I think it's taking a while for
people to understand
that vast improvements in supercomputing
are not requiring some massive changes,
you know. It's cloud, yes, new
technology. It is, you know,
500 GPUs, 1,000 GPUs, but not hundreds
of thousands or millions of GPUs, right?
So, so I I think we got into a point
where where most people are seeing that
for engineering calculations, this is
the way to go.
So, where I I agree with you there. I
think that's an interesting
I always do this. I always show this in
any presentation I do about like the
cost
and that doing an, you know, a DNS or
things like that are are so unbelievably
expensive that it's it's good maybe for
academic work or things where for
national security reasons or whatever,
you know, you have to get the answer
through CFD and
maybe the accuracy. But I I would agree
with you that we've made very large
inroads into showing high fidelity
methods are maybe not as expensive as
people thought they were maybe 10 years
ago. You know, that sort of vision of
2030
I would argue is come closer and
obviously, you know, that was something
you were heavily involved with. Do you
think
How do you think things are looking? So
the CFD Vision 2030 report was a very big
pioneering is quoted everywhere. How are
things progressing towards achieving
those
aims?
Yeah.
So as you mentioned I was one of the
co-authors of that study and it was a
very fun study to do cuz it involved
academics, it involved industry, you
know, it involved people who have been
in the computer science side of the
effort etc. etc.
At the time we were so that was
published in 2014
10 years ago.
We've been working on it for about 2
years. I think is the total time that it
took us a a small contract from NASA to
sort of put this vision together of what
CFD in the 2030 should actually be. Um
at the time that we were writing that
report and we published it
I don't think anyone of us of 10 or so
people in the committee that wrote that
paper thought we would get anywhere
close to being at the level predicted by
2030. And here we are 6 years before
the deadline
and I think much of what we were talking
about in the solver technology
in the managing large numbers of
simulations, in some of the
multiphysics elements, and some of the
design optimization elements that I'm
you know, I that was one of the major
writers for, I think we're almost there.
Um
meshing
adaptation, accuracy, scale resolving
simulations, those were things that were
not deemed to be possible
you know, until 2030 or beyond and and I
I think I think we're going to
definitely meet the goals by 2030 or
before.
Which by the way is a lesson for the
next 20 years, right? The Like I was
telling you at Stanford people were
looking at how to program in GPUs before
there was CUDA or anything else 20 years
ago. So, you know, we're in 2024, 2044,
hopefully we're both still around.
And it could be radically different than
than what people are working on today
may actually have a substantial impact
when, right? So, so we we we're
definitely on track to achieving the
goals of the CFD Vision 2030 uh CFD vision
before.
Uh there's a group that's actually
tracking this and and you could argue
that you could interpret all the
statements made in the original report
in one way or another, but but we made
tremendous progress mostly thanks to GPU
computing and sort of advances in sort
of meshing, adaptation, post-processing,
and multiphysics, right? I think
I think taking calculations that used to
take 4 to 6 hours and doing them in 2
minutes opens up the possibilities for
multiphysics which were recognized in
the CFD Vision 2030 as one of the key
ingredients, you know, for for future
uses of CFD in in you know, beyond
what's been used today.
Mhm. I think one um and I probably
should have read the report before
saying this, but I'm pretty sure it
doesn't have it in there, but correct me
if I'm wrong.
Is as we move into now the machine
learning
side of things. Um
I'm interested to know your thoughts on
this cuz just as
GPUs, totally agree, have been a
game-changer, rewriting codes um for
GPUs, and you know, all the advantages
that gave and and and and and even just
as you were saying, integrating the HPC
and the software more tightly,
um so it's not separate things.
But
where do you see machine learning
coming? Do you think it will be a major
change or do you think it's too hyped?
Where's your viewpoint on this?
Yeah, so
this is a long topic and that one that's
close and dear to my heart. I've been
doing research in this at Stanford since
I would say 2010 or so.
Um
There is no question
that it's it's one of our technological
revolutions
in general.
In science, engineering, and consumer
industries, etc., etc.
The abundance of data is what motivated
this, whether you produce it through
more accurate
much quicker simulations that you can
run in parallel, you know, hundreds of
them, etc., etc., or whether you're
collecting data from sensors, sensor
technology from existing systems feel it
in the
you know,
in the world.
Um, I do think it's a revolution, but I
am afraid it is
massively hyped up when it comes to
physics-based simulation impact of AI
and ML. And actually, if you will allow
me, I'll always say ML and AI.
Because I mean, what we're talking about
is is
advanced methodologies
for regression of existing data,
mathematically speaking, right?
Um
I don't think it's a question of whether
it will be useful or not. It will be
useful. I think the key question is for
what will it be useful?
And also, how will it be useful for
people who are doing simulation-based
work, right? So, I got I got I have to
carve out that niche, which is my niche,
right?
Um, it is my strong opinion at the
moment and I've been thinking about this
quite a bit that there are four
potential uses of ML and AI in
simulation-driven
workflows. By the way, if I hear anybody
put a LinkedIn post or publish something
when they say like, "Ooh, we did this
and it's 10,000 times faster than the
original solver."
I'm going to write a nasty gram because
they never talk about how much it took
to generate the data, how much it took
to train the model.
Something recently on
I wrote a comment on a few days ago. I
didn't say it was 10,000, to be clear.
Somebody else did. And I Okay.
Well, so what what I'm trying to say is
that those things are are hype.
No discussion of how many actual
simulations were required to train the
model,
right?
No discussion
as to what the training costs were.
No discussion as to the accuracy of the
predictive tool. No discussion as to
whether that methodology is
interpolative in nature only or
extrapolative in nature, typically not,
obviously.
And you know, sort of no discussion as
to whether, you know, you were actually
training for something and actually
testing for something else. So So my
take is that those things just ring very
hollow.
Most people do not understand the real
problems for which these replacements of
high-performance computing sort of type
of approaches would actually be used
for. And I I hope I'm not insulting you
or any of your of your
you know, podcast viewers and listeners.
Um
I I believe strongly that there are uses
for it, but I think we have to sort of
get over the hype and and sort of move
on to to show things. So So if I can
tell you
um the four things where I think uh this
technology is going to be very useful.
Um
I I Do you have time? Yeah. Yeah,
absolutely. Let me start. Number one,
one that makes absolute sense to me in
aerospace and outside of aerospace,
real-time control of systems.
You have a system, a plan that's fixed.
You can analyze and hyper-analyze it and
create training data,
right? The
it requires that you query the model
many times per second. So, there's a
performance requirement that is
absolutely necessary.
It is a control system and therefore
it's built to reject errors,
which means it's okay
to actually build a model that has some
errors. And in fact, it's okay to build
models that have significant errors, so
you can reduce the amount of training
data, right? The
And at the end of the day, like I said,
the system's not changing, so so you can
actually build it and you can amortize
it over, you know, many many many
repetitions of that system, whether it's
an airplane or a jet engine or a car or
something else. That makes perfect sense
to me. It's a very viable use. So,
that's that to me will be use number
one.
Uh, use number two,
uh, would be some very hard optimization
problems. So, design, design
optimization for various different
reasons. Maybe it's very high
dimensional, right? Maybe there has
noise. Maybe it's very multiphysics
oriented, etc., etc. I can see how what
I would call ML/AI surrogates
with certain amount of errors in the
context of an optimization framework,
like let's say a trust region based type
of approach, could actually be helpful,
more helpful than doing direct
optimization on top of the high fidelity
analysis. Except in many situations, you
know, if I can get away with adjoint
methods and various other sophisticated
methodologies, well, let's say 100 or
200 function evaluations, well, and and
get to the optimum with high fidelity
without having to check and recheck, why
am I going to train a model with several
thousand simulations, you know, unless
I'm going to be doing it very often. So,
so some of these optimization hard
optimization problems could benefit from
these types of methodologies. That to me
is application number two, right there.
Um application number three are some of
the outer loops that also can tolerate
some errors. So, uncertainty
quantification, design under
uncertainty, some large parameter
studies, data assimilation, inverse
problems. There are some situations
where this makes sense. And then
finally, if you have a system that is
not only simulatable
and trainable, but you can actually
collect a lot of data. So, digital twin
type ideas in certain situations. The
the ability of having frameworks,
possibly cloud-based, where you're
constantly retraining based on the
availability of data for bespoke models
for various different, you know,
products that you have out there. That
could actually be very useful. So, so I
can see a tremendous potential for those
four types of applications, but
they're all always going to be based on
the high-fidelity simulations that you
have to create in the first place. And
they're going to have to be based on
some more modern, more non-linear
techniques. And hopefully, as we move
forward over the next 10 years or so,
academics, industry, and others will
begin looking for ways in which these
models can be much more extrapolative
than they are today. So, the cost and
investment of setting up the model and
training it can be amortized over much
larger numbers of user uses um than than
what is the limited set of uses that one
can use today. So, so I'm not cynical. I
hope I don't come across as cynical. I I
I'm more about sort of trying to
understand from a very rigorous
mathematical and physical point of view
what these methodologies can and cannot
do,
Yeah. Um so, that that's my thinking.
There's there's There's of generative
design that we could go into, that may
be enabled by the high fidelity
simulations, but but that's even at an
earlier stage at the moment. So
Yeah, I find Yeah, I definitely find an
interesting topic because um
Mhm.
we
you know, we see a lot of
interesting companies come out.
I agree with you there's a
there's a lot of
bold, shall we say, marketing claims
Yeah. that
uh
funny in a way. I kind of see on one
hand it puts people off, but on the
other hand
I kind of see that some companies need
to do that almost to get the attention.
So there's a sort of uh
counterbalance um
and and I kind of wonder
well, firstly, whether
whether that's true. I mean, I think
it's crying out for a proper study that
does a more fairer comparison because I
know that just looking at the inference
time
alone
is is not the full picture. Right.
To the same point that I know that some
wind tunnel people hate it when you say,
"Oh, the cost of CFD is this and the
cost of a wind tunnel is this." And they
say, "Well, hold on, how long did you
take to mesh that?" Now, I know maybe
with your code you don't need to spend
as long meshing it, but there's always a
slight challenge of comparing things
like like. Um but what do you think
about the bolder claim around
sort of foundational
models? So the theory being that if I'm
an automotive customer and I always run
cars,
do you not perceive that with enough
high fidelity simulations
with enough sort of input-output
mappings that you could get to a point
where you could train a model that could
predict
a car?
You know, like is it a simply a data
problem? If there's enough data,
do you think you can ultimately
get to that point, or do you see it more
from a
sort of
physics enforcing
as in it's okay for low fidelity, but if
you really want to
get everything right, you still need the
high
fidelity?
Um
definitely Well,
that's a wonderful question, and let me
say a few things about it.
It's uh going to be a factor of the
level of accuracy you require. Sorry.
Don't worry.
Don't use the phone.
It doesn't do it for me. I don't know I
think
You could do it in the outtakes. Uh
I think the answer to that is is
multi-pronged. So,
let me uh let me start by saying that I
I do believe
that additional amount of data, vast
amount of data, are going to be helpful.
But, I think
whether you can replace a physics solver
by an ML AI sort of capability, it's
going to depend very strongly
on the level of accuracy that you
require.
I I'm a little biased. I come from the
aerospace industry where, you know, a
half a percent difference in the
prediction of drag and therefore fuel
burn of an aircraft is a huge number.
Mhm.
I have some hope
that if we had data for thousands or
hundreds of thousands or millions of
airplanes, we'll get there. But, I think
that's going to be a very expensive
proposition.
If you're designing a valve, you know,
for an irrigation system,
and you can tolerate five or 10% errors,
then I think there's going to be strong
potential use even without hundreds of
millions of data points, etc., etc.,
right? Uh Mhm. So, I do think the
accuracy level is going to be important.
Um
I do think the availability of massive
amounts of data is going to be
important.
In aerospace, I
mean at the end of the day, Neil, you
know this, right? The CFD solver is
solving a PDE
with a basis.
And because we have meshes that are very
fine,
these bases can represent all kinds of
features that are very small in size and
therefore, you know, there there's a
very good ability to represent the exact
solution of that PDE that you're
actually solving.
Here, what you're doing is you have a
non-linear basis that you're combining
in various different ways, but part of
the decrease in cost of the simulation
requires that the number of basis
vectors, let's say, is significantly
reduced. So, you're always going to be
trading this. You know, we've been doing
this from finite element bases to, you
know, wavelet transforms and various
other things. This is yet another
non-linear basis combination of various
different tools, which will have
potential use in many areas, but I don't
see it as a complete replacement of the
types of things that we're talking
about. I
Also, I have to tell you that the
I've lived this over the last 5 years.
When you go from executing one
calculation in 6 hours to 1 minute,
your your trade-off between speed of
execution of a surrogate model of some
kind and you know, the the actual
accuracy that you need changes, right?
So, and I I do think that that's going
to sort of be sort of coming after us
for a long, long time in some
applications where the accuracy is very,
very, very important.
In other applications, I think we'll
we'll transition to some of those models
more quickly. I think there's a dearth
of research
that is trying to understand
fundamentals of the physics
to then
introduce in a machine learning
methodology to extrapolate from the data
you learn from by using sort of the
commonality of the physics that was
actually learned. I'm excited about sort
of researching those areas that that
could have tremendous potential over the
next 10 years. So, there are a number of
people around the world trying these
ideas.
Uh I I almost see it as a
an ironic way that the very thing
that makes machine learning so
potentially transformative
um
which you could which some people may
think would challenge the need
for research into sort of high fidelity
or improved CFD is almost the motivation
for it. And the reason I say that is
because if you need so much training
data
the actual method you use to create the
training data becomes a huge cost. So,
if you can if your code can run five
times faster, means you could
potentially generate five times more
training examples and make your model
much better.
Now, whether the cost saving means that
why you're even doing that, you know,
you might as well just run the normal
simulation. That's I guess to be
determined.
Um it's it's it seems to be almost a
motivation for the higher fidelity fast
methods. I I'll make a
I'll make a prediction and then I'll
I'll give you an analogy.
The
The prediction is I think the the small
companies that are
simply
sort of taking simulation data from some
other provider
and doing
let's say ML AI any one of the
methodologies
um making the claims that we're talking
about are unlikely to be successful and
viable companies because there'll be a
number of use cases as we were
discussing before that could be useful,
but they're going to depend very heavily
on on on tight integration
with the simulation tools that are
producing the data in the first place.
And and they're not adding a significant
amount of IP in terms of coming up with
brand new methods that are not fully
published out there. And with PyTorch,
most people who know what they're doing
could actually code up in a couple
months, right? So So I I think there's
going to have to be much more
interaction between companies or tools
that do the AI and the machine learning
and simulation technology in order to be
able to sort of address many of these
different fields. So you you asked me a
question as to where I think this whole
thing is going. And again, I I don't
want to sound cynical at all. I think
I'm very upbeat about it for certain
uses. I
you know, as I get older, I can
pontificate about these kinds of things.
So
over my lifetime, I've seen NX, PVM and
MPI, you know, for for um
message passing sort of things. Then
then you could argue you you see single
core to multi-core processors to
Titanium processors to IBM cell
processors to GPU computing, etc. etc.
You never know which of those things are
really going to pan out and which ones
are going to just, you know, die and
wither on the vine. So
I think AI and ML is a broad uh topic
with many different elements. I think
some of those are going to be successful
and some of them are going to die and
wither on the vine because
uh you know, high-performance computing
simulations are going to be done. They
don't need millions of evaluations and
and therefore you're going to be better
off just doing it directly and not
having to worry about whether you have
to reevaluate, retrain, so on and so
forth. So
So yeah, it's it it's it's early uh
stages. And I think I think you can see,
as I told you, I'm convinced that
there's three, four, five uses where
this is going to be very, very powerful.
And I think there are others where it's
just hype and it'll go away.
One of the um
I think interesting things that you've
done and
and I guess there's a little bit of
analogy to the ML world, which is
this whole argument of open-source
versus closed source. What's the way to
advance things? Obviously, one of the
things I think you have made a large
contribution as well with your you know,
colleagues and people who who founded
the SU2 movement. Um
What do you think are the sort of
What can open-source codes achieve? What
can't they achieve? Well, you know, what
Where do you need to almost have a
commercial company
that an open-source couldn't do? Or I'm
I'm kind of always interested on what's
like the way to advance the science in a
way.
Yeah, so I came to open-source
reluctantly, I would say. We had always
given our codes that we had developed at
Stanford to anybody who wanted them, but
we said, "Here it is, not much
documentation, you're on your own,
right?"
So,
when I came back from NASA headquarters
in 2009, I had
a very talented sort of researcher in my
lab, Francisco Palacios, who uh you
probably have come across at some point
in your before then.
And
he convinced me that we had to ditch our
multi-block solvers and start doing
unstructured, and we said, "Okay, let's
do it." And then he and some of the
students were the ones who said,
"Let's put it on the open-source." And
I'll get back to your question in a
moment, but just for context.
And at the time I was very concerned
about it. I was like, "Well, it carries
the Stanford name, so we cannot have
something that's crappy."
Um
it's something that people are going to
be to a lot of questions, so we have to
have documentation and various other
things. You know, it's not clear that in
a university environment with people who
come and go over time, we're going to be
able to sustain it over a long period of
time. So, it was important to start
enlisting other colleagues,
collaborators around the world.
Um but I had learned a very valuable
management lesson at NASA from somebody
who was my senior technical advisor
there.
And that is that you never say no
because you say yes if. And we organized
ourselves
you know, to make it happen and we put
it out in the open-source and we wish
for the best.
And at the time to be honest, my
ambition for SU2 was to make sure my
students at Stanford didn't have to
redevelop technology every time that was
not intrinsic or or exciting or
interesting for their own research. That
was the motivation.
Um soon after we released it, several
key universities around the world jumped
in and I I I have to say the value of
open-source
was twofold. One One was about building
community of people who had different
areas of expertise but were like-minded
about developing new capabilities and
sharing it.
Um and I would say it was also very
important uh
to make sure that we generated an a new
generation of graduate students who were
trained in these five types of tools who
then go out to industry and sort of do
amazing things. So, so to me SU2 was the
most wonderful experience that was
completely serendipitous and it
continues to this day.
Mhm. But
open-source at least at the level of
SU2, you know more about OpenFOAM than I
do although we we've interacted with the
OpenFOAM team many times.
Um
if you think the most important thing is
X
and the universities have funding for Y
Y gets done
and X, you know, maybe we make a little
bit of progress if we organize ourselves
and we put a foundation together and
various things, we tried all those
things.
So, what ends up happening is that the
progress is slower.
You know, what you can do in industry,
with venture capital funds, with focus,
with ex- experienced people who are not
coding, you know, the solver for the
first time, etc., etc., means that you
can do things much more quickly, more
professionally, more robustly, uh and
you can do end-to-end solutions. It's
very hard to do that in open-source, as
you know. Um
at the same time,
it's how you train people to be able to
do great things, because they have
access to every line of code of a
state-of-the-art algorithm, a
state-of-the-art physics model, a
state-of-the-art multiphysics coupling,
a state-of-the-art automatic
differentiation tool. So, I think it in
in academia, we have to figure out how
to leverage open-source tools to train
our students to be the next generation
of people who do amazing things like
we're doing at Luminary.
Mhm. And without those people that
understand the details, you don't get to
do amazing things. So, so there there's
a tremendous value of open-source. At
the same time, you know, I'm back in
academia now.
And
I know academia cannot compete
with the level of talent we put together
at a company like Luminary, and I
imagine other companies that may be
trying to do similar things. And
um it is a good question that I don't
have a good answer to.
That's what academia should be doing to
add value on how could companies team up
with academic teams
to allow the use of these established
tools that that are, you know,
non-research value,
but enable the research in order for
academia to continue to be relevant. And
that's something that I'm I'm struggling
with a little bit right now, and need to
continue sort of pushing on. I
Continuing open-source is one of the
options, right? And then and that I'm
very committed to the future of SU2.
but but there may be other models that
allow us to continue to push the
research boundaries in academia with the
aid of commercial tools. And how how do
we do that? I think it's a good
question. I don't know if you have any
any thoughts
I don't know about that. Yeah, it's it's
um
it's also the case
I mean there's always a healthy um
movement, I guess, cuz you as you say
you need
if all of academia uses commercial tools
with no access to the source code,
they're never going to be able to learn
how to do the coding that is to develop
it. Right. Um but if the code if I think
you said it very well,
if every student has to start from the
beginning,
they never really get to focus on the
novelty bit. So, there needs to be a
foundation and so that it naturally
motivates the desire for codes, you
know, to become more
as a platform, I guess.
It's what you build then on top of it.
And that's why I guess the PyTorch sort
of thing is interesting that there's a
framework that CFD doesn't have, does
it? I mean, if you look at ML, most
people use PyTorch or TensorFlow and
build on top of it.
We
well, I I guess you could argue there's
some linear solvers and things like that
that people try and build on, but we we
haven't been as
coordinated, maybe. Yeah. Um Our
abstraction layer
has not been created as effectively as
AI/ML has done theirs. But of course, it
their theirs is a much much bigger
market, right? So, so there is there is
a very very high value to creating those
abstraction layers for execution in any
platform um than there is for CFD,
right? Not many people around the world
write CFD solvers.
So, um maybe a final question. So, you
you were the author of the 2030 report.
So, if you were going to now
put down what you think is this s-
2050
Yeah. What would you put as the grand
challenges? The stuff that can't be done
now
and are the things that still we need to
put as our grand challenges? If we
assume that the goals of 2030 are
achieved in 2030 or before, right? Let's
assume, like I mentioned, that inner
flow, inner workflow Mhm. is is fast, is
accurate, it always works, you know,
it's scalable, it can be executed
anywhere you want. So, let's say we've
forgotten about that.
I think the challenge, the the next
challenge is the outer flows
and how we're going to achieve them.
So, the outer flows for me are, you
know, always optimization, design
optimization, uncertainty
quantification, design and their
uncertainty, AI/ML, you know, those
things that require repeated evaluation
of the actual, you know, physical
models, right? So
So, I think it's all about that. I think
it's about multiphysics.
It's about judicious use of ML/AI,
right? The um
I think those are the challenges, but
then there are many, many challenges of
how we get there.
Right? Then Mhm. um
I strongly believe we're going to have
GPUs around for another 6 to 10 years.
That's the interesting one, isn't it?
Hardware, because it feels like
it's been machine learning that has made
GPUs. It's nothing to do with CFD, is
it, really? They didn't We haven't
suddenly got more GPUs cuz someone got,
"Oh, I really like fluid dynamics and
they're helping wind tunnels." It's
It's just come back
learning, it was video gaming. It's not
It wasn't the machine learning and it
wasn't computing, either, right? So
Yeah. um
We're going to run out of
ideas and and how to make these things
faster at some point with GPUs, as well,
right? The
Uh we can still do a few things. So,
there's there's a lot of technology that
I'm sure you know about um that gives me
confidence that that it's a stable model
for at least a good number of years,
right? Um
Um but there's going to be other ways in
which we use artificial intelligence. Uh
there's going to be quantum computing
coming along. I mean, if we're talking
about another 20 years, right? 2030 CFD
was written in essentially 2012. So, it
was almost a 20-year prediction.
So, we're talking about 20 more years.
It's not out of the scope that many of
these things will But would you not say
that
the irony
which goes back to right at the
beginning when I said about what's the
difference between design then and now
is it takes people 20 years to change
the way they work sometimes. That like
you know, the technology arguably
that you as a company are building in as
you said you're doing it now because it
has reached maturity
and then maybe over the next 10 years
people will start to use it. Yeah. But
it takes time. So, maybe the 2050 is
just that everybody will be using the
stuff available now
in production. I don't know, you know.
There's a human time constant that is
very important because it takes time to
build experience, build processes, so on
and so forth. Maybe there'll be
technology that accelerate that, but
that's been a constant over time.
Mhm. But there's also something that I
would say about the human beings is we
never stop innovating.
So, I I think we'll be using So, the the
state of the art in 2050 will be that
nobody will be thinking about
just doing a single simulation. They'll
be running a thousand simulations
simultaneously in 2 minutes. They'll be
real models about it and they'll be
querying them and you know, our vision
at Luminary was always the the Jarvis uh
Iron Man vision. I don't know if you're
familiar with that. It's this little AI
that Tony Stark has where you're like,
"Oh, I want to design a new rocket.
Yeah. here's three options you have. So
So, my guess is that people in 2050 will
be doing ensembles of simulations and
extracting information from those in
both design, uncertainty, risks, so on
and so forth, and that will become
commonplace. These are things that
academia has been sort of working on for
the last 10 years at least, I would say,
and and they're they're going to be
transitioned to become commonplace, but
there'll be something else beyond that.
Right? So,
I hope so.
It's something to work with.
Yeah.
That's it.
But but I I I have tremendous faith that
we'll keep innovating and however slowly
for those of us who are involved in this
business, you know, we see it day-to-day
and it seems slow, but when you look
back 10 20 years, you're like, "Wow, we
actually got some stuff done, right?"
There's been some step changes along the
way. There'll continue to be step
changes along the way by the year 2050.
So, I'm I'm quite bullish on the uh
on the future of computational driven
science. I think it's largely going to
replace physical experimentation by 2050
for sure in many engineering
disciplines, let's say. So, Yeah. Yeah.
Well, thank you for doing this. Uh it's
been lovely to chat to you, and I really
do I am so pleased to see, you know, the
Luminary Cloud that it's been launched
now, and I must have been a fantastic
excitement, stress journey, but I really
do wish you all the best and and hope it
is a a big success. People check it out
and um
hope we get to meet in person again
point at some conference and uh have a
drink or a coffee.
I would love to do that. Um thank you
for doing the podcast and inviting me to
the podcast. Thanks for the kind words
about Luminary. We really do think that
there's a nugget there that can help
change the way we do engineering, and
and it's always going to be fed by new
ideas that are going to come out from
academia. So, our academic colleagues
are are also, you know, amazing people
who have made this this current
state-of-the-art
sort of happen and
this is this going to continue along and
I think you and I will have many coffees
and good opportunities to think about
what the future might bring. Yeah,
awesome. Thanks very much. Neil, it's a
real pleasure. Thank you for the
invitation and, you know, have a nice
evening there.
Yeah.