# OpenQP: MRSF-TDDFT, a Fortran core and a source-available licence

> A quantum chemistry program built around mixed-reference spin-flip TDDFT, distributed as a Fortran core with Python bindings, a GUI called OQP Studio and a digest-pinned container. The README is precise about which method has analytic gradients and which falls back to central differences.

**Open-Quantum-Platform/openqp** — The main repository of Open Quantum Platform (OpenQP) maintained by Choi Group at KNU.

- Repository: https://github.com/Open-Quantum-Platform/openqp
- Website: https://www.openqp.org
- Stars: 80 · Forks: 22
- Language: Fortran
- License: NOASSERTION
- Published: 2026-08-23 · Updated: 2026-08-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/open-quantum-platform-openqp

## MRSF-TDDFT is the centre, and the linear-response shape is the point

Open Quantum Platform, abbreviated OQP and pronounced oh-coop, is a quantum chemistry program centred on mixed-reference spin-flip TDDFT. The reason the method exists is stated plainly: MRSF-TDDFT keeps the linear-response structure of TDDFT while removing the spin contamination that limits conventional spin-flip TDDFT. What that buys is a consistent description of multiconfigurational ground and excited states, and the README names the cases it is aimed at: diradicals, bond breaking, conical intersections, photochemical processes and spin-orbit coupling. The default MRSF-TDDFT route uses an ROHF mixed reference with DTCAM-series functionals and covers ground and excited states, analytic gradients, properties, NAC and NACME, SOC, optimization and dynamics. Two variants sit next to it: UMRSF-TDDFT for excitation energies from a UHF based unrestricted reference, and plain SF-TDDFT as spin-flip TDA from a high-spin reference.

## Analytic gradients are the dividing line between the methods

The capability table draws a line that matters more than the method list. Analytic nuclear gradients exist for the MRSF, SF and TDDFT response methods, for HF and DFT, for RHF-based MP2, and for state-specific CASSCF and SA-CASSCF, which is what makes state-specific derivatives available to grad, optimization and reaction paths. Everything else falls back to central differences of converged energies: the legacy method=casscf plus [state_average] spelling, and the CASPT2, NEVPT2 and QDPT2 families. Two exceptions are spelled out. Nonadiabatic dynamics under runtype=namd is MRSF-TDDFT only. And SA-CASSCF additionally differentiates the weighted objective, which is not a state, so it is selected by [casscf] gradient_state rather than by [properties] grad. That table is worth reading before a method is chosen, since it decides which gradients a job can have.

## MP2, coupled cluster and multireference PT2 fill in the correlated side

Around the response methods sits a conventional correlated toolkit. MP2 is available for RHF, ROHF and UHF references in conventional and spin-scaled variants, with analytic nuclear gradients for the RHF-based variants. Coupled cluster covers CCSD and CCSD(T) for all three references, with reference-appropriate frozen-core, Cholesky, in-core or direct algorithms. Configuration interaction provides FCI and CASCI in determinant active spaces at fixed molecular orbitals, and CASSCF comes in state-specific and state-averaged forms. Multireference perturbation theory is listed as SS, MS and XMS-CASPT2, nevpt2 and sc-nevpt2, and MRMP2, MCQDPT2 and XMCQDPT2, with central-difference gradients for the supported geometry workflows. Two smaller entries complete the picture: MRSF-EKT applies extended Koopmans' theorem to MRSF states for ionization and electron-attachment energies, Dyson orbitals and pole strengths, and the X-ray absorption workflows include ΔCHP-MRSF core excitations with oscillator strengths.

## Vibrations, NMR, SOC and NACME round out the properties

The property side is where a study usually ends up needing something the energy code did not promise. Frequencies, normal modes, thermochemistry, IR intensities and Raman intensities come from analytic HF and DFT Hessians, or from numerical Hessians built on the gradients a method supports. NMR shieldings are computed at HF and DFT level with either the CGO or the GIAO, London-orbital, gauge, for closed-shell and open-shell tensors. Nonadiabatic couplings, NAC and NACME, are taken between MRSF-TDDFT states and feed both optimization and nonadiabatic dynamics. Spin-orbit coupling covers the one-electron and two-electron terms between MRSF-TDDFT states and returns spin-mixed energies and coupling matrices for intersystem crossing. The pattern across all of these is that the excited-state machinery is MRSF-centric, so a workflow that mixes CASSCF with dynamics has to be checked method by method rather than assumed to compose.

## The wheel is source-available, with a licence name of its own

The packaging is where the licensing question gets answered. The Python project is named OpenQP at version 1.3.1 and describes itself as Python bindings for the Open Quantum Platform, a Fortran core with a Python wrapper, authored by Mohsen Mazaherifar and Alireza Lashkaripour. It requires Python 3.9 or newer, depends on numpy, scipy, cffi and basis_set_exchange, offers geometric as an optional dependency and installs an openqp entry point. The licence field is not a standard identifier:

```toml
license = "LicenseRef-OpenQP-Research-1.0"
```

The declared licence files are LICENSE, LICENSING.md, SUSTAINABILITY.md, THIRD_PARTY_NOTICES.md and the third_party directory under licenses. That is why the project describes itself as source-available rather than open source, and it is the first thing to read if your institution has a policy opinion about licence names. An mpi4py dependency is present but commented out, so parallel Python-side work is not wired up by default.

## The Windows MKL pin is a deliberate, explained constraint

One dependency carries a long comment that is worth reading before you touch Windows builds. The wheel for that platform links MKL in its ILP64 form but does not carry it, because libmkl_core on its own exceeds PyPI's per-file size limit, so the Intel package is installed alongside and pyoqp/oqp/runtime.py adds its DLL directory to the search path. The mkl requirement is pinned to mkl>=2026.1,<2027 for win32, and the reason is mechanical: MKL embeds versioned DLL names in its import libraries, with liboqp.dll referencing names such as mkl_core.2.dll, and those names change between releases, so an older runtime that satisfies a loose lower bound leaves liboqp unable to load. CI has only ever resolved and tested mkl 2026.1, and the pin is meant to be bumped together with the oneAPI version used by the Windows workflows.

## The container pins digests and drops the toolchain from the runtime

The Dockerfile describes a release-candidate image, and its comments explain the discipline. Both inputs are immutable registry digests recorded in docker/base-images.lock.json. The build environment exists only to compile and verify a wheel, and none of the compiler, source checkout or external build cache is inherited by the final runtime image. The builder is openqp-buildenv:1, which is Ubuntu 24.04 with Python 3.12 and is linux/amd64 only, so the runtime deliberately uses the same Python minor version with a newer glibc baseline. Moving the container to Python 3.11 would first require publishing a proposed 3.11 builder, and the version and revision of the build arrive as arguments that feed the CMake options:

```sh
CMAKE_ARGS="-DUSE_LIBINT=OFF -DENABLE_OPENMP=ON -DENABLE_OPENTRAH=OFF -DENABLE_MPI=OFF -DENABLE_DDX=OFF -DOQP_ALLOW_REFERENCE_BLAS=OFF -DLINALG_LIB=OpenBLAS -DCMAKE_PREFIX_PATH=/opt/openblas -DOQP_EXTERNALS_ROOT=/root/.cache/openqp/externals -DOQP_SOURCE_REVISION=${OPENQP_REVISION}"
```

Those switches say what the container build turns off: LibInt, OpenTraH, MPI and DDX are disabled, OpenMP stays on, and OpenBLAS replaces the reference BLAS.

## OQP Studio is the GUI route, and examples/ is the map of the methods

For anyone who does not want a command line, OQP Studio is the desktop application for building molecular structures, preparing OpenQP inputs, running calculations and analyzing results. It is published for macOS, Windows and Linux, and the download page offers a with-engine installer that bundles OpenQP for the easiest setup; a release notes and version comparison page tracks changes, known limitations and upgrade guidance. The command line path has its own map: the examples directory is split into 24 folders named after the workflows, among them CC, DFT, ECP, GPU, HESS, HF, MP2, MRSF-TDDFT, NAMD, NMR, OPT, OQP_INPUT, PCM, PERF, PROP, QMMM, SF-TDDFT, SOC, TDDFT, TDHF and TRAH. Beside them sit basis_sets/, pyoqp/, source/, tests/ and tools/, with TROUBLESHOOTING.md at the root and CI configured on both GitHub Actions and GitLab.

## Conclusion

OpenQP fits a computational chemistry group that wants MRSF-TDDFT for diradicals, conical intersections and nonadiabatic dynamics and needs the same code path for the correlated and response methods around it, and it fits a GUI-first user through OQP Studio. Two things to check before you plan around it. The package calls itself source-available and declares LicenseRef-OpenQP-Research-1.0 rather than a standard open source licence, so read LICENSING.md and SUSTAINABILITY.md before assuming your institution's policy accepts it. And the Windows wheels depend on an MKL runtime pinned to oneAPI 2026.1, because the compiled DLL names are version specific and CI has only ever resolved that one series, so a Windows rollout should track the workflows rather than loosening the pin. Version 1.3.1 shipped on 21 August 2026 and the last push is 27 September 2026.

## FAQ

### Is OpenQP open source?

The project calls itself source-available. The Python package declares the licence LicenseRef-OpenQP-Research-1.0 and names LICENSE, LICENSING.md, SUSTAINABILITY.md, THIRD_PARTY_NOTICES.md and the third_party licence files as its licence documents, so check those before assuming a standard open source grant.

### What does OQP Studio do?

It is the desktop application for building molecular structures, preparing OpenQP inputs, running calculations and analyzing results. Builds are offered for macOS, Windows and Linux, and a with-engine installer bundles OpenQP so it is ready to run. A release notes page covers changes, known limitations and upgrade guidance.

### Which OpenQP methods have analytic nuclear gradients?

The MRSF, SF and TDDFT response methods, HF and DFT, RHF-based MP2, and state-specific CASSCF and SA-CASSCF. The legacy method=casscf plus [state_average] spelling and the CASPT2, NEVPT2 and QDPT2 families use central differences of converged energies instead.

### What does runtype=namd do in OpenQP?

It selects nonadiabatic dynamics, and it is available for MRSF-TDDFT only. The nonadiabatic couplings it consumes, NAC and NACME, are computed between MRSF-TDDFT states and are also used for optimization.

### How do I install the OpenQP Python bindings?

The package is OpenQP 1.3.1, built with scikit-build-core and CMake 3.25 or newer, requiring Python 3.9 or newer. It depends on numpy, scipy, cffi and basis_set_exchange, installs an openqp entry point, and has an optional geometric dependency.

## Sources

- [Official documentation](https://www.openqp.org)
- [Official README](https://github.com/Open-Quantum-Platform/openqp#readme)
- [Project repository](https://github.com/Open-Quantum-Platform/openqp)
- [Release notes](https://github.com/Open-Quantum-Platform/openqp/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/open-quantum-platform-openqp