Skip to content

CP2K: register the code, with a first editor, input generator and parser (periodic DFT+U geometry optimisation) #329

Closed

Description

@ohlincha

CP2K is one of the target codes, but ECCE has no CP2K support yet: there is no code registration (EDML, scripts/codereg), no input generator, and no output parser. The Builder already opens with the lattice tools for periodic codes (#300).

First case

A periodic geometry optimisation with Quickstep:

  • GPW, MOLOPT basis sets and GTH pseudopotentials, with the basis and potential files given by name
  • PBE, with D3 dispersion
  • DFT+U on a transition-metal site
  • UKS, with charge and multiplicity set
  • OT SCF
  • periodic in XYZ, with the cell taken from the Builder lattice
  • coordinates written into the input or a PDB coordinate file

Stages

  1. Code registration. CP2K in Register Machines and in the code lists, run as cp2k.psmp (MPI) or cp2k.ssmp, through the sh job scripts.
  2. Calculation editor for the first case: run type (ENERGY, GEO_OPT, CELL_OPT), functional, basis/potential per element, charge, multiplicity, UKS, +U per element (U value and orbital), dispersion, cutoff/rel_cutoff, SCF settings, memory in GB (Gaussian-16 Theory Details: Memory field shows wrong unit label (Megawords instead of Gigabytes) despite correct source and correct generated GB value #77 rule).
  3. Input generator (ai.cp2k or a .tpl) writing &GLOBAL, &FORCE_EVAL/&DFT, &SUBSYS with &CELL, &COORD, &KIND, and &MOTION for optimisations.
  4. Output parsing: total energy, SCF and optimisation progress (Organizer progress, Job progress in the Organizer: SCF, optimisation and frequency progress, and jobs out of contact #284), final geometry from the -pos-1.xyz trajectory, cell, Mulliken charges, spin moments.
  5. Test set: a small cell derived from a real job (no third-party research data in the repo), run on niobium and on Kebnekaise.

Later

MD (NVT/NPT), CELL_OPT, vibrational analysis, QM/MM (FIST), restart from .wfn.

Activity

  1. ohlincha commented on Oct 14, 2026

    @ohlincha
    CollaboratorAuthor

    Plan

    CP2K follows the Quantum ESPRESSO registration: needsBasis="false", its own theory and runtype dialogs, the cell taken from the Builder lattice only, and per-element files picked by scanning the code's own libraries (BASIS_MOLOPT, GTH_POTENTIALS), as qetheory.py does for UPF files. It does not use the NWChem MD path, which is classical force-field MD (topology, segments); CP2K's classical side (FIST, QM/MM) is later and closer to GROMACS.

    QE was modelled on NWChem's plane-wave module (NWPW) but did not take all of it. Compared with NWPW, QE has k-points (NWPW never had them) and lacks:

    • an MD run type (NWPW: Car-Parrinello, with time step, fictitious mass, inner/outer iterations, ion and electron thermostats, restart)
    • Vibration
    • the BAND theory, and Mulliken analysis

    Order:

    1. QE md (Born–Oppenheimer) run type and the trajectory parser, starting from the NWPW Car-Parrinello widgets for time step, temperature and thermostat. QE vc-relax cell trace (LATTICEVEC).
    2. CP2K on the same pieces: ENERGY/GEO_OPT first, then CELL_OPT and MD.
  2. ohlincha commented on Oct 15, 2026

    @ohlincha
    CollaboratorAuthor

    Coverage audit: Quantum ESPRESSO and CP2K in ECCE (2026-10-15)

    Columns: Dialog = can be set in the theory/runtype dialogs; Writer = ai.qe/qe.tpl writes it; Reader = qe.desc extracts it; Display = shown in the Builder/Viewer or a property panel. Priority: P1 = needed for the first real periodic DFT+U/MD cases, P2 = common in published periodic work, P3 = specialised.

    Quantum ESPRESSO (pw.x and companions)

    Capability Dialog Writer Reader Display Priority
    scf (Energy) yes yes energy, ΔE, time, version yes –
    relax (Geometry), forces yes yes (&IONS bfgs) GEOMTRACE, EGRADVEC trajectory –
    vc-relax ("Optimize cell"), stress yes yes (&CELL bfgs) LATTICEVEC, STRESS, PRESSURE box animates –
    Cutoffs, k-point grid + offset, smearing, nspin + starting magnetisation, conv_thr, mixing, input_dft, tot_charge yes yes – – –
    Pseudopotentials: picked per element from a UPF directory yes yes – – –
    md (Born–Oppenheimer; dt, nstep, ion_temperature/thermostat) no no no trajectory/energy-vs-time no P1
    DFT+U (HUBBARD card, QE ≥ 7.1 syntax) no no no occupations no P1
    Dispersion (vdw_corr = dft-d3 / grimme-d2 / xdm) no no – – P1
    tot_magnetization / fixed spin no no magnetic moments not read no P2
    Cell constraints (cell_dofree), target pressure (press) no no – – P2
    Fixed atoms (if_pos in ATOMIC_POSITIONS) no no – – P2
    nscf + bands + DOS/PDOS (dos.x, projwfc.x) no no no no band structure/DOS plot P2 (two-step job; does not fit one input/one output)
    Löwdin charges (projwfc.x) no no no no P2
    Hybrid functionals (exx: nqx, ecutfock) only through the input_dft override partly – – P3
    Isolated systems (assume_isolated), ESM, Environ solvation no no – – P3
    Phonons / IR / Raman (ph.x, dynmat.x) no no no no P3
    NEB (neb.x) no no no no P3
    Noncollinear / spin–orbit no no – – P3

    CP2K (Quickstep; nothing in ECCE yet)

    The first case is taken from the structure of a real periodic input in hand (a talc cell with Fe, GEO_OPT and MD); no data from it goes into the repository.

    Capability Priority Notes
    Registration, cp2k.psmp/cp2k.ssmp, sh job scripts P1 as QE
    ENERGY, GEO_OPT P1 &MOTION &GEO_OPT; trajectory from -pos-1.xyz
    GPW, MOLOPT basis + GTH potentials per element (charge state qn picked from BASIS_MOLOPT/GTH_POTENTIALS) P1 scan the files, as qetheory.py scans UPFs
    PBE + D3 (&VDW_POTENTIAL PAIR_POTENTIAL DFTD3) P1
    UKS, charge, multiplicity P1
    DFT+U per kind (&DFT_PLUS_U, U_MINUS_J, L) P1
    OT SCF, cutoff/rel_cutoff P1
    Cell from the Builder lattice, PERIODIC XYZ P1
    Energy, SCF/opt progress (#284), final geometry, Mulliken charges, spin moments P1 reader
    MD (NVT/NPT; Nosé–Hoover, CSVR, GLE thermostats) P1 the same real input uses MD with GLE
    CELL_OPT P2
    Restart (.wfn, RESTART_HISTORY) P2
    Vibrational analysis P3
    QM/MM (FIST), classical MD P3 closer to the GROMACS path
    Hybrid functionals (ADMM), TDDFPT, metadynamics P3

    Proposed order

    1. QE P1: md, DFT+U and dispersion. These three appear together in most published periodic work on oxides and clays.
      • md reuses the NWPW Car–Parrinello widgets (time step, temperature, thermostat) and the GEOMTRACE reader, plus energy and temperature against time.
      • DFT+U and dispersion are dialog and writer only.
    2. CP2K P1 on the same pieces, plus the file-scanning basis/potential picker. Validation: run CP2K and QE directly on the same cell (ENERGY, GEO_OPT, short NVT) and compare with ECCE's results.
    3. QE and CP2K P2: constraints and target pressure, magnetic moments and charges, then the two-step jobs (bands/DOS), which need the multi-step job model.
    4. P3 only on request.

    Steps 1 and 2 are each about one working session; step 3 is larger, because of the two-step job model.

  3. ohlincha commented on Oct 16, 2026

    @ohlincha
    CollaboratorAuthor

    QE status after 9.2.0: md, DFT+U and dispersion shipped. Next, for battery work (2026-10-16): magnetic moments per site and Löwdin charges; NEB (#182); DOS/PDOS and band structure (multi-step jobs, #153); phonons last. The multi-step job mechanism is needed for DOS, bands, phonons and partly NEB. Design it once, for QE, CP2K and the workflows. Planned for 9.4.0.

  4. added 3 commits that reference this issue on Oct 18, 2026
  5. ohlincha commented on Oct 21, 2026

    @ohlincha
    CollaboratorAuthor

    Done on main: CP2K is registered with editor, input generator and parser, stages 1-4 (dc7325a ... e00f79d), parser fixtures from real CP2K 2025.1 runs. The QE points discussed here are tracked in #153, #181 and #182.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions