Fix an example dependency problem and fix some paths in the documentation

This commit is contained in:
Mitch Watrous
2011-05-06 13:21:20 -07:00
parent 8059489a88
commit e0c73e34f2
13 changed files with 41 additions and 38 deletions

View File

@@ -149,12 +149,12 @@ alternative way to run distributed examples is shown below:::
./waf shell
cd build/debug
mpirun -np 2 examples/mpi/simple-distributed
mpirun -np 2 src/mpi/examples/simple-distributed
Creating custom topologies
++++++++++++++++++++++++++
The example programs in examples/mpi give a good idea of how to create different
The example programs in src/mpi/examples give a good idea of how to create different
topologies for distributed simulation. The main points are assigning system ids
to individual nodes, creating point-to-point links where the simulation should
be divided, and installing applications only on the LP associated with the

View File

@@ -141,8 +141,8 @@ to these other net devices:::
EmuHelper::EnablePcapAll ("emu-udp-echo-client");
To see an example of a client script using the ``Emu`` net device, see
``examples/emu-udp-echo-client.cc`` and ``examples/emu-udp-echo-server.cc``
For examples that use the ``Emu`` net device, see
``src/emu/examples/emu-udp-echo.cc`` and ``src/emu/examples/emu-ping.cc``
in the repository `<http://code.nsnam.org/craigdo/ns-3-emu/>`_.
Implementation

View File

