Index: papers/SMPaT-2012_DCWoRMS/elsarticle-DCWoRMS.aux
===================================================================
--- papers/SMPaT-2012_DCWoRMS/elsarticle-DCWoRMS.aux	(revision 1067)
+++ papers/SMPaT-2012_DCWoRMS/elsarticle-DCWoRMS.aux	(revision 1068)
@@ -27,8 +27,8 @@
 \citation{SLURM}
 \citation{TORQUE}
-\citation{Ghislain}
 \@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces  DCworms architecture}}{6}}
 \newlabel{fig:arch}{{1}{6}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {3.1}Architecture}{6}}
+\citation{Ghislain}
 \@writefile{toc}{\contentsline {subsection}{\numberline {3.2}Workload modeling}{7}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {3.3}Resource modeling}{7}}
Index: papers/SMPaT-2012_DCWoRMS/elsarticle-DCWoRMS.fdb_latexmk
===================================================================
--- papers/SMPaT-2012_DCWoRMS/elsarticle-DCWoRMS.fdb_latexmk	(revision 1067)
+++ papers/SMPaT-2012_DCWoRMS/elsarticle-DCWoRMS.fdb_latexmk	(revision 1068)
@@ -1,4 +1,4 @@
 # Fdb version 2
-["pdflatex"] 1370006529 "elsarticle-DCWoRMS.tex" "elsarticle-DCWoRMS.pdf" "elsarticle-DCWoRMS" 
+["pdflatex"] 1370008374 "elsarticle-DCWoRMS.tex" "elsarticle-DCWoRMS.pdf" "elsarticle-DCWoRMS" 
   "/usr/local/texlive/2010/texmf-dist/tex/context/base/supp-pdf.mkii" 1251025892 71625 fad1c4b52151c234b6873a255b0ad6b3 ""
   "/usr/local/texlive/2010/texmf-dist/tex/generic/oberdiek/etexcmds.sty" 1267408169 5670 cacb018555825cfe95cd1e1317d82c1d ""
@@ -30,7 +30,7 @@
   "/usr/local/texlive/2010/texmf-dist/tex/latex/psnfss/upsy.fd" 1137110629 148 2da0acd77cba348f34823f44cabf0058 ""
   "/usr/local/texlive/2010/texmf-dist/tex/latex/psnfss/upzd.fd" 1137110629 148 b2a94082cb802f90d3daf6dd0c7188a0 ""
-  "elsarticle-DCWoRMS.aux" 1370006531 7677 ee860bc99ef90374805dbf64aaf0a430 ""
-  "elsarticle-DCWoRMS.spl" 1370006529 0 d41d8cd98f00b204e9800998ecf8427e ""
-  "elsarticle-DCWoRMS.tex" 1370006526 82123 6dafeac83286db1a04f54ac8551d85b2 ""
+  "elsarticle-DCWoRMS.aux" 1370008377 7677 f71d3a69833156dd0cd55997caa941bf ""
+  "elsarticle-DCWoRMS.spl" 1370008375 0 d41d8cd98f00b204e9800998ecf8427e ""
+  "elsarticle-DCWoRMS.tex" 1370007766 81944 a4f37cdda6dc074fed8954549930ec15 ""
   "elsarticle.cls" 1352447924 26095 ad44f4892f75e6e05dca57a3581f78d1 ""
   "fig/70dfsGantt.png" 1370005142 138858 edc557d8862a7825f2941d8c69c30659 ""
Index: papers/SMPaT-2012_DCWoRMS/elsarticle-DCWoRMS.tex
===================================================================
--- papers/SMPaT-2012_DCWoRMS/elsarticle-DCWoRMS.tex	(revision 1067)
+++ papers/SMPaT-2012_DCWoRMS/elsarticle-DCWoRMS.tex	(revision 1068)
@@ -228,7 +228,5 @@
 
 As it was said, experiments performed in DCworms require a description of applications that will be scheduled during the simulation. As a primary definition, DCworms uses files in the Standard Workload Format (SWF) or its extension the Grid Workload Format (GWF) \cite{GWF}. In addition to the SWF file, some more detailed specification of a job and tasks can be included in an auxiliary XML file. This form of description extends the basic one and provides the scheduler with more detailed information about application profile, task requirements, user preferences and execution time constraints, which are unavailable in SWF/GWF files. To facilitate the process of adapting the traces from real resource management systems, DCworms supports reading those delivered from the most common ones like SLURM \cite{SLURM} and Torque \cite{TORQUE}. 
