ExternalElectricField is not compatible with SlabDipoleCorrection

Bug #1593725 reported by Roberto Robles
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Siesta
Fix Released
High
Nick Papior
4.0
Fix Released
High
Nick Papior

Bug Description

Introducing an external electric field is not compatible with slab dipole corrections. When the later are activated the electric field is automatically set to 0. However, the dipole corrections are needed to avoid spurious dipole interactions between the repeated images.

I propose a fix that just affects dhscf.F and siesta.tex. The old behavior can always be recovered with SlabDipoleCorrection = .false.

I consider the current behavior a bug, but they might be reasons to prefer it to the proposed one. In any case now it would be for the user to decide if dipole corrections are included or not. For that reason I also propose a modification in the manual to alert the user of the change.

Siesta version: all. Patch for trunk-518.

Related branches

Revision history for this message
Roberto Robles (roberto-robles) wrote :
description: updated
Nick Papior (nickpapior)
Changed in siesta:
status: New → Invalid
Revision history for this message
Nick Papior (nickpapior) wrote :

Having given this some thought. Each term is linearly independent and thus the correct method for applied electric field is actually to always include the slab dipole correction.

As such the bug extends beyond that reported and further changes are needed.

Changed in siesta:
status: Invalid → In Progress
importance: Undecided → High
assignee: nobody → Nick Papior (nickpapior)
Revision history for this message
Nick Papior (nickpapior) wrote :

Could you please check the referenced branch whether the result is as expected? It now defaults to using the dipole correction when using an external electric field.

Also, please note that the total energy will be different from your attached patch, there was an error in calculating the dipole correction of the total Hartree energy (see h2_dipole and h2_dipole2).

Revision history for this message
Roberto Robles (roberto-robles) wrote :

The behavior is as expected in the tested case. Adding an electric field adds dipole corrections by default. Explicitly using 'SlabDipolCorrection F' recovers the old behavior. The resulting energies are different as you point out, but the rest looks OK.

Nick Papior (nickpapior)
Changed in siesta:
status: In Progress → Fix Released
Revision history for this message
akaaykohli (akaaykohli) wrote :

It seems like you're discussing a modification or enhancement proposal for the SIESTA electronic structure code like https://electriciandiary.com/ . The proposed fix involves changes to the dhscf.F file and the siesta.tex documentation. It appears that the current behavior, where introducing an external electric field automatically sets the field to 0 when slab dipole corrections are activated, is considered a bug, and you suggest allowing users to decide whether dipole corrections are included or not.

Here's a breakdown of your proposal:

Issue: Introducing an external electric field is not compatible with slab dipole corrections.

Current Behavior: The electric field is automatically set to 0 when slab dipole corrections are activated.

Proposed Fix:

Modify dhscf.F and siesta.tex.
Allow users to decide if dipole corrections are included or not by introducing a parameter like SlabDipoleCorrection = .false.
Reasoning: The dipole corrections are essential to avoid spurious dipole interactions between repeated images, but the current behavior is considered a bug. Users should have the flexibility to decide whether dipole corrections are applied or not.

Reverting to Old Behavior: Users can always revert to the old behavior with SlabDipoleCorrection = .false.

Manual Modification: Propose a modification in the manual to inform users about the change and allow them to make an informed decision.

It's a clear and detailed proposal. If you're submitting this to the SIESTA development team, make sure to provide all necessary details and consider including test cases or examples to demonstrate the impact of the proposed changes. Additionally, providing reasons for the proposed modifications can help the team understand the motivation behind the changes.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.