Read circuits with different numbers of gates (and bond dimensions) between different neighboring qubits. Once this is supported, the depth parameter, which assumes constant bond dimension between all qubits, is removed.

We will use the standard Google Contributing file, with minor modifications to the Contributing license agreement to ensure that if developer touches certain files, they would have to also sign the contributing license agreements from NASA.

Example of Contributing File:

https://github.com/quantumlib/Cirq/blob/master/CONTRIBUTING.md

We should provide documentation for the following items (this list is incomplete):

1. From-scratch qFlex installation process for at least one OS (preferably several)
2. Directory structure and purpose of each library
3. Expected input files and formatting for each

I have a python virtual environment in the root of qflex. Yapf3 is checking the style in that folder.

There is currently an unstated assumption that ordering-file cuts list the qubits they affect in index order (i.e. 'cut 28 40' is valid, but 'cut 40 28' is not). This causes segfaults if the qubits are given in the wrong order.

To resolve this, cuts read from file should be internally re-ordered to be in the correct order.

Unit tests need to be added before refactoring to ensure the same behaviour is maintained.

It probably makes the most sense to use gtest.

NOT A PRIORITY. Right now general reorderings are split in three simpler ones. Every one of the simpler reorderings copies data from the tensor to scratch and back, so that each of the reorderings is complete and puts the data in the tensor data array. However, each simple reordering doesn't have to be complete in this sense, but only the end result of the three (or fewer, sometimes) simple reorderings. For this reason, a few copying parts of the reordering can be neglected, which can speed it up up to a 20-30% I estimate.

When computing all amplitudes of the "open" region of the circuit, it is faster to contract that region without closing the indexes. The resulting tensor is contracted with the tensor resultant from the rest of the circuit.

Eventually, add something like Travis CL.

Blocked by #3 obviously.

Are the grid layouts bristlecone48 and bristlecone70 the only supported for the moment? Will there be other grids like sycamore_48?

The current file format is restricted to 12x12 grids. Is this a hard limit? Can it be, for example, 7x7 or 15x15?

There appear to be several places in the code which may use more memory than necessary, though it's not clear if they're on the critical path. Would be good to create a memory profile using something like gperftools.

without this line (added doctopt.o to the OBJS1)
OBJS1 = evaluate_circuit.o tensor.o contraction_utils.o read_circuit.o docopt.o
the make returns

main.cpp:(.text.startup+0x9c): undefined reference to `docopt::docopt(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, bool, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool)'
collect2: error: ld returned 1 exit status

Pointer ownership should be clarified using, e.g., std::unique_ptr. Right now, scratch pointers are being passed around all over the place, and it's not clear what the chain of ownership is. (The pointers are also just NULLed at the end, without any deletes.)

Using inheritance for ContractionOperations resulted in lots of clunky dynamic_cast calls. Having different operation types as members of ContractionOperation should be much cleaner.

YAPF is the preferred tool for formatting python code at Google. As noted in PR #55, we should update check_format.sh to enforce this check.

In the event of a test failure, it's important that users get a clear idea of how and why the test failed. Steps to achieve this include:

1. Unit-testing all assert() calls, to build user confidence in code correctness.
2. Providing clear and unique error messages for each failure case, so users can tell at a glance where the test failed and why.
3. Adding assertions and log messages to unprotected segfault locations, since segfaults are notoriously difficult to track down.

Installing Cirq on Alpine seems problematic. The following commands:

# apk add libpng-dev
# apk add freetype-dev
# apk add python3
# apk add python3-dev
# apk add python3-tkinter
# apk add py3-scipy
# apk add py3-numpy
# apk add py-numpy-dev
# apk add openblas-dev
# pip3 install cirq

allow the installation of Cirq. However, I get the following error:

# python3 -m cirq
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.7/site-packages/cirq/__init__.py", line 41, in <module>
    from cirq.experiments import (
  File "/usr/lib/python3.7/site-packages/cirq/experiments/__init__.py", line 1, in <module>
    from cirq.experiments.google_v2_supremacy_circuit import (
  File "/usr/lib/python3.7/site-packages/cirq/experiments/google_v2_supremacy_circuit.py", line 19, in <module>
    from cirq import circuits, devices, google, ops
  File "/usr/lib/python3.7/site-packages/cirq/google/__init__.py", line 29, in <module>
    from cirq.google.sim import (
  File "/usr/lib/python3.7/site-packages/cirq/google/sim/__init__.py", line 18, in <module>
    from cirq.google.sim.xmon_simulator import (
  File "/usr/lib/python3.7/site-packages/cirq/google/sim/xmon_simulator.py", line 45, in <module>
    from cirq.google.sim import xmon_stepper
  File "/usr/lib/python3.7/site-packages/cirq/google/sim/xmon_stepper.py", line 29, in <module>
    from cirq.google.sim import mem_manager
  File "/usr/lib/python3.7/site-packages/cirq/google/sim/mem_manager.py", line 186, in <module>
    SharedMemManager.get_instance()
  File "/usr/lib/python3.7/site-packages/cirq/google/sim/mem_manager.py", line 137, in get_instance
    SharedMemManager._instance = SharedMemManager()
  File "/usr/lib/python3.7/site-packages/cirq/google/sim/mem_manager.py", line 47, in __init__
    self._lock = Lock()
  File "/usr/lib/python3.7/multiprocessing/context.py", line 67, in Lock
    return Lock(ctx=self.get_context())
  File "/usr/lib/python3.7/multiprocessing/synchronize.py", line 162, in __init__
    SemLock.__init__(self, SEMAPHORE, 1, 1, ctx=ctx)
  File "/usr/lib/python3.7/multiprocessing/synchronize.py", line 59, in __init__
    unlink_now)
FileNotFoundError: [Errno 2] No such file or directory

Any idea?

In particular, using namespace std should be removed.

There's code duplication all over the place. For example, functions to read different formats of circuit files have large overlaps.

There also appear to be a number of variables which are unused. Some of these are due to code being copied and changed.

The ideal experience is someone who knows how to use Cirq can fire up QFlex, and run a supremacy circuit.

In read_circuit.cpp, the function circuit_data_to_grid_of_tensors(), num_qubits is set to I * J, then num_qubits == I * J is evaluated. This raises the question of whether or not the number of qubits should be determined from the circuit data or from inputs of I and J.

The method of determining num_qubits should be set straight, whether it be from the grid or from I * J

Instead of having two different branches for the cpp_only and master (C++ and Fortran) code, there should be one codebase, with flags in the Makefile to control which dependencies are used and so on.

Header .h files should have only declarations, and definitions should be in source .cpp files.

These gates need to be added:

• sqrt(Hz): single-qubit gate, not parameterized
• Rz: single-qubit gate with one real parameter
• fSim: two-qubit gate with two real parameters

Remove quantum circuits we don't want to make public / standardize name.

See issue #90 for details.

qFlex should implement the Cirq "SimulatesAmplitudes" interface to allow high-performance simulation of Cirq circuits. Prerequisites for this:

1. A Python wrapper for qFlex (e.g., using Cython).
2. A method for generating qFlex input from Cirq circuits. The circuit and grid files should be simple, but "contraction ordering" is not a supported concept in Cirq AFAIK.

Add 7x7x40, 11x11x24, sycamorex12 and sycamorex14.

After the latest commit on the master branch I get the following error

./qflex.x 11 12 2 0.005 ./circuits/ben_11_16_0.txt ./ordering/bristlecone_48.txt ./grid/bristlecone_48.txt
The number of qubits read from the file: 70, does not match I*J: 132.
The second qubit of '1 cz 80 81' references (6, 9) which must be coordinates of an active qubit.
qflex.x: read_circuit.cpp:487: void qflex::circuit_data_to_grid_of_tensors(std::istream*, int, int, int, std::__cxx11::string, std::__cxx11::string, const std::optional<std::vector<std::vector<int> > >&, const std::optional<std::vector<std::vector<int> > >&, std::vector<std::vector<std::vector<qflex::Tensor> > >&, qflex::s_type*): Assertion `!second_qubit_off' failed.

