What are the most difficult, computationally complex applications of computers besides nuclear weapons simulations?
I am not very familiar with computer science, so I probably misused some of the terms in the previous sentence.
I’m not sure what you mean. Are you looking for the most computationally intensive applications, in other words, the applications that require the most computing power? Are you asking about the most difficult software to create or understand?
Coupled atmosphere-ocean general climate models are, in terms of raw size and complexity of the data operations, probably the most computationally intensive models currently in “production” use. Several of the world’s largest supercomputing clusters have been built specifically to solve such models. Solar atmosphere models, which include significant plasma dynamic effects, are even more complex and generally have to be highly simplified even with modern tools.
Complex finite element/hydrocode models, especially those involving coupled fluid-structural interaction (FSI) or smoothed particle hydrodynamics can also be very complex. A simulation such as the flow field of exhaust through a duct make require tens or hundreds of hours to solve a single millisecond timestep on a 128 core beowulf cluster. Similarly, multiphysics models of such as even relatively simple magnetohydrodynamic systems (such as plasma flow in a fusion tokamak) have such complex interactions that it is only in about the last decade that really useful simulations have even been possible sufficient to accurately predict flow instabilities. The difficulty of these “simulation” type tasks is to relate the dynamic behavior of the individual parts of the system back to one another while the calculations are going on.
Tasks such as massive database management (done by large online retailers), financial market projection, and gene sequencing are challenging, but more in the sense of managing and relating humongous amounts of data and extracting statistically meaningful trends rather than computational intensity per se. It’s hard, but a different kind of hard than performing dynamic simulation-type work, and goes into the area of data science.
By the way, the original nuclear weapons simulations were essentially parameterized 1D calculations run in parallel by “computers” consisting of young women using industrial adding machines. A simple calculation of, say, one “shake” (10[SUP]-8[/SUP] seconds) would take about a week, and was typically run in parallel for error checking. It took around four months to calculate the yield of the original “gadget” in Fat Man (the bomb detonated over Nagasaki, Japan). You could run the same calculation on a modern desktop computer in the span of a few seconds or less, depending on what language/package you are using, and most of that time would be interpretation and memory allocation/cleanup.
Most of the calculations that were run during the early years of the “Super” program (the follow-on program to the Manhattan Project to develop the hydrogen bomb) provided results that were often off a substantial amount, and several of the more talented weapon designers such as Ted Taylor were capable of making as good or better estimates as simulation codes using rules of thumb, a slide rule, and “engineer’s intuition”. It wasn’t until the 'Sixties that there was sufficient digital computing capability combined with the advent of a truly usable scientific programming language (FORTRAN IV) that sophisticated calculations that could make really accurate predictions of yield of multistage weapons.
Nuclear weapon simulation is frankly probably in the middle of the scale of difficulty in terms of simulation. The real trick (as with any kind of simulation) is assuring that the boundary conditions and interaction dynamics that you have built into the model actually represent all of the pertinent behavior. This is why test data is invaluable in “grounding” (validating) the model and all of the assumptions going into it. Managers who insist that real products can be “tested by analysis” are living in a fantasy world along with a bird of genus Geococcyx and a very hungry and much abused coyote.
Stranger
In the chicken-and-egg thing suggested sounds slightly weighted towards software creation always pre-dating computational ability to run the software (“all we have to is wait until a really fast/big machine comes along”). That doesn’t sound right.
Protein structure prediction is one of the hardest problems out there, to the point where people are building specialized supercomputers just to do it.
In the Wikipedia entry on supercomputing, it suggests the following:
weather forecasting, aerodynamic research, probabilistic analysis, radiation shielding modeling, brute force code breaking, 3D nuclear test simulations, molecular dynamics simulation, simulation of artificial neurons, quantum physics, molecular modeling, climate research, oil and gas exploration
Some of them, maybe, but the solar physicists I knew ran most of their codes on plain ordinary Sun workstations.
And the same supercomputers, and very close to the same codes, that are used to simulate nuclear weapons are also used to simulate supernovae. It’s only been in the past five years or so that the supernova simulations have actually managed to explode: Apparently, a 1-D or even 2-D simulation isn’t enough to capture all the necessary detail.
Yet another difficult computational task, where the first solutions only recently became possible, is numerical relativity, simulating the merger of two black holes. There, though, the difficulty isn’t so much in terms of requiring a great many processor cycles, but in designing the code: All of the codes used for it up until 6 or 7 years ago just plain wouldn’t work no matter how long you let the computer run, and they had to introduce all sorts of sophisticated mathematical tricks to overcome that.
Note that in general the difficulty of “problems” in computer science are traditionally measured in two ways - time complexity and space complexity, usually written in O notation.
For example something with time complexity of O(n^2) basically means that the time to run the algorithm is proportional to the square of the size of the input.
Most of the problems given above are slow not because the problem to be solved is conceptually that complex, but because the datasets to be worked upon are just so damn massive.
You can take a much tinier lump o stuff (sizewise) to what’s involved in those problems above and say “generate me all the unrestricted permutations of this poset” and all the supercomputers in the world couldn’t do it.
This may seem like it only has academic interest, but it has masses of real world implications. Most relevantly (and it all stems from this) lookup whether P is NP…
Crysis
A lot of supercomputer problems have effectively unbounded complexity. Nuclear simulation, weather modeling, etc. work by dividing a volume into some number of elements. The finer the divisions, the better results you get (to a point). So you can’t really qualify one problem as more difficult than another; you just use as much supercomputer as you have available and as much time as you can afford. Any increase in supercomputer power can be spent immediately.
Some time-consuming problems are rather frivolous; e.g. large-number factorization, Chess endings, or the recent solution of Goofspiel.
Richard Feynman discusses this in one of his books. During the project they switched to IBM card machines; Feynman’s team developed a clever scheme, involving colored cards, to maximize throughput despite errors.
The Female Orgasm, if someone could write code for that, we’d be rich.
I see that I chose the word “application” poorly. I mean the former; what is the computationally intensive usage of computers.
Diesel engine combustion simulation is a bitch:
-the combustion chamber varies in size with time, with stationary and moving boundaries
-the mixture is spatially and temporally inhomogenous, and includes liquid and vaporous fuel
-the simulation must account for time-varying fluid mechanics, heat transfer, multi-phase mixing, and a huge array of intermediate chemical reactions that we ordinarily lump together and refer to as “combustion”
When I was in grad school our department had a Cray dedicated to this task. By the time I left school, desktop workstations were up to the task, but I’ll wager this was only because the simulation models they were using hadn’t been refined to take advantage of the higher computing power that a new supercomputer might have offered. I haven’t checked back, but I’ll bet that the models they are using nowadays are even higher in resolution and account for more complex interactions, such that they still take the same amount of time of time to run to convergence (i.e. hours to days).
Yes, but the time/space scale at which you get diminishing returns is basically what matters. As a civil engineer I can get good information running a simulation with a mesh size of inches to feet, depending on the individual problem. I can get better information using a smaller mesh, but not that much better. For something like nuclear weapon detonation, the scales are much smaller, so I think it’s reasonable to say that it’s a more difficult problem even if I could theoretically use the same amount of computing power to model beam bending or the settlement of a mat foundation.
Of course they did. 
What brand did the ones working on other stars use?
And as long as this is my specialty, I can give a couple of numbers that put the calculations in perspective regarding their complexity. Assuming a protein of 100 amino acids in length (a small protein), you have 100 amino acids that each have between 2 (glycine/alanine) and 6 (Lysine/Arginine) rotatable bonds as well as having between 10 and 26 atoms each. There are known energy minima that can be used to shrink this space to fewer possibilities (for instance the Ramachandran plot. But still every additional degree of rotation is multiplied many fold across all of the amino acids. Bond lengths are often held fixed to speed up the calculations but in reality are variable as well as oscillating in ps time frames. Now for every motion of folding you have to calculate the electrostatic charges between all of the functional groups, the energetics of desolvating any group, hydrogen bonding between atoms, unsatisfied hydrogen bonds, pi stacking, van der Waals forces as well as repulsion.
So quite simply you have 100 amino acids with an average of 19 atoms in 3 dimensions with a ~14 component forcefield in which many of “forces” take advantage of statistical terms and the remainder need to efficient calculate the interactions between each atom and all of the other 1899 atoms that it could be interacting with. Thus adding another amino acid (#101) and you have 19*1900 new possible interactions across 3D space with a 14-component forcefield and you start to see how the problem doesn’t scale well.
Coming from a Computer Aided Engineering (CAE) background, I would say unsteady turbulent flow in Computational Fluid Dynamics (CFD). Whereas most CAE simulations give you definitive, albeit approximate results (and subject to GIGO), unsteady turbulence is only going to give you probabilistic results due to its inherent unpredictability. Though, since I’m more of a structural expert with just a passing familiarity with fluids, this could be just me saying, “Ooooh, scary CFD.”
Stranger-without-an-i makes a good point about coupled-field analysis. Until recently, physics calculations within CAE were standalone. You did structural OR thermal OR fluid OR electromagnetics. But now there’s a bigger push to more accurately simulate “real-life” by considering the interactions of two or more physics environments.
Hah, that hadn’t even occurred to me. I can’t speak in general, but my advisor’s codes all ran on whatever Unix boxes her grad students happened to have lying around, most of which were scavenged from machines that would otherwise have been thrown out. Which means that they were all thousands of times more powerful than the machines those codes were written to run on.