aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorBlaise Thompson <blaise@untzag.com>2018-04-05 12:09:16 -0500
committerBlaise Thompson <blaise@untzag.com>2018-04-05 12:09:16 -0500
commitd80603d70f1dbd7bc12f9fe2d67ab25f4b60cc56 (patch)
treeddd24c4e7e6850a9a177880c07431bc0c3383cd8
parentf8c9747d3b6425b420839ff06931b63692318f03 (diff)
2018-04-05 12:09
-rw-r--r--abstract.tex14
-rw-r--r--dissertation.tex9
-rw-r--r--introduction/chapter.tex12
-rw-r--r--software/chapter.tex61
-rw-r--r--todo.org4
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: