Closed mondracek closed 8 months ago
Attention: 12 lines
in your changes are missing coverage. Please review.
Comparison is base (
18a5d8a
) 46.40% compared to head (00f61c3
) 46.34%.
Files | Patch % | Lines |
---|---|---|
ppafm/cli/generateElFF.py | 0.00% | 9 Missing :warning: |
ppafm/HighLevel.py | 50.00% | 2 Missing :warning: |
ppafm/PPPlot.py | 0.00% | 1 Missing :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
This PR now also closes #252. On the one hand, I understand this is a somewhat non-standard work flow as the two issues, #250 and #252, have nothing in common except they both need to be solved in order to generate the LCPD image for the paper. On the other hand, we need the figure for the paper urgently and the commit that solves #252 changes literary just one line of code. As long as the change is uncontroversial, doing all the motions with a separate pull request would be a waste of time and effort.
Tl;dr: Please also check the second commit in this PR.
Fixes #250. What I have done to address the sign issue itself can be best understood from the code changes I think. Besides that
main
ofppafm/cli/generateElFF.py
was creating two copies of the electrostatic potential before calculating LCPD:v_v0_aux = electrostatic_potential.copy()
andv_v0_aux2 = electrostatic_potential.copy()
. Having the same field written in three places made the code look rather messy to me and I found it difficult to keep track of the required sign changes in such a mess so I did away with those copies. As I understood it, they were needed because thepotential2forces_mem
function inppafm/fieldFFT.py
would remove the array with the potential after the potential had been used, unless the function had been called with thedeleteV=False
argument. In order to address this, I have therefore introduced thedeleteV
argument to the functioncomputeElFF
fromppafm/HighLevel.py
so that thedeleteV=False
option could be passed fromgenerateElFF.py
topotential2forces_mem
throughcomputeElFF
.FFkpfm_tVs0
term was scaled by the tip chargeabs(PPU.params.["charge"])
here https://github.com/Probe-Particle/ppafm/blob/18a5d8a68158e5ffc76d7988bb3e9a6a3b86ff2d/ppafm/HighLevel.py#L160 I did not think this made any sense so I removed this scaling: https://github.com/Probe-Particle/ppafm/blob/aaeedbcbabab2c82453ff283379b4a4e21720071/ppafm/HighLevel.py#L160 @aureliojgc, can you comment on what idea was behind it? Anyway, as I removed it, I changed the meaning of the numerical tip polarizabilities defined here: https://github.com/Probe-Particle/ppafm/blob/aaeedbcbabab2c82453ff283379b4a4e21720071/ppafm/cli/generateElFF.py#L126-L137 I did not change the numbers (only the signs) as it seemed to me that before I removed the scaling, theFFkpfm_tVs0
contribution was always negligible with respect to theFFkpfm_t0sV
contribution for default tip polarizability and typical tip charge, which did not seem right. Now this relative contributions ofFFkpfm_tVs0
andFFkpfm_tVs0
somewhat improved as to become more equalized.