why are we getting negative mobilities?
Closed this issue · 18 comments
It is showing a negative hole mobility in the p3ht workflow. I think negative mobility is illegal.
I need to look more into the definitions. I thought mobility was positive by definition. A quick read through this wiki for electron mobility for what its worth (https://en.wikipedia.org/wiki/Electron_mobility) agrees and I always see them reported as positive numbers. Now my brain hurts. Does morphct's zero-field mobility calculation effect the sign?
Yep, I see this:
Hole mobility = -5.86E-03 +/- -7.16E-03 cm^2 V^-1 s^-1
I'm also noticing that the error is larger than the value and also negative, which seems bad.
pulling the thread:
from morphct/mobility_kmc.py
213 init_pos = self.initial_chromo.center
214 final_pos = self.current_chromo.center
215 displacement = final_pos - init_pos + self.image * self.box
216 self.displacement = np.linalg.norm(displacement)
The displacement is used in the mobility calculation and it can't be negative. Then the mobility is calculated from the mean square of this displacement along with the carrier lifetime. I think the error could be two-fold:
(1) the parallel sort I am using is not working correctly, so the slope is negative
(2) I am using the specified carrier lifetimes but should be using the actual times? (not sure--I don't think I changed this from how Matty had it.)
Jotting down some thoughts: I think maybe I'm a little confused why the times are calculated the way they are--see morphct.kmc_analyze.get_times_msds. We specify the desired lifetimes for the simulation and then we get the mobility from linear fit to the lifetime we specified vs the average MSD obtained using that lifetime. This is how Matty had it too.
Wouldn't it make more sense to use more data points for the linear fit, each actual lifetime along with the MSD? Or is that data too messy?
Matty mentioned in Slack the straight line between two data points, which makes me wonder if that was different than he was expecting?:
Gotta love a straight-line MSD plot formed from two data points! Ship it!
Now that I am a little more familiar, I know the two data points are a result of using two lifetimes as input to the KMC sim... (I did this because one of the test asset pickle files was this way, so I just assumed it was the way to do it! 😅 )
You're right that the MSD calculation is a bit confusing.
A short-term answer is to pass a list of lifetimes of varying orders of magnitude to get MSDs spanning a broader set of times with the current implementation.
But I'm with you about calculating MSDs from each charge: Then we would be able to set one upper-bound lifetime and have full MSD data averaged from thousands of charges over thousands of hops.
Ahhhh, but the messy part is binning the MSD data: Because KMC hops can be of arbitrary time each step, we'll need to either be careful about choosing how to add each hop to a histogram spanning many orders of magnitude in time (e.g. e-15s to e3s), or do it like currently implemented, where we set some speed limits (lifetimes) and use those to artificially bin for ourselves.
Lifetime limits of 1e-12, 1e-9, 1e-6, 1e-3 are probably a fine place to begin for debugging purposes, though. Can probably omit 1e-3, even.
And now after digging into this i can see how a negative mobility is mathematically possible when we only have a couple lifetimes and MSD's from both have very high variances as we do: We're fitting a line through noise. How the STD could be negative is... befuddling, though. That's no good.
The mobility itself does have a factor of the elementary charge in it, so that's another way (electron) mobility can (should) be negative, on top of the variance issue above. Yet it doesn't explain negative standard deviations, which to me still look constrained to be positive, unless there's something going on in how linear fits are applied to the carrier MSDs or the parallel_sort helper function.
Can @JimmyRushing or @jennyfothergill verify what mobilities look like with lifetimes of 1e-12, 1e-9, 1e-6 seconds?
I think using that large of a lifetime is causing morphct to run for a very long time to the point where it seems like it's hanging.
The 1e-6? Or 1e-9?
I tried this in the meantime using examples/workflow-p3ht.ipynb:
lifetimes = [1e-14, 1e-13, 1e-12, 1e-11]
temp = 300
I get Hole mobility = 7.88E-03 +/- 9.93E-04 cm^2 V^-1 s^-1
and the plot looks like:
Probably 1e-14 is too small, which explains the very small MSD.
leaving out 1e-14 makes a big difference
Hole mobility = 1.66E-02 +/- 1.70E-03 cm^2 V^-1 s^-1
And I wouldn't think of the lower distance of 1e-14 being a "too small" mistake per say, more like that's a timescale that's so fast that most charges don't have time to move 1 or more hops: it should tell us something about the physics of hopping if it's a big enough anomaly
OK, that makes sense. this paper reports hole mobilities in P3HT around 1e-4 cm^2/(V s) (experimental using SCLC) so maybe including those lifetimes where the carrier is restricted is actually more realistic
Fig 10 in 10.1080/08927022.2017.1296958 is our buddy here. Experimental hole mobilities are measured anywhere between 1e-5 and 1e-3, (which we found!), and in our defect-free perfect p3ht crystals we get 1e0! So this all looks pretty reasonable on the whole.
OK, this issue in the example with the negative mobility is fixed by using more values for the lifetimes. It's hard to tell in fig 10(a), but judging from the wiggliness of the blue line, I think that multiple lifetimes were given in the past as well. It's my bad for not realizing sooner that this was important! The mobilities we're getting with the larger spread of lifetimes are much more reasonable even though this system is very small. I'll update the example and close this issue.