You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Migrate to Open-Quantum-Platform/tagarray v1.0.0 (#232)
* Migrate to Open-Quantum-Platform/tagarray v1.0.0
Re-point libtagarray at OQP/tagarray v1.0.0 and migrate all call sites off the
removed 0.0.x API (reserve_data/remove_records/has_records/get_record_info/
get_status) to create/erase/contains/get + recordinfo count/ndims/dims and the
TA_CONTAINER_GET_* macros.
- external/CMakeLists.txt: URL -> OQP/tagarray v1.0.0 (+SHA), drop obsolete
default-integer-shapes patch, add CMAKE_POSITION_INDEPENDENT_CODE.
- tagarray_driver.F90 + c_interop.F90: wrapper/C-interop ported to v1.0.0.
- 23 modules: one-call c%alloc_or_die; hf_energy create() for C-filled Fock;
int2e int64-shape create() for nbf**4 ERI.
Supersedes stale PR #34. Verified: liboqp links and H2 MRSF-CIS reproduces
S0 = -1.1150793163 Ha exactly.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Address review: preserve input orbitals + ILP64 integer kind for libtagarray
Codex review fixes (data erased by over-eager migration):
- basis_projection: OQP::DM_A/E_MO_A/VEC_MO_A (and beta) are the converged
initial-basis orbitals READ by corresponding_orbital_projection; the old
reserve_data (no remove_records) preserved them. alloc_or_die overrides, so
it erased the projection source. Revert those 6 tags to data_has_tags +
tagarray_get_data (read, not reallocate). The *_tmp outputs stay alloc_or_die.
- guess_json: the beta OQP::DM_B/E_MO_B/VEC_MO_B are loaded from the JSON guess
and read by get_ab_initio_density for ROHF/UHF; read them, do not reallocate.
ILP64 build fix (CI failure on -fdefault-integer-8 builds):
- tagarray's c%alloc/alloc_or_die take default-INTEGER shapes and create takes
a default-LOGICAL override; OpenQP promotes those to 8 bytes via
add_compile_options(-fdefault-integer-8/-i8), which ExternalProject does not
inherit, so libtagarray was built int4 -> alloc_or_die/override failed to
resolve. Forward the same integer-8 flag to the libtagarray Fortran build so
the kinds match (verified: the library builds cleanly under -fdefault-integer-8).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Migrate population_analysis + resp to tagarray v1.0.0 alloc_or_die
These two modules came in from the main merge still using the removed
reserve_data API (they store Mulliken/Lowdin/RESP atomic charges). Convert
their single output-tag reserve_data + tagarray_get_data to the one-call
alloc_or_die, matching the rest of the migration.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Fix wheel link: resolve dftd4->LAPACK static link order (undefined ssytri_)
dftd4/multicharge/mctc-lib reference BLAS/LAPACK symbols (e.g. ssytri_) but are
linked after the static liblapack/libblas archives. With a static NetLib build
the linker has already passed those archives, so the objects are never pulled
in and liboqp.so gets an undefined symbol that only fails at load time
(import oqp in the wheel smoke). The gcc-build jobs miss it because they never
load the library, and main slips through on its warm externals cache; a fresh
rebuild (forced here by the tagarray version bump) exposes it.
Wrap the dispersion libs together with LAPACK/BLAS in a RESCAN link group so the
cross-references resolve regardless of order (NetLib static only; shared
BLAS/LAPACK such as macOS Accelerate is unaffected).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Fix: don't use RESCAN link group on Apple (ld64 lacks --start-group)
$<LINK_GROUP:RESCAN> emits --start-group/--end-group, which is a GNU ld
feature; Apple's ld64 rejects it. A macOS + from-source-NetLib-static build
(LIBLAPACK set on Apple) would therefore fail to link -- and Linux-only CI
never catches it. ld64 resolves cross-archive references by a global symbol
scan anyway, so Apple just needs the plain link. Gate the RESCAN group on
NOT APPLE.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
0 commit comments