Commit e72f23ec authored by Philip Carns's avatar Philip Carns

misc edits

parent dda26107
...@@ -171,7 +171,7 @@ xleftmargin=6ex ...@@ -171,7 +171,7 @@ xleftmargin=6ex
\begin{abstract} \begin{abstract}
This document outlines best practices for developing models in the This document outlines best practices for developing models in the
CODES/ROSS framework. The reader should already be familiar with ROSS CODES/ROSS framework. The reader should already be familiar with ROSS
and discrete event simulation; those topics are covered in the primary and discrete event simulation in general; those topics are covered in the primary
ROSS documentation. ROSS documentation.
% %
The main purpose of this document is to help the reader produce The main purpose of this document is to help the reader produce
...@@ -227,6 +227,18 @@ card and disk resources for accurate modeling of resource usage. They key ...@@ -227,6 +227,18 @@ card and disk resources for accurate modeling of resource usage. They key
reason for splitting them up is to simplify the model and to encourage reason for splitting them up is to simplify the model and to encourage
reuse. reuse.
One hypothetical downside to splitting up models into multiple LP types is that it likely
means that your model will generate more events than a monolithic model
would have. Remember that \emph{ROSS is really efficient at generating and
processing events}, though! It is usually a premature optimization to try to optimize a model by
replacing events with function calls in cases where you know the necessary
data is available on the local MPI process. Also recall that any information
exchanged via event automatically benefits by shifting burden for
tracking/retaining event data and event ordering into ROSS rather than your
model. This can help simplify reverse computation by breaking complex
operations into smaller, easier to understand (and reverse) event units with
deterministic ordering.
TODO: reference example, for now see how the LPs are organized in Triton TODO: reference example, for now see how the LPs are organized in Triton
model. model.
...@@ -234,17 +246,19 @@ model. ...@@ -234,17 +246,19 @@ model.
Once you have organized a model into separate LP types, it is tempting to Once you have organized a model into separate LP types, it is tempting to
transfer information between them by directly sending events to an LP or by transfer information between them by directly sending events to an LP or by
modifying the state of an LP from a different LP type. This approach entangles the LP types, modifying the state of an LP from a different LP type. This approach
however, so that each LP type is dependent upon how the other is entangles the components,
implemented. If you change one LP then you have to take care that you don't however, such that one LP is dependent upon the internal architecture of
another LP. If you change one LP then you have to take care that you don't
break assumptions in other LPs that use their event or state structures. This causes break assumptions in other LPs that use their event or state structures. This causes
problems for reuse. It also means (even if you don't plan to reuse an problems for reuse. It also means (even if you don't plan to reuse an
LP) that incompatibilities will be difficult to detect at compile time; the LP) that incompatibilities will be difficult to detect at compile time; the
compiler has no way to know which fields in a struct must be set before compiler has no way to know which fields in a struct must be set before
sending an event. sending an event. Event structures are not a good public API for exchanging
information between different LP types.
For these reasons we encourage that all event struct and state struct For these reasons we encourage that all event structs and state structs
definitions be defined only within the .c file that implements the LP that be defined (and accessible) only within source file for the LP that
must use those structs. They should not be exposed in external must use those structs. They should not be exposed in external
headers. If the definitions are placed in a header then it makes it headers. If the definitions are placed in a header then it makes it
possible for those event and state structs to be used as an ad-hoc interface possible for those event and state structs to be used as an ad-hoc interface
...@@ -282,7 +296,8 @@ TODO: pull in Misbah's codes-mapping documentation. ...@@ -282,7 +296,8 @@ TODO: pull in Misbah's codes-mapping documentation.
TODO: fill this in. Modelnet is a network abstraction layer for use in TODO: fill this in. Modelnet is a network abstraction layer for use in
CODES models. It provides a consistent API that can be used to send CODES models. It provides a consistent API that can be used to send
messages between nodes using a variety of different network transport messages between nodes using a variety of different network transport
models. models. Note that modelnet requires the use of the codes-mapping API,
described in previous section.
\subsection{lp-io} \subsection{lp-io}
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment