2018-04-26 10:51

3 files changed, 20 insertions, 22 deletions

diff --git a/acquisition/chapter.tex b/acquisition/chapter.tex
index 8ca947c..7fbd1e7 100644
--- a/acquisition/chapter.tex
+++ b/acquisition/chapter.tex
@@ -53,7 +53,7 @@ require custom software to address all of the simultaneous, repeated motor motio
 requires.  %

 Because MR-CMDS is really a family of techniques which require different kinds of motor motion,

 this acqusition software should be flexable enough to meet the creativity of its users.  %

-Furthermore, because MR-CMDS is a bleeding edge, rapidly evolving technique the instrumental

+Furthermore, because MR-CMDS is a, rapidly evolving technique the instrumental

 software must be built in an extendable way to accommodate the ever-changing hardware

 configurations.  %

 In this chapter I describe how I built such an acquisition software, PyCMDS.  %

@@ -439,8 +439,8 @@ This is typical behavior for Mutexes, however.  %
 \subsubsection{Hardware and driver}  % ------------------------------------------------------------

 

 Now that we have basic data types to work with, let's actually communicate with hardware.  %

-Every hardware and sensor have two classes: a driver class, which lives in the worker thread and

-handles direct communication, and a hardware class which lives in the main thread and

+Every hardware and sensor are made of two classes: a driver class, which lives in the worker thread

+and handles direct communication, and a hardware class which lives in the main thread and

 ``represents'' that device to the rest of PyCMDS.  %

 The idea is that all of PyCMDS communicates to that device \emph{only} via its hardware class, and

 that hardware class only talks to that driver class.  %

@@ -778,8 +778,8 @@ forward.  %
 \begin{landscape}

 \begin{figure}

   \includegraphics[width=9in]{"acquisition/screenshots/003"}

-  \caption{

-    PCI-6251 samples tab.

+  \caption[PCI-6251 samples tab.]{

+    Screenshot of PCI-6251 samples tab.

   }

   \label{acq:fig:samples}

 \end{figure}

@@ -937,7 +937,7 @@ from the file \bash{PyCMDS/somatic/acquisition.py}.  %
 This method understands how to any scan that PyCMDS can do: any stepwise multidimensional scan with

 separate hardware and sensors.  %

 

-The central scan method requires acquisition modules to provide all of the axes (instances of

+The central scan method requires acquisition modules to provide all of the axes (instances of \\

 \python{PyCMDS.somatic.acquisition.Axis}) that need to be broadcast across each-other.  %

 Then something very simple happens.  %

 For each hardware that will move during the scan, a destinations object (instance of

@@ -1020,14 +1020,14 @@ Arbitrary expressions (PyCMDS calls them ``constants'') are also possible, as ca
 The TUNE TEST module does a simple thing: it sets a chosen OPA to each of the points in its tuning

 curve and does a monochromator scan of set width about that setpoint.  %

 In this way the tune (output color) agreement between the curve and the OPA can be determined.  %

-As a convinience, a new point curve with remapped colors is automatically created.  %

+A new point curve with remapped colors is automatically created.  %

 % TODO: link to place in tuning chapter...

 

 \subsubsection{MOTORTUNE}

 

 MOTORTUNE is capable of arbitrary acquisitions in OPA motor space.  %

 Users are free to choose any set of positions for any set of motors, and PyCMDS will broadcast all

-of those positions against eachother to form a multidimensional acquisition.  %

+of those positions against each-other to form a multidimensional acquisition.  %

 Optionally, a leading dimension of \emph{setpoint} may be added, with motor positions being scanned

 about the points in the old curve.  %

 

@@ -1044,11 +1044,11 @@ regular tuning. See \autoref{act:sec:poynting} for more information.  %
 

 \section{Conditional validity}  % =================================================================

 

-The central conceit of the PyCMDS modular hardware abstraction is that experiments can be boiled

-down to a set of orthogonal axes that can be set separately from other hardware and sensor

+The central requirement of the PyCMDS modular hardware abstraction is that experiments can be

+boiled down to a set of orthogonal axes that can be set separately from other hardware and sensor

 status.  %

 This requirement is loosened by the autonomic and expression systems, such that any experiment

-could \emph{probably} be forced into PyCMDS, but still the conceit stands---PyCMDS is probably

+could \emph{probably} be forced into PyCMDS, but still the requirement stands---PyCMDS is probably

 \emph{not} the correct framework if your experiment cannot be reduced in this way.  %

 From this we can see that it is useful to talk about the conditional validity of the modular

 hardware abstraction.  %

@@ -1066,7 +1066,6 @@ For measurement-complex problems, the challenge is, well, the measurement.  %
 These are experiments where every little piece of the instrument is tied together into a complex

 network of inseparable parts.  %

 These are often time-domain or ``single shot'' measurements.  %

-Consider work of (GRAPES INVENTOR).  %

 Such instruments are typically much faster at data acquisition and more reliable.  %

 This comes at a price of flexibility: often such instruments cannot be modified or enhanced without

 touching everything.  %

@@ -1076,8 +1075,6 @@ purpose modular software design.  %
 The instrument is so custom that it certainly requires entirely custom software.  %

 

 Measurements can be neither hardware-complex nor software-complex (simple) or both (expensive).  %

-Conceptually, can imagine a 4 quadrant system.  %

-

 Thus PyCMDS can be proud to try and generalize the hardware-complex part of acquisition software

 because indeed that is all that can be generalized.  %

 

@@ -1124,9 +1121,9 @@ Wigners are all correct.  %
 

 \subsection{``Headless'' hardware, sensors}  % ----------------------------------------------------

 

-The abstraction of hardware complexity that PyCMDS offers is really convienient, but currently

-these convinient classes can only be used within PyCMDS itself.  %

-Since code in PyCMDS is inseperable from the GUI, it is not possible to \python{import PyCMDS} and

+The abstraction of hardware complexity that PyCMDS offers is really convenient, but currently

+these convenient classes can only be used within PyCMDS itself.  %

+Since code in PyCMDS is inseparable from the GUI, it is not possible to \python{import PyCMDS} and

 use the abstract tools in other programs or scripts.  %

 This design is not necessary, and doing the work to free hardware and sensor code from the GUI code

 would allow for all kinds of creative experiments that are not currently possible within the

@@ -1166,7 +1163,7 @@ Of course, linearizing pixels in signal requires prior expectations about the sh
 multidimensional signal---linear stepping is still an appropriate choice for low-resolution

 ``survey'' scans.  %

 

-CMDS scans often posses correlated features in the multidimensional space.  %

+CMDS scans often contain correlated features in the multidimensional space.  %

 In order to capture such features as cheaply as possible, one would want to define regions of

 increased pixel density along the correlated (diagonal) lineshape.  %

 As a concession to reasonable simplicity, our acquisition software (PyCMDS) assumes that all scans

@@ -1271,3 +1268,4 @@ See \autoref{cha:pro} for more information about WrightTools.  %
 Even more exciting, wt5 files can be instantiated as empty and \textit{then} filled.  %

 This means that the wt5 file can be a self-describing set of destinations that actually defines

 which pixels PyCMDS should visit.  %

+% JCW: i don't think there is enough information provided to support these sentences
\ No newline at end of file
diff --git a/active_correction/chapter.tex b/active_correction/chapter.tex
index d3028fe..e996898 100644
--- a/active_correction/chapter.tex
+++ b/active_correction/chapter.tex
@@ -44,7 +44,7 @@ Section \ref{act:sec:chop} addresses (dual) chopping, used to actively subtract
 scatter and unwanted nonlinear outputs.  %

 Chopping can only account for intensity level (additive) artifacts.  %

 Fibrillation is the opposite of chopping, as it can only account for amplitude level

-\emph{iterference} effects.  %

+\emph{interference} effects.  %

 Section \ref{act:sec:chop} also addresses fibrillation.  %

 

 \section{Spectral delay correction} \label{act:sec:sdc} % =========================================

@@ -66,7 +66,7 @@ SDC was first implemented by Schuyler Kain within his COLORS acquisition softwar
 COLORS' implementation was hardcoded for one particular OPA / delay configuration---it wasn't until

 PyCMDS that fully arbitrary SDC became possible through the autonomic system (see

 \autoref{acq:sec:autonomic}).  %

-Erin Boyle ``backported'' similar functionality into to ps\_control, although her implementation

+Erin Boyle ``backported'' similar functionality into ps\_control, although her implementation

 allowed only for a simple, first order linear correction.  %

 

 Sometimes, spectral delay can be corrected for after-the-fact.  %

@@ -125,7 +125,7 @@ The curvature in the plot is due entirely to SDC, as sapphire is entirely nonres
 Using WrightTools, PyCMDS fits each slice to find the delay that gives maximum signal.  %

 It then passes those separate fits through a spline to guess the ultimate SDC dependence.  %

 PyCMDS makes a best guess in regions where there is not enough signal to determine the appropriate

-delay, like in at 800 nm in the left hand plot.  %

+delay, like at 800 nm in the left hand plot.  %

 The magnitude of the corrections are roughly 30 fs in this particular experiment: not large, but

 enough to change signal levels by roughly a factor of 2.  %

 In other cases SDC is as much as 200 fs.  %

diff --git a/opa_phase/chapter.tex b/opa_phase/chapter.tex
index ae1a9ea..6fef62f 100644
--- a/opa_phase/chapter.tex
+++ b/opa_phase/chapter.tex
@@ -7,7 +7,7 @@ This makes interference processes quickly average to zero over many shots---we r
 than 100 shots per pixel.  %
 Here I demonstrate that this assumption is very poor, at least for the femtosecond OPAs.  %
 
-In these experiments, I simply send OPA1 and OPA2 simultaniously into the array detector.  %
+In these experiments, I simply send OPA1 and OPA2 simultaneously into the array detector.  %
 The crucial detail is that the beams are exactly collinear---overlaped in a beamsplitter.  %
 I then scan delay between them while collecting single shot spectra using the array detector.  %