[NamTaf]

In my experience from solid mechanics, generally no. I don’t know exactly why, but my guess would be that there’s a significant lag time in development of these packages. They are conservative and heavily favour accuracy to speedy new techniques.

Often they use back-end solvers that are very old. For example I use FEMAP professionally and it’s essentially a pre- and post-professor over NASTRAN, which is way older than me. Adding GPGPU to it would be difficult indeed, and no one will pick a less accurate new solver without it having been robustly proven (it’s a chicken and egg problem, in a way).

Also, GPUs aren’t suited to all problems. You still have the memory limits of GPUs which aren’t as Large as traditional RAM (I see no GPUs with 32-64GB RAM). They’re not the silver bullet people sometimes hope for.

Lastly, the people who do this are surprisingly less overlapping with the flashy new IT development-aware crowd than you’d expect. They’re not Silicon Valley types with their finger on the pulse of the latest and greatest. Most just use PCs as a tool and wouldn’t know the benefits GPGPU could provide. To them, video cards are just video cards.

[tgamblin]

There are plenty of scientific and engineering fluid dynamics codes that take advantage of GPUs. The current fastest supercomputer in the US, Titan at ORNL, uses GPUs. Here’s a CFD code that ran on it: https://www.olcf.ornl.gov/2014/06/13/ramgen-takes-turbomachi.... ORNL likes their OpenACC; here’s a GTC presentation on the code: http://on-demand.gputechconf.com/gtc/2014/presentations/S475...

LLNL and ORNL are right now rolling out two new gigantic GPU systems, Sierra and Summit: https://www.google.com/amp/s/www.nextplatform.com/2017/09/19.... There will be plenty more GPU CFD simulations of running on those systems.

[fermienrico]

I understand the difficultly with legacy code, but your opinion about "Silicon Valley" types, etc. is very off putting.

World needs to evolve. Those who do not, disappear.

If there is a way without sacrificing accuracy, then GPU computation would be absolutely amazing. Imagine the productivity boost, time savings, power and infrastructure savings you'd gain by using a GPU (if it is possible that is). Imagine being able to simulate engineering problems in near real time without having to wait for hours for a solver to converge.

I don't have experience in the solvers, but if there is a way to enable GPU computation then why the hell not!? Silicon valley types or not. People who are engaged in CFD (I used to work at Lockheed's flutter dynamics team) are certainly not "old fashioned" as you describe. GPU to them wouldn't just be a "kid's video game toy" - I can assure you having worked with these folks.

[bauta-steen]

Perhaps the main issue is that even if a PDE solver supports distributed CPU parallelism, the distributed block solvers do not typically allow for decoupling to thousands of independent threads that GPUs are good at. Therefore as the PDE problems and solvers are tightly coupled they do not easily parallelize to GPUs and don't allow for simple recompilation with GPU targets. Most often an existing code would require a complete rewrite/redesign (man years of work for big code bases), at least if there are to be any gains to be had. There are new codes coming, particularly in academia, utilizing GPUs. From what I've seen one can expect around 10x improvement switching to GPUs, so it's good, but not magnitudes better considering the work involved.