Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When outputting a DMR sparse format matrix, the ordering definition in R differs from that in HR. #5741

Open
14 tasks
goodchong opened this issue Dec 18, 2024 · 0 comments
Assignees
Labels
Feature Discussed The features will be discussed first but will not be implemented soon Input&Output Suitable for coders without knowing too many DFT details

Comments

@goodchong
Copy link
Collaborator

Background

The difference lies in the logic of the output section. For HR, the order of the list used to construct R has no relation to the order of neighboring atoms. For DMR, the order of R's list corresponds to the order of atom pairs.
Review the output section code: the logic for HR, SR, TR, rR, and dHR is the same and does not have an impact. Only the DMR logic differs and can cause an impact.
The output method of HR may result in matrices with R zeros, while DMR will not.
The code that defines the order of R:
HR: source/module_hamilt_lcao/hamilt_lcaodft/spar_dh.cpp void sparse_format::set_R_range
DMR: source/module_hamilt_lcao/module_hcontainer/hcontainer.cpp size_t HContainer::size_R_loop() const

Describe the solution you'd like

Leave it for further discussion.

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.
@goodchong goodchong added Feature Discussed The features will be discussed first but will not be implemented soon Input&Output Suitable for coders without knowing too many DFT details labels Dec 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature Discussed The features will be discussed first but will not be implemented soon Input&Output Suitable for coders without knowing too many DFT details
Projects
None yet
Development

No branches or pull requests

2 participants