qutech-delft / openql Goto Github PK

Additional tests for existing features.
Always add proper tests to new features.
detailed look into coverage with py test as why it is not being reported. may be because fo symlink issue as mentioned by Adrian or because of improper coverage compilation flags for underlying C++ code !

Add support for T and Tdag gates for lingling.

@imranashraf , I did a fresh update of the latest work on the CCL eqasm compiler branch and I get massive amounts of assertion errors. These cause my program to crash (much harder than ever before).

I would like to know what happened and how they got introduced.

For clarity, I am working on commit 2e55705 . I have first deleted the cbuild folder and then reinstalled everything using pip install -e . . Runing py.test -v directly after leads to these problems.

This is running on windows (the intended measurement computer). Error message is shown in screenshot below. I will try if this reproduces on my laptop.

To ease the installation process of OpenQL (especially on windows) we should make a conda build recipe for each release version of OpenQL. We'll have to look into the details on how to include the build files for the conda installs.

Docs for conda.
http://conda-test.pydata.org/docs/intro.html

Depends on #131

The basic compilation should include

• single qubit gates
• two qubit gates
• measurement

This issue can be closed when:
There is a working python test containing a basic program that gets compiled and produces valid CC-light instructions.

• A basic program must contain single qubit gates, two qubit gates and measurement.
• The basic program should contain an example configuration file.
• The validity of the output must be tested using the CC-light assembler from within the test.
• If possible the validity of the output must be verified by hand by testing on hardware and/or using the simulator. If this is valid, the output eQASM should be saved in the golden folder for future tests.

Current expected delivery date: Aug 25.

There are several use cases that motivate gates that have arguments beyond the target qubit(s). Examples are:

• Specifying a variable wait instruction (timing) as required for e.g., a T1 experiment.
• Gates with a varying rotation angle e.g. r(theta, phi) (rotate theta degrees along axis phi).

Points of discussion

• Syntax within OpenQL programs
• How to format the platform_config.json file
• What is the meaning of the arguments specified in the config

I propose the following syntax within OpenQL, I will use the wait instruction as an example.

k =ql.Kernel()
k.gate('wait', 0, 10) # This would be an extension of existing syntax 
k.gate('wait', q=0, wait=10)  # this is the same existing syntax but using keyword args 
k.wait(0, 10)  # this adds custom gates as a method to the kernel as per issue #14 
k.wait(q=0, wait=10) 

    platf = Platform('OpenQL_Platform', platf_cfg)
    p = Program(pname="AllXY", nqubits=1, p=platf)

The nqubits parameter can be extracted from the platform.

Allowing overwriting of certain settings in the configuration (such as e.g., the latency for a specific pulse) is required to do things like timing calibration experiments.

@imranashraf
If the config json file is not found, the python interface raises the wrong error.

Below is the traceback of running some tests (in pycqed).
The file not found error is correctly printed form the C++ running under the hood, however this does not "raise" the error (only logs it).

The error that is finally raised is
[openql] [x] error : ql::hardware_configuration::load() : eqasm compiler backend is not specified in the hardware config file !

Traceback below

__________________ Test_single_qubit_seqs_CCL.test_single_elt_on ___________________

self = <pycqed.tests.test_openql_expmts.Test_single_qubit_seqs_CCL testMethod=test_single_elt_on>

    def test_single_elt_on(self):
>       sqo.single_elt_on(qubit_idx=0, platf_cfg=config_fn)

pycqed/tests/test_openql_expmts.py:22:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
pycqed/measurement/openql_experiments/single_qubit_oql.py:240: in single_elt_on
    platf = Platform('OpenQL_Platform', platf_cfg)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = <openql.openql.Platform;  >, name = 'OpenQL_Platform'
config_file = '/Users/Adriaan/GitHubRepos/DiCarloLab_Repositories/PycQED_py3/pycqed/tests/test_data/test_cfg_CCL.json'

    def __init__(self, name, config_file):
>       this = _openql.new_Platform(name, config_file)
E       TypeError: [x] error : ql::hardware_configuration::load() : eqasm compiler backend is not specified in the hardware config file !

../OpenQL/openql/openql.py:669: TypeError
------------------------------- Captured stdout call -------------------------------
[openql] [x] error : failed to open file '/Users/Adriaan/GitHubRepos/DiCarloLab_Repositories/PycQED_py3/pycqed/tests/test_data/test_cfg_CCL.json' !
[openql] [x] error : ql::hardware_configuration::load() : eqasm compiler backend is not specified in the hardware config file !
============================= 4 failed in 4.28 seconds =============================

@Nader-Khammassi I took the liberty to put your email here, hope that is OK.

Hi everyone,

Based on the discussion we had few days ago, I implemented a first representation of the custom instruction definition which can be supported in OpenQL to offer more flexibility to the users in the short term.

Here, I propose the following instruction description template and its corresponding implementation in the standard “JSON” format, the current implementation matches the internal
OpenQL interface for qasm instruction definition as well. I share with you also some notes on some implications of this instruction definition for the current OpenQL compilation stages and the resulting requirements in term of the hardware description.

You can find attached as well an example of the “JSON” file which uses this paradigm to specify an “rx180” instruction.

I propose to focus the discussion on the instruction definition at this point, if you have any comments or suggestions, please let me know.

1. Custom Instruction Definition:

The custom or “generic" instruction is defined by the following attributes:

“qasm” : the qasm identifier or name of the instruction, for example: “x180", “ry90”, “abc”… etc (the type of this attribute is a string).
“parameters” : this is the number of parameters, for instance this value could be 1 if the instruction is acting on a single target qubit or 2 if it is acting on a control and target qubit, etc… (the type of this attribute is an integer)
“qumis” : this attribute includes the sequence of microcode instructions associated to this qasm instruction, for example: { “pulse 0100 0000 0000”, “wait 5” } (the type of this attribute is a list of strings)
“duration” : the duration of the instruction in ns. (the type of this attribute is an integer)
“latency” : the latency of the instruction in ns. (the type of this attribute is an integer)
“channels” : this corresponds to the hardware resources used or "kept busy” during the execution of this instruction. For example, this value can be : { “awg0“ , “vsm" } (the type of this attribute is a list of strings).
“type” : this field specifies the type of the instruction such as “flux” or “rf” as suggested by Adriaan.
“matrix” : this field provide a mathematical description of the effect of the instruction on the quantum state when executed, this is required to enable optimizations on the compiler as well as the simulation of the circuit. This attribute is represented as a list of complex doubles. For instance the matrix representation of an “rx180” is { {0.0,0.0 }, {1.0,0.0}, {1.0,0.0}, {0.0,0.0} }

2. Implementation Example in JSON Format

Here is an example of the specification of a working example of the “x180” instruction in the json format, this example can be loaded by OpenQL (tested).

{
    "name": "x180",
    "parameters": 1,
    "qumis": [
        "pulse 0100,0000,0000",
        "wait 5"
    ],
    "duration": 20,
    "hardware": [
        "awg0",
        "vsm"
    ],
    "latency": 3,
    "matrix": [
        [
            0.0,
            0.0
        ],
        [
            1.0,
            0.0
        ],
        [
            1.0,
            0.0
        ],
        [
            0.0,
            0.0
        ]
    ],
    "type": "rf"
}

3. Notes on the Implications for the Compilation Stages and the Hardware Description

3.1. Compilation : Custom Gate Decomposition

The different compilation phases such as the circuit synthesis, decomposition (expansion) and optimization (compression) happens at the qasm gate level, these compilation phases operates usually on a common gate set (mainly Clifford+T gates since most circuit synthesis/decomposition techniques on the literature operates on this gate set).

This means that a custom qasm instruction can be handled by the compiler in 2 ways:
The instruction is introduced “inline” in the gate sequence such as in classical code (inline assembly code can be inserted inline in a c/c++ code for example). In this case the compiler cannot do much about the instruction more than converting it into QuMis code ! The side effect of this is that this will break the circuit into segments of optimisable qasm sequences and consequently would prevent any global optimization on the overall gate sequence if it contains such instruction, this is pretty similar to the effect of the measure instruction.
The compiler can take into account a decomposition of a custom instruction into the a common gate set (Clifford+T) then operates on a homogeneous qasm constituted exclusively of Clifford+T. In this case a decomposition should be provided by the user as an additional attribute: “decomposition” : { “x180(0)” , “t(1)”, “cz(1,0)”, … } . In this case, these operations can be fully supported by the compiler at all stages. Automatic decomposition of such custom instructions by the compiler into Clifford+T based on the matrix representation can be quite complex and should be excluded at least for now.

These 2 ways of using custom instructions do not exclude each others and should be discussed later, a good compromise in my opinion is to make the “decomposition" attribute optional to allow more flexibility and allow later works on the second point. For now, the first case should be supported by the compiler.

3.2. Hardware Description

On the hardware description side, mainly 2 attributes of the instruction definition are tightly related to the hardware description:
The first one is the “channels” attribute which specifies the hardware resources used by the instruction, so the values of this attribute (“awg0”, “awg1”, “awg2”, “trigger1” … etc) should be defined in the hardware setup description.
The second one is the “type” attribute which indicates the type of the operation (Flux or RF …), a matrix of the latencies required by the ordering of the operations (based on their types) should be specified in the hardware description file.

This simple hardware description could be described in a simple JSON file which contains at least these 2 fields, I am currently working on how to link it to the instruction description.

@Adiaan: can you provide me with some numbers of the latency matrix ? Thanks.

Best Regards,
Nader

When running the default test script test_cc_light.py:

The control store is then generated:

There are two problems in the control store:

1. A single opcode (the number in the first column) appears for many times. For example, the opcode 32 is configured 16 times with different left operations and right operations.
2. Different left&right operations should belong to different opcodes.
3. The two-qubit gates should have an opcode which is larger than 128. Line 3 to 18 indicate that the opcode 32 corresponds to a two-qubit gate. However, QuMA will raise an error since it only treats the opcodes ranging from 128 to 255 as two-qubit gates.

Also, another important part which is missing is the QISA instruction opcode definition table. An example of this is here. This is an essential part required to generate the assembler for this control store.

Timestamps added to lines of QISA. This is required for extracting timing of flux pulses.

Format is:
Line starts with integer denoting clock that corresponds to the start of the instruction.
Rest of the line contains the actual instruction.
Timestamp and instruction are separated using a colon (:) .
To ensure alignment integers are prepended with spaces.

In the tests folder there is an instructions.JSON.

It is not clear to me how to specify what instructions.JSON (including mapping to qumis) can be specified when starting a kernel. I don't think it is using some hardcoded location but this should be easily doable.

Since every event should be assigned a timestamp before issuing it in QuMA. It is required there is a waiting time before the first operation. Otherwise, the hardware will run into a buggy state and the timing of operations cannot be maintained.

The simplest way to do this is to make the pre_interval value of the first bundle none zero.

In the following example, the first quantum bundle bs 0 prepz s10 can be changed to bs 1 prepz s10.

smis s10 , { 0, 1, 2, 3 } 
smis s11 , { 2, 3 } 
smis s12 , { 0, 1 } 
bs  0    prepz s10
qwait 19
bs 1    x s11 | h s12
qwait 7
bs 1    measure s10

We need a proper way to explicitly specify timings in our circuits. For the moment we have a workaround that is a bit dirty.

We should also discuss how to specify parallelism.
Postponed until after October 1st deadline.

should be able to see:

• name of a program/kernels
• what kernels are there in a program
• what gates are there in a kernel

@imranashraf @Nader-Khammassi

I would like the OpenQL repository to be an open repository. @imranashraf told me that we just need an OK from @Nader-Khammassi .

I think this is important for several reasons in addition to the general open source stuff

• it allows easier integration with PycQED as I can make my test code dependent on OpenQL. This is essential for driving the development IMO.
• it allows free automation of the tests that @imranashraf already made for OpenQL.

I think that both reasons make this something we really want to do.

@imranashraf , I'm playing around a bit with openQL but it is quite hard to find what all the features are and how they work. I'm now trying this out by using an interactive terminal (ipython) and testing what all the functions do. Normally calling e.g., k.clifford? would give me a docstring, however no docstrings at all are specified.

This is problematic because looking at the source code will only show me that it links to a certain binary and does not show me anything on how a function is supposed to behave.

Another problem with this is that it is hard to find all the features are there or how I am supposed to interact with objects.

