diff options
| -rw-r--r-- | acquisition/chapter.tex | 156 | ||||
| -rw-r--r-- | active_correction/chapter.tex | 20 | ||||
| -rw-r--r-- | dissertation.tex | 14 |
3 files changed, 180 insertions, 10 deletions
diff --git a/acquisition/chapter.tex b/acquisition/chapter.tex index 8e75cc1..1525b9e 100644 --- a/acquisition/chapter.tex +++ b/acquisition/chapter.tex @@ -26,8 +26,156 @@ PyCMDS has, through software improvements alone, dramatically lessened scan time \item ideal axis positions \ref{acq:sec:ideal_axis_positions}
\end{ditemize}
+% TODO: screenshot
+
+% TODO: modularity
+
+% TODO: n-dimensional scans...
+
+% TODO: calibration
+
+\section{Structure} % ============================================================================
+
+I think of PyCMDS as a central program with three kinds of modular ``plugins'' that can be extended
+indefinitely:
+\begin{ditemize}
+ \item Hardware: things that can be set to a position (\autoref{aqn:sec:hardware}).
+ \item Sensors: things that can be used to measure a signal (\autoref{aqn:sec:sensors}).
+ \item Acquisition modules: things that can be used to define and carry out an acquisition, and
+ associated post-processing (\autoref{aqn:sec:somatic}).
+\end{ditemize}
+The first design rule for PyCMDS is that these three things should be easy for the average
+(motivated) user to add by herself. %
+Modularity and extensibility is important for all software projects, but it is of paramount
+importance for acquisition software simply because the diversity of hardware and experimental
+configurations is so great. %
+It is conceivable to imagine 90\% overlap between the data processing and simulation needs of one
+spectroscopist to the next, but there is almost no overlap between hardware configurations even in
+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. %
+
+For the kinds of acquisitions that the Wright Group has done the acquisition software spends the
+vast majority of its run-time waiting---waiting for user input through mouse clicks or keyboard
+presses, waiting for hardware to finish moving or for sensors to finish reading and return
+signals. %
+Despite all of this downtime, it is crucial that the software respond very quickly when
+instructions or signals are recieved. %
+A multi-threaded implementation is necessary to achieve this. %
+The main thread handles the graphical user interface (GUI) and other top level things. %
+Everything else happens in child threads. %
+Each hardware instance (e.g. a delay stage) lives in its own thread, as does each sensor. %
+Since only one scan happens at a time, all acquisition modules share a single thread that handles
+the orchestration of hardware motion, sensor operation, and data processing that the chosen
+acquisition requires. %
+
+Threads are powerful because they allow for ``semi-synchronous'' operation. %
+Imagine PyCMDS is in the middle of a 2D delay-delay scan, and the scan thread has just told each of
+the two delay stages to head to their positions. %
+PyCMDS must sit in a tight loop to keep track of the position as closely as possible during motor
+motion. %
+In a single-threaded configuration, this tight loop would only run for one delay at a time, such
+that PyCMDS would have to finish shepherding one delay stage before turning its attention to the
+second. %
+In a multi-threaded configuration, each thread will run simultaniously, switching off CPU cycles at
+a low level far faster than human comprehension. %
+This switching is handled in an OS and hardware specific way---luckily it is all abstracted through
+platform-agnostic Qt threads. %
+
+Threads are dangerous because it is hard to pass information between them. %
+Thus, mutexes... signals and slots...
+
+Without getting into details, let's investigate the key ``signals and slots'' that hardware and
+sensors have. %
+% TODO: elaborate
+
+The central loop of scans in PyCMDS. %
+\begin{codefragment}{python, label=aqn:lst:loop_simple}
+for coordinates in list_of_coordinates:
+ for hardware, coordinate in zip(hardwares, coordinates):
+ hardware.set(coordinate)
+ for hardware in hardwares:
+ hardware.wait_until_still()
+ for sensor in sensors:
+ sensor.read()
+ for sensor in sensors:
+ sensor.wait_until_done()
+\end{codefragment}
+
+\subsection{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
+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
+\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. %
+
+The important axis is hardware complexity vs measurement complexity.
+
+For hardware-complex problems, the challenge is coordination. %
+MR-CMDS is the perfect example of a hardware-complex problem. %
+MR-CMDS is composed of a collection (typically 5 to 10 members) of relatively simple hardware
+components. %
+The challenge is that experiments involve complex ``dances'', including expressions, of the
+component hardwares. %
+
+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. %
+
+From an acquisition software perspective, measurement-complex problems are not amenable to general
+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. %
+
+% TODO: 4 quadrants of complexity figure
+
+\section{Hardware} \label{aqn:sec:hardware} % ====================================================
+
+\section{Sensors (devices)} \label{aqn:sec:sensors} % ============================================
+
+\subsection{Sensors as axes} % -------------------------------------------------------------------
+
+\section{Autonomic} % ============================================================================
+
+% TODO: concept of additive offsets
+
+\section{Somatic} \label{aqn:sec:somatic} % =======================================================
+
+\subsection{Acquisition modules} % ---------------------------------------------------------------
+
+% TODO: the aqn file
+
+% TODO: list of modules, descriptions thereof
+
+\subsection{Queue manager} % ---------------------------------------------------------------------
+
+\subsection{The central loop of PyCMDS} % --------------------------------------------------------
+
+\subsection{The data file} % ---------------------------------------------------------------------
+
+\subsection{Automatic processing} % --------------------------------------------------------------
+
\section{Future directions} % ====================================================================
+\subsection{Spectral delay correction module} % --------------------------------------------------
+
+\subsection{``Headless'' hardware, sensors} % ----------------------------------------------------
+
\subsection{Ideal Axis Positions} \label{acq:sec:ideal_axis_positions} % -------------------------
Frequency domain multidimensional spectroscopy is a time-intensive process. %
@@ -138,4 +286,10 @@ S_n &=& (1-c)\left(\frac{n}{N}\right)^{\frac{\tau_{\mathrm{step}}}{\tau_{\mathrm \subsubsection{Lorentzian}
-\subsubsection{Bimolecular}
\ No newline at end of file +\subsubsection{Bimolecular}
+
+\subsection{Simultanious acquisitions} % ---------------------------------------------------------
+
+\subsection{Enhanced modularity} % ---------------------------------------------------------------
+
+\subsection{wt5 savefile} % ----------------------------------------------------------------------
\ No newline at end of file diff --git a/active_correction/chapter.tex b/active_correction/chapter.tex index fbbc26c..57093f4 100644 --- a/active_correction/chapter.tex +++ b/active_correction/chapter.tex @@ -1,7 +1,23 @@ -% TODO: BerkTobyS1975.000 people trust computers too much
-
\chapter{Active Correction in MR-CMDS}
+\begin{dquote}
+ Calibrate.
+
+ Calibrate.
+
+ Calibrate.
+
+ Calibrate.
+
+ Calibrate.
+
+ Run!
+
+ \dsignature{Long-hanging poster in Wright Group laser lab.}
+\end{dquote}
+
+\clearpage
+
\section{Hardware} % -----------------------------------------------------------------------------
\subsection{Delay Stages}
diff --git a/dissertation.tex b/dissertation.tex index f80af7e..0fae477 100644 --- a/dissertation.tex +++ b/dissertation.tex @@ -77,8 +77,8 @@ This dissertation is approved by the following members of the Final Oral Committ \part{Development}
\include{processing/chapter}
\include{acquisition/chapter}
-%\include{active_correction/chapter}
-%\include{opa/chapter}
+\include{active_correction/chapter}
+\include{opa/chapter}
%\include{mixed_domain/chapter}
\part{Applications}
@@ -95,12 +95,12 @@ This dissertation is approved by the following members of the Final Oral Committ \part{Appendix}
\begin{appendix}
-%\include{public/chapter}
-%\include{procedures/chapter}
-%\include{hardware/chapter}
+\include{public/chapter}
+\include{procedures/chapter}
+\include{hardware/chapter}
% TODO: consider inserting WrightTools documentation as PDF
-%\include{errata/chapter}
-%\include{colophon/chapter}
+\include{errata/chapter}
+\include{colophon/chapter}
\end{appendix}
% post --------------------------------------------------------------------------------------------
|