{"action":"created","comment":{"url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/pulls/comments/209286144","pull_request_review_id":145264926,"id":209286144,"node_id":"MDI0OlB1bGxSZXF1ZXN0UmV2aWV3Q29tbWVudDIwOTI4NjE0NA==","diff_hunk":"@@ -0,0 +1,849 @@\n+\\documentclass[a4paper,english,numbers=noenddot,bibliography=totoc,chapterprefix=on,DIV=12]{scrartcl}\n+\n+\\usepackage[utf8x]{inputenc}\n+\\usepackage{graphicx}\n+\\usepackage{xcolor}\n+\\usepackage{amssymb,amsmath}\n+\\usepackage{enumitem}\n+\\PassOptionsToPackage{hyphens}{url}\\usepackage{bookmark,hyperref}\n+\\usepackage{multirow}\n+\\usepackage[labelfont=bf,font=small]{caption}\n+\\usepackage[font=footnotesize]{subcaption}\n+\\usepackage{rotating}\n+\n+\\usepackage{subcaption}\n+\\usepackage{tabularx}\n+\\usepackage{listings}\n+\n+\\setcapindent{0mm}\n+\n+% boldmath in headings and toc, but not headers\n+\\def\\bfseries{\\fontseries \\bfdefault \\selectfont \\boldmath}\n+\n+%allows footnotes in tabular\n+\\usepackage{footnote}\n+\\makesavenoteenv{tabular}\n+\\makesavenoteenv{table}\n+\n+% avoid space issues after macro\n+\\usepackage{xspace}\n+\\newcommand{\\tof}{TOF\\xspace}\n+\\newcommand{\\angstrom}{\\textup{\\AA}}\n+\n+\\newcommand{\\Treduction}{t_{\\text{reduction}}}\n+\\newcommand{\\Trun}{t_{\\text{run}}}\n+\\newcommand{\\Tbin}{t_{\\text{bin}}}\n+\\newcommand{\\Tevent}{t_{\\text{event}}}\n+\\newcommand{\\Nbin}{N_{\\text{bin}}}\n+\\newcommand{\\Ncore}{N_{\\text{core}}}\n+\\newcommand{\\Ncoremean}{\\langle N_{\\text{core}}\\rangle}\n+\\newcommand{\\Nevent}{N_{\\text{event}}}\n+\\newcommand{\\Nreduction}{N_{\\text{reduction}}}\n+\\newcommand{\\Nworkspace}{N_{\\text{workspace}}}\n+\\newcommand{\\Nspec}{N_{\\text{spec}}}\n+\\newcommand{\\Bmax}{B_{\\text{max}}}\n+\\newcommand{\\Fevent}{f_{\\text{event}}}\n+\\newcommand{\\Mcore}{M_{\\text{core}}}\n+\n+\\newcommand{\\beer}{BEER\\xspace}\n+\\newcommand{\\bifrost}{BIFROST\\xspace}\n+\\newcommand{\\cspec}{CSPEC\\xspace}\n+\\newcommand{\\dream}{DREAM\\xspace}\n+\\newcommand{\\estia}{ESTIA\\xspace}\n+\\newcommand{\\loki}{LoKI\\xspace}\n+\\newcommand{\\magic}{MAGIC\\xspace}\n+\\newcommand{\\odin}{ODIN\\xspace}\n+\n+\\newcommand{\\mantid}{Mantid\\xspace}\n+\\newcommand{\\nexus}{NeXus\\xspace}\n+\n+\\makeatletter\n+\\def\\input@path{{generated/}}\n+\\makeatother\n+\n+\\begin{document}\n+\n+\\title{Estimation of hardware requirements for data reduction with \\mantid at ESS}\n+\\author{Simon Heybrock\\\\\n+    {\\small\\href{mailto:simon.heybrock@esss.se}{\\nolinkurl{simon.heybrock@esss.se}}}}\n+\n+\\maketitle\n+\n+\\tableofcontents\n+\n+\\section{Introduction}\n+\\subsection{Overview}\n+\n+The aim of this document is to capture our understanding of what hardware resources will be required for reducing data with \\mantid for ESS.\n+While we attempt to give some estimates for, e.g., required core counts, it will become clear below there are too many uncertainties. In practice the main contribution of this document may thus be the description of how various parameters affect what hardware is required, allowing us the continuously update and improve our estimates.\n+\n+Data reduction covers three main cases, live reduction, interactive reduction, and script-based reduction.\n+\n+\\paragraph{Live reduction}\n+Preliminary/simplified on-the-fly reduction of data and visualization is a key promise of ESS and will be required for all instruments, any time the beam is on, and at times also with beam off for other calibration work.\n+It is critical that this is available at all times so a dedicated pool of hardware may be required.\n+\n+\\paragraph{Interactive reduction} \n+The general view is that data at ESS will be so large that users cannot do data reduction on their laptop or desktop PC. Therefore DMSC needs to provide resources for all interactive workflows using the \\mantid GUI (MantidPlot or its successor) for data reduction and visualization.\n+This is required during a user visit as well as a certain time period after the experiment.\n+Furthermore, we need to provide access to such resources \\emph{before} an experiment such that users can familiarize themselves with the tools and provided software infrastructure, avoiding wasting beam time due to software problems.\n+For interactive reduction, due to the interactive nature, high CPU use will alternate with shorter or longer idle breaks.\n+However, generally there will be a rather large permanent memory requirement, i.e., clustering interactive user sessions on a single compute node is only possible to a limited extent, and will require nodes with a large amount of memory.\n+\n+\\paragraph{Script-based reduction}\n+Reduction of data based on a (Python) script.\n+This covers automatic reduction and batch reduction.\n+This is suitable for being run on a cluster using a standard queuing system with adequate means to ensure that queue lengths stay within limits.\n+For example, one could imagine that jobs for data reduction of a running experiment need to be prioritized over modelling jobs of a experiment that happened a long time ago.\n+\n+\n+\\subsection{Threading and MPI support}\n+\\label{sec:threading-and-mpi-support}\n+\n+The \\mantid framework is multithreaded and algorithms run by a script or interactively by the GUI will typically run with multiple threads.\n+To allow for scaling data reduction beyond a single node, MPI support has been added to \\mantid.\n+MPI support is only available for script-based reduction.\n+In principle it could also be used for live reduction, provided that it is only a passive way to observe raw and reduced data.\n+There is no MPI support connected to the GUI and there are no plans for this either.\\footnote{That is, there will be no equivalent to the client-server MPI mode supported by, e.g., ParaView.}.\n+\n+In various benchmarks we observed that generally an equivalent threaded run of a \\mantid reduction script takes longer than the same reduction done with MPI:\\footnote{This is true even without the optimized MPI-based NeXus loader.}\n+The scaling with the number of used cores is worse.\n+The reason for this is not fully understood but it is probably related to the fork-join threading approach.\n+Thus we cannot directly transfer results and scaling behaviors obtained for MPI to a threaded version of \\mantid.\n+For machines with a moderate number of cores of up to roughly 10 cores we can probably use the rule of thumb that the threaded reduction will be $2\\times$ slower than the MPI reduction.\n+\n+\n+\\subsection{Ramp-up in hot commissioning and early operations}\n+\n+The initial rates and pixel counts will be lower than the design values due to the ramp-up of accelerator power and incomplete detector coverage.\n+In Fig.~\\ref{fig:accelerator-power} we show the estimate for the accelerator power ramp-up used in the following for scaling the expected event rates.\n+ESS instrument scientists expect a linear scaling of the useable wavelength with the accelerator power.\n+In Tab.~\\ref{tab:pixel-counts} we list the pixel counts for the first instruments, i.e., effectively $\\Nspec$.\n+We do not list the imaging beamline \\odin.\n+It is not suitable for joint estimation with the other beamlines and it reduction hardware requirements should probably be considered jointly with its requirements for reconstruction and analysis.\n+To obtain $\\Nbin$ we need to combine $\\Nspec$ with the number of bins per spectrum.\n+This depends on the resolution of the instrument, which can be configurable.\n+Details for this and other parameters are listed in Sec.~\\ref{sec:script-based-results}.\n+\n+\\begin{figure}\n+  \\centering\n+\\includegraphics[height=0.33\\textheight]{accelerator-power.pdf}\n+\\caption{\\label{fig:accelerator-power}Estimate of accelerator power ramp up.}\n+\\end{figure}\n+\n+\\begin{table}\n+  \\centering\n+  \\begin{tabular}{lrrl}\n+    Instrument & Pixel count day 1 & Pixel count final & Comment\\\\\n+    \\hline\n+    \\beer & 200k & 400k & not including SANS upgrade\\\\\n+    \\bifrost & ? & 5k & low pixel count but scanning\\\\\n+    \\cspec & 400k & 750k \\\\\n+    % 1.25*32*6.2/(0.003*0.006) = 14000k\n+    \\dream & 4000 & 12000k & estimated\\footnote{We did not yet receive pixel counts from DREAM, but MAGIC uses same technology with a pixel size of $3~\\mathrm{mm} \\times 6~\\mathrm{mm}$ with 32 voxel layers. Full coverage is $5.11~\\mathrm{sr}$ with a sample-detector distance of $1.25~\\mathrm{m}$. Day-1 coverage is $1.81~\\mathrm{sr}$.}\\\\\n+    \\estia & 250k & 500k \\\\\n+    \\loki & 750k & 1500k \\\\\n+    \\magic & 1440k & 2880k \\\\\n+  \\end{tabular}\n+  \\caption{\\label{tab:pixel-counts}Pixel counts for the first instruments. Generally instruments to not have full detector coverage at day 1 and will add more pixels in an upgrade, typically a couple of years later.}\n+\\end{table}\n+\n+\n+\n+\n+\\section{Live reduction}\n+\n+The discussion in this section is based on live reduction benchmarks conducted by Lamar Moore.\n+See the reference given in App.~\\ref{app:refs} for details.\n+In Tab.~\\ref{tab:consumption-rate} we show benchmark results for the event consumption rate of the Kafka event listener in \\mantid without processing or visualization.\n+This test is done using a default (non-MPI) build of \\mantid.\n+MPI support for the Kafka listener is not implemented currently.\n+\n+With the exception of the SANS2D data point at $10^5$ the scaling with the event rate is linear.\\footnote{It is likely that for the high rate of more than 1000 frames per second other effects become relevant. Since we are not interested in such high frame rates we ignore this data point and assume linear scaling.}\n+The benchmarks also show a (very approximately) linear scaling of the consumption rate with the number of pixels.\n+This is not entirely expected.\n+There are two aspects that can be used to explain the scaling:\n+With more pixels the write behavior to the \\verb|EventWorkspace| becomes more random leading to a less and less efficient use of cache and the rest of the memory subsystem.\n+This effect should be expected to reach a steady state above a certain number of pixels.\n+In addition to that, a separate vector needs to be allocated for every pixel to store the events.\n+This allocation cost could grow linearly with the pixel count.\n+\n+\\begin{table}\n+  \\centering\n+  \\begin{tabular}{c|rrr}\n+    Instrument & SANS2D & MERLIN & WISH\\\\\n+    Pixel count & 122888 & 286729 & 778245\\\\\n+    \\hline\n+    $10^5$ events in 14 frames & 1379 & 915 & 400 \\\\\n+    $10^6$ events in 14 frames & 284 & 93 & 38 \\\\\n+    $10^7$ events in 14 frames & 23 & 8 & 3 \\\\\n+  \\end{tabular}\n+  \\caption{\\label{tab:consumption-rate}Number of consumed frames per second. For ESS there are 14 frames (pulses) per second, i.e., we require a consumption rate of at least 14. The update timeout is set to $1~\\mathrm{s}$.}\n+\\end{table}\n+\n+By increasing the update timeout, which was set to one second in Tab.~\\ref{tab:consumption-rate}, the consumption rate can be improved moderately.\n+A couple of other optimization also appear to be possible.\n+On the other hand, live display of the raw data using the \\verb|InstrumentView|, (simplified) data reduction, and live display of the reduced data add extra overhead.\n+Combining these opposite effects, which --- according to preliminary benchmarks --- all appear to be in the order of a $2\\times$ change, leads us to conclude that the numbers given in Tab.~\\ref{tab:consumption-rate} are a reasonable estimate.\n+That is, without having access to much more detailed workflows and instrument models we have the crude estimate\n+\n+\\begin{align}\n+  R_{\\text{live}} &= \\frac{N_{\\text{frame}}^{\\text{max}}}{14} = \\frac{3\\cdot10^{13}~\\mathrm{s}}{14\\Fevent\\Nspec} = \\frac{2\\cdot10^{12}~\\mathrm{s}}{\\Fevent\\Nspec},\n+\\end{align}\n+where $N_{\\text{frame}}^{\\text{max}}$ is the maximum number of consumed frames as in Tab.~\\ref{tab:consumption-rate}, 14 is the number of frames per second at ESS, and $\\Fevent$ is the event rate.\n+We require $R_{\\text{live}} > 1$ to be able to support live reduction without MPI.\n+In Fig.~\\ref{fig:live-reduction-no-mpi} we show the implications for the first ESS instruments, depending on the accelerator power.\n+With the exception of \\dream and possibly \\magic, we seem to be able to handle most cases for most instruments even at higher accelerator power.\n+However, we will definitely require MPI support in live reduction for \\dream from day one.\n+\n+\\begin{figure}\n+  \\centering\n+\\includegraphics[height=0.8317\\textheight]{live-reduction-no-mpi.pdf}\n+\\caption{\\label{fig:live-reduction-no-mpi}Reduction speed ratio $R_{\\text{live}}$ for the first ESS instruments.\n+With increasing accelerator power, $\\Fevent$ increases and $R_{\\text{live}}$ decreases.\n+We require $R_{\\text{live}} > 1$ to be able to handle the data.\n+The plot range has been chosen accordingly --- a graph hitting the lower horizontal axis implies that the rate cannot be handled anymore.\n+For \\bifrost the pixel count is very low and we are not confident that we can extrapolate the scaling benchmarks from Tab.~\\ref{tab:consumption-rate} this far.\n+We have therefore excluded the panel for \\bifrost but expect that the rate can be handled even at a power of $5~\\mathrm{MW}$.\n+The imaging beamline \\odin is a special case and has thus also been excluded from this figure.\n+}\n+\\end{figure}\n+\n+For experiments with very high throughput, i.e., quick changes of sample-environment parameters or sample, we have to deal with additional complexity in the live reduction workflow.\n+This could include more advanced filtering, display and comparison of multiple results at the same time,\\footnote{e.g., waterfall plots} and overhead from frequent transitions to a new run.\n+We have not yet started development of these features so benchmarks are not available.\n+That being said, high throughput experiments are not likely to be required in the early days.\n+Furthermore, UX is likely to be a bigger issue than performance in this case.\n+We consider it unlikely that this scenario will cause a significant overall difference in the required hardware.\n+\n+\n+\n+\n+\\section{Interactive reduction}\n+\n+As discussed in Sec.~\\ref{sec:threading-and-mpi-support} there is no MPI support for the GUI or interactive reduction in general, limiting scaling with the number of available cores.\n+Generally we do not expect good scaling far beyond 10 cores.\n+For reductions that are too slow in that case there are several options that can be used in practice:\n+\\begin{itemize}\n+  \\item Use slow interactive reduction for a single run/sample, apply resulting workflow to other samples using script-based reduction on the cluster.\n+  \\item Use interactive reduction using a reduced or compressed set of data, e.g., by loading only every $N$-th pulse or by compressing events, apply resulting workflow to other samples using script-based reduction on the cluster.\n+  \\item Use slow interactive reduction and use different sessions to do something else in the meantime, such as reducing another sample.\n+\\end{itemize}\n+With exception of the second option, there is a minimum amount of required total RAM.\n+We can attempt to estimate the requirement as\n+\n+\\begin{align}\n+  \\label{eq:ram-interactive}\n+  M_{\\text{interactive}} &= 2~\\mathrm{GByte} + \\Nspec \\cdot 256~\\mathrm{Byte} + N_{\\text{workspace}}(24\\Nbin + 16\\Nevent)~\\mathrm{Byte},\n+\\end{align}\n+with\n+\\begin{itemize}\n+  \\item $\\Nworkspace$ is the number of workspaces present in \\mantid at the same time.\n+    For interactive reduction this can typically be larger than the absolute minimum required for a fixed script-based reduction.\n+    Therefore we use $\\Nworkspace = 10$ here, which is higher than what we will require below for script-based reduction in Sec.~\\ref{sec:script-based-results}.\n+  \\item $2~\\mathrm{GByte}$ base memory.\n+    We assume a larger base requirement than in Sec.~\\ref{sec:script-based-results} for GUI requirements.\n+  \\item $256~\\mathrm{Byte}$ of memory per pixel to represent the instrument geometry.\n+    This is assumed to be shared between workspaces.\n+  \\item $24~\\mathrm{Byte}$ per bin per workspace for double-precision X, Y, and E.\n+  \\item $16~\\mathrm{Byte}$ per event per workspace for double-precision time-of-flight and pulse-time.\n+\\end{itemize}\n+Considering the projected duration of a single run $\\Trun$ for design-power event rates, most experiments seem to use roughly $10^8$ to $10^9$ events.\n+Based on this equation, we give example requirements for various instrument configurations in Fig.~\\ref{fig:interactive-ram}.\n+Notable exceptions to this are the inelastic beamlines and the single-crystal beamlines, if we consider merging data from all sample rotation angles.\n+Traditionally single crystal diffraction and inelastic scattering have the highest memory requirements but it is currently unclear whether this merge step would be done in \\mantid.\n+\n+\\begin{figure}\n+  \\centering\n+\\includegraphics[height=0.33\\textheight]{interactive-ram.pdf}\n+\\caption{\\label{fig:interactive-ram}\n+Scaling of memory requirements for interactive reduction with the event count per run.\n+The plot uses the final pixel count from Tab.~\\ref{tab:pixel-counts} and $\\Nbin$ based on Tab.~\\ref{tab:resolution}.\n+The powder and single crystal diffractometers \\dream, \\magic, and \\beer show an exceedingly high memory requirement due to the high pixelation and time resolution.\n+This is probably not a real and realistic requirement, see the discussion in Sec.~\\ref{sec:script-based-results}.\n+The worst-case assumption that a histogram-representation for all workspaces is required leads to a rather high baseline requirement --- scaling with the total event count only becomes visible near $10^9$ events and above.\n+Excluding the special cases listed above, the required memory will mostly not exceed $256~\\mathrm{GByte}$ or up to $1~\\mathrm{TByte}$ for large runs with $10^{10}$ events.\n+The requirement can be lowered further by reducing $\\Nworkspace$ and/or by avoiding binning of most workspaces, i.e., working purely in event mode.\n+}\n+\\end{figure}\n+\n+Instrument scientists expect that typically 5 interactive sessions would be required per instrument at any given time.\n+This figure is to be combined with requirements for data analysis since typically the interactive sessions would be used for both, data reduction and data analysis.\n+For data reduction, a lot of the time \\mantid will actually be idle or unused.\n+Thus simply adding the required 5 sessions to the required numbers for data analysis is likely to overestimate the required resources.\n+\n+\n+\n+\n+\\section{Script-based reduction}\n+\n+\n+\\subsection{Scaling analysis}\n+\\label{sec:scaling-analysis}\n+\n+The number of cores required for MPI-based reduction depends on the required maximum runtime for a reduction.\n+It is unclear what a good limit for the runtime $\\Treduction$ is.\n+For now we define:\n+\n+\\begin{itemize}\n+  \\item The reduction should be $5\\times$ faster than the experiment.\n+  \\item To ensure that long-running experiments with low event rates are processed quickly we require that a minimum of $2\\cdot10^6$ events/s are processed.\n+  \\item We never require a runtime below 30 seconds.\n+\\end{itemize}\n+A visualization of these requirements is given in Fig.~\\ref{fig:reduction-time-requirement}.\n+\n+\\begin{figure}\n+  \\centering\n+\\includegraphics[height=0.33\\textheight]{reduction-time-requirement.pdf}\n+\\caption{\\label{fig:reduction-time-requirement}Imposed requirements for the maximum reduction time. The checked areas indicate regions that are forbidden by the defined limits. For runs that are short relative to the event rate we are governed by the 30-second limit. Above that limit, at low event rates the required reduction duration is low compared to the run duration. With increasing event rate we get closer to the limit of $5\\times$ speedup indicated by the bold red line.}\n+\\end{figure}\n+\n+With a couple of approximations (which are probably minor for this purpose and compared to other sources of uncertainty) we can describe the time required to reduce a set of data as\n+\n+\\begin{align}\n+  \\Treduction = t_0 + \\frac{\\Nbin\\Tbin + \\Nevent\\Tevent}{\\Ncore} + \\frac{\\Nevent}{\\Bmax},\n+  \\label{eq:master}\n+\\end{align}\n+where\n+\\begin{itemize}\n+  \\item $\\Nbin$ is the number of bins in the workflow, i.e., the number of spectra $\\Nspec$ multiplied by the number of bins per spectrum.\\footnote{Typically $\\Nspec$ is the number of pixels of the instrument, but it can be different, e.g., when multiple adjacent pixels are grouped due to a lower resolution requirement or due to potential projections related to volumetric detectors.}\n+    The number of bins per spectrum depends on the bandwidth and resolution of the instrument.\n+    As a rule of thumb, for a given energy resolution $\\delta E$ we require a bin size of $\\delta E/10$.\n+  \\item $\\Nevent$ is the total number of events that are being handled in the reduction workflow.\n+    This can include events from multiple files, e.g., for a sample run and a background run.\n+  \\item $\\Ncore$ is the number of cores (MPI ranks) used in the reduction.\n+    We are not considering a hybrid threading+MPI approach.\\footnote{A few specialized algorithms are using threading internally, even in an MPI run.}.\n+  \\item $t_0$ is a constant time specific to the reduction workflow.\n+    It includes anything that does not depend and the number of spectra or number of events.\n+    Typically this includes small parts of the time spend in every algorithm, time for loading experiment logs from NeXus files, time for loading auxiliary files, and other overheads.\n+  \\item $\\Tbin$ is the (computed) time to run the workflow for a single bin.\n+  \\item $\\Tevent$ is the (computed) time to run the workflow for a single event.\n+  \\item $\\Bmax$ is the number of events that can be loaded from the file system per second.\n+\\end{itemize}\n+The equation is motivated by an analysis of benchmark results --- see Sec.~\\ref{sec:benchmarks} --- and the computational structure of data reduction.\n+$\\Ncore$ can be adjusted such that $\\Treduction$ fulfills the conditions listed above.\n+There can be cases where the conditions are violated, e.g., when the event rate is high and $\\Bmax$ is too low.\n+More details on this equation can be found in App.~\\ref{app:master_eq}.\n+\n+Our benchmarks based on existing instruments and investigations of parameters for a series of ESS instruments show that any of the terms in Eq.~\\eqref{eq:master} can be relevant or even dominant, depending on the instrument, the experiment, and the number of used cores:\n+\n+\\begin{itemize}\n+  \\item \n+    For instruments that produce many small files with few spectra and events, the $t_0$ term can become dominant.\n+    This can in theory be improved by processing multiple files in the same workflow, but at this point making such an assumption is not justified.\n+    It is thus important to capture the typical run duration for each instrument.\n+  \\item\n+    Even if the $t_0$ term is not dominant, a run may contain relatively few events relative to the pixel count.\n+    In that case the $\\Nbin$ term is important.\n+    Given that many ESS instruments have a high pixel count this could very well become a dominating factor.\\footnote{In many experiments the total number of events required for each measurement may not increase drastically over present-day experiments. However, the ESS event \\emph{rate} and pixel counts are often much higher, so the balance may shift to our disadvantage.}\n+  \\item\n+    For instruments with many events we may be using many cores to offset the reduction cost.\n+    In that limit the bandwidth-limiting term becomes relevant.\n+\\end{itemize}\n+\n+Based on the time for reducing a single run we can thus compute the average number of cores required for reducing data for the instrument.\n+Note that this does \\emph{not} include live reduction and interactive sessions.\n+We define\n+\n+\\begin{align}\n+  \\Ncoremean = p_{\\text{use}}\\Nreduction \\Ncore \\frac{\\Treduction}{\\Trun},\n+\\end{align}\n+where\n+\n+\\begin{itemize}\n+  \\item $p_{\\text{use}}$ is the probability that the instrument is in use in a specific operating mode.\n+  Typically there are multiple operating modes for an instrument so there will be multiple $\\Ncoremean$ values that need to be be summed.\n+  \\item $\\Nreduction$ is the number of times data is reduced.\n+    Typically this should be small, e.g., 1, 2, or 3, but especially in the early days there will be exceptions.\n+  \\item $\\Trun$ is the duration of a single run.\n+\\end{itemize}\n+For convenience, we can expand the master equation and obtain\n+\n+%TODO include factor for use-fraction and use same symbol when generating tables\n+\\begin{align}\n+  \\Ncoremean &= \\frac{\\Nreduction}{\\Trun}\\left[\\Ncore \\left(t_0 + \\frac{\\Nevent}{\\Bmax}\\right) + \\Nbin\\Tbin + \\Nevent\\Tevent\\right]\\\\\n+  \\label{eq:master-v2}\n+   &= \\Nreduction\\left[\\Ncore \\left(\\frac{t_0}{\\Trun} + \\frac{\\Fevent}{\\Bmax}\\right) + \\frac{\\Nbin\\Tbin}{\\Trun} + \\Fevent\\Tevent\\right]\\\\\n+   &= \\Nreduction\\left[\\Ncore \\left(\\frac{t_0\\Fevent}{\\Nevent} + \\frac{\\Fevent}{\\Bmax}\\right) + \\frac{\\Nbin\\Tbin\\Fevent}{\\Nevent} + \\Fevent\\Tevent\\right].\n+\\end{align}\n+All three lines are trivial variations of each other and are merely listed to highlight different aspects of the scaling behavior.\n+\n+It is important to note that $\\Ncoremean$ depends on $\\Ncore$, i.e., the more cores we use, the higher our overall hardware requirement.\n+Reasons for using more cores are primarily (1) to reduce the time for a single reduction to something that is acceptable for users, and (2) to work around memory limitations on a single node.\n+There are two terms that depend on $1/\\Trun$ (see Eq.~\\eqref{eq:master-v2}), i.e., shorter runs will increase the number of required cores even if all other parameters such as the event rate $\\Fevent$ are unchanged.\n+\n+%Under the assumption that we are not bound by any of the other limits we can also substitute the $5\\times$ speedup factor and eliminate $\\Ncore$.\n+%Then Eq.~\\eqref{eq:master} yields\n+%\n+%\\begin{align}\n+%  \\frac{\\Trun}{5} &= t_0 + \\frac{\\Nbin\\Tbin + \\Nevent\\Tevent}{\\Ncore} + \\frac{\\Nevent}{\\Bmax},\\\\\n+%  \\Rightarrow \\Ncore &= \\frac{\\Nbin\\Tbin + \\Nevent\\Tevent}{\\frac{\\Trun}{5} - t_0 - \\frac{\\Nevent}{\\Bmax}},\\\\\n+%  \\Rightarrow \\Ncoremean &= \\Nreduction\\left[ \\frac{\\Nbin\\Tbin + \\Nevent\\Tevent}{\\frac{\\Trun}{5} - t_0 - \\frac{\\Nevent}{\\Bmax}} \\left(\\frac{t_0}{\\Trun} + \\frac{\\Fevent}{\\Bmax}\\right) + \\frac{\\Nbin\\Tbin}{\\Trun} + \\Fevent\\Tevent\\right].\n+%\\end{align}\n+\n+\n+\\subsection{Event filtering}\n+\n+The discussion in this section is based on event filtering benchmarks conducted by Neil Vaytet.\n+See the reference given in App.~\\ref{app:refs} for details.\n+Many ESS instruments will require filtering events in one way or another.\n+Benchmarks indicate that the contribution to the overall runtime is less than $10\\%$, i.e., we do not need to handle it explicitly in our evaluations.\n+While the cost of filtering itself is not significant, in many cases we are dealing with many more workspaces after the filtering process, e.g., one for every temperature interval in a temperature scan.\n+If the majority of data reduction can be done \\emph{before} filtering this is not a problem.\n+However, if a significant portion of data treatment can only happen after the filtering/splitting process the cost is increasing significantly since we are effectively dealing with many distinct runs.\n+This problem is probably similar to the case of sample rotation angles discussed later in Tab.~\\ref{tab:hardware-magic} for \\magic and needs to be investigated closer in the future.\n+\n+\n+\\subsection{Baseline benchmarks}\n+\\label{sec:benchmarks}\n+\n+To establish an estimate for the parameters $t_0$, $\\Tbin$, $\\Tevent$, and $\\Bmax$ in Eq.~\\eqref{eq:master} a number of benchmarks have been undertaken.\n+\n+\\begin{enumerate}\n+  \\item Using an MPI-build of \\mantid we measured run times of workflows for SANS, powder diffraction, and direct geometry spectroscopy (using the ISIS workflow for SANS2D, the \\verb|SNSPowderDiffraction| workflow for PG3, and the \\verb|DgsReduction| workflow for CNCS).\n+    We studied the scaling behavior with the number of used cores (MPI ranks), the number of events, and also the number of bins per spectrum.\n+    By looking at the various limits (few/many cores and few/many events) we can extract an approximation for $t_0$, $\\Tbin$, $\\Tevent$.\n+    All these experiments were done on a single node, a dual-socket Xeon E5-2620 v3 running at 2.40GHz.\n+  \\item Scaling beyond a single node has been established in older benchmarks in 2015, again using the \\verb|SNSPowderDiffraction|.\n+    This benchmark showed that scaling beyond a single node does not lead to any significant slowdown and scaling works well up to a high number of MPI ranks, with the exception of algorithms loading or saving files.\n+  \\item For the special case of I/O we rely on benchmarks for the recently optimized parallel event loader for \\nexus files.\n+    Currently only benchmarks with a local SSD are available and show scaling up to nearly $10^8$ loaded events per second (slightly lower for compressed files) with 10 used cores.\n+    Benchmarks with a parallel file system are pending.\n+\\end{enumerate}\n+The experiments show a surprisingly consistent pattern, independent of the technique:\n+\n+\\begin{itemize}\n+\\item $t_0$ is about 10 seconds.\n+\\item $\\Tbin$ varies from 1/1.000.000 seconds for histogram-heavy reductions to about 1/10.000.000 seconds for reductions with near-ubiquitous use of event-mode.\n+\\item $\\Tevent$ is about 1/1.000.000 seconds, or slightly smaller.\n+\\item $\\Bmax$ is about 50.000.000 events/second for an SSD, tests with a parallel file system are pending.\n+\\end{itemize}\n+\n+\n+\\subsection{Other factors}\n+\n+With low accelerator power and lower detector coverage in the early days it is to be expected that the type of experiments will be different from what is envisioned for full power.\n+For example, larger samples will be used to compensate for the lower rates.\n+The compensation could be of up to a order of magnitude in size, at least for certain experiments.\n+While some instruments indicate they will do so, e.g., \\loki and \\dream, not all of them will, e.g., \\cspec.\n+We have \\emph{not} included a scaling term to represent this effect in the numbers given in this document.\n+Ensuring that the compute cluster size ramp up is sufficiently ahead of the accelerator power ramp up could help to deal with this uncertainty.\n+\n+\n+\\subsection{Results}\n+\\label{sec:script-based-results}\n+\n+This section discusses results obtained for script-based reduction with the performance model introduced earlier.\n+In the following we give example listings of reduction times, core counts, and memory consumption for various instruments and operating modes.\n+We strongly emphasize that the resulting values heavily depend on parameters that we cannot estimate with good accuracy.\n+Parameters used for generating the listings can be found in Tab.~\\ref{tab:hardware-estimation-parameters}.\n+Resolution options and the resulting bin counts are given in Tab.~\\ref{tab:resolution}.\n+Python scripts to generate the tables are described in App.~\\ref{app:scripts}.\n+The resulting data for the given parameters can be found in Tabs.~\\ref{tab:hardware-beer}--\\ref{tab:hardware-magic}.\n+\n+\\begin{table}\n+  \\centering\n+  \\begin{tabular}{lrp{8cm}}\n+    Parameter & Value & Comment\\\\\n+    \\hline\n+    $t_0$ & $10~\\mathrm{s}$ \\\\\n+    $\\Tbin$ & $2\\times10^{-7}~\\mathrm{s}$ \\\\\n+    $\\Tevent$ & $10^{-6}~\\mathrm{s}$ \\\\\n+    $\\Bmax$ & $10^8~\\mathrm{s}^{-1}$ \\\\\n+    scale factor for $\\Nevent$ & 2 & to approximate cost from need to reduce sample \\emph{and} background for every sample run TODO above we state the Nevent includes this, this is just internal based on count required for sample run (need it if we give that in a table?) \\\\\n+    $\\Nworkspace$ & 5 \\\\\n+    $\\Nreduction$ & 2 \\\\\n+    $\\Ncore^{\\text{max}}$ & 512 & set as arbitrary limit to reduce the number of nonsensical results from special parameter combinations in conflict with generic performance requirements from Sec.~\\ref{sec:scaling-analysis} \\\\\n+    \\hline\n+  \\end{tabular}\n+  \\caption{\\label{tab:hardware-estimation-parameters}\n+  List of parameters used to generate Tabs.~\\ref{tab:hardware-beer}--\\ref{tab:hardware-magic}.\n+  See also Eq.~\\eqref{eq:ram} regarding memory requirements and related parameters.\n+}\n+\\end{table}\n+\n+\\begin{table}\n+  \\centering\n+  \\begin{tabular}{llrl}\n+    Instrument & Mode & Bins per spectrum & Comment \\\\\n+    \\hline\n+    \\hline\n+    \\multirow{2}{*}{\\beer}\n+    & medium-flux & 8500 \\\\\n+    & high-flux & 2000 \\\\\n+    \\hline\n+    \\multirow{1}{*}{\\bifrost}\n+    & average & 850\\\\\n+    & high-flux & 110 & is highest flux always lowest resolution?\\\\\n+    \\hline\n+    \\multirow{1}{*}{\\cspec}\n+    & (all) & 1000 & no large resolution variation possible? \\\\\n+    \\hline\n+    \\multirow{3}{*}{\\dream}\n+    & high-resolution & 71000 \\\\\n+    & medium & 10000 \\\\\n+    & high-intensity & 1420 \\\\\n+    \\hline\n+    \\multirow{1}{*}{\\estia}\n+    & (all) & 450 \\\\\n+    \\hline\n+    \\multirow{1}{*}{\\loki}\n+    & (all)    & 240 \\\\\n+    \\hline\n+    \\multirow{1}{*}{\\magic}\n+    & (all) & 7100 \\\\\n+    \\hline\n+  \\end{tabular}\n+  \\caption{\\label{tab:resolution}\n+List of bin counts used to generate Tabs.~\\ref{tab:hardware-beer}--\\ref{tab:hardware-magic}.\n+Bin counts have been estimated based on instrument proposals and input from instrument scientists.\n+Details can be found in App.~\\ref{app:instrument-parameters}.\n+}\n+\\end{table}\n+\n+We adopt a simplified model to estimate the amount of required main memory.\\footnote{This is similar to but different from Eq.~\\eqref{eq:ram-interactive} used for the case of interactive reduction.}\n+We define\n+\n+\\begin{align}\n+  \\label{eq:ram}\n+  M &\\equiv \\Ncore(1~\\mathrm{GByte} + \\Nspec \\cdot 256~\\mathrm{Byte}) + N_{\\text{workspace}}(24\\Nbin + 16\\Nevent)~\\mathrm{Byte},\\\\\n+  \\Mcore &\\equiv \\frac{M}{\\Ncore} = 1~\\mathrm{GByte} + \\Nspec \\cdot 256~\\mathrm{Byte} + \\frac{\\Nworkspace}{\\Ncore}(24\\Nbin + 16\\Nevent)~\\mathrm{Byte}.\n+\\end{align}\n+with\n+\\begin{itemize}\n+  \\item $1~\\mathrm{GByte}$ base memory per core.\n+  \\item $256~\\mathrm{Byte}$ of memory per pixel per core to represent the instrument geometry.\n+    This is assumed to be shared between workspaces.\n+  \\item $24~\\mathrm{Byte}$ per bin per workspace for double-precision X, Y, and E.\n+  \\item $16~\\mathrm{Byte}$ per event per workspace for double-precision time-of-flight and pulse-time.\n+\\end{itemize}\n+This is a naive model that assumes that we require a histogram representation of the data at some point during the reduction.\n+Histogram mode is used for visualization as well as data reduction steps that cannot be done in event mode, such as normalization.\n+Accounting for memory for a full histogram representation can lead to very high memory requirements, see in particular the discussion on \\dream below.\n+\n+\\begin{table}\n+  \\scriptsize\n+  \\input{BEER.tex}\n+  \\caption{\\label{tab:hardware-beer}\n+Example estimate of hardware required for script-based reduction for \\beer.\n+In this and the following tables, the `Pixels' column refers to the build-out phase.\n+`Use' is a guess of the fraction a particular instrument mode/configuration is used.\n+The values are chosen to add up to 100\\% but could be adjusted to take into account time without beam and time for changing samples.\n+If the obtainable $\\Treduction$ violates the conditions such as a $5\\times$ speedup stated in Sec.~\\ref{sec:scaling-analysis} the corresponding $\\Trun$ in the table is highlighted in \\textcolor{red}{red}.\\\\","path":"doc/report.tex","position":532,"original_position":532,"commit_id":"f55bbf2cc0307010a0471fcd3da254682d733332","original_commit_id":"f55bbf2cc0307010a0471fcd3da254682d733332","user":{"login":"nvaytet","id":39047984,"node_id":"MDQ6VXNlcjM5MDQ3OTg0","avatar_url":"https://avatars2.githubusercontent.com/u/39047984?v=4","gravatar_id":"","url":"https://api.github.com/users/nvaytet","html_url":"https://github.com/nvaytet","followers_url":"https://api.github.com/users/nvaytet/followers","following_url":"https://api.github.com/users/nvaytet/following{/other_user}","gists_url":"https://api.github.com/users/nvaytet/gists{/gist_id}","starred_url":"https://api.github.com/users/nvaytet/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/nvaytet/subscriptions","organizations_url":"https://api.github.com/users/nvaytet/orgs","repos_url":"https://api.github.com/users/nvaytet/repos","events_url":"https://api.github.com/users/nvaytet/events{/privacy}","received_events_url":"https://api.github.com/users/nvaytet/received_events","type":"User","site_admin":false},"body":"`corresponding $\\Trun$` : i thin you mean `$\\Treduction$`","created_at":"2018-08-10T14:52:13Z","updated_at":"2018-08-10T14:59:47Z","html_url":"https://github.com/DMSC-Instrument-Data/data-reduction-hardware-requirements/pull/2#discussion_r209286144","pull_request_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/pulls/2","author_association":"CONTRIBUTOR","_links":{"self":{"href":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/pulls/comments/209286144"},"html":{"href":"https://github.com/DMSC-Instrument-Data/data-reduction-hardware-requirements/pull/2#discussion_r209286144"},"pull_request":{"href":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/pulls/2"}}},"pull_request":{"url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/pulls/2","id":206996705,"node_id":"MDExOlB1bGxSZXF1ZXN0MjA2OTk2NzA1","html_url":"https://github.com/DMSC-Instrument-Data/data-reduction-hardware-requirements/pull/2","diff_url":"https://github.com/DMSC-Instrument-Data/data-reduction-hardware-requirements/pull/2.diff","patch_url":"https://github.com/DMSC-Instrument-Data/data-reduction-hardware-requirements/pull/2.patch","issue_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/issues/2","number":2,"state":"open","locked":false,"title":"First draft of report","user":{"login":"SimonHeybrock","id":12912489,"node_id":"MDQ6VXNlcjEyOTEyNDg5","avatar_url":"https://avatars1.githubusercontent.com/u/12912489?v=4","gravatar_id":"","url":"https://api.github.com/users/SimonHeybrock","html_url":"https://github.com/SimonHeybrock","followers_url":"https://api.github.com/users/SimonHeybrock/followers","following_url":"https://api.github.com/users/SimonHeybrock/following{/other_user}","gists_url":"https://api.github.com/users/SimonHeybrock/gists{/gist_id}","starred_url":"https://api.github.com/users/SimonHeybrock/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/SimonHeybrock/subscriptions","organizations_url":"https://api.github.com/users/SimonHeybrock/orgs","repos_url":"https://api.github.com/users/SimonHeybrock/repos","events_url":"https://api.github.com/users/SimonHeybrock/events{/privacy}","received_events_url":"https://api.github.com/users/SimonHeybrock/received_events","type":"User","site_admin":false},"body":"This is meant for reviewing the first draft of the report of hardware requirement estimates.\r\n\r\nThe report itself is a PDF (sorry about that, it got too complex, so writing it as Markdown or Word or on Confluence was not an option). The PR includes the source files so they can be used for commenting. For reading I recommend the PDF version I distributed.\r\n\r\nUnfortunately there are a lot of unrelated files visible in this (dummy) PR. Please consider only `doc/report.tex` and optionally related files like the script `generate_tables.py` for the review.","created_at":"2018-08-08T12:50:17Z","updated_at":"2018-08-10T14:59:47Z","closed_at":null,"merged_at":null,"merge_commit_sha":"6fb3512f8ca00afa4e2516b25682aa6ddd6c448a","assignee":null,"assignees":[],"requested_reviewers":[],"requested_teams":[],"labels":[],"milestone":null,"commits_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/pulls/2/commits","review_comments_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/pulls/2/comments","review_comment_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/pulls/comments{/number}","comments_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/issues/2/comments","statuses_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/statuses/f55bbf2cc0307010a0471fcd3da254682d733332","head":{"label":"DMSC-Instrument-Data:master","ref":"master","sha":"f55bbf2cc0307010a0471fcd3da254682d733332","user":{"login":"DMSC-Instrument-Data","id":15102351,"node_id":"MDEyOk9yZ2FuaXphdGlvbjE1MTAyMzUx","avatar_url":"https://avatars0.githubusercontent.com/u/15102351?v=4","gravatar_id":"","url":"https://api.github.com/users/DMSC-Instrument-Data","html_url":"https://github.com/DMSC-Instrument-Data","followers_url":"https://api.github.com/users/DMSC-Instrument-Data/followers","following_url":"https://api.github.com/users/DMSC-Instrument-Data/following{/other_user}","gists_url":"https://api.github.com/users/DMSC-Instrument-Data/gists{/gist_id}","starred_url":"https://api.github.com/users/DMSC-Instrument-Data/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/DMSC-Instrument-Data/subscriptions","organizations_url":"https://api.github.com/users/DMSC-Instrument-Data/orgs","repos_url":"https://api.github.com/users/DMSC-Instrument-Data/repos","events_url":"https://api.github.com/users/DMSC-Instrument-Data/events{/privacy}","received_events_url":"https://api.github.com/users/DMSC-Instrument-Data/received_events","type":"Organization","site_admin":false},"repo":{"id":135272415,"node_id":"MDEwOlJlcG9zaXRvcnkxMzUyNzI0MTU=","name":"data-reduction-hardware-requirements","full_name":"DMSC-Instrument-Data/data-reduction-hardware-requirements","owner":{"login":"DMSC-Instrument-Data","id":15102351,"node_id":"MDEyOk9yZ2FuaXphdGlvbjE1MTAyMzUx","avatar_url":"https://avatars0.githubusercontent.com/u/15102351?v=4","gravatar_id":"","url":"https://api.github.com/users/DMSC-Instrument-Data","html_url":"https://github.com/DMSC-Instrument-Data","followers_url":"https://api.github.com/users/DMSC-Instrument-Data/followers","following_url":"https://api.github.com/users/DMSC-Instrument-Data/following{/other_user}","gists_url":"https://api.github.com/users/DMSC-Instrument-Data/gists{/gist_id}","starred_url":"https://api.github.com/users/DMSC-Instrument-Data/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/DMSC-Instrument-Data/subscriptions","organizations_url":"https://api.github.com/users/DMSC-Instrument-Data/orgs","repos_url":"https://api.github.com/users/DMSC-Instrument-Data/repos","events_url":"https://api.github.com/users/DMSC-Instrument-Data/events{/privacy}","received_events_url":"https://api.github.com/users/DMSC-Instrument-Data/received_events","type":"Organization","site_admin":false},"private":false,"html_url":"https://github.com/DMSC-Instrument-Data/data-reduction-hardware-requirements","description":"Scripts and documentation about hardware requirements for data reduction","fork":false,"url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements","forks_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/forks","keys_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/keys{/key_id}","collaborators_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/collaborators{/collaborator}","teams_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/teams","hooks_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/hooks","issue_events_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/issues/events{/number}","events_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/events","assignees_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/assignees{/user}","branches_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/branches{/branch}","tags_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/tags","blobs_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/git/blobs{/sha}","git_tags_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/git/tags{/sha}","git_refs_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/git/refs{/sha}","trees_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/git/trees{/sha}","statuses_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/statuses/{sha}","languages_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/languages","stargazers_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/stargazers","contributors_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/contributors","subscribers_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/subscribers","subscription_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/subscription","commits_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/commits{/sha}","git_commits_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/git/commits{/sha}","comments_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/comments{/number}","issue_comment_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/issues/comments{/number}","contents_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/contents/{+path}","compare_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/compare/{base}...{head}","merges_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/merges","archive_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/{archive_format}{/ref}","downloads_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/downloads","issues_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/issues{/number}","pulls_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/pulls{/number}","milestones_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/milestones{/number}","notifications_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/notifications{?since,all,participating}","labels_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/labels{/name}","releases_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/releases{/id}","deployments_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/deployments","created_at":"2018-05-29T09:24:27Z","updated_at":"2018-08-09T06:35:59Z","pushed_at":"2018-08-09T06:35:57Z","git_url":"git://github.com/DMSC-Instrument-Data/data-reduction-hardware-requirements.git","ssh_url":"git@github.com:DMSC-Instrument-Data/data-reduction-hardware-requirements.git","clone_url":"https://github.com/DMSC-Instrument-Data/data-reduction-hardware-requirements.git","svn_url":"https://github.com/DMSC-Instrument-Data/data-reduction-hardware-requirements","homepage":null,"size":2265,"stargazers_count":0,"watchers_count":0,"language":"Python","has_issues":true,"has_projects":true,"has_downloads":true,"has_wiki":true,"has_pages":false,"forks_count":1,"mirror_url":null,"archived":false,"open_issues_count":1,"license":null,"forks":1,"open_issues":1,"watchers":0,"default_branch":"master"}},"base":{"label":"DMSC-Instrument-Data:review-dummy","ref":"review-dummy","sha":"8ce5e262f9d5528cc1391b29d6ac11aa789daa03","user":{"login":"DMSC-Instrument-Data","id":15102351,"node_id":"MDEyOk9yZ2FuaXphdGlvbjE1MTAyMzUx","avatar_url":"https://avatars0.githubusercontent.com/u/15102351?v=4","gravatar_id":"","url":"https://api.github.com/users/DMSC-Instrument-Data","html_url":"https://github.com/DMSC-Instrument-Data","followers_url":"https://api.github.com/users/DMSC-Instrument-Data/followers","following_url":"https://api.github.com/users/DMSC-Instrument-Data/following{/other_user}","gists_url":"https://api.github.com/users/DMSC-Instrument-Data/gists{/gist_id}","starred_url":"https://api.github.com/users/DMSC-Instrument-Data/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/DMSC-Instrument-Data/subscriptions","organizations_url":"https://api.github.com/users/DMSC-Instrument-Data/orgs","repos_url":"https://api.github.com/users/DMSC-Instrument-Data/repos","events_url":"https://api.github.com/users/DMSC-Instrument-Data/events{/privacy}","received_events_url":"https://api.github.com/users/DMSC-Instrument-Data/received_events","type":"Organization","site_admin":false},"repo":{"id":135272415,"node_id":"MDEwOlJlcG9zaXRvcnkxMzUyNzI0MTU=","name":"data-reduction-hardware-requirements","full_name":"DMSC-Instrument-Data/data-reduction-hardware-requirements","owner":{"login":"DMSC-Instrument-Data","id":15102351,"node_id":"MDEyOk9yZ2FuaXphdGlvbjE1MTAyMzUx","avatar_url":"https://avatars0.githubusercontent.com/u/15102351?v=4","gravatar_id":"","url":"https://api.github.com/users/DMSC-Instrument-Data","html_url":"https://github.com/DMSC-Instrument-Data","followers_url":"https://api.github.com/users/DMSC-Instrument-Data/followers","following_url":"https://api.github.com/users/DMSC-Instrument-Data/following{/other_user}","gists_url":"https://api.github.com/users/DMSC-Instrument-Data/gists{/gist_id}","starred_url":"https://api.github.com/users/DMSC-Instrument-Data/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/DMSC-Instrument-Data/subscriptions","organizations_url":"https://api.github.com/users/DMSC-Instrument-Data/orgs","repos_url":"https://api.github.com/users/DMSC-Instrument-Data/repos","events_url":"https://api.github.com/users/DMSC-Instrument-Data/events{/privacy}","received_events_url":"https://api.github.com/users/DMSC-Instrument-Data/received_events","type":"Organization","site_admin":false},"private":false,"html_url":"https://github.com/DMSC-Instrument-Data/data-reduction-hardware-requirements","description":"Scripts and documentation about hardware requirements for data reduction","fork":false,"url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements","forks_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/forks","keys_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/keys{/key_id}","collaborators_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/collaborators{/collaborator}","teams_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/teams","hooks_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/hooks","issue_events_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/issues/events{/number}","events_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/events","assignees_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/assignees{/user}","branches_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/branches{/branch}","tags_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/tags","blobs_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/git/blobs{/sha}","git_tags_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/git/tags{/sha}","git_refs_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/git/refs{/sha}","trees_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/git/trees{/sha}","statuses_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/statuses/{sha}","languages_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/languages","stargazers_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/stargazers","contributors_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/contributors","subscribers_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/subscribers","subscription_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/subscription","commits_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/commits{/sha}","git_commits_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/git/commits{/sha}","comments_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/comments{/number}","issue_comment_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/issues/comments{/number}","contents_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/contents/{+path}","compare_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/compare/{base}...{head}","merges_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/merges","archive_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/{archive_format}{/ref}","downloads_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/downloads","issues_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/issues{/number}","pulls_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/pulls{/number}","milestones_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/milestones{/number}","notifications_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/notifications{?since,all,participating}","labels_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/labels{/name}","releases_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/releases{/id}","deployments_url":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/deployments","created_at":"2018-05-29T09:24:27Z","updated_at":"2018-08-09T06:35:59Z","pushed_at":"2018-08-09T06:35:57Z","git_url":"git://github.com/DMSC-Instrument-Data/data-reduction-hardware-requirements.git","ssh_url":"git@github.com:DMSC-Instrument-Data/data-reduction-hardware-requirements.git","clone_url":"https://github.com/DMSC-Instrument-Data/data-reduction-hardware-requirements.git","svn_url":"https://github.com/DMSC-Instrument-Data/data-reduction-hardware-requirements","homepage":null,"size":2265,"stargazers_count":0,"watchers_count":0,"language":"Python","has_issues":true,"has_projects":true,"has_downloads":true,"has_wiki":true,"has_pages":false,"forks_count":1,"mirror_url":null,"archived":false,"open_issues_count":1,"license":null,"forks":1,"open_issues":1,"watchers":0,"default_branch":"master"}},"_links":{"self":{"href":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/pulls/2"},"html":{"href":"https://github.com/DMSC-Instrument-Data/data-reduction-hardware-requirements/pull/2"},"issue":{"href":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/issues/2"},"comments":{"href":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/issues/2/comments"},"review_comments":{"href":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/pulls/2/comments"},"review_comment":{"href":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/pulls/comments{/number}"},"commits":{"href":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/pulls/2/commits"},"statuses":{"href":"https://api.github.com/repos/DMSC-Instrument-Data/data-reduction-hardware-requirements/statuses/f55bbf2cc0307010a0471fcd3da254682d733332"}},"author_association":"CONTRIBUTOR"}}
{"actor":{"display_login":"nvaytet"}}