a follow-up piece for hpcwire, this one about procurement rather than development.
buying a supercomputer means committing tens of millions to a configuration chosen largely from benchmarks that are not your workload. get it wrong in one direction and you have paid for capability that sits idle; get it wrong in the other and the machine is saturated the month it arrives. the usual mitigations — vendor benchmarks, reference customers, a proof of concept on last generation's hardware — all stop short of the thing you actually want to know, which is how your codes behave on this machine.
emulating the system first turns that into an empirical question. run the real applications against a digital twin of the proposed configuration and find out whether you are short on interconnect bandwidth or on node count, before the purchase order rather than after. that helps the vendor as much as the buyer: most of the risk in a deal that size is a customer discovering eighteen months later that they bought the wrong shape of machine, and unhappy reference customers are expensive.