2018-04-05 12:09

5 files changed, 54 insertions, 46 deletions

diff --git a/abstract.tex b/abstract.tex
index 2c9b4ed..566d95a 100644
--- a/abstract.tex
+++ b/abstract.tex
@@ -6,7 +6,7 @@
 Coherent multidimensional spectroscopy (CMDS) encompasses a family of experimental strategies
 involving the nonlinear interaction between electric fields and a material under investigation.  %
 This approach has several unique capabilities: 1. resolving congested states [CITE KLUG and % JCW Zhao and Wright-JACS], 
-2. extracting spectra that would otherwise be selection-rule disslowed [CITE BOYLE], 3. resolving
+2. extracting spectra that would otherwise be selection-rule disallowed [CITE BOYLE], 3. resolving
 fully coherent dyanmics [CITE % JCW Pakoulev and Wright], 
 4. measuring coupling [CITE], and 5. resolving ultrafast dynamics
 [CITE].  %
@@ -15,10 +15,10 @@ CMDS can be collected in the frequency or the time domain, and each approach has
 disadvantages.  %
 Frequency domain ``Multi-resonant'' CMDS (MR-CMDS) requires pulsed ultrafast light sources with
 tunable output frequencies.  %
-These frequency-tunable pulses are directed into a material under investigation.  %
+These pulses are directed into a material under investigation.  %
 The pulses interact with the material, and due to the specific interference between the multiple
 fields the material is driven to emit a new pulse: the MR-CMDS signal.  %
-This new pulse may be different in frequency from the input pulses, and it may travel in a new
+This signal may be different in frequency from the input pulses, and it may travel in a new
 direction depending on the exact experiment being performed.  %
 The MR-CMDS experiment involves tracking the intensity of this output signal as a function of
 different properties of the excitation pulses.  %
@@ -31,10 +31,10 @@ Because MR-CMDS is a family of related-but-separate experiments, each of them a
 space, there are special challenges that must be addressed when designing a general-purpose MR-CMDS
 instrument.  %
 These issues require development of software, hardware, and theory.  %
-Five different improvements to MR-CMDS are presented in \hyperref[prt:development]{Part II:
-  Development}: 1. processing software (\autoref{cha:pro}), 2. acquisition software
-(\autoref{cha:aqn}) 3, active artifact correction ([REF]), 4. automated OPA calibration
-(\autoref{cha:opa}), and 5. finite pulse accountancy (\autoref{cha:mix}).  %
+Five different improvements to MR-CMDS are presented in this dissertation: 1. processing software
+(\autoref{cha:pro}), 2. acquisition software (\autoref{cha:acq}) 3, active artifact correction
+(\autoref{cha:act}), 4. automated OPA calibration (\autoref{cha:opa}), and 5. finite pulse
+accountancy (\autoref{cha:mix}).  %
 \hyperref[prt:background]{Part I: Background} introduces relevant literature which informs on this
 development work.  %
 Finally, \hyperref[prt:applications]{Part III: Applications} presents three examples where these
diff --git a/dissertation.tex b/dissertation.tex
index cf02bd5..c9c42c3 100644
--- a/dissertation.tex
+++ b/dissertation.tex
@@ -1,12 +1,7 @@
 \documentclass{dissertation}

 

-%\include{glossary}

-

-

 \begin{document}

 

-

-

 % --- preamble ------------------------------------------------------------------------------------

 

 \begin{centering}

@@ -102,9 +97,7 @@ This dissertation is approved by the following members of the Final Oral Committ
 

 \pagenumbering{gobble}

 

-%\singlespacing

-%\renewcommand{\arraystretch}{2}  % there is probably a better way...

-%\printglossaries

+\renewcommand{\arraystretch}{2}  % there is probably a better way...

 \printbibliography

 

 \end{document}
\ No newline at end of file
diff --git a/introduction/chapter.tex b/introduction/chapter.tex
index b8877e6..109f692 100644
--- a/introduction/chapter.tex
+++ b/introduction/chapter.tex
@@ -45,7 +45,7 @@ there is no theoretical limit to the frequency range that can be resolved in thi
 MR-CMDS can be homodyne-detected, so experiments with unique output colors are much more

 accessible.  %

 Finally, because the components are more self-contained, MR-CMDS instruments tend to be more

-flexable in the kinds of experiments that they can perform.  %

+flexible in the kinds of experiments that they can perform.  %

 

 % TODO: boilerplate about the kinds of things that make up an MR-CMDS instrument... OPAs, delays...

 

@@ -69,13 +69,13 @@ has meant that MR-CMDS practitioners have used custom, one-off data processing
 workflows that need to be changed for each particular experiment.  %

 These changes take time to implement, and can become stumbling blocks or opportunities for

 error.  %

-Even worse, the challenge of designing a new processing workflow may dissuade A scientist from

+Even worse, the challenge of designing a new processing workflow may dissuade a scientist from

 creatively modifying their experimental strategy, or comparing their data with data taken from

 another group.  %

 This limit to creativity and flexibility defeats one of the main advantages of the MR-CMDS

 strategy.  %

-\autoref{cha:pro} describes a new software package, WrightTools, that greatly simplifies CMDS data

-processing.  %

+Chapter \ref{cha:pro} describes a new software package, WrightTools, that greatly simplifies CMDS

+data processing.  %

 WrightTools defines a \emph{universal format} that is capable of representing any CMDS dataset,

 regardless of dimensionality or the axes scanned.  %

 A set of simple functions are used to convert raw data into this universal format.  %

@@ -177,6 +177,10 @@ Chapter [...] describes an experiment performed on PEDOT:PSS.
 useful because...

 we learned...

 

+% BJT: consider getting rid of the following paragraph

+% if it remains, it needs to address a more 'broader impacts approach' rather than simply

+% re-summarizing

+

 Despite challenges in software, hardware, and theory MR-CMDS is a crucial tool in the hands of

 scientists.  %

 This dissertation describes several ways to make MR-CMDS more accessible through software and

diff --git a/software/chapter.tex b/software/chapter.tex
index b235ecb..3ab3831 100644
--- a/software/chapter.tex
+++ b/software/chapter.tex
@@ -19,16 +19,16 @@
 \section{Science needs software}  % ===============================================================

 

 Cutting-edge science increasingly relies on custom software.  %

-Software does more than just help scientists analyze data---scientific software enables scientists

-to collect, analyze, and model results in ways that would otherwise be wholly impossible.  %

+Scientific software enables scientists to collect, analyze, and model results in ways that would

+otherwise be wholly impossible.  %

 

 How does scientific software get made?  %

 Who makes it, and what is the quality of that product?  %

 Much has been written about these questions.  %

-To this authors knowledge, there are at least 8 case studies and surveys dedicated to how

-scientists develop and use scientific software. \cite{CardDavidN1986a, SeamanCarolynB1997a,

-  MullerMatthiasM2001a, SegalJudith2004a, SegalJudith2005a, CarverJeffreyC2007a,

-  HannayJoErskine2009a, PrabuPrakash2011a}  %

+To my knowledge, there are at least 8 case studies and surveys dedicated to how scientists develop

+and use scientific software. \cite{CardDavidN1986a, SeamanCarolynB1997a, MullerMatthiasM2001a,

+  SegalJudith2004a, SegalJudith2005a, CarverJeffreyC2007a, HannayJoErskine2009a,

+  PrabuPrakash2011a}  %

 Although they focus on different disciplines, and were published at different times, these articles

 present a remarkably consistent perspective on what challenges tend to arise when developing

 software ``by and for'' scientists.  %

@@ -47,6 +47,7 @@ comes down to software development:  %
     software.

 \end{ditemize}

 PrabhuPrakash2011a---35\% developing, breakdown by type of work...

+% TODO: finish this paragraph

 

 Despite the importance of software to science and scientists, most scientists are not familiar with

 basic software engineering concepts.  %

@@ -88,13 +89,13 @@ On a more positive note, better software development practices may be ``low-hang
 can greatly improve researcher's lives without huge amounts of investment.  %

 Great software makes science easier, faster, and often of higher quality.  %

 And making great software isn't necessarily harder than the development practices that scientists

-are following today---indeed sometimes it is easier to follow best practices.  %

+are following today---indeed sometimes it is easier to follow best practices.  % TODO: cite wilson

 

 In the United States, funding agencies have recognized the crucial role that software plays in

 science.  %

 The National Science Foundation has a long-running ``Software Infrastructure for Sustained

-Innovation'' (SI$^2$) program, which endeavors to take a ``leadership role in providing software as

-enabling infrastructure for science and engineering research'' [CITE https://www.nsf.gov/pubs/2012/nsf12113/nsf12113.pdf].

+Innovation'' (SI$^2$) program, which endeavors to take a \emph{``leadership role in providing software as

+enabling infrastructure for science and engineering research''} [CITE https://www.nsf.gov/pubs/2012/nsf12113/nsf12113.pdf].

 % https://www.nsf.gov/funding/pgm_summ.jsp?pims_id=503489

 

 \section{Challenges in scientific software development}  % ========================================

@@ -109,8 +110,14 @@ Typically the developers of scientific software are not trained software develop
 This is perfectly appropriate, because scientific software development typically requires a large

 amount of domain knowledge that only ``end-users'' possess.  %

 Software development practices may not be valued in a scientific environment.  %

+End-users may lack the skill and knowledge required to develop high quality, maintainable

+software.  %

+They may not be aware of best practices in software development.  %

+They focus on feature additions and neglect documentation and maintenance.  %

+% BJT: what are the consequences of end-users

 

-\textbf{Extensibility.} \cite{SegalJudith2005a, CarverJeffreyC2007a, HannayJoErskine2009a,

+

+\textbf{Shifting goals.} \cite{SegalJudith2005a, CarverJeffreyC2007a, HannayJoErskine2009a,

   PrabhuPrakash2011a}

 Many traditional software development paradigms demand an upfront articulation of goals and

 requirements.  %

@@ -120,7 +127,8 @@ In her seminal 2005 case study \textcite{SegalJudith2005a} describes a collabora
 of researchers and a contracted team of software engineers.  %

 

 \begin{dquote}

-  Unlinke traditional commercial software developers, but very much like developers in open source

+

+  Unlike traditional commercial software developers, but very much like developers in open source

   projects or startups, scientific programmers usually don't get their requirements from customers,

   and their requirements are rarely frozen.

   In fact, scientists often can't know what their programs should do next until the current version

@@ -135,15 +143,12 @@ cannot simply ``contract out'' a large part of its software development needs.
 Sometimes, a scientific problem is worked out though the iterative process of developing software

 to solve it.  %

 

-\textbf{Lifetime.} \cite{CarverJeffreyC2007a, PrabhuPrakash2011a}

-Many scientific software projects have long life cycles, measured in decades or more.  %

-Challenges with portability, and updating to ``modern standards''.  %

-

-\textbf{Maintenance.} \cite{PrabhuPrakash2011a}

-Scientific software, especially software maintained by graduate students, tends to be very hard to

-maintain.  %

-This problem is compounded by the long lifetime of such software, and the poorly defined

-requirements and lack of documentation and testing.  %

+\textbf{Maintenance.} \cite{CarverJeffreyC2007a, PrabhuPrakash2011a}

+Scientific software is famously hard to maintain.  %

+Graduate students graduate, and institutional knowledge about the internal workings of software

+projects is diminished over time.  %

+This problem is compounded by the long lifetime of some software, the poorly defined

+requirements, and lack of documentation and testing.  %

 Often times, scientific software ends up being a mess of layer upon layer of incongruent pieces

 written by generation upon generation of student.  %

 Worse, software is sometimes abandoned or left untouched to become a crucial but arcane component

@@ -163,9 +168,9 @@ Scientists are unaware of parallelization paradigms.  %
 

 \section{Good-enough practices}  % ================================================================

 

-In their [...] perspective, ``Good enough practices in scientific computing'', (from which this

+In their 2017 perspective, ``Good enough practices in scientific computing'', (from which this

 section gets its name) \textcite{WilsonGreg2017a} describe a set of techniques that, in their

-words, ``every researcher can and should consider adopting''.  %

+words, \emph{``every researcher can and should consider adopting''}.  %

 In this section, I attempt to very quickly summarize my personal perspective on what makes good

 software development good---with citations to literature that supports each idea.  %

 These practices are not, generally, \emph{extra work}.  %

@@ -188,6 +193,8 @@ If you do need to write some software, make sure that you do not duplicate code
 work.  %

 Instead of writing the same 10 lines of code again and again with small tweaks, write a function

 that accepts a set of arguments.  %

+If you are doing the same operation in many different contexts, consider defining a library to that

+operation that can be imported and shared between your different projects.  %

 If your software package grows to contain multiple files, make those files modular.  %

 As a general rule, once you have two classes you need multiple files.  %

 

@@ -208,14 +215,14 @@ Don't forget units.  %
 Version control systems allow programmers to save a software package such that they can always

 return to that save point.  %

 All of the files in the package are saved together.  %

-Modern version control systems allow programmers to see exactly what has changed between each save

+These systems also allow programmers to see exactly what has changed between each save

 point, and since the last save point.  %

 This is indispensable when trying to diagnose software problems.  %

 In order to use version control as effectively as possible, try to save the package after every

 change (feature addition, bugfix, etc).  %

 Typically version control is coupled with uploading to a remote server, for example using git with

-GitHub \cite{GitHub} or git.chem.wisc.edu \cite{git.chem.wisc.edu}, but version control need not be

-synonymous with uploading and distribution.  %

+GitHub \cite{GitHub}, GitLab [CITE] or git.chem.wisc.edu \cite{git.chem.wisc.edu}, but version

+control need not be synonymous with uploading and distribution.  %

 Tools like git have a lot of fantastic features beyond simply saving [CITE], but those are beyond the

 scope of these ``good enough'' recommendations.  %

 Also consider defining a version for the software package as a whole.  %

@@ -231,7 +238,7 @@ functionality.  %
 In this way, as you make changes you can run your tests to ensure that those changes do not

 accidentally break important functionality.  %

 Testing sounds difficult, but it's really just about writing simple functions that use your

-software to do something, and then raise an exception if the result is not correct.  %

+software to do something, and then asking if the result is correct.  %

 If you add tests when you add features or fix bugs, you'll quickly find that you have a lot of

 tests that do a good job of defining the expected behavior of your software.  %

 Software engineers tend to be dogmatic about testing, but don't worry too much about test coverage

@@ -266,7 +273,7 @@ Try to follow the recommended style for your language, but don't obsess about it
 \textbf{Avoid premature optimization.} \cite{WilsonGreg2017a}

 Don't get pulled into the trap of trying to make things perfect the first time.  %

 Software design is typically a very iterative process, and for good reason.  %

-Write first, and if it works, consider optimization.  %

+Write for correctness first, and if it works, consider optimization.  %

 If you do need to make your software faster, use profiling tools like cProfile

 \cite{PythonProfilers} and SnakeViz \cite{SnakeViz} to empirically determine what operations are

 taking the longest, rather than trying to guess or use intuition.  %

diff --git a/todo.org b/todo.org
index a1777e5..4839dbf 100644
--- a/todo.org
+++ b/todo.org
@@ -1,9 +1,13 @@
 * DONE draft challenges section                                    :software:
   CLOSED: [2018-04-05 Thu 09:12]
+* TODO citations                                                   :abstract:
 * TODO "quadrants of complexity" idea                           :acquisition:
 ** TODO figure
 ** TODO arguments
 * TODO tables                                                    :processing:
+* TODO summarize PbSe chapter                                  :introduction:
+* TODO summarize MX2 chapter                                   :introduction:
+* TODO summarize PEDOT:PSS chapter                             :introduction:
 * TODO distribution section                                      :processing:
 * TODO development section                                       :processing:
 * TODO incorporate "most software is not peer reviewed"            :software: