I can elaborate a bit. Most of the large-scale problems are actually as straightforward as “just throw a supercomputer at it”. However, just like when mathematicians say “that’s an implementation detail”, it turns out that actually throwing a supercomputer at the problem is much more difficult to do in practice than merely setting up some shell scripts to run, especially where scientific computing is concerned. For one, there’s usually no concept of “micro services” or “containerized” applications, at least not in my experience. Most of the modern distributed computing practices are actually thrown right out the window when it comes to scientific computing, since the scientists are going to be directly programming distribution schemes via MPI and stuff. The reason is because academic projects don’t have lots of money and need to efficiently use every dollar, and because most of the time distribution schemes really aren’t suitable for the science. You might have one layer where node interactions occur according to some mathematical and physical criteria instead of “load” or some other abstract flag, for example; that’s a bit harder to code for, and it’s much better to have a domain scientist who knows the physics deciding how to decompose the problem, instead of a computer scientist who has no idea of the physics adopting a scheme which ignores the problem entirely. Hence why I said most scientific tools are “bespoke”.
The result is that most of the distributed systems people are moved to a supporting role, where their job is to develop tooling and libraries to allow for better communication between nodes, for example. I’ve also heard of some compsci people being directly integrated into these scientific teams to develop specialized APIs and such in-house, but that’s a bit more rare imo. These are just some examples of how science and compsci intersect; for example here’s one group I know of: https://www.ornl.gov/group/dcs