@@ -7,13 +7,13 @@ Energy consumption is a key issue for wireless devices, and wireless network res
Model Description
=================
The source code for the Energy Framework is currently at: ``src/contrib/energy``.
The source code for the Energy Framework is currently at: ``src/energy``.
Design
******
The ns-3 Energy Framework is composed of 2 parts: Energy Source and Device Energy Model.
The framework will be implemented into the ``src/contrib/energy/models`` folder.
The framework will be implemented into the ``src/energy/models`` folder.
Energy Source
#############
@@ -59,7 +59,7 @@ References
Usage
=====
The main way that ns-3 users will typically interact with the Energy Framework is through the helper API and through the publicly visible attributes of the framework. The helper API is defined in ``src/contrib/energy/helper/*.h``.
The main way that ns-3 users will typically interact with the Energy Framework is through the helper API and through the publicly visible attributes of the framework. The helper API is defined in ``src/energy/helper/*.h``.
In order to use the energy framework, the user must install an Energy Source for the node of interest and the corresponding Device Energy Model for the network devices. Energy Source (objects) are aggregated onto each node by the Energy Source Helper. In order to allow multiple energy sources per node, we aggregate an Energy Source Container rather than directly aggregating a source object.
@@ -69,7 +69,9 @@ The Energy Source object also keeps a list of Device Energy Model objects using
Examples
********
The example ``examples/energy/`` contain some basic code that shows how to set up the framework.
The example directories, ``src/examples/energy`` and
``examples/energy``, contain some basic code that shows how to set up
the framework.
Helpers
*******

View File

@@ -3,6 +3,7 @@ Flow Monitor
*Placeholder chapter*
This feature was added as contributed code (``src/contrib``) in *ns-3.6* and to
the main distribution for *ns-3.7*. A paper on this feature is published in the
proceedings of NSTools: `<http://www.nstools.org/techprog.shtml>`_.
This feature was added as contributed code (``src/contrib``) in
*ns-3.6* and to the main distribution (``src/flow-monitor``) for
*ns-3.7*. A paper on this feature is published in the proceedings of
NSTools: `<http://www.nstools.org/techprog.shtml>`_.

View File

@@ -21,7 +21,7 @@ Model Description
*****************
The source code for the LTE models lives in the directory
``src/devices/lte``.
``src/lte``.
Design
======
@@ -249,16 +249,16 @@ The main way that users who write simulation scripts will typically
interact with the LTE models is through the helper API and through
the publicly visible attributes of the model.
The helper API is defined in ``src/devices/lte/helper/lte-helper.h``.
The helper API is defined in ``src/lte/helper/lte-helper.h``.
The example ``src/devices/lte/examples/`` contain some basic
The example ``src/lte/examples/`` contain some basic
code that shows how to set up the model in order to simualte an
E-UTRAN downlink transmission.
Examples
========
``src/devices/lte/examples/lte-device.cc`` shows how it is possible to set up the LTE module::
``src/lte/examples/lte-device.cc`` shows how it is possible to set up the LTE module::
NodeContainer ueNodes;
NodeContainer enbNodes;
@@ -352,7 +352,7 @@ Caveats
Validation
**********
In the ``src/devices/lte/example/lte-amc.cc`` has been developed an important example
In the ``src/lte/example/lte-amc.cc`` has been developed an important example
that shows the proper functioning of both AMC module and Channel model.
The analyzed scenario is composed by two nodes: a eNB and a single UE
(registered to the eNB). The UE moves into the cell using the

View File

@@ -174,7 +174,7 @@ sort, it makes sense to put it into the ``src/`` directory somewhere,
particularly for ease of integrating with the build system.
In the case of the error model, it is very related to the packet class, so it
makes sense to implement this in the ``src/common/`` directory where |ns3|
makes sense to implement this in the ``src/network/model/`` directory where |ns3|
packets are implemented.
waf and wscript
@@ -186,7 +186,7 @@ want to integrate your new source files into this system. This requires that you
add your files to the ``wscript`` file found in each directory.
Let's start with empty files error-model.h and error-model.cc, and add this to
``src/common/wscript``. It is really just a matter of adding the .cc file to the
``src/network/wscript``. It is really just a matter of adding the .cc file to the
rest of the source files, and the .h file to the list of the header files.
Now, pop up to the top level directory and type "./waf --check". You
@@ -304,8 +304,8 @@ from class Object.::
A few things to note here. We need to include ``object.h``. The convention in
|ns3| is that if the header file is co-located in the same directory, it may be
included without any path prefix. Therefore, if we were implementing ErrorModel
in ``src/core`` directory, we could have just said "``#include "object.h"``".
But we are in ``src/common``, so we must include it as "``#include
in ``src/core/model`` directory, we could have just said "``#include "object.h"``".
But we are in ``src/network/model``, so we must include it as "``#include
"ns3/object.h"``". Note also that this goes outside the namespace declaration.
Second, each class must implement a static public member function called

View File

@@ -60,8 +60,8 @@ perspective. Users just need to set the attribute
GlobalValue::Bind ("SimulatorImplementationType",
StringValue ("ns3::RealtimeSimulatorImpl"));
There is a script in ``examples/realtime-udp-echo.cc`` that has an example of
how to configure the realtime behavior. Try: ::
There is a script in ``examples/realtime/realtime-udp-echo.cc`` that
has an example of how to configure the realtime behavior. Try: ::
./waf --run realtime-udp-echo

View File

@@ -267,7 +267,7 @@ Optimized Link State Routing (OLSR)
+++++++++++++++++++++++++++++++++++
This IPv4 routing protocol was originally ported from the OLSR-UM implementation
for ns-2. The implementation is found in the src/routing/olsr directory, and an
for ns-2. The implementation is found in the src/olsr directory, and an
example script is in examples/simple-point-to-point-olsr.cc.
Typically, OLSR is enabled in a main program by use of an OlsrHelper class that

View File

@@ -8,4 +8,4 @@ Statistics
This wiki page: `This wiki page
<http://www.nsnam.org/wiki/index.php/Statistical_Framework_for_Network_Simulation>`_
contains information about the proposed statistical framework that is located in
``src/contrib`` directory.
``src/stats`` directory.

View File

@@ -12,7 +12,7 @@ Model Description
*****************
The source code for the UAN Framework lives in the directory
``src/devices/uan``, ``src/devices/uan/auv`` and in ``src/contrib/energy`` for the contribution on
``src/uan`` and in ``src/energy`` for the contribution on
the li-ion battery model.
The UAN Framework is composed of two main parts:
@@ -26,7 +26,7 @@ As enabling component for the energy models, a Li-Ion batteries energy source ha
Design
======
The development of the UAN Framework for ns-3 is composed by three consecutive steps. The first one is the development of the AUV simulator, the second one is the development of the UAN energy models and the third one is the integration of such components with the existing modules, UAN module and Energy Model. The module is implemented into the ``/src/contrib/uan`` folder for the part regarding acoustic modem energy model and in ``/src/contrib/uan/auv`` for the part regarding the AUV simulator.
The development of the UAN Framework for ns-3 is composed by three consecutive steps. The first one is the development of the AUV simulator, the second one is the development of the UAN energy models and the third one is the integration of such components with the existing modules, UAN module and Energy Model. The module is implemented into the ``/src/uan`` folder for the part regarding acoustic modem energy model and the part regarding the AUV simulator.
AUV mobility models
@@ -198,10 +198,10 @@ The main way that users who write simulation scripts will typically
interact with the UAN Framework is through the helper API and through
the publicly visible attributes of the model.
The helper API is defined in ``src/devices/uan/helper/acoustic-modem-energy-model-helper.{cc,h}`` and in ``/src/devices/uan/auv/helper/...{cc,h}``.
The helper API is defined in ``src/uan/helper/acoustic-modem-energy-model-helper.{cc,h}`` and in ``/src/uan/helper/...{cc,h}``.
The example folder ``src/devices/uan/auv/examples/`` contain some basic code that shows how to set up and use the models.
further examples can be found into the Unit tests in ``src/devices/uan/auv/test/...cc``
The example folder ``src/uan/examples/`` contain some basic code that shows how to set up and use the models.
further examples can be found into the Unit tests in ``src/uan/test/...cc``
Examples
========
@@ -363,7 +363,7 @@ Auv Energy Model
================
Includes test cases for single packet energy consumption, energy depletion, Glider and REMUS energy consumption.
The unit test can be found in ``src/devices/uan/auv/test/auv-energy-model-test.cc``.
The unit test can be found in ``src/uan/test/auv-energy-model-test.cc``.
The single packet energy consumption test do the following:
@@ -395,7 +395,7 @@ Auv Mobility
============
Includes test cases for glider and REMUS mobility models.
The unit test can be found in ``src/devices/uan/auv/test/auv-mobility-test.cc``.
The unit test can be found in ``src/uan/test/auv-mobility-test.cc``.
* create a node with glider capabilities
* set a specified velocity vector and verify if the resulting buoyancy is the one that is supposed to be
@@ -415,7 +415,7 @@ Li-Ion Energy Source
====================
Includes test case for Li-Ion energy source.
The unit test can be found in ``src/contrib/energy/test/li-ion-energy-source-test.cc``.
The unit test can be found in ``src/energy/test/li-ion-energy-source-test.cc``.
The test case verify that after a well-known discharge time with constant current drain, the cell voltage has followed the datasheet discharge curve [9].

View File

@@ -77,7 +77,7 @@ attributes of the model.
The helper API is defined in ``src/helper/wimax-helper.{cc,h}``.
The example ``examples/wimax/wimax-simple.cc`` contains some basic code that
The example ``src/wimax/examples/wimax-simple.cc`` contains some basic code that
shows how to set up the model:::
switch (schedType)
@@ -116,7 +116,7 @@ created. The helper method ``Install`` allows the user to specify the scheduler
type, the physical layer type, and the device type.
Different variants of ``Install`` are available; for instance, the example
``examples/wimax/wimax-multicast.cc`` shows how to specify a non-default channel
``src/wimax/examples/wimax-multicast.cc`` shows how to specify a non-default channel
or propagation model:::
channel = CreateObject<SimpleOfdmWimaxChannel> ();
@@ -133,13 +133,13 @@ or propagation model:::
scheduler);
Mobility is also supported in the same way as in Wifi models; see the
``examples/wimax/wimax-multicast.cc``.
``src/wimax/examples/wimax-multicast.cc``.
Another important concept in WiMAX is that of a service flow. This is a
unidirectional flow of packets with a set of QoS parameters such as traffic
priority, rate, scheduling type, etc. The base station is responsible for
issuing service flow identifiers and mapping them to WiMAX connections. The
following code from ``examples/wimax/wimax-multicast.cc`` shows how this is
following code from ``src/wimax/examples/wimax-multicast.cc`` shows how this is
configured from a helper level:::
ServiceFlow MulticastServiceFlow = wimax.CreateServiceFlow (ServiceFlow::SF_DIRECTION_DOWN,

View File

@@ -408,7 +408,7 @@ in the following code,
::
int
int
main (int argc, char *argv[])
{
...

View File

@@ -10,7 +10,7 @@ def build(bld):
obj.source = 'tcp-nsc-lfn.cc'
obj = bld.create_ns3_program('tcp-nsc-zoo',
['csma', 'internet'])
['csma', 'internet', 'applications'])
obj.source = 'tcp-nsc-zoo.cc'
obj = bld.create_ns3_program('tcp-star-server',