Assertions aren't the best option for terminating processes, since they don't provide much in the way of logs. We should investigate alternatives (e.g. C++ exceptions) and migrate away from assert() calls.

This also affects our tests, where EXPECT_DEATH doesn't play nice with multithreading.

In order for qflex to support arbitrary circuit layouts, we need to write a generic version of the contraction code which can take contraction details (i.e., ordering and cuts) as input.

The code should follow a major open source C++ style guide. The most obvious one would be Google's, unless there are good reasons to use another one?

We should use clang-tidy to automatically lint any new code which is submitted.

qflex has a variable num_qubits which is read in as the first line of an input file, and is assumed to be the number of qubits in a rectangular grid of size I * J. (All qubits set to off are ignored.)

ShallowQC also has a variable named num_qubits, which is also read in as the first line of an input file, but denotes the number of qubits in the circuit. Consequently, when qflex reads in a ShallowQC circuit file, it has to read the first line into a dummy variable, then calculate num_qubits based on I and J.

The file formats should be reconciled so that circuit files can be shared without modifications to inputs or source code.

The "sanity checks" mentioned in contraction_utils.h should be documented in the input_formats file. In particular, the naming restrictions surrounding cuts need to be properly explained.

Some context: when performing a cut, we iterate over all projection values of the cut. Since we allocate memory on a per-patch-name basis, and memory space is shared across these iterative steps, it's crucial that patches modified before a cut are not also modified after that cut - otherwise, the changes will spill over to the next iteration.

It would be possible to avoid this restriction by saving all patches prior to a cut, but this has a substantial memory cost. Instead, we prefer allowing users to specify which patches to copy by 'renaming' them with a merge after the cut. An example of this using the original 7x7 grid contraction can be found in the "ExampleOrdering" test.

Is it possible to specify a circuit with no hadamard layers at the beginning/end?

Add number of qubits to first line of circuit files when missing.

Fidelity is now determined from cuts; the "fidelity" parameter can be removed.

Documentation should be updated to reflect this as well.

In #88, I would expect that amplitude[0].second correspond to the quantum state |11000> (where qubit=5 is in last position). However, it corresponds to the state |00011>. Similarly, amplitude[1].second should correspond to |11001>, and instead correspond to |10011>. Am I doing/assuming something wrong?

In order for the linker to work I had to change lines 18 and 19 from the Makefile

$(TARGET1): $(OBJS1)
	$(CXX) -o $(TARGET1).x $(OBJS1) $(FLAGS)

Otherwise it complained that in tensor.cpp the cblas_*** methods were not found

I can send a PR with this if necessary.

Edit: My compiler is c++ (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0

I'm not sure why s_type is defined the way it is, rather than using MKL_Complex8 from the MKL?

There are also a couple of places where a parameter or return value is a vector, when maybe it should be a struct.

I think there are also some places where ints should be size_ts or vice versa, to allow compilation on different architectures, but I will need to do some more investigation.