Standardize Molden output and add Multiwfn-specific interface#7424
Standardize Molden output and add Multiwfn-specific interface#7424Stardust0831 wants to merge 14 commits into
Conversation
Title: Improve ABACUS Molden output for wavefunction analysis Summary: This PR fixes several Molden conversion issues in tools/molden/molden.py while keeping the default workflow unchanged as much as possible. Changes: - Correct the primitive Gaussian coefficient convention when writing Molden GTO data. The NAO-to-GTO fit uses unnormalized radial primitives, while Molden readers usually normalize primitive Gaussian functions internally. - Fix Cartesian_angstrom coordinate conversion. Coordinates in Angstrom are now converted to Bohr for the Molden [Atoms] AU section by dividing by 0.529177210903. - Add optional multi-start NAO-to-GTO fitting. A single -r value keeps the old single-start behavior; comma-separated -r values enable multi-start fitting and keep the fit with the lowest nonlinear error. - Add optional Molden [Nval] output via --write-nval. The values are read from UPF z_valence. This option is disabled by default. Notes: - The changes are limited to the Molden converter. Validation: - Ran the existing molden.py unit tests successfully. - Checked that default output does not contain [Nval]. - Checked that --write-nval writes C/O/H valence charges for the PhenolDimer test case. - Checked that Cartesian_angstrom coordinates are written at the correct Bohr scale.
Refactor Molden file writing functions to handle effective nuclear charges instead of valence charges. Update command line arguments and main function to remove Nval section. - Write [Pseudo] metadata by default in tools/molden/molden.py - Remove the [Nval] command-line option from the core Molden generator
This change modifies the molden_nval.py script to write [Nval] metadata by default instead of [Pseudo] when generating Molden files for Multiwfn.
|
In this update, I separated the Multiwfn-specific behavior from the core Molden converter. The main changes are:
The purpose is to make the core |
kirk0830
left a comment
kirk0830
left a comment
There was a problem hiding this comment.
This PR is submitted after a long discussion with @Stardust0831, @QuantumMisaka, and @Growl1234, during which several general ideas were developed on how to appropriately implement an interface with other software.
Generally speaking, the interface is where data is reorganized and postprocessed. It would be the best case in which the software interface accepts some common file formats such as Gaussian cube, xyz (extxyz), Protein Data Bank (pdb), Crystallographic Information File (cif), etc, and in this case, it is only needed to add a function/module to dump such a file, and due to there are always not only one softwares accept those formats, it is better to place such codes into tools/ instead of the interfaces/, due to it is a "one (ABACUS)-to-many" case.
Molden is a standard format for organizing wavefunction information and has been widely used in the quantum chemistry community for decades. Its standard regulating a correct format has also been published online. The implementation in the folder tools/ was designed to convert the wavefunction of ABACUS-LCAO into a compatible format that can be stored in the Molden file.
However, there are software programs that may also suggest or accept some customized sections in Molden such as [Nval], [Cell], etc, say, a non-standard Molden format. In this case, the adaptation of the Molden file should not be implemented in the code supporting a standard Molden file generation. Instead, the code to modify the Molden so that it supports software like Multiwfn would be better placed in the folder interfaces/ instead of tools/, as an example of a "one (ABACUS)-to-one (Multiwfn)" case.
This design concept can help ABACUS maintain better code integrity and functionality, to be decoupled from any changes in other software (or, say, avoid any unnecessary dependency). In the future, when the software ABACUS interfaces updates, it is only needed to update the code in interfaces/, avoiding any risks of the spoilage of the functionality of ABACUS's main body.
cc. @mohanchen
mohanchen
added
Feature Discussed
Updated regex pattern for reading ABACUS lowf files to support new naming conventions. Added functions to handle multiple k points and modified the moldengen function to accept ikpoint parameter.
Growl1234
left a comment
Growl1234
left a comment
There was a problem hiding this comment.
Thank you so much, it worked!
Just some minor comments, otherwise looks good.
It's also suggested to run chmod +x to those scripts (with #!/usr/bin/env python3 header).
Co-authored-by: SY Wang <uwsy1059@qq.com>
Removed ikpoint parameter from moldengen function and adjusted related logic.
Refactor find_abacus_lowf_files function to remove ikpoint parameter and update related logic. Remove unused append_molden_filename_suffix and find_abacus_lowf_file_groups functions.
Growl1234
left a comment
Growl1234
left a comment
There was a problem hiding this comment.
I don't quite see the point of the follow-up refactoring, but I think that the discussion of post-processing regarding k-points might be too much for this PR...
I agree, multiple k points support seems a complicated topic and there is no Molden file standard regarding k points. |
Thanks, I agree. I have removed the k-point-related changes from this PR, including the The converter now keeps the original behavior: only gamma-only single-k calculations are accepted, and non-gamma-only k-point calculations are rejected. So the remaining scope of this PR is limited to the wavefunction filename compatibility issue in the current ABACUS development branch, while keeping the Multiwfn-specific handling separated in the interface script. |
4 participants
Summary
This PR updates the ABACUS Molden conversion workflow to make the core
tools/molden/molden.pyoutput closer to the Molden format conventions, while moving Multiwfn-specific metadata handling into a dedicated interface.Changes
tools/molden/molden.py.[Nval]output intools/molden/molden.pywith default[Pseudo]output.--write-nvaloption from the core Molden generator.interfaces/Multiwfn_interface/molden_nval.py, which callstools/molden/molden.pyviaimportliband writes[Nval]metadata for Multiwfn-specific usage.Rationale
[Nval]is useful for Multiwfn analysis, but it is not part of the standard Molden format. Keeping it in the core Molden generator couplestools/molden/molden.pyto one downstream analysis program.This PR decouples the two use cases:
tools/molden/molden.pynow generates a more standard Molden file with[Pseudo]metadata by default.interfaces/Multiwfn_interfaceprovides the Multiwfn-specific[Nval]behavior separately.