From 8d24954c1bc110d8b88d135786e03265bb678c23 Mon Sep 17 00:00:00 2001
From: Blaise Thompson <blaise@untzag.com>
Date: Fri, 30 Mar 2018 16:58:46 -0500
Subject: 2018-03-30 16:58

---
 acquisition/chapter.tex | 121 +++++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 110 insertions(+), 11 deletions(-)

(limited to 'acquisition/chapter.tex')

diff --git a/acquisition/chapter.tex b/acquisition/chapter.tex
index bd08edd..6805150 100644
--- a/acquisition/chapter.tex
+++ b/acquisition/chapter.tex
@@ -351,19 +351,39 @@ 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.  %
 
-% TODO: 4 quadrants of complexity figure
-
+\begin{figure}
+  \caption{
+    CAPTION TODO: 4 QUADRANTS OF COMPLEXITY
+  }
+  \label{aqn:fig:complexity_quandrants}
+\end{figure}
+ 
 \section{Hardware} \label{aqn:sec:hardware}  % ====================================================
 
 Hardware are things that 1) have a position, 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}).  %
 Each hardware can be thought of as a dimension of the MR-CMDS experiment, and scans include a
 specific traversal through this multidimensional space.  %
 
 \subsection{Hardware inheritance}  % --------------------------------------------------------------
 
-All hardware classes are children of the parent \python{Hardware} class, which is itself subclassed
-from the global \python{Hardware} class shown in \autoref{aqn:lst:parent_hardware}.  %
+All hardware classes are children of the parent \python{Hardware} class
+(\autoref{aqn:fig:hardware_class}), which is itself a child of the the global \python{Hardware}
+class shown in \autoref{aqn:fig:parent_hardware_class}.  %
+By inspecting \autoref{aqn:fig:hardware_class}, we can see that all hardware require the following
+methods:
+\begin{ditemize}
+  \item \python{close}
+  \item \python{get_destination}
+  \item \python{get_position}
+  \item \python{on_address_initialized}
+  \item \python{poll}
+  \item \python{set_offset}
+  \item \python{set_position}
+  \item \python{@property units}
+\end{ditemize}
 
 \begin{figure}
 	\includepython{"acquisition/hardware.py"}
