Review qubit operand separation in strings in old style configuration files

[jvansomeren]

In old style configuration files in the instruction and decomposition sections keys (and decompositions) contain gates with operands. Those operands are identifiers such as q0, %0, etc. In those keys and decomposition sections, those operands are separated by a single comma optionally with spaces around them (that is the way that OpenQL accepts those rules).
But when those commas are omitted and only white space separates those operands, OpenQL cannot match those keys with actual gates with operands and/or when in decomposition rules operand separation no commas are used, the generated gates cannot be matched with instruction and decomposition rule keys. The end-effect is that particular gates are not decomposed and end up in the resulting qasm or at the entry of the code-generator. Examples have been seen of such behavior with cnot and swap gates (because these are the ones that occur often and need decomposition, also because swap decomposes to cnots).

Exactly which absence of commas is accepted and which result in non-matching has not been investigated yet.
What has been done, is a consistent replacement of sole white space by commas, which worked out well.

So the following are suspect in the decomposition section:

• key: “swap q0 q1” (specialized decomposition)
• key: “swap %0 %1” (parameterized decomposition); key: “swap” (parameterized decomposition) is ok
• subinstruction in the decomposition: “cz q0 q1”
• subinstruction in the decomposition: “cz %0 %1”

And in the instructions section:

• key: “cz q0 q1” (specialized instruction)
• key: “cz %0 %1” (parametrized instruction)

What needs to be done:

• verify what is documented: for each of those cases above: a single comma, only spacing, or a comma with opt. spacing
• check all json files in OpenQL (tests/.json and src/ql/arch//resources/*.json) on this
• decide whether the practice of all json files in OpenQL is ok, i.e. an update of OpenQL should accept all current practice
• decide on what will be ok and what not
• update the documentation accordingly
• verify what is silently accepted though not according to the documentation
• solve that in OpenQL where json instructions/decompositions are read, and give the appropriate error when wrong
• add tests

[jvansomeren]

Part of the problem is existing practice: some json files for cc and for diamond use a space as separator in the key in the gate_decomposition section and/or in the sub instructions.
Are the following used:

• src/ql/arch/cc/resources/hwconf_default.json
• tests/cc/cc_s5_direct_iq.json
• src/ql/arch/diamond/resources/hwconf_default.json

Nowhere in the code is checked when reading a json file what is the case. Only some sanitation is done: removal of redundant spacing. Resulting keys are accepted and stored in the instruction_map.
When finding keys on gate creation in the instruction_map, a comma without spacing is required, hence those finds fail.

[wvlothuizen]

The documentation is quite clear that the operands should be a comma separated list:

• https://openql.readthedocs.io/en/latest/gen/reference_configuration.html#instructions-section
• https://openql.readthedocs.io/en/latest/gen/reference_configuration.html#gate-decomposition-section
  In practice, extra spaces are allowed, in an attempt to cope with the historic mess.

The spaces as operand separator are probably a hangover of #214 (Jan 2019), and were already unsupported in https://github.com/DiCarloLab-Delft/OpenQL/blob/0.8.1.dev4/src/hardware_configuration.h#L157 (which is the version that now still runs on QI)

For reference, the extra check should be built into:

• platform.cc, which handles the 'old' API, see Platform::load()
• old_to_new.cc, see parse_instruction_name()

[jvansomeren]

The gate_decomposition section only specifies commas in an example, not in the text. So the documentation text should be updated as well. Conclusion for the interfacing to PycQED: standardizing on a comma optionally surrounded by spacing as separator of qubit operands in keys in instruction and decomposition sections and in decompositions is ok. All spacing that we see is either old stuff already repaired in updates to come or backward compatibility that can be deleted. Op 4 apr. 2022, om 10:08 heeft Wouter Vlothuizen ***@***.******@***.***>> het volgende geschreven: The documentation is quite clear that the operands should be a comma separated list: * https://openql.readthedocs.io/en/latest/gen/reference_configuration.html#instructions-section<https://urldefense.proofpoint.com/v2/url?u=https-3A__openql.readthedocs.io_en_latest_gen_reference-5Fconfiguration.html-23instructions-2Dsection&d=DwMCaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=kNdT9ewT6pQdYFkBLR_5-ZqsrSTk7k5Hdd7MSC_Vnzg&m=yLJPbNMkLnhiQ3OfcVKuJFzyPxqja2qhbc4H7ffd1Fk&s=pRe0tuUPlbF2nDNGFyf9pJgFqcJNoE7E9ZIgdpYBpY0&e=> * https://openql.readthedocs.io/en/latest/gen/reference_configuration.html#gate-decomposition-section<https://urldefense.proofpoint.com/v2/url?u=https-3A__openql.readthedocs.io_en_latest_gen_reference-5Fconfiguration.html-23gate-2Ddecomposition-2Dsection&d=DwMCaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=kNdT9ewT6pQdYFkBLR_5-ZqsrSTk7k5Hdd7MSC_Vnzg&m=yLJPbNMkLnhiQ3OfcVKuJFzyPxqja2qhbc4H7ffd1Fk&s=UDKatUfVJqYphGdt9rU_4vgluCIYObeAzig9e2WCKEs&e=> In practice, extra spaces are allowed, in an attempt to cope with the historic mess. The spaces as operand separator are probably a hangover of #214<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_QuTech-2DDelft_OpenQL_pull_214&d=DwMCaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=kNdT9ewT6pQdYFkBLR_5-ZqsrSTk7k5Hdd7MSC_Vnzg&m=yLJPbNMkLnhiQ3OfcVKuJFzyPxqja2qhbc4H7ffd1Fk&s=ieNMUUCQc2_BBzdFszUrKMUSNxDudPAZfmYG8KNVHMc&e=> (Jan 2019), and were already unsupported in https://github.com/DiCarloLab-Delft/OpenQL/blob/0.8.1.dev4/src/hardware_configuration.h#L157<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_DiCarloLab-2DDelft_OpenQL_blob_0.8.1.dev4_src_hardware-5Fconfiguration.h-23L157&d=DwMCaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=kNdT9ewT6pQdYFkBLR_5-ZqsrSTk7k5Hdd7MSC_Vnzg&m=yLJPbNMkLnhiQ3OfcVKuJFzyPxqja2qhbc4H7ffd1Fk&s=QBRkFfqgyGbfUXgrLXHmxYs227DvHN62pD32ay7_Fb4&e=> (which is the version that now still runs on QI) For reference, the extra check should be built into: * platform.cc<http://platform.cc>, which handles the 'old' API, see Platform::load() * old_to_new.cc<http://old_to_new.cc>, see parse_instruction_name() — Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_QuTech-2DDelft_OpenQL_issues_444-23issuecomment-2D1087243967&d=DwMCaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=kNdT9ewT6pQdYFkBLR_5-ZqsrSTk7k5Hdd7MSC_Vnzg&m=yLJPbNMkLnhiQ3OfcVKuJFzyPxqja2qhbc4H7ffd1Fk&s=7MfV95ccDM4B4G_m3AWUJqhH_w-ebAfcJjpiHcOiDlU&e=>, or unsubscribe<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AEDTBNWNFB5BHS6HZSBZA4DVDKPPLANCNFSM5SKVWI7Q&d=DwMCaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=kNdT9ewT6pQdYFkBLR_5-ZqsrSTk7k5Hdd7MSC_Vnzg&m=yLJPbNMkLnhiQ3OfcVKuJFzyPxqja2qhbc4H7ffd1Fk&s=1OWJwHbi4sn0g2lRGDfXqVXMKaTfBdxTH6n7E0VqueU&e=>. You are receiving this because you authored the thread.Message ID: ***@***.***>