update scheduling incorporating platform constraints like AWGs, Measurement Units, Edges etc.

Add python interface to the custom gate.

This would require testing CBox eQASM output by running in an experiment.

Openql package should be installable with -e option as:

pip3 install -e .

When specifying the qubit number in the measure instruction
k.measure(0) this passes or fails depending on wether it is an int32 or int64.

The fix should not include any changes on the C++ part of the assembler but it should accept all python Int types (and convert it to the proper int). It should explicitly not do things like rounding or other type conversions.

@imranashraf

When compiling the AllXY code (in PycQED) using the config file attached below, which contains an explictly long duration for the prepz operation, the prepz duration get's compiled away.

test_cfg_CCL.json.txt
Resulting (incorrect) QISA.
AllXY.qisa.txt

Generated using the following function

def AllXY(qubit_idx: int, platf_cfg: str, double_points: bool=True):
    """
    Single qubit AllXY sequence.
    Writes output files to the directory specified in openql.
    Output directory is set as an attribute to the program for convenience.

    Input pars:
        qubit_idx:      int specifying the target qubit (starting at 0)
        platf_cfg:      filename of the platform config file
        double_points:  if true repeats every element twice
    Returns:
        p:              OpenQL Program object containing


    """
    platf = Platform('OpenQL_Platform', platf_cfg)
    p = Program(pname="AllXY", nqubits=platf.get_qubit_number(),
                p=platf)

    allXY = [['i', 'i'], ['rx180', 'rx180'], ['ry180', 'ry180'],
             ['rx180', 'ry180'], ['ry180', 'rx180'],
             ['rx90', 'i'], ['ry90', 'i'], ['rx90', 'ry90'],
             ['ry90', 'rx90'], ['rx90', 'ry180'], ['ry90', 'rx180'],
             ['rx180', 'ry90'], ['ry180', 'rx90'], ['rx90', 'rx180'],
             ['rx180', 'rx90'], ['ry90', 'ry180'], ['ry180', 'ry90'],
             ['rx180', 'i'], ['ry180', 'i'], ['rx90', 'rx90'],
             ['ry90', 'ry90']]

    # this should be implicit
    p.set_sweep_points(np.arange(len(allXY), dtype=float), len(allXY))

    for i, xy in enumerate(allXY):
        k = Kernel("AllXY_"+str(i), p=platf)
        k.prepz(qubit_idx)
        k.gate(xy[0], qubit_idx)
        k.gate(xy[1], qubit_idx)
        k.measure(qubit_idx)
        p.add_kernel(k)

    p.compile()
    # attribute get's added to program to help finding the output files
    p.output_dir = ql.get_output_dir()
    p.filename = join(p.output_dir, p.name + '.qisa')
    return p

This should be the same as the AllXY test in the openQL test folder.

Support the gate decomposition feature that is part of the config.

@imranashraf
When using the OpenQL compiler from python, there are a lot of messages that "flood" my terminal. It would be nice if the verbosity level is configurable.

This problem is discussed at this issue.

The change should happen in OpenQL after it is done in the assembler. Once it is done in the assembler, I will notify this repo.

@imranashraf , When testing your latest fixes I find that there is an error in the .dbpd file that is generated. Some instructions are defined twice, which predictably leads to errors in the assembler.

I have found that this is because of an error in the config file I gave you.
For some Cc_light_instr fields different cc_light_opcodes are defined. The compiler now (incorrectly) adds two entries to the .dbpd file. I think that instead it should raise an exception forcing the user to specify a valid config file.

            "cc_light_instr": "CW_00",
            "cc_light_codeword": 0,
            "cc_light_opcode": 30

@imranashraf

As discussed while going through it today.

• support for I gate
• enable/disable compilation flags
• allow specification of instruction.map file
• creation of output directory

In the file test_cc_light.py, there is the following test case:

    def test_smis(self):
        # You can specify a config location, here we use a default config
        config_fn = os.path.join(curdir, 'hardware_config_cc_light.json')
        platform  = ql.Platform('seven_qubits_chip', config_fn)
        sweep_points = [1,2]
        num_circuits = 1
        num_qubits = 7
        p = ql.Program('test_smis', num_qubits, platform)
        p.set_sweep_points(sweep_points, num_circuits)

        # populate kernel using default gates
        k = ql.Kernel('first_kernel', platform)
        k.prepz(0)
        k.prepz(1)
        k.prepz(2)
        k.prepz(3)
        k.hadamard(0)
        k.hadamard(1)
        k.x(2)
        k.x(3)
        k.measure(0)
        k.measure(1)
        k.measure(2)
        k.measure(3)

        # add the kernel to the program
        p.add_kernel(k)

        # compile the program
        p.compile(optimize=False, verbose=True)

In the file hardware_config_cc_light.json, the cycle time is 5 ns and the duration of prepz/prepx operation is 40 (clock or ns?):

By executing this code, the output of OpenQL is:

[openql] Printing simplified CC-Light QISA
1  prepz q0 , prepz q1 , prepz q2 , prepz q3
21  x q2 , x q3 | h q0 , h q1
29  measure q0 , measure q1 , measure q2 , measure q3
[openql] Printing CC-Light QISA
smis s0 , { 0 } 
smis s1 , { 1 } 
smis s2 , { 2 } 
smis s3 , { 3 } 
smis s4 , { 4 } 
smis s5 , { 5 } 
smis s6 , { 6 } 
smis s7 , { 0, 1, 2, 3, 4, 5, 6 } 
smis s8 , { 0, 1, 5, 6 } 
smis s9 , { 2, 3, 4 } 
smis s10 , { 0, 1, 2, 3 } 
smis s11 , { 2, 3 } 
smis s12 , { 0, 1 } 

bs 0    prepz s10
qwait 19
bs 1    x s11 | h s12
qwait 7
bs 1    measure s10

In this case, the interval between the starting points of the prepz operations and x and h operations is 20 cycles. However, 40 is expected here (assuming the duration is 40 clocks).

It is important to notice that: seen from the eQASM program, the cycle time used in CC-Light will be 20 ns.

Both "Kernel" and "Program" do not have any attributes but a lot of methods to set things which one would expect to be attributes.

To give an example. The program has a set_sweep_points method but no way to see what the current sweep_points are.

This makes it hard to debug and see if everything works.

the converse of #11 .

It should be possible to insert custom gates using the following syntax k.gate_name(*args).

Whenever we apply a 2 qubit gate (CZ) we do this using flux pulses.

Before we initialize for a next experiment ("subcircuit") we need to discharge our bias tee. We do this by applying all the Flux pulses in reverse (same pulse but negative amplitude). This should be included in the output of the compiler.

@imranashraf we should probably discuss this in a bit more detail at our next meeting.

Lingling requires the generation of qubit interaction matrix for CNOT gates.

These are fixed static number of iterations jump statements/loops

@Nader-Khammassi We have decided to drop custom qubit names for now. This would be a good feature to add in the future.

@imranashraf
In the configuration specification https://github.com/DiCarloLab-Delft/OpenQL/blob/master/configuration_specification.md, it is specified that all durations are in ns. The parameter cycle_time should be used for conversion to #cycles.

Currently the parameter cycle_time is not used and durations are assumed to be in #cycles. This is inconsistent with the configuration file for the specification of buffers (in ns).

Scheduling openql code and extract parallelism to generate parallel cc-light code.

Currently openQL generates the QISA, the ControlStore (CS). A third file, known as the map file should also be generated.

Similar to #34 . The advanced eQASM example should include compilation of "fast" feedback using the binary controlled gate.

Work on this should start after #34.

@AdriaanRol I had a discussion with @imranashraf about some tests failing systematically if the user does not update manually the qisa opcode file of the assembler before executing the tests, this can be misleading because the failure reason is not explicitly mentioned in the output (only the "expected" assembler errors are displayed ).

The tests using the assembler are not using the qisa opcode file generated by the openql test code, to make these tests work properly:

1. The generated instruction map file should be copied into the qisa assembler folder (this step should happen each time a different configuration file is used).
2. The qisa assembler should be recompiled.
3. Then the test code can be executed.

These steps should be automated and included in the python test flow.

The CC-light supports the notion of "dummy" operation types as supported within the CCL.

Note that there is a difference between the actual type (MW, Flux, Meas) used in scheduling and the type in the CCL (MW, Flux, Meas, Dummy).

