Working with multiple versions of KQC and/or KLayout

[srjmas]

For a designer, it would be a very useful feature to be able to jump back in time to work on old designs with exactly the same KLayout:KQC tuple it was originally created with. Many times just a slight modification is needed, and it is very time consuming to find the PCells not functioning.

So far, I think that I found a way to switch between different versions of KQC, by manually redirecting the links to the relevant directory following the manual https://iqm-finland.github.io/KQCircuits/developer/setup.html#windows My first question is: is it a sufficient practice? Or should I always perform python setup_within_klayout.py? Or something entirely different?

It would be best, however, to be able to switch also to the exact KLayout version that was used. Klayout supports multiple installations in different directories. KQC, however, expects the KLayout to be installed in the default location. A workaround is to uninstall KLayout, and install an old version + KQC from scratch, but it is rather a long process. Is there some shorter workaround?

If not, I would like to request a feature: the setup_within_klayout.py to receive an optional parameter of the KLayout installation directory.

[qpavsmi]

When it comes to setting up KQC, if it was set up using the Developer guide, KQC is often simple to set up to previous versions by using 'git checkout' to either specified tagged versions or to individual commits. The symlinks in KLayout points to the same source directory, so they don't need to be changed. At relatively rare events a run of python setup_within_klayout.py is needed when KQC needs to be upgraded to enable certain features. The setup script is never needed when KQC is downgraded. However, it is safe to run the setup script even if it was not needed. To sum up, a workflow to jump to a version of KQC, what is needed is:

1. Look up KQC version or commit hash (by using git log) you want to jump to.
2. In KQC source directory, use git checkout <tag name/commit hash>
3. python setup_within_klayout.py, good to do just in case, usually not needed.
4. Launch KLayout

We do not have a mechanism to install KQC to a specific KLayout version, that is true. I'll add that to our feature backlog, but can't promise that it will receive high priority and will be completed swiftly. It looks like it could be a simple fix, but when it comes to installation stuff you can never know in advance. It will also have to be tested on Linux platforms as well.

In the meantime, a method that I use is I have multiple KLayoutXXX directories for XXX versions containing full installations in C:/Users/<USERNAME> and C:/Users/<USERNAME>/AppData/Roaming directories. When I want to activate a specific version XXX, I rename the directories KLayoutXXX -> KLayout, and run the application from that directory (maybe run setup script just to be sure). So uninstall was never needed for me so far, but would love to know if under certain conditions this workflow breaks down.

[srjmas]

Thank you very much, Your way of generating a KQC-KLayout tuple loolks very robust indeed, I will recommend it to my team. If it worked so far - it is not probable that KLayout will change it's behavior in the future. It looks like a good workaround, eliminating the need of dedicated feature development. Maybe consider adding it to the User Guide.

[iqmtestd]

There is an "official" method for having simultaneous KQCircuits environments: https://iqm-finland.github.io/KQCircuits/developer/setup.html#secondary-install. This sets up a secondary directory to be used by a second KLayout executable.

The only thing to remember is to pass the proper KLAYOUT_HOME variable to the second KLayout.

[srjmas]

Thank you, I thought it is only relevant for the GUI-less KLayout installation as a standalone python package. So as a worked example, I want KLayout v0.26.12 with KQC v4.0.0 and KLayout v0.27.11 with KQC v4.4.5

Do I understand correctly the procedure: 1) Download and install the different KLayout versions under %APPDATA%/KLayout_v0.26.12 and %APPDATA%/KLayout_v0.27.11 2) git clone KQCircuits to %HOMEPATH%/KQC_v4.0.0 and %HOMEPATH%/KQC_v4.4.5 3) modify the KQC versions with git checkout 4) install the missing packages to each KLayout from each KQC with pip -r requirements.txt -t <%APPDATA%/KLayout_vxxx> 5) Create two batch files on my desktop that a) modify the %KLAYOUT_HOME% to %HOMEPATH%/KQC_vxxx b) execute %APPDATA%/KLayout_vxxx/klayout.exe

• setting venv is not required

[iqmtestd]

I don't know Windows, but the the basic idea is the same.

First git clone KQCircuits to a secondary location, then running setup_within_klayout.py there will set up an alternative KLayout config directory.

To run a second KLayout binary (even simultaneously) with this setup you have to pass the KLAYOUT_HOME environment variable pointing to the alternative config dir to the executable. In other words, KLAYOUT_HOME should not point to the secondary repository clone but to the secondary KLayout configuration directory.

Also, if your OS permits it, it is possible to use different versions of the KLayout executable.

[srjmas]

Sorry for my Windows, I will use Ansys HFSS as an excuse :) I am able to run simultaneously different versions of KLayout

Ok, I think I find now the Klayout_alt directory automatically created for every time I executed the setup_within_klayout.py, I will configure them in the KLAYOUT_HOME.

However, how does the setup_within_klayout.py knows which installation of KLayout to update with the required python packages? From what I see, the default KLayout installation directory is hardcoded into that script. Should I run pip manually?

[iqmtestd]

setup_within_klayout.py uses pip install --target ... to put the Python packages in the correct place.

[srjmas]

I think it might be transparent to you on Unix/Linux, but for windows setup_within_klayout.py updates a hardcoded location

target_dir = get_klayout_packages_path(os.path.join(os.getenv("APPDATA"), "KLayout")) pip_args = f'requirements_within_klayout_windows.txt --target="{target_dir}"'

target_dir is hardcoded to %APP_DATA%\KLayout, which is indeed the default installation directory for KLayout, but if I choose a different installation directory (as I must to maintain multiple KLayout versions), pip will not work.

[iqmtestd]

Good catch! I think this is a bug. To my excuse, I have not tested the Windows version. :) We will fix this eventually but would also happily accept a PR from you.

In Linux this is not an issue, as (unfortunately) it always installs to the system environment.

[srjmas]

Thank you. I think @qpavsmi already logged my request, however it is really a low priority if we can make a working procedure of installation. One workaround @qpavsmi already described (renaming KLayout directories), but I like the KLAYOUT_HOME approach more - once installed, many KLayout-KQC tuples can work simultaneously. I think it is exactly the 5 steps procedure I described above but with 5a) modify the %KLAYOUT_HOME% to %HOMEPATH%/KLayout_alt/KQC_vxxx Does it make sense?

[iqmtestd]

Yes, that's correct.

[srjmas]

I managed an installation of two simultaneous KLayout with two separate KQC. It requires installing everything in default directories, then changing KLayout directories names in %HOMEPATH% and %APPDATA%, and then creating a simple .bat file: set KLAYOUT_HOME=C:\Users\xxx\KLayout_0.27.12 C:\Users\xxx\AppData\Roaming\KLayout_0.27.12\klayout_app.exe

[iqmtestd]

Thanks for the information. We will use this to fix setup_withn_klayout.py to facilitate using different KLayout versions with separate KQcircuits directories simultanously also in Windows.

[iqmtestd]

As for now we've decided not to implement this feature as it is a niche case and we have easy enough workarounds for both Windows and Linux.

In Windows it is even possible to run the two versions simultaneously. See earlier comments.

In Linux one only needs to remove KLayout package and install a different version.

In both cases multiple configured KQCircuits work directories may be kept around.