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 are vendor benchmarks, reference customers, a proof of concept on last generation's hardware, and none of them tell you how your own codes will 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.