Changeset 2760

Show
Ignore:
Timestamp:
10/30/09 06:33:03 (4 weeks ago)
Author:
wark
Message:

made more room

Location:
HydroWatch/Tim/doc/ipsn10
Files:
2 modified

Legend:

Unmodified
Added
Removed
  • HydroWatch/Tim/doc/ipsn10/sec_eval.tex

    r2750 r2760  
    3737\end{figure*} 
    3838 
    39 \begin{figure}[ht] 
    40 \centering 
    41   \includegraphics[width=9cm]{fig/util_hist1} 
    42 \caption{Histograms of utility as derived from cases of 3-day ahead prediction and only using todays prediction.} 
    43 \label{fig:util_hist1} 
    44 \end{figure} 
     39%\begin{figure}[ht] 
     40%\centering 
     41%  \includegraphics[width=9cm]{fig/util_hist1} 
     42%\caption{Histograms of utility as derived from cases of 3-day ahead prediction and only using todays prediction.} 
     43%\label{fig:util_hist1} 
     44%\end{figure} 
    4545 
    4646\begin{figure}[ht] 
     
    166166%\end{figure*} 
    167167 
    168 \begin{figure} 
    169 \centering 
    170 \includegraphics[width=0.25\textwidth]{fig/hsu_case1}  
    171 \caption{Configuring the input parameter $\alpha$ for 
    172 Hsu's algorithm} 
    173 \label{fig:hsu_algorithm} 
    174 \end{figure} 
     168%\begin{figure} 
     169%\centering 
     170%\includegraphics[width=0.25\textwidth]{fig/hsu_case1}  
     171%\caption{Configuring the input parameter $\alpha$ for 
     172%Hsu's algorithm} 
     173%\label{fig:hsu_algorithm} 
     174%\end{figure} 
    175175 
    176176 
  • HydroWatch/Tim/doc/ipsn10/sec_sysarch.tex

    r2714 r2760  
    33\label{sec:system} 
    44 
    5 \subsection{Overview} 
     5%\subsection{Overview} 
    66In order to implement the functionality as described in Sections~\ref{sec:adaptive} and~\ref{sec:energypredict}, we have developed an architecture as shown in Figure~\ref{fig:sysarch2}. The architecture allows for all computationally heavy tasks (such as prediction and optimization) to take place on a remote server machine and updates of node state to be sent out over nodes at the scheduled intervals as shown in Figure~\ref{fig:schedule1}. A brief description of each main module is given in the subsections below.   
    77 
     
    1616 
    1717\subsection{Server-side modules} 
    18 All server-side modules are written in Python and currently run on a standard PC running Linux. The main modules are as follows: 
    19 \begin{itemize} 
    20         \item Energy Prediction: Implements the protocols as described in Section~\ref{sec:energypredict} where weather condition estimates are retuned from the \emph{Wunderground} web-service. 
    21         \item Optimization: Performs the LP optimization to obtain updated estimates of report and sample frequencies. 
    22         \item Network sync: This module plays an important role in determining the network communication schedule for each node in the network. The module runs multiple threads which allows it to buffer any user commands, coming from a client machine, ready to send at the next scheduled period. 
    23         \item Database push: This module is responsible for pushing high-fidelity and report data into the database.    
    24 \end{itemize} 
     18All server-side modules are written in Python and currently run on a standard PC running Linux. The main modules are energy prediction, optimization, d/b push and network sync. This last module plays an important role in determining the network communication schedule for each node in the network. The module runs multiple threads which allows it to buffer any user commands, coming from a client machine, ready to send at the next scheduled period. 
     19 
     20% 
     21%\begin{itemize} 
     22%       \item Energy Prediction: Implements the protocols as described in Section~\ref{sec:energypredict} where weather condition estimates are retuned from the \emph{Wunderground} web-service. 
     23%       \item Optimization: Performs the LP optimization to obtain updated estimates of report and sample frequencies. 
     24%       \item Network sync: This module plays an important role in determining the network communication schedule for each node in the network. The module runs multiple threads which allows it to buffer any user commands, coming from a client machine, ready to send at the next scheduled period. 
     25%       \item Database push: This module is responsible for pushing high-fidelity and report data into the database.    
     26%\end{itemize} 
    2527 
    2628\subsection{Client-side modules}