-Since the applications may vary depending on their nature in terms of their requirements and structure, DCworms provides user flexibility in defining the application model. Thus, considered workloads may have various shapes and levels of complexity that range from multiple independent jobs, through large-scale parallel applications, up to whole workflows containing time dependencies and preceding constraints between jobs and tasks. Each job may consist of one or more tasks and these can be seen as groups of processes. Moreover, DCworms is able to handle rigid and moldable jobs, as well as pre-emptive ones. To model the application profile in more detail, 
-DCworms follows the DNA approach proposed in \cite{Ghislain}. Accordingly, each task can be presented as a sequence of phases, which shows the impact of this task on the resources that run it. Phases are then periods of time where the system is stable (load, network, memory) given a certain threshold. Each phase is linked to values of the system that represent a resource consumption profile. Such a stage could be for example described as follows: â60\% CPU, 30\% network, 10\% memoryâ.
-Levels of information about incoming jobs are presented in Figure~\ref{fig:jobsStructure}.
+Since the applications may vary depending on their nature in terms of their requirements and structure, DCworms provides user flexibility in defining the application model. Thus, considered workloads may have various shapes and levels of complexity that range from multiple independent jobs, through large-scale parallel applications, up to whole workflows containing time dependencies and preceding constraints between jobs and tasks. Each job may consist of one or more tasks and these can be seen as groups of processes. Moreover, DCworms is able to handle rigid and moldable jobs, as well as pre-emptive ones. Levels of information about incoming jobs are presented in Figure~\ref{fig:jobsStructure}. 
 
 
@@ -239,5 +237,5 @@
 \end{figure}
 
-
+To model the application profile in more detail, DCworms follows the DNA approach proposed in \cite{Ghislain}. Accordingly, each task can be presented as a sequence of phases, which shows the impact of this task on the resources that run it. Phases are then periods of time where the system is stable (load, network, memory) given a certain threshold. Each phase is linked to values of the system that represent a resource consumption profile. Such a stage could be for example described as follows: â60\% CPU, 30\% network, 10\% memoryâ.
 This form of representation allows users to define a wide range of workloads:
 HPC (long jobs, computational-intensive, hard to migrate) or virtualization (short requests) that are also typical for data center environments.
@@ -248,5 +246,5 @@
 The main goal of DCworms is to enable researchers evaluation of various resource management policies in diverse computing environments. To this end, it supports flexible definition of simulated resources both on physical (computing resources) as well as on logical (scheduling entities) level. This flexible approach allows modeling of various computing entities consisting of compute nodes, processors and cores. In addition, detailed location of the given resources can be provided in order to group them and arrange into physical structures such as racks and containers. Each of the components may be described by different parameters specifying available memory, storage capabilities, processor speed etc. In this way, it is possible to describe power distribution system and cooling devices. Due to an extensible description, users are able to define a number of experiment-specific and visionary characteristics. Moreover, with every component, dedicated profiles can be associated that determines, among others, power, thermal and air throughput properties. The energy estimation plugin can be bundled with each resource. This allows defining various power models that can be then followed by different computing system components. Details concerning the approach to energy-efficiency modeling in DCworms can be found in the next sections.
 
-Scheduling entities allow providing data related to the brokering or queuing system characteristics. Thus, information about available queues, resources associated with them and their parameters like priority, availability of advance reservation (AR) mechanism etc. can be defined. Moreover, allocation policy and task scheduling strategy for each scheduling entity can be introduced in form of the reference to an appropriate plugin. DCworms allows building a hierarchy of schedulers corresponding to the hierarchy of resource components over which the task may be distributed.
+Scheduling entities allow providing data related to the brokering or queuing system characteristics. Thus, information about available queues, resources associated with them and their parameters like priority, availability of advance reservation mechanism etc. can be defined. Moreover, allocation policy and task scheduling strategy for each scheduling entity can be introduced in form of the reference to an appropriate plugin. DCworms allows building a hierarchy of schedulers corresponding to the hierarchy of resource components over which the task may be distributed.
 
 In this way, the DCworms supports simulation of a wide scope of physical and logical architectural patterns that may span from a single computing resource up to whole data centers (even geographically distributed). In particular, it supports simulating complex distributed architectures containing models of the whole data centers, containers, racks, nodes, etc. In addition, new resources and distributed computing entities can easily be added to the DCworms environment in order to enhance the functionality of the tool and address more sophisticated requirements. Granularity of such topologies may also differ from coarse-grained to very fine-grained modeling single cores, memory hierarchies and other hardware details.
@@ -352,5 +350,5 @@
 Power function may depend on load and states of resources or even specific applications as explained in Section~\ref{sec:power}. Total energy can be also completed by adding constant power usage of components that does not depend on load or state of resources. 
 
-In large computing systems which are often characterized by high computational density, total energy consumption of computing nodes is not the only result interesting for researchers. Temperature distribution is getting more and more important as it affects energy consumption of cooling devices, which can reach even half of a total data center energy use. In order to obtain accurate values of temperatures heat transfer simulations based on the Computational Fluid Dynamics (CFD) methods  have to be performed. These methods require as an input (i.e. boundary conditions) a heat dissipated by IT hardware and air throughput generated by fans at servers' outlets. Another approach is based on simplified thermal models that without costly CFD calculations provide rough estimations of temperatures. DCworms enables the use of both approaches. In the former, the output of simulations including power usage of computing nodes in time and air throughput at node outlets can be passed to CFD solver. Details addressing this integration issues are introduced in \cite{d2.2}.
+In large computing systems which are often characterized by high computational density, total energy consumption of computing nodes is not the only result interesting for researchers. Temperature distribution is getting more and more important as it affects the energy consumption of cooling devices, which can reach even half of a total data center energy use. In order to obtain accurate values of temperatures heat transfer simulations based on the Computational Fluid Dynamics (CFD) methods  have to be performed. These methods require as an input (i.e. boundary conditions) a heat dissipated by IT hardware and air throughput generated by fans at servers' outlets. Another approach is based on simplified thermal models that without costly CFD calculations provide rough estimations of temperatures. DCworms enables the use of both approaches. In the former, the output of simulations including power usage of computing nodes in time and air throughput at node outlets can be passed to CFD solver. Details addressing this integration issues are introduced in \cite{d2.2}.
 %This option is further elaborated in Section \ref{sec:coolemall}. Simplified thermal models required by the latter approach are proposed in \ref{sec:thermal}.
 
@@ -720,5 +718,5 @@
 
 \subsection{Discussion}
-The following tables Table~\ref{loadEnergy} and Table~\ref{loadMakespan} contain the values of evaluation criteria (total energy usage and makespan respectively) gathered for all investigated workloads.
+The following tables: Table~\ref{loadEnergy} and Table~\ref{loadMakespan} contain the values of evaluation criteria (total energy usage and makespan respectively) gathered for all investigated workloads.
 
 \begin {table}[h!]
@@ -755,4 +753,5 @@
 
 Referring to the Table~\ref{loadEnergy}, one should easily note that gain from switching off unused nodes decreases with the increasing workload density. In general, for the highly loaded system such policy does not find an application due to the cost related to this process and relatively small benefits. Another interesting conclusion, refers to the poor result for Random strategy with downgrading the frequency approach. The lack of improvement on the energy usage criterion for higher system load can be explained by the relatively small or no benefit obtained for prolonging the task execution, and thus, maintaining the node in working state. The cost of longer workload completion can not be compensate by the very little energy savings derived from the lower operating state of node. The greater criteria values for the higher system load are the result of greater time space between submission of successive tasks, and thus longer workload execution. Based on Table~\ref{loadMakespan}, one should note that differences in workload completion times are relatively small for all evaluated policies, except Random + lowest frequency approach.
+
 We also demonstrated differences between power usage models. They span from rough static approach to accurate application specific models. However, the latter can be difficult or even infeasible to use, as it requires real measurements for specific applications beforehand. This issue can be partially resolved by introducing application profiles and classification, which can deteriorate the accuracy though. This issue is begin studied more deeply within CoolEmAll project. 
 
@@ -829,7 +828,4 @@
 \bibitem{CloudSim} R. N. Calheiros, R. Ranjan, A. Beloglazov, C. A. F. De Rose, R. Buyya. CloudSim: A Toolkit for Modeling and Simulation of Cloud Computing Environments and Evaluation of Resource Provisioning Algorithms, Software: Practice and Experience (SPE), Volume 41, Number 1, Pages: 23-50, ISSN: 0038-0644, Wiley Press, New York, USA, January, 2011.
 
-Modeling Data Center Building Blocks for Energy-efficiency and Thermal Simulations.
-Micha Vor Dem Berge, Georges Da Costa, Mateusz Jarus, Ariel Oleksiak, Wojciech PiÄ
-tek and Eugen Volk
 \bibitem{DCSG} http://dcsg.bcs.org/welcome-dcsg-simulator
 
