From a CFD perspective, I think this analysis is flawed because of two things:
1) any organization thinking about buying a 1000-core cluster will have at least one in-house code. The reason being that none of the commercial ones really scale well to much beyond 50 cores. And that changes the comparison a lot, since any external support for an in-house code will be really expensive. (If you've ever looked at an in-house CFD code, you'd generally be mortified at the coding.)
2) they say that hardware costs are only 1/3 of total costs, but they are assuming a slow-ass interconnect that no-one in their right mind is considering today. Once you go up to a real HPC cluster with 1:1 non-blocking FDR or dual-rail QDR, hardware costs are more like 3/4. And really, you need that kind of interconnect to be able to scale around the memory bandwidth bottleneck, which any code that does stencil operations is bound by.
But if your organization is, say, a Gromacs shop working on chemical engineering, it could make sense.
1) any organization thinking about buying a 1000-core cluster will have at least one in-house code. The reason being that none of the commercial ones really scale well to much beyond 50 cores. And that changes the comparison a lot, since any external support for an in-house code will be really expensive. (If you've ever looked at an in-house CFD code, you'd generally be mortified at the coding.)
2) they say that hardware costs are only 1/3 of total costs, but they are assuming a slow-ass interconnect that no-one in their right mind is considering today. Once you go up to a real HPC cluster with 1:1 non-blocking FDR or dual-rail QDR, hardware costs are more like 3/4. And really, you need that kind of interconnect to be able to scale around the memory bandwidth bottleneck, which any code that does stencil operations is bound by.
But if your organization is, say, a Gromacs shop working on chemical engineering, it could make sense.