From f39b6eb293b4ae36fcf42efb4f7256d3d1b01cfc Mon Sep 17 00:00:00 2001 From: Phil Carns Date: Wed, 11 Dec 2013 21:56:09 -0500 Subject: [PATCH] clean up IO sections (hold off on syncio stuff) --- doc/codes-best-practices.tex | 8 -------- 1 file changed, 8 deletions(-) diff --git a/doc/codes-best-practices.tex b/doc/codes-best-practices.tex index f36741b..6f048e9 100644 --- a/doc/codes-best-practices.tex +++ b/doc/codes-best-practices.tex @@ -315,8 +315,6 @@ statistics, but for scalability and data management reasons those results should be aggregated into a single file rather than producing a separate file per LP. -TODO: look at ross/IO code and determine how it relates to this. - \subsection{codes-workload generator} TODO: fill this in. codes-workload is an abstraction layer for feeding I/O @@ -335,12 +333,6 @@ global end timestamp for ROSS. The assumption is that CODES models will normally run to a completion condition rather than until simulation time runs out, see later section for more information on this approach. -\subsection{ross/IO} - -TODO: fill this in. This is the I/O library included with ROSS, based on -phasta I/O library. What are the use cases and how do you use it. Does it -deprecate the lp-io tool? - \section{CODES: reproducability and model safety} TODO: fill this in. These are things that aren't required for modularity, -- 2.26.2