N_excess vs. Pressure
andyletzhang opened this issue · comments
Hopefully this is just a matter of changing the columns we're pulling for cell 1.5.
That would be sweet. I need to learn how to pull the right columns (as per my error in trying to write a pressures file with delta z and having it write alpha instead!) This error occurs in cell 13 of the notebook called BIAS_Jan14-2.ipynb in the Sarah Chang project.
I've taken a look at the notebook in question, and I think everything's actually working as desired in that you're getting delta z values, but they're all being evaluated with respect to some static ZC=3.85 or so from an old curve fit since the actual sp.curve_fit() line has been commented out for some time! So the ΔZ=0.15 values you were getting were the right data column but not very useful data.
Speaking of not very useful data, looks like we're going to need to modify this code:
Given how we've treated files with various pressures in the past, here we're fitting each segment separately. I think what we want to do next is just concatenate foos 2 through 6 together and get a reasonable fit; I'll add this as a new issue tonight.
An issue of similar importance is how we're writing pressure. We should definitely have pressure written as prs2 to begin with in Info_Analysis so that we would never have to meddle with it again. As this is currently written, each reiteration of the ΔZ cell adds an extra factor of rs2 to pressure! Should be an easy fix, it just has to get done.
One other thing you may have happened upon which tripped me up a good deal: at some point in the last few months I put this insidious little filter into the read_data() function of BondInfo_Analysis:
return dataset.loc[get_pressures(filename).index]
This is meant to filter out any data sets that have unreasonable elastic moduli to bring it into accordance with our Pressures data files, but in the case that a pressure file doesn't exist or is empty, it just doesn't return any bond data! I don't remember what this was meant to address, but this seems like a very scorched-earth approach to loading BondInfo datasets and we should probably only apply this filter on a case-by-case basis; as it stands this necessitates generating a pressures file before we do any BondInfo_Analysis work.
Nothing too crazy code-wise with plotting Nexcess against pressure. This means we need to pair up each Nexcess value with its pressure from the corresponding Pressures.txt file, which isn't bad at all since each Nexcess value is already paired up with its corresponding trial name. As usual, this means dropping a few trials which don't show up in Pressures.txt due to undesirable elastic moduli; I'm not sure if we want to just drop these criteria and use all our data, but it's typically under 10 trials out of 600 or so total so it shouldn't be a significant difference either way.
The plot looks like a power scaling, which is good because the essence of this plot is the same as the Z vs. P plots we've been making for a long time, but with everything (hopefully) centered at zero, so that this looks the same as ΔZ vs. P (but N, being the number of bonds, should be half as large as Z, the number of bond-ends).
Doing power fits with the presumption that there's no intercept gives pretty nice slopes a little larger than a half. Hopefully they correspond to the β values we fitted before:
Looks like this isn't exactly the case... am I right to think that these should both be β?
After consulting Amy, looks like this isn't β unless we have no pins. A simple question we can address, however, is this: are these configurations isostatic at jamming?
Zooming in at the origin, we can see that Nexcess looks like it goes to 0 as pressure does, which goes a good way to showing that systems even with pins are isostatic.
