Standardize Molden output and add Multiwfn-specific interface

[Stardust0831]

Summary

This PR updates the ABACUS Molden conversion workflow to make the core tools/molden/molden.py output closer to the Molden format conventions, while moving Multiwfn-specific metadata handling into a dedicated interface.

Changes

• Add Molden format references at the beginning of tools/molden/molden.py.
• Replace the previous optional [Nval] output in tools/molden/molden.py with default [Pseudo] output.
• Remove the --write-nval option from the core Molden generator.
• Add interfaces/Multiwfn_interface/molden_nval.py, which calls tools/molden/molden.py via importlib and 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 couples tools/molden/molden.py to one downstream analysis program.

This PR decouples the two use cases:

• tools/molden/molden.py now generates a more standard Molden file with [Pseudo] metadata by default.
• interfaces/Multiwfn_interface provides the Multiwfn-specific [Nval] behavior separately.

[Stardust0831]

@kirk0830

In this update, I separated the Multiwfn-specific behavior from the core Molden converter.

The main changes are:

• Added a dedicated interfaces/Multiwfn_interface/molden.py wrapper for Multiwfn-oriented Molden generation.
• Kept the [Nval] handling inside the Multiwfn interface only, instead of adding it to tools/molden/molden.py.
• Kept tools/molden/molden.py focused on generating a more standard Molden file.
• Made optional non-standard or auxiliary sections configurable:
  • tools/molden/molden.py: [Cell] and [Pseudo] are optional and disabled by default.
  • interfaces/Multiwfn_interface/molden.py: [Cell] and [Nval] are enabled by default for Multiwfn usage, while [Pseudo] remains optional and disabled by default.
• Added Molden format references to clarify the intended output convention.

The purpose is to make the core tools/molden/molden.py output closer to the standard Molden format, while keeping program-specific compatibility logic, such as Multiwfn [Nval], in the interface layer.

[kirk0830]

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

[Growl1234]

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).

[Growl1234]

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...

[kirk0830]

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.

[Stardust0831]

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 --ikpoint option, selected/all k-point conversion, and k-point-based output naming.

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.

[mohanchen]

Please migrate the entire content from tools/molden to interfaces/Multiwfn_interface. Interface-related tools will be removed from the tools folder going forward.

[Growl1234]

Is this really appropriate, given that the Molden output is not, in principle, designed specifically for Multiwfn?

[mohanchen]

It's a very nice PR!

[Stardust0831]

@mohanchen
Thanks for the suggestion. I agree that interface-related tools should be moved out of tools/ since they will be removed from that folder going forward. In this update, I have migrated the entire contents of tools/molden/ to interfaces/Multiwfn_interface/, including the Molden converter and example files. I also updated the script to support the latest ABACUS NAO wavefunction files (wf_nao.txt, wfs1_nao.txt, and wfs2_nao.txt) and added optional controls for Molden sections such as [Cell], [Nval], and [Pseudo].