The word 'LASCI' is used in the code in an inconsistent way throughout class and method names

[MatthewRHermes]

Historically, the 'LASCI' method classes were always misnamed: although it appears to describe the process of optimizing the CI vectors of a LAS wave function with all orbitals fixed, in reality, it partially optimized the orbitals as well: mixing inactive and virtual orbitals, and active orbitals in one fragment with active orbitals in another, but not mixing active orbitals with either inactive or external orbitals (thus omitting the most costly part of the orbital optimization: the ERIs of index type ppaa and papa). This corresponds to the step indicated in the top-right node of the algorithm in Figure 3 of DOI:10.1021/acs.jctc.0c00222, as part of the effort to "repair" the defects of the first LASSCF implementation originally reported in DOI:10.1021/acs.jctc.8b01009. I called this step "LASCI" in the code because I was too lazy to come up with (or look up) a proper name for this kind of esoteric, partial SCF. The (more-)PySCF-compatible reimplementations of LASSCF (both the "synchronous" and "asynchronous" versions) were built as child classes of this misnamed 'LASCI' class, in order to maintain backwards compatibility. One symptom of this is that output files say "LASCI" in places where users might expect to see the word "LASSCF".

However, now we are actually doing LASCI, properly defined as full self-consistent optimization of CI vectors with all orbitals frozen, as well. It is implemented as an attribute of the LASSCF method object:

las.lasci () # optimize CI vectors with orbitals fixed

and this is potentially terribly confusing. las in the above is always an instance of class LASCINoSymm, which has a kernel attribute which does something completely different from its lasci attribute.