@@ -379,12 +399,11 @@ from the global \python{Hardware} class shown in \autoref{aqn:lst:parent_hardwar
 \begin{figure}
 	\includebash{"acquisition/hardware_inheritance"}
   \caption[Hardware inheritance.]{
+    CAPTION TODO
   }
   \label{aqn:fig:hardware_inheritance}
 \end{figure}
 
-So every hardware object must have the following...
-
 \subsection{Delays}  % ----------------------------------------------------------------------------
 
 Delays are the kind of thing that have a position in absolute units, a zero position, and a
@@ -408,7 +427,14 @@ The delay GUI, by default, offers
   \item \python{on_set_motor}
   \item \python{on_set_zero}
 \end{ditemize}
-  
+
+\begin{figure}
+  \caption[Representative delay stage advanced menu.]{
+    CAPTION TODO
+  }
+  \label{aqn:fig:delay_advanced}
+\end{figure}
+
 \subsection{Spectrometers}  % ---------------------------------------------------------------------
 
 Spectrometers are the kind of thing that can be set to a single color (typically native units are
@@ -423,6 +449,13 @@ Driver:
 
 GUI:
 
+\begin{figure}
+  \caption[Representative delay stage advanced menu.]{
+    CAPTION TODO
+  }
+  \label{aqn:fig:spectrometer_advanced}
+\end{figure}
+
 \subsection{OPAs}  % ------------------------------------------------------------------------------
 
 Hardware:
@@ -439,6 +472,13 @@ United
 
 Interpolation
 
+\begin{figure}
+  \caption[Representative delay stage advanced menu.]{
+    CAPTION TODO
+  }
+  \label{aqn:fig:opa_advanced}
+\end{figure}
+
 \subsection{Filters}  % ---------------------------------------------------------------------------
 
 Hardware:
@@ -447,6 +487,7 @@ Driver:
 
 GUI:
 
+\clearpage
 \section{Sensors (devices)} \label{aqn:sec:sensors}  % ============================================
 
 Sensors are...
@@ -465,6 +506,13 @@ Old boxcar: 300 ns window, ~10 micosecond delay. Onset of saturation ~2 V.
 
 % TODO: poweramp tune test  (see darien slack)
 
+\begin{figure}
+  \caption[Array detector serving as an axis.]{
+    CAPTION TODO
+  }
+  \label{aqn:fig:array_as_axis}
+\end{figure}
+
 \section{Autonomic} \label{aqn:sec:autonomic}  % ==================================================
 
 \begin{dquote}
@@ -487,6 +535,13 @@ Old boxcar: 300 ns window, ~10 micosecond delay. Onset of saturation ~2 V.
 
 % TODO: concept of additive offsets
 
+\begin{figure}
+  \caption[Representative spectral delay correction]{
+    CAPTION TODO
+  }
+  \label{aqn:fig:sdc}
+\end{figure}
+  
 \section{Somatic} \label{aqn:sec:somatic} % =======================================================
 
 In contrast with the autonomic system (\autoref{aqn:sec:autonomic}), the somatic system is all
@@ -535,8 +590,26 @@ For scan module, just
 
 \subsection{Spectral delay correction module}  % --------------------------------------------------
 
+Currently spectral delay correction is done ``manually''.  %
+Relevant Wigner scans are taken using the SCAN module, processed using WrightTools, and generated
+coset files are manually applied in the autonomic menu.  % 
+Ideally, ``check'' Wigners are then taken to verify the veracity of the corrections.  %
+In the future, it would be preferable to have a dedicated SDC module that did all of these things
+automatically.  %
+
+It would start from existing corrections (for that table geometry) and iterate until the applied
+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
+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
+central conceit of PyCMDS.  %
+
 \subsection{Ideal Axis Positions} \label{acq:sec:ideal_axis_positions}  % -------------------------
 
 Frequency domain multidimensional spectroscopy is a time-intensive process.  %
@@ -651,10 +724,36 @@ S_n &=& (1-c)\left(\frac{n}{N}\right)^{\frac{\tau_{\mathrm{step}}}{\tau_{\mathrm
 
 \subsection{Simultanious acquisitions}  % ---------------------------------------------------------
 
-\subsection{Enhanced modularity}  % ---------------------------------------------------------------
-
-\subsection{wt5 savefile}  % ----------------------------------------------------------------------
+Sometimes PyCMDS needs to do multiple scans that are completely orthogonal.  %
+For example, certain OPA tuning operations only require signals from pyroelectric detectors that
+are each permanently installed to monitor a single OPA.  %
+In such cases, theoretically multiple OPAs could be tuned simultaneously.  %
+The coordination of such operations would be more difficult than what currently exists, but could
+be possible within PyCMDS' multithreaded design.  %
 
 \subsection{Hotswappable hardware}  % -------------------------------------------------------------
 
-\subsection{Better logging and error handling}  % -------------------------------------------------
\ No newline at end of file
+One of the most important basic capabilities of PyCMDS is the ability to reconfigure itself
+depending on what hardware is loaded.  %
+However controlling the hardware configuration is currently more difficult than it should be.  %
+Currently users need to shut down PyCMDS, manually edit INI files to configure which hardware are
+included, and restart PyCMDS.  %
+A better solution would allow users to ``hotswap''---load, or drop hardware and sensors
+without shutting down PyCMDS.  %
+The work of allowing this would also allow users to reload hardware, a great fallback option when
+there are communication issues.  %
+
+\subsection{wt5 savefile}  % ----------------------------------------------------------------------
+
+The wt5 save format, introduced in WrightTools 3, is a huge improvement over the simple, plaintext
+data format currently used by PyCMDS.  % TODO: link to discussion of wt5 format
+wt5 files are smaller on disk, have richer metadata and self-descriptive properties, and multiple
+scans can be stored in the same file using \python{Collections}.  % TODO: again, link
+Because wt5 files are stored on disk but fully accessible through slicing, PyCMDS could have full
+access to the scan arrays without risk of memory overflow, which promises to allow for new
+potential visualizations during acquisition.  % TODO: presumably we talk about buffered file
+                                % writing above?
+
+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.  %
-- 
cgit v1.2.3