We should add this feature as it is supported in hardware and has concrete use cases. We currently have a workaround but we should solve this after M18.

@imranashraf
open_ql.py seems to be codegenerated (as is shown with the comments up top). When I install open_ql it has a file that is different from what is in the repository. This creates problems when trying to pull in changes from the remote (or generally when making commits).

Should this file be added to the gitignore and excluded from version tracking?

CMakeError

Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe 
Build flags: 
Id flags: 

The output was:
The requested operation requires elevation


Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe 
Build flags: 
Id flags: -c

The output was:
The requested operation requires elevation


Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe 
Build flags: 
Id flags: -Aa

The output was:
The requested operation requires elevation


Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe 
Build flags: 
Id flags: -D__CLASSIC_C__

The output was:
The requested operation requires elevation


Checking whether the C compiler is IAR using "" did not match "IAR .+ Compiler":
Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" failed.
Compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe 
Build flags: 
Id flags: 

The output was:
The requested operation requires elevation


Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" failed.
Compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe 
Build flags: 
Id flags: -c

The output was:
The requested operation requires elevation


Checking whether the CXX compiler is IAR using "" did not match "IAR .+ Compiler":
Determining if the C compiler works failed with the following output:
Change Dir: D:/GitHubRepos/OpenQL/cbuild/CMakeFiles/CMakeTmp

Run Build Command:"nmake" "/NOLOGO" "cmTC_53248\fast"

Generator: execution of make failed. Make command was: "nmake" "/NOLOGO" "cmTC_53248\fast"


Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe 
Build flags: 
Id flags: 

The output was:
The requested operation requires elevation


Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe 
Build flags: 
Id flags: -c

The output was:
The requested operation requires elevation


Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe 
Build flags: 
Id flags: -Aa

The output was:
The requested operation requires elevation


Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe 
Build flags: 
Id flags: -D__CLASSIC_C__

The output was:
The requested operation requires elevation


Checking whether the C compiler is IAR using "" did not match "IAR .+ Compiler":
Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" failed.
Compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe 
Build flags: 
Id flags: 

The output was:
The requested operation requires elevation


Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" failed.
Compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe 
Build flags: 
Id flags: -c

The output was:
The requested operation requires elevation


Checking whether the CXX compiler is IAR using "" did not match "IAR .+ Compiler":
Determining if the C compiler works failed with the following output:
Change Dir: D:/GitHubRepos/OpenQL/cbuild/CMakeFiles/CMakeTmp

Run Build Command:"nmake" "/NOLOGO" "cmTC_bd841\fast"
	"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\nmake.exe" -f CMakeFiles\cmTC_bd841.dir\build.make /nologo -L                  CMakeFiles\cmTC_bd841.dir\build

Building C object CMakeFiles/cmTC_bd841.dir/testCCompiler.c.obj

	C:\PROGRA~2\MICROS~1.0\VC\bin\cl.exe     -o CMakeFiles\cmTC_bd841.dir\testCCompiler.c.obj   -c D:\GitHubRepos\OpenQL\cbuild\CMakeFiles\CMakeTmp\testCCompiler.c

NMAKE : fatal error U1045: spawn failed : Invalid argument

Stop.

NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\nmake.exe"' : return code '0x2'

Stop.



Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe 
Build flags: 
Id flags: 

The output was:
2
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

CMakeCCompilerId.c
Microsoft (R) Incremental Linker Version 14.00.24215.1
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:CMakeCCompilerId.exe 
CMakeCCompilerId.obj 
LINK : fatal error LNK1104: cannot open file 'LIBCMT.lib'


Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" failed.
Compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe 
Build flags: 
Id flags: 

The output was:
2
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

CMakeCXXCompilerId.cpp
Microsoft (R) Incremental Linker Version 14.00.24215.1
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:CMakeCXXCompilerId.exe 
CMakeCXXCompilerId.obj 
LINK : fatal error LNK1104: cannot open file 'LIBCMT.lib'


Determining if the C compiler works failed with the following output:
Change Dir: D:/GitHubRepos/OpenQL/cbuild/CMakeFiles/CMakeTmp

Run Build Command:"nmake" "/NOLOGO" "cmTC_a3569\fast"
	"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\nmake.exe" -f CMakeFiles\cmTC_a3569.dir\build.make /nologo -L                  CMakeFiles\cmTC_a3569.dir\build

Building C object CMakeFiles/cmTC_a3569.dir/testCCompiler.c.obj

	C:\PROGRA~2\MICROS~1.0\VC\bin\cl.exe  @C:\Users\TUD278~1\AppData\Local\Temp\nm16E9.tmp

testCCompiler.c

Linking C executable cmTC_a3569.exe

	C:\ProgramData\Anaconda3\Library\bin\cmake.exe -E vs_link_exe --intdir=CMakeFiles\cmTC_a3569.dir --manifests  -- C:\PROGRA~2\MICROS~1.0\VC\bin\link.exe /nologo @CMakeFiles\cmTC_a3569.dir\objects1.rsp @C:\Users\TUD278~1\AppData\Local\Temp\nm197A.tmp

RC Pass 1 failed to run.

NMAKE : fatal error U1077: 'C:\ProgramData\Anaconda3\Library\bin\cmake.exe' : return code '0xffffffff'

Stop.

NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\nmake.exe"' : return code '0x2'

Stop.



Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe 
Build flags: 
Id flags: 

The output was:
The requested operation requires elevation


Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe 
Build flags: 
Id flags: -c

The output was:
The requested operation requires elevation


Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe 
Build flags: 
Id flags: -Aa

The output was:
The requested operation requires elevation


Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe 
Build flags: 
Id flags: -D__CLASSIC_C__

The output was:
The requested operation requires elevation


Checking whether the C compiler is IAR using "" did not match "IAR .+ Compiler":
Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" failed.
Compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe 
Build flags: 
Id flags: 

The output was:
The requested operation requires elevation


Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" failed.
Compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe 
Build flags: 
Id flags: -c

The output was:
The requested operation requires elevation


Checking whether the CXX compiler is IAR using "" did not match "IAR .+ Compiler":
Determining if the C compiler works failed with the following output:
Change Dir: D:/GitHubRepos/OpenQL/cbuild/CMakeFiles/CMakeTmp

Run Build Command:"nmake" "/NOLOGO" "cmTC_81dd7\fast"
	"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\nmake.exe" -f CMakeFiles\cmTC_81dd7.dir\build.make /nologo -L                  CMakeFiles\cmTC_81dd7.dir\build

Building C object CMakeFiles/cmTC_81dd7.dir/testCCompiler.c.obj

	C:\PROGRA~2\MICROS~1.0\VC\bin\cl.exe     -o CMakeFiles\cmTC_81dd7.dir\testCCompiler.c.obj   -c D:\GitHubRepos\OpenQL\cbuild\CMakeFiles\CMakeTmp\testCCompiler.c

NMAKE : fatal error U1045: spawn failed : Invalid argument

Stop.

NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\nmake.exe"' : return code '0x2'

Stop.

CMakeOutput

The system is: Windows - 6.1.7601 - AMD64
Compiling the C compiler identification source file "CMakeCCompilerId.c" succeeded.
Compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe 
Build flags: 
Id flags: -c

The output was:
0
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

CMakeCCompilerId.c


Compilation of the C compiler identification source "CMakeCCompilerId.c" produced "CMakeCCompilerId.obj"

The C compiler identification is MSVC, found in "D:/GitHubRepos/OpenQL/cbuild/CMakeFiles/3.6.3/CompilerIdC/CMakeCCompilerId.obj"

Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" succeeded.
Compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe 
Build flags: 
Id flags: -c

The output was:
0
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

CMakeCXXCompilerId.cpp


Compilation of the CXX compiler identification source "CMakeCXXCompilerId.cpp" produced "CMakeCXXCompilerId.obj"

The CXX compiler identification is MSVC, found in "D:/GitHubRepos/OpenQL/cbuild/CMakeFiles/3.6.3/CompilerIdCXX/CMakeCXXCompilerId.obj"

The same html visualization that already exists for qumis.

It should be possible to add non-custom gates as well with k.gate() syntax.

The QISA that is generated is correct.

The errors get printed after generating the QISA.
No exception is raised in python (I think every error should raise an exception ), explaining why it passed by the tests.

Example below is from me testing in PyCQED. I expect the same problem in the OpenQL tests, however the code needs to be run by hand as the test will conclude it passes.

In [16]: p = sqo.AllXY(qubit_idx=0, platf_cfg=config_fn)
[openql] compiling eqasm code...
[openql] writing control store file to '/Users/Adriaan/GitHubRepos/DiCarloLab_Repositories/PycQED_py3/pycqed/measurement/openql_experiments/output/cs.txt' ...
[openql] writing qisa instruction file to '/Users/Adriaan/GitHubRepos/DiCarloLab_Repositories/PycQED_py3/pycqed/measurement/openql_experiments/output/qisa_instructions.dbpd' ...
[openql] Scheduling ALAP to get bundles ...
[openql] Scheduling ALAP to get bundles [DONE]
[openql] Writing CC-Light QISA to /Users/Adriaan/GitHubRepos/DiCarloLab_Repositories/PycQED_py3/pycqed/measurement/openql_experiments/output/AllXY.qisa
[openql] Writing Time-stamped CC-Light QISA to /Users/Adriaan/GitHubRepos/DiCarloLab_Repositories/PycQED_py3/pycqed/measurement/openql_experiments/output/AllXY.tqisa
[openql] scheduling ccLight instructions done.
[openql] [x] error : cc_light_eqasm_compiler : instruction 'measz q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_01 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_01 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'measz q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_02 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_02 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'measz q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_01 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_02 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'measz q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_02 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_01 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'measz q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_03 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'measz q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_04 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'measz q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_03 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_04 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'measz q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_04 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_03 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'measz q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_03 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_02 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'measz q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_04 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_01 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'measz q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_01 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_04 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'measz q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_02 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_03 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'measz q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_03 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_01 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'measz q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_01 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_03 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'measz q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_04 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_02 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'measz q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_02 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_04 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'measz q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_01 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'measz q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_02 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'measz q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_03 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_03 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'measz q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_04 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'cw_04 q0' not supported by the target platform !
[openql] [x] error : cc_light_eqasm_compiler : instruction 'measz q0' not supported by the target platform !
[openql] compilation done.
[openql] writing eqasm code (27 lines) to '/Users/Adriaan/GitHubRepos/DiCarloLab_Repositories/PycQED_py3/pycqed/measurement/openql_experiments/output/AllXY.asm' ...
[openql] writing traces...
[openql] compilation of program 'AllXY' done.

@imranashraf , both pip install -e . and python setup.py install --user do not work on OSX.

Previously it did work for me. I get the output shown below:
For the record I have both SWIG and cmake

Conda version information for swig and cmake

cmake                     3.6.3                         0
swig                      3.0.10                        0

Bug report below

Obtaining file:///Users/Adriaan/GitHubRepos/DiCarloLab_Repositories/OpenQL
    Complete output from command python setup.py egg_info:
    CMake Error at /Users/Adriaan/anaconda/share/cmake-3.6/Modules/FindSWIG.cmake:50 (message):
      Command "/usr/local/bin/swig -swiglib" failed with output:

    Call Stack (most recent call first):
      openql/CMakeLists.txt:1 (FIND_PACKAGE)


    CMake Error at openql/CMakeLists.txt:2 (INCLUDE):
      include called with wrong number of arguments.  include() only takes one
      file.


    CMake Error at openql/CMakeLists.txt:19 (SWIG_ADD_MODULE):
      Unknown CMake command "SWIG_ADD_MODULE".


    Detected OSX but its not yet tested!
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/Users/Adriaan/GitHubRepos/DiCarloLab_Repositories/OpenQL/setup.py", line 26, in <module>
        ret = subprocess.check_output(cmd, shell=True)
      File "/Users/Adriaan/anaconda/lib/python3.6/subprocess.py", line 336, in check_output
        **kwargs).stdout
      File "/Users/Adriaan/anaconda/lib/python3.6/subprocess.py", line 418, in run
        output=stdout, stderr=stderr)
    subprocess.CalledProcessError: Command 'cmake ..' returned non-zero exit status 1.

    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in /Users/Adriaan/GitHubRepos/DiCarloLab_Repositories/OpenQL/