Skip to content

Feature: an simple xml I/O library might be needed for parsing pseudopotentials and output files for orbital generation #3625

@kirk0830

Description

@kirk0830

Background

Currently in ABACUS there are many modules import and export data in xml format. Manually typing the tag may be not a good choice if xml is really designed to be used widely:
image
There are two main functions where xml is heavily used: reading pseudopotential and generating numerical orbital. There are also other parts use xml-like format, such as paw and pw wavefunction saving.
To make compatible with COHP for pw, it is also a good choice to dump a xml file, like QE.

Describe the solution you'd like

add a simple xml I/O library making easier for importing and exporting data. For example:

qsv = xml("QSV"); // create an empty xml file with root tag <QSV>...</QSV>

qsv.add_attrib("QSV", "version", "2.0.0"); // add an attribute to <QSV> tag, resulting in <QSV "version"="2.0.0">...</QSV>
qsv.add_data("QSV", std::vector<double>{1, 2, 3, 4}, "w"); // add data in write (overwrite if not empty) manner, resulting <QSV "version"="2.0.0">1.0 2.0 3.0 4.0</QSV>
qsv.add_data("QSV", std::vector<double>{1, 2, 3, 4}, "a"); // add data in appending manner, resulting <QSV "version"="2.0.0">1.0 2.0 3.0 4.0 1.0 2.0 3.0 4.0</QSV>

qsv.add_child("QSV", "OVERLAP_Q"); // add a child tag to <QSV>, resulting <QSV "version"="2.0.0">1.0 2.0 3.0 4.0 1.0 2.0 3.0 4.0<OVERLAP_Q></OVERLAP_Q></QSV>
qsv.add_child("QSV", "OVERLAP_Sq"); // <QSV "version"="2.0.0">1.0 2.0 3.0 4.0 1.0 2.0 3.0 4.0<OVERLAP_Q></OVERLAP_Q><OVERLAP_Sq></OVERLAP_Sq></QSV>
qsv.add_data("QSV/OVERLAP_Q", data, "a"); // symbol "/" is not allowed by xml standard, therefore use to uniquely define a tag that is not root

Task list only for developers

  • Notice possible changes of behavior
  • Explain the changes of codes in core modules of ESolver, HSolver, ElecState, Hamilt, Operator or Psi

Notice Possible Changes of Behavior (Reminder only for developers)

No response

Notice any changes of core modules (Reminder only for developers)

No response

Notice Possible Changes of Core Modules (Reminder only for developers)

No response

Additional Context

No response

Task list for Issue attackers (only for developers)

  • Review and understand the proposed feature and its importance.
  • Research on the existing solutions and relevant research articles/resources.
  • Discuss with the team to evaluate the feasibility of implementing the feature.
  • Create a design document outlining the proposed solution and implementation details.
  • Get feedback from the team on the design document.
  • Develop the feature following the agreed design.
  • Write unit tests and integration tests for the feature.
  • Update the documentation to include the new feature.
  • Perform code review and address any issues.
  • Merge the feature into the main branch.
  • Monitor for any issues or bugs reported by users after the feature is released.
  • Address any issues or bugs reported by users and continuously improve the feature.

Metadata

Metadata

Assignees

Labels

Feature DiscussedThe features will be discussed first but will not be implemented soon

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions