2018-04-14 12:59

1 files changed, 21 insertions, 13 deletions

diff --git a/acquisition/chapter.tex b/acquisition/chapter.tex
index 78b4199..a7d434e 100644
--- a/acquisition/chapter.tex
+++ b/acquisition/chapter.tex
@@ -103,7 +103,7 @@ spectroscopist to the next, but there is almost no overlap between hardware conf
 the two primary instruments maintained by the Wright Group.  %

 Besides the extendable modular pieces, the rest of PyCMDS is a mostly-static code-base that accepts

 modules and does the necessary things to handle display of information from, and communication

-between them.  %

+between, them.  %

 

 PyCMDS offers many ways to interact with component hardwares.  %

 Hardware can be set directly, or it can be moved in the context of a scan.  %

@@ -124,7 +124,7 @@ I have borrowed the terms ``autonomic'' and ``somatic'':
 

   The autonomic and somatic systems operate hand in hand...

 

-  The functions of the autnomic nervous system are to keep the internal milieu of the body constant

+  The functions of the autonomic nervous system are to keep the internal milieu of the body constant

   (homeostasis...) or adjust it as required by changing circumstances (e.g., mechanical work, food

   intake, water deprivation, heat or cold).  %

 

@@ -143,7 +143,6 @@ acquiring a multidimensional scan.  %
 

 In this section I introduce the GUI of PyCMDS, with the goal of introducing the basic structure as

 experienced by a first time user of the software.  %

-

 When PyCMDS starts up, the GUI is constructed out of modules depending on which hardware and

 sensors the user has instructed the program to address.  %

 A screenshot of the PyCMDS GUI, running on the fs table, is shown in

@@ -353,7 +352,7 @@ For OPAs in the Wright Group, this operation requires the following:
 This is not even to mention the complexity of spawning and sending information between the main

 thread and working threads.  %

 Through abstraction, PyCMDS is able to wrap all this complexity into the \python{OPA} class and

-it's \python{set_position} method---so doing all of the operations above is as simple as

+its \python{set_position} method---so doing all of the operations above is as simple as

 \python{opa.set_position(1300, 'nm')}.  %

 Importantly, abstraction does not magically get rid of the complexity.  %

 It simply \emph{hides} the complexity so that it becomes tractable to write simple interfaces to

@@ -365,7 +364,7 @@ The \emph{child} class acquires all of the properties of the \emph{parent} class
 The child class, then, can modify or extend the properties that it needs, without needing to

 re-implement the properties that it shares with the parent.  %

 Let's consider PyCMDS hardware again.  %

-Every single unique hardware in PyCMDS lives in it's own worker thread, so the basic problem of

+Every single unique hardware in PyCMDS lives in its own worker thread, so the basic problem of

 information transfer through queues and Mutexes is shared between them.  %

 A \python{Hardware} class which is parent to \emph{all} hardwares can define the methods and

 attributes necessary to abstract this basic thread communication issue.  %

@@ -399,7 +398,7 @@ Now we can see that PyCMDS is going to use multi-threading, inheritance and abst
 possible, so let's get into some details about the \emph{actual} internal structure of the

 software.  %

 

-For those that want to dig deeper, most of these top level classes are defined in

+For those that want to dig deeper, most of these top level classes are defined in \\

 \bash{PyCMDS/project/classes.py}.  %

 

 \subsubsection{Data types}  % ---------------------------------------------------------------------

@@ -512,7 +511,10 @@ enabled.  %
 Input tables are the two column GUI elements that are everywhere in PyCMDS.  %

 The great thing about input tables is that they accept PyCMDS ``data type'' objects directly.  %

 Given an instance of \python{Number} called \python{destination}, adding to the input table is as

-easy as \python{input_table.add('Destination', destination)}.  %

+easy as

+\begin{codefragment}{python}

+input_table.add('Destination', destination)

+\end{codefragment}

 Internally, PyCMDS will do all of the work to make sure that \python{destination} is displayed in

 the GUI.  %

 The \python{destination.updated} signal will fire whenever a user manually interacts with the

@@ -538,16 +540,16 @@ delay stage.  %
 

 PyCMDS uses pyqtgraph \cite{pyqtgraph} for interactive plotting.  %

 pyqtgraph is great because it is optimized for speed and interactivity.  %

-Currently only line plots are supported (through the \python{PyCMDS.project.widgets.Plot1D} class),

+Currently only line plots are supported (through PyCMDS' \python{Plot1D} class),

 but 2D plots are supported by pyqtgraph and could be added in future versions.  %

 

-For those wanting to learn more, all graphical components are defined in

+For those wanting to learn more, all GUI components are defined in

 \bash{PyCMDS/project/widgets.py}.  %

 

 \clearpage

 \section{Hardware} \label{aqn:sec:hardware}  % ====================================================

 

-Hardware are things that 1) have a position, 2) can be set to a destination.  %

+Hardware are things that 1. have a position, and 2. can be set to a destination.  %

 Typically they also have associated units and limits.  %

 They sometimes have an offset, as specified by the autonomic system

 (\autoref{aqn:sec:autonomic}).  %

@@ -712,7 +714,7 @@ following:
 

 Many of these additional features have to do with the tuning curve, a crucial feature of OPAs.  %

 The tuning curve contains motor positions needed to achieve each valid output color.  %

-Read more about my implementation of tuning curves in \ref{cha:opa}.  %

+Read more about my implementation of tuning curves in \autoref{cha:opa}.  %

 

 \autoref{aqn:fig:opa_advanced} is a screenshot of the advanced menu for one of the TOPAS-C [CITE]

 OPAs on the fs table.  %

@@ -807,7 +809,13 @@ Although only one piece of hardware was scanned, the data is considered to be
 \emph{two}-dimensional, with the second dimension being $\bar{\nu}_a$, the differential color axis

 for the array vs the OPA setpoint.  %

 

-[EQUATION]

+The data in \autoref{aqn:fig:array_as_axis} does not occupy a rectangular region in this

+parameterization.  %

+This is because the range of colors covered at each monochromator setpoint is different, with a

+smaller dispersion (more colors across the finite array) at higher energies.  %

+This relationship is somewhat complex, and requires terms like angle of deviation, focal length,

+and focal plane tilt to solve.  %

+It has been derived previously by \textcite{KainSchuyler2017a}.  %

 

 \begin{figure}

   \includegraphics[scale=0.5]{"acquisition/tune_test"}

@@ -994,7 +1002,7 @@ Arbitrary expressions (PyCMDS calls them ``constants'') are also possible, as ca
 

 \subsubsection{TUNE TEST}

 

-The TUNE TEST module does a simple thing: it sets a chosen OPA to each of the points in it's tuning

+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.  %