JIJ and Mitsubishi Electric put a hybrid solver into an industrial test program
The companies will evaluate a concrete engineering workflow and its computational costs.
JIJ and Mitsubishi Electric have secured a place in the JHPC-quantum Test User Program to evaluate a quantum-classical hybrid linear solver for thermal-fluid analysis. JIJ announced the selection on October 26, with Mitsubishi Electric leading the proposal.[1]
The work targets systems of linear equations used in simulations of heat and fluid behavior. The companies intend to combine industrial simulation experience with quantum-computing methods through a program associated with quantum and high-performance computing integration.[1]
The announcement establishes a planned evaluation. It does not report a completed benchmark, a faster industrial simulation or deployment in a customer product. The specific performance advantage remains a question for the experiments.[1]
Editorial interpretation
The useful test will be whether the complete workflow delivers an acceptable answer more efficiently than a strong conventional solver. That comparison should include preparing inputs, transferring data, quantum execution and checking the output. A successful proposal is the beginning of that assessment. Published methods and results would make the outcome assessable.
Learn: Time the whole hybrid quantum workflow
A hybrid algorithm earns its practical value through the complete job it performs. The quantum portion is one component of that job. Data preparation, classical computation, communication and measurement can all affect the time required to obtain the answer a user actually needs.
JIJ's announcement with Mitsubishi Electric describes an evaluation of a hybrid linear solver for thermal-fluid analysis. Evaluations of this kind are most informative when their timing boundaries and output requirements are stated before the comparison begins.[1]
Worked example
Hypothetical example: a quantum subroutine takes 2 milliseconds, input preparation takes 100 milliseconds, extracting the required result takes 20 milliseconds and coordination takes another 10 milliseconds. The complete assumed workflow takes 132 milliseconds. If a classical workflow produces the same required output at the same accuracy in 50 milliseconds, comparing only the 2-millisecond subroutine with that 50-millisecond job would answer the wrong question. These numbers are an illustration, not results from the announced project.
The comparison should also define the output. A method that estimates one quantity from a solution may have a different cost from a method that returns every element of a large solution vector. Both can be useful, but their outputs must match the engineering question being tested.
Repeated use introduces another distinction. A setup cost might be reusable across many jobs. If so, report both the first-job time and the sustained cost under the stated reuse assumptions. Include failed runs and repetitions needed to reach the chosen accuracy rather than timing only the best successful attempt.
A good benchmark is therefore a small contract with the reader: this input, this output, this tolerance, this hardware and this timing boundary. It should compare against a competent classical approach and explain whether queue time is included. Those details make a positive result credible and a negative result useful for deciding what needs to improve next.