| Line 8 was replaced by line 8 |
| - * User has the ability to begin a Kepler workflow with laptop, detach/disconnect, and reconnect at a later time to check on execution status. Notifications may optionally be sent when Kepler completes. |
| + * User would like the ability to begin a Kepler workflow with laptop, detach/disconnect, and reconnect at a later time to check on execution status. Notifications may optionally be sent when workflow execution completes (how notifications will be sent will likely be configured in the workflow). |
| Lines 10-11 were replaced by lines 10-11 |
| - * Ability to re-attach to running job, see current progress. |
| - * User can also check check status of remote jobs via a web interface. |
| + * Ability to re-attach to running job to check its progress. |
| + * User would also like to check status, and stop workflow jobs via a web interface. |
| Lines 15-17 were replaced by lines 15-17 |
| - * Have a complete workflow assembled. |
| - * Distributed execution system has been built, a server is running this. |
| - * Server has all software that workflow requires (R, Matlab, gcc, ) |
| + * Have a complete workflow assembled. |
| + * Distributed execution system has been built and running on an accessible server. |
| + * Server has all software that the workflow requires (eg R, Matlab, etc) |
| Lines 26-27 were replaced by line 26 |
| - * User designs workflow. |
| - * User selects style of notification. |
| + * User designs workflow that includes notification system (eg uses Email Sender actor). |
| Line 29 was replaced by line 28 |
| - * User executes workflow in either batch or gui mode (when workflow has graphical output, batch mode can handle this, eg ignore it, write it out to eg pdfs) |
| + * User executes workflow in either batch or gui mode (when workflow has graphical output, batch mode can handle this, eg ignore it, or write it out to eg pdfs) |
| Line 31 was replaced by line 30 |
| - * User can reconnect to server and see status, alter settings, stop job or retrieve results. |
| + * While job is running, user can reconnect to server and check status, alter settings, stop job or retrieve results. |
| Line 44 was replaced by lines 43-44 |
| - ----\\__Use Case Name__: Smart reruns |
| + ---- |
| + \\__Use Case Name__: Smart Reruns |
| Line 49 was replaced by line 49 |
| - # conditions under which a normal complete rerun of workflow should occur when user executes workflow (eg "if data sources I have marked have changed, a smart rerun cannot occur") |
| + # conditions under which a complete rerun of workflow should occur when user executes workflow (eg "if data sources I have marked have changed, a smart rerun cannot occur") |
| Line 58 was replaced by line 58 |
| - User executes a workflow that uses Smart rerun features and all User-specified Smart rerun criteria have been met. |
| + User executes a workflow that uses Smart Rerun features and all Smart Rerun criteria have been met. |
| Line 62 was replaced by line 62 |
| - Workflow developer designs a workflow that makes use of smart rerun components. |
| + Workflow developer designs a workflow that makes use of Smart Rerun components. |
| Line 64 was replaced by line 64 |
| - Upon execution of this workflow, smart rerun components check to see if their input data sources have changed. If these have been changed (or are being used for the first time), components (re)produce derived data products and save those that are marked as smart rerun derived data products. If data sources have not changed, and previously saved derived data products exist, a smart rerun can occur whereby these products are reused. Special considerations for stochastic systems must be taken into account in the design of this usecase (do we allow smart reruns for certain stochastic models?). |
| + Upon execution of this workflow, Smart Rerun components check to see if their input data sources have changed (possibly the user can also specify conditions which must also be met). If these data sources have changed (or are being used for the first time), components (re)produce derived data products and save those that are marked as Smart Rerun derived data products. If data sources have not changed, and previously saved derived data products exist, a Smart Rerun can occur reusing these existing products. Special considerations for stochastic systems must be taken into account in the design of this usecase (do we allow Smart Reruns for certain stochastic models?). |
| At line 68 added 2 lines. |
| + * It is possible a user would also like the ability to do a Smart Rerun even if Smart Rerun criteria are not met, ie they might want to ignore the fact that data sources have changed and reuse existing derived data products to test something else. |
| + |
| Line 71 was replaced by line 73 |
| - Intermediary derived data products produced by smart rerun actors are saved. |
| + Intermediary derived data products produced by Smart Rerun actors are saved. |
| Line 79 was replaced by lines 81-82 |
| - ----\\__Use Case Name__: Optional archiving of intermediate derived datasets. |
| + ---- |
| + \\__Use Case Name__: Optional archiving of intermediate derived datasets. |
| Line 92 was replaced by line 95 |
| - \\__Notes:__ This usecase can be seen as required by the "Smart Rerun" usecase and the "Manage a group of model runs" usecase |
| + \\__Notes:__ This usecase can be seen as required by the "Smart Rerun", "Manage a group of model runs", and "Archive a complete end to end run" usecases |
| Line 99 was replaced by lines 102-103 |
| - ----\\__Use Case Name__: Archive a complete end to end run ("publication ready archive") |
| + ---- |
| + \\__Use Case Name__: Archive a complete end to end run ("publication ready archive") |
| Line 103 was replaced by line 107 |
| - Users would like the ability to create "publication ready archive", which is an archive that contains the Kepler workflow, all required inputs (data sources like database tables are included), and all produced output. At the completion of a study, the user can produce this archive and submit it (or a link to it) alongside their paper to peers and journals. |
| + Users would like the ability to create a "publication ready archive"--an archive that contains the Kepler workflow, all required inputs (data sources like database tables are included), and all produced output. For example, at the completion of a study, a user can produce this archive and submit it (or a link to it) alongside their paper to peers and journals. |
| Lines 107-108 were replaced by lines 111-112 |
| - User has created workflow that contains everything needed (eg data sources). |
| - Ability to save intermediate and |
| + * User has created workflow that contains everything needed (eg data sources). |
| + * User documents any external software the workflow requires |
| Line 120 was replaced by line 124 |
| - User uses features from "Smart Rerun" usecase the "Manage a group of model runs" usecase. |
| + User uses features from "Smart Rerun", "Manage a group of model runs", and "save intermediate derived data products" usecase (ie a special "publication ready archive" mode might not be required). |
| Line 128 was replaced by line 132 |
| - A specific "publication ready archive" option would not be required if requiredments for "Smart Rerun" usecase and "Manage a group of model runs" usecase are implemented. |
| + A specific "publication ready archive" option would not be required if requirements for usecases mentioned in Alt Paths are implemented. |
