doc/standards.txt

   1 ********************
   2 Standard experiments
   3 ********************
   4
   5 .. toctree::
   6    :maxdepth: 2
   7
   8 Overview
   9 ========
  10
  11 Force spectroscopy experiments are generally classified as "force
  12 clamp", "velocity clamp", etc..  While previous versions of Hooke
  13 attempted to reproduce such classification, I now believe this
  14 classification is counter-productive.  The type of experiment carried
  15 out by a given :class:`~hooke.curve.Curve` is determined by the
  16 sequence of :class:`~hooke.curve.Data` blocks in the curve.  For
  17 example, a classic velocity clamp experiment would look like::
  18
  19     hooke> curve_info --enable-block_names
  20     block names: ['approach', 'pause', 'retract']
  21
  22 And classic force clamp experiment would look like::
  23
  24     hooke> curve_info --enable-block_names
  25     block names: ['approach', 'pause', 'retract', 'force clamp']
  26
  27 However, the situation is complicated by refolding experiments such as::
  28
  29     hooke> curve_info --enable-block_names
  30     block names: ['approach-0', 'pause-0', 'retract-0',
  31                   'approach-1', 'pause-1', 'retract-1',
  32                   'approach-2', 'pause-2', 'retract-2',
  33                   ...]
  34
  35 The benefit to classifying curves in Hooke is that each class of
  36 experiment has a standard analysis procedure (e.g. unfolding force
  37 extraction for velocity clamp experiments or survival time extraction
  38 for force clamp experiments).  However, the potential convenience of
  39 Hooke being able to guess a user's desired analysis is outweighed by
  40 the increased complexity and rigidity that such guessing requires.
  41 Instead we provide :class:`~hooke.command.Command`\s that can be
  42 applied to any data block, and leave it up to the user to construct a
  43 sequence of analysis commands that makes sense.  The risk to this
  44 flexible approach is confusion for both the user and the Hooke
  45 developer.  The remainder of this section lays out a scheme for
  46 maintaining developer sanity.  Users should read over the
  47 :doc:`analysis` section for an overview of analysis procedures
  48 that are standardized enough to have written documentation.
  49
  50 Drivers
  51 =======
  52
  53 .. todo:: Explain driver responsibilities.
  54
  55 Commands
  56 ========
  57
  58 .. todo:: Explain command analysis and storage behaviour.
  59
  60 Results
  61 =======
  62
  63 .. todo:: Explain procedure for exporting analysis results.