singa-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From wang...@apache.org
Subject svn commit: r1703880 [1/2] - in /incubator/singa/site/trunk/content: ./ markdown/ markdown/develop/ markdown/docs/
Date Fri, 18 Sep 2015 15:10:59 GMT
Author: wangwei
Date: Fri Sep 18 15:10:58 2015
New Revision: 1703880

URL: http://svn.apache.org/viewvc?rev=1703880&view=rev
Log:
update the content of rbm and rnn examples; reformat links in some pages.

Modified:
    incubator/singa/site/trunk/content/markdown/develop/schedule.md
    incubator/singa/site/trunk/content/markdown/docs.md
    incubator/singa/site/trunk/content/markdown/docs/architecture.md
    incubator/singa/site/trunk/content/markdown/docs/checkpoint.md
    incubator/singa/site/trunk/content/markdown/docs/cnn.md
    incubator/singa/site/trunk/content/markdown/docs/communication.md
    incubator/singa/site/trunk/content/markdown/docs/debug.md
    incubator/singa/site/trunk/content/markdown/docs/installation.md
    incubator/singa/site/trunk/content/markdown/docs/layer.md
    incubator/singa/site/trunk/content/markdown/docs/neural-net.md
    incubator/singa/site/trunk/content/markdown/docs/param.md
    incubator/singa/site/trunk/content/markdown/docs/programmer-guide.md
    incubator/singa/site/trunk/content/markdown/docs/quick-start.md
    incubator/singa/site/trunk/content/markdown/docs/rbm.md
    incubator/singa/site/trunk/content/markdown/docs/rnn.md
    incubator/singa/site/trunk/content/markdown/docs/updater.md
    incubator/singa/site/trunk/content/markdown/index.md
    incubator/singa/site/trunk/content/site.xml

Modified: incubator/singa/site/trunk/content/markdown/develop/schedule.md
URL: http://svn.apache.org/viewvc/incubator/singa/site/trunk/content/markdown/develop/schedule.md?rev=1703880&r1=1703879&r2=1703880&view=diff
==============================================================================
--- incubator/singa/site/trunk/content/markdown/develop/schedule.md (original)
+++ incubator/singa/site/trunk/content/markdown/develop/schedule.md Fri Sep 18 15:10:58 2015
@@ -3,7 +3,7 @@
 
 | Release | Module| Feature | Status |
 |---------|---------|-------------|--------|
-| 0.1 August    | Neural Network |1.1. Feed forward neural network, including CNN, MLP | done|
+| 0.1 September    | Neural Network |1.1. Feed forward neural network, including CNN, MLP | done|
 | |          |1.2. RBM-like model, including RBM | testing|
 |         |                |1.3. Recurrent neural network, including standard RNN | working|
 |         | Architecture   |1.4. One worker group on single node (with data partition)| done|

Modified: incubator/singa/site/trunk/content/markdown/docs.md
URL: http://svn.apache.org/viewvc/incubator/singa/site/trunk/content/markdown/docs.md?rev=1703880&r1=1703879&r2=1703880&view=diff
==============================================================================
--- incubator/singa/site/trunk/content/markdown/docs.md (original)
+++ incubator/singa/site/trunk/content/markdown/docs.md Fri Sep 18 15:10:58 2015
@@ -1,21 +1,23 @@
 # Documentation
 
-* [Introduction](http://singa.incubator.apache.org/docs/overview)
-* [Installation](http://singa.incubator.apache.org/docs/installation)
-* [Quick Start](http://singa.incubator.apache.org/docs/quick-start)
-* [Programming Guide](http://singa.incubator.apache.org/docs/programming-guide)
-  * [NeuralNet](http://singa.incubator.apache.org/docs/neural-net)
-    * [Layer](http://singa.incubator.apache.org/docs/layer)
-    * [Param](http://singa.incubator.apache.org/docs/param)
-  * [TrainOneBatch](http://singa.incubator.apache.org/docs/train-one-batch)
-  * [Updater](http://singa.incubator.apache.org/docs/updater)
-* [Distributed Training](http://singa.incubator.apache.org/docs/distributed-training)
-* [Data Preparation](http://singa.incubator.apache.org/docs/data)
-* [Checkpoint and Resume](http://singa.incubator.apache.org/docs/checkpoint)
-* [Examples](http://singa.incubator.apache.org/docs/examples.html)
-  * Feed-forward models
-    * [CNN](http://singa.incubator.apache.org/docs/cnn)
-    * [MLP](http://singa.incubator.apache.org/docs/mlp)
-  * [RBM + Auto-encoder](http://singa.incubator.apache.org/docs/rbm)
-  * [RNN](http://singa.incubator.apache.org/docs/rnn)
+---
+
+* [Introduction](docs/overview.html)
+* [Installation](docs/installation.html)
+* [Quick Start](docs/quick-start.html)
+* [Programming Guide](docs/programming-guide.html)
+    * [NeuralNet](docs/neural-net.html)
+        * [Layer](docs/layer.html)
+        * [Param](docs/param.html)
+    * [TrainOneBatch](docs/train-one-batch.html)
+    * [Updater](docs/updater.html)
+* [Distributed Training](docs/distributed-training.html)
+* [Data Preparation](docs/data.html)
+* [Checkpoint and Resume](docs/checkpoint.html)
+* [Examples](docs/examples.html)
+    * Feed-forward models
+        * [CNN](docs/cnn.html)
+        * [MLP](docs/mlp.html)
+    * [RBM + Auto-encoder](docs/rbm.html)
+    * [RNN](docs/rnn.html)
 

Modified: incubator/singa/site/trunk/content/markdown/docs/architecture.md
URL: http://svn.apache.org/viewvc/incubator/singa/site/trunk/content/markdown/docs/architecture.md?rev=1703880&r1=1703879&r2=1703880&view=diff
==============================================================================
--- incubator/singa/site/trunk/content/markdown/docs/architecture.md (original)
+++ incubator/singa/site/trunk/content/markdown/docs/architecture.md Fri Sep 18 15:10:58 2015
@@ -1,6 +1,8 @@
 # SINGA Architecture
 
-### Logical Architecture
+---
+
+## Logical Architecture
 
 <img src="http://singa.incubator.apache.org/assets/image/logical.png" style="width: 550px"/>
 <p><strong> Fig.1 - Logical system architecture</strong></p>
@@ -36,7 +38,7 @@ within a group:
   * [**Hybrid parallelism**](). SINGA also supports hybrid parallelism.
 
 
-### Implementation
+## Implementation
 In SINGA, servers and workers are execution units running in separate threads.
 They communicate through [messages](http://singa.incubator.apache.org/docs/communication.html).
 Every process runs the main thread as a stub that aggregates local messages

Modified: incubator/singa/site/trunk/content/markdown/docs/checkpoint.md
URL: http://svn.apache.org/viewvc/incubator/singa/site/trunk/content/markdown/docs/checkpoint.md?rev=1703880&r1=1703879&r2=1703880&view=diff
==============================================================================
--- incubator/singa/site/trunk/content/markdown/docs/checkpoint.md (original)
+++ incubator/singa/site/trunk/content/markdown/docs/checkpoint.md Fri Sep 18 15:10:58 2015
@@ -1,5 +1,7 @@
 # CheckPoint
 
+---
+
 SINGA checkpoints model parameters onto disk periodically according to user
 configured frequency. By checkpointing model parameters, we can
 
@@ -21,12 +23,17 @@ Checkpointing is controlled by two confi
 For example,
 
     # job.conf
-    workspace: "WORKSPACE"
     checkpoint_after: 100
     checkpoint_frequency: 300
     ...
 
 Checkpointing files are located at *WORKSPACE/checkpoint/stepSTEP-workerWORKERID.bin*.
+*WORKSPACE* is configured in
+
+    cluster {
+      workspace:
+    }
+
 For the above configuration, after training for 700 steps, there would be
 two checkpointing files,
 
@@ -61,33 +68,3 @@ partitioning, all the checkpointing file
 The training command is the same as starting a new job,
 
     ./bin/singa-run.sh -conf JOB_CONF
-
-{% comment %}
-## Advanced user guide
-
-Checkpointing is done in the [Worker class](http://singa.incubator.apache.org/api/classsinga_1_1Worker.html).
-Only `Param`s from the first group are dumped into
-checkpointing files. For a `Param` object, its name, version and values are saved.
-It is possible that the snapshot is separated
-into multiple files because the neural net is partitioned into multiple workers.
-
-The Worker's `InitLocalParam` function will initialize parameters from checkpointing files if the
-`checkpoint` field is set. Otherwise it randomly initialize them using user
-configured initialization method. The `Param` objects are matched based on name.
-If a `Param` object is not configured with a name, `NeuralNet` class will automatically
-create one for it based on the name of the layer.
-The `checkpoint` can be set by users (Application 1) or by the `Resume` function
-(Application 2) of the Trainer class, which finds the files for the latest
-snapshot and add them to the `checkpoint` filed. It also sets the `step` field
-of model configuration to the checkpoint step (extracted from file name).
-
-
-### Caution
-
-Both two applications must be taken carefully when `Param` objects are
-partitioned due to model partitioning. Because if the training is done using 2
-workers, while the new model (or continue training) is trained with 3 workers,
-then the same original `Param` object is partitioned in different ways and hence
-cannot be matched.
-
-{% endcomment %}

Modified: incubator/singa/site/trunk/content/markdown/docs/cnn.md
URL: http://svn.apache.org/viewvc/incubator/singa/site/trunk/content/markdown/docs/cnn.md?rev=1703880&r1=1703879&r2=1703880&view=diff
==============================================================================
--- incubator/singa/site/trunk/content/markdown/docs/cnn.md (original)
+++ incubator/singa/site/trunk/content/markdown/docs/cnn.md Fri Sep 18 15:10:58 2015
@@ -1,5 +1,7 @@
 # CNN Example
 
+---
+
 Convolutional neural network (CNN) is a type of feed-forward artificial neural
 network widely used for image and video classification. In this example, we will
 use a deep CNN model to do image classification for the

Modified: incubator/singa/site/trunk/content/markdown/docs/communication.md
URL: http://svn.apache.org/viewvc/incubator/singa/site/trunk/content/markdown/docs/communication.md?rev=1703880&r1=1703879&r2=1703880&view=diff
==============================================================================
--- incubator/singa/site/trunk/content/markdown/docs/communication.md (original)
+++ incubator/singa/site/trunk/content/markdown/docs/communication.md Fri Sep 18 15:10:58 2015
@@ -1,5 +1,7 @@
 # Communication
 
+---
+
 Different messaging libraries has different benefits and drawbacks. For instance,
 MPI provides fast message passing between GPUs (using GPUDirect), but does not
 support fault-tolerance well. On the contrary, systems using ZeroMQ can be
@@ -26,7 +28,7 @@ background threads running the worker an
 thread forwards messages among threads . The worker and
 server tasks are performed by the background threads.
 
-### Message
+## Message
 
 <object type="image/svg+xml" style="width: 100px" data="../images/msg.svg" > Not
 supported </object>
@@ -246,16 +248,16 @@ helper functions, shown as below.
     }
 
 
-### Socket
+## Socket
 
-In Singa, there are two types of sockets, the Dealer Socket and the Router
+In SINGA, there are two types of sockets, the Dealer Socket and the Router
 Socket, whose names are adapted from ZeroMQ. All connections are of the same type, i.e.,
 Dealer<-->Router. The communication between dealers and routers are
 asynchronous. In other words, one Dealer
 socket can talk with multiple Router sockets, and one Router socket can talk
 with multiple Dealer sockets.
 
-#### Base Socket
+### Base Socket
 
 The basic functions of a Singa Socket is to send and receive messages. The APIs
 are:
@@ -314,7 +316,7 @@ for sending and receiving messages. The
     };
 
 
-#### Dealer Socket
+### Dealer Socket
 
 The Dealer socket inherits from the base Socket. In Singa, every Dealer socket
 only connects to one Router socket as shown in Fig.1.  The connection is set up
@@ -347,7 +349,7 @@ by connecting the Dealer socket to the e
       void* InternalID() const override;
     };
 
-#### Router Socket
+### Router Socket
 
 The Router socket inherits from the base Socket. One Router socket connects to
 at least one Dealer socket. Upon receiving a message, the router forwards it to
@@ -386,9 +388,9 @@ the appropriate dealer according to the
 
     };
 
-### Implementation
+## Implementation
 
-#### ZeroMQ
+### ZeroMQ
 
 **Why [ZeroMQ](http://zeromq.org/)?** Our previous design used MPI for
 communication between Singa processes. But MPI is a poor choice when it comes
@@ -415,7 +417,7 @@ destination dealer.
 Besides the DEALER-ROUTER pattern, we may also implement the Dealer socket and
 Router socket using other ZeroMQ patterns. To be continued.
 
-#### MPI
+### MPI
 
 Since MPI does not provide intra-process communication, we have to implement
 it inside the Router and Dealer socket. A simple solution is to allocate one
@@ -449,78 +451,3 @@ similar architecture as [Fig.2](architec
 where every process has a server group and is connected with all other processes.
 Hence, we can implement DeepImage in Singa by simply using MPI's AllReduce function for
 inter-process communication.
-
-{% comment %}
-#### Server socket
-
-Each server has a DEALER socket to communicate with the stub in the main
-thread via an _in-proc_ socket. It receives requests issued from workers and
-other servers, and forwarded by the ROUTER of the stub. Since the requests are forwarded by the
-stub, we can make the location of workers transparent to server threads. The
-stub records the locations of workers and servers.
-
-As explained previously in the [APIs](http://singa.incubator.apache.org{% post_url /docs/2015-03-20-parameter-management %})
-for parameter management, some requests may
-not be processed immediately but have to be re-queued. For instance, the Get
-request cannot be processed if the requested parameter is not available, i.e.,
-the parameter has not been put into the server's ParamShard. The re-queueing
-operation is implemented sendings the messages to the ROUTER
-socket of the stub which treats the message as a newly arrived request
-and queues it for processing.
-
-#### Worker socket
-
-Each worker thread has a DEALER socket to communicate with the stub in the main
-thread via an _in-proc_ socket. It sends (Get/Update) requests to the ROUTER in
-the stub which forwards the request to (local or remote) processes. In case of
-the partition of ParamShard of worker side, it may also transfer data with other
-workers via the DEALER socket. Again, the location of the other side (a server
-or worker) of the communication is transparent to the worker. The stub handles
-the addressing.
-
-PMClient executes the training logic, during which it generates GET and UPDATE
-requests. A request received at the worker's main thread contains ID of the
-PMClient instance. The worker determines which server to send the request based
-on its content, then sends it via the corresponding socket. Response messages
-received from any of the server socket are forwarded to the in-proc ROUTER
-socket. Since each response header contains the PMClient ID, it is routed to
-the correct instance.
-
-#### Stub sockets
-
-##### ROUTER socket
-The main thread has a ROUTER socket to communicate with background threads.
-
-It forwards the requests from workers to background servers. There can be
-multiple servers.If all servers maintain the same (sub) ParamShard, then the
-request can be forwarded to any of them. Load-balance (like round-robin) can be
-implemented in the stub to improve the performance. If each server maintains a
-sub-set of the local ParamShard, then the stub forwards each request to the
-corresponding server.  It also forwards the synchronization requests from
-remote servers to local servers in the same way.
-
-In the case of neural network partition (i.e., model partition), neighbor
-layers would transfer data with each other. Hence, the ROUTER would forwards
-data transfer requests from one worker to other worker. The stub looks up the
-location table to decide where to forward each request.
-
-##### DEALER sockets
-
-The main thread has multiple DEALER sockets to communicate with other
-processes, one socket per process. Two processes are connected if one of the
-following cases exists:
-
-  * one worker group spans across the two processes;
-  * two connected server groups are separated in the two processes;
-  * workers and the subscribed servers are separated in the two processes.
-
-
-All messages in SINGA are of multi-frame ZeroMQ format. The figure above demonstrates different types of messages exchanged in the system.
-
-  1. Requests generated by PMClient consist of the parameter content (which could be empty), followed by the parameter ID (key) and the request type (GET/PUT/REQUEST). Responses received by PMClient are also of this format.
-  2. Messages received by the worker's main thread from PMClient instances contain another frame identifying the PMClient connection (or PMClient ID).
-  3. Requests originating form a worker and arriving at the server contain another frame identifying the worker's connection (or Worker ID).
-  4. Requests originating from another server and arriving at the server have the same format as (3), but the first frame identifies the server connection (or Server ID).
-  5. After a PMServer processes a request, it generates a message with the format similar to (3) but with extra frame indicating if the message is to be routed back to a worker (a response message) or to route to another server (a SYNC request).
-  6. When a request is re-queued, the PMServer generates a message and sends it directly to the server's front-end socket. The re-queued request seen by the server's main thread consists of all the frames in (3), followed by a REQUEUED frame, and finally by another frame generated by the ROUTER socket identifying connection from the PMServer instance. The main thread then strips off these additional two frames before  forwarding it to another PMServer instance like another ordinary request.
-{% endcomment %}

Modified: incubator/singa/site/trunk/content/markdown/docs/debug.md
URL: http://svn.apache.org/viewvc/incubator/singa/site/trunk/content/markdown/docs/debug.md?rev=1703880&r1=1703879&r2=1703880&view=diff
==============================================================================
--- incubator/singa/site/trunk/content/markdown/docs/debug.md (original)
+++ incubator/singa/site/trunk/content/markdown/docs/debug.md Fri Sep 18 15:10:58 2015
@@ -2,24 +2,19 @@
 
 ___
 
-### Compile with -g
-
 Since SINGA is developed on Linux using C++, GDB is the preferred debugging
-tool. To use GDB, the code must be compiled with `-g` flag. The files (e.g.,
-Makefile.am) from GNU compilation tool are not easy to change. Hence SINGA
-comes with a Makefile.example for developers. To compile the code for
-debugging, just
-
-    cp Makefile.example  Makefile
-    #change -O3 to -g for the CXXFLAGS
-    make singa
+tool. To use GDB, the code must be compiled with `-g` flag. This is enabled by
+
+    ./configure --enable-debug
+    make
+
 
 To debug, first start zookeeper if it is not started yet, and launch GDB
 
     # do this for only once
     ./bin/zk-service.sh start
     # do this every time
-    gdb singa
+    gdb ./bin/singa
 
 Then set the command line arguments
 

Modified: incubator/singa/site/trunk/content/markdown/docs/installation.md
URL: http://svn.apache.org/viewvc/incubator/singa/site/trunk/content/markdown/docs/installation.md?rev=1703880&r1=1703879&r2=1703880&view=diff
==============================================================================
--- incubator/singa/site/trunk/content/markdown/docs/installation.md (original)
+++ incubator/singa/site/trunk/content/markdown/docs/installation.md Fri Sep 18 15:10:58 2015
@@ -1,11 +1,12 @@
 # Installation
 
+---
 
-### Dependencies
+## Dependencies
 
 SINGA is developed and tested on Linux platforms.
 
-The following dependenies are required:
+The following dependent libraries are required:
 
   * glog version 0.3.3
 
@@ -22,19 +23,15 @@ The following dependenies are required:
 
 Optional dependencies include:
 
-  * gtest version 1.7.0
-
-  * opencv version 2.4.9
-
   * lmdb version 0.9.10
 
 
-SINGA comes with a script for installing the external libraries (see below).
+SINGA comes with a script for installing the above libraries (see below).
 
-### Building SINGA from source
+## Building SINGA from source
 
 SINGA is built using GNU autotools. GCC (version >= 4.8) is required.
-There are three ways to build SINGA,
+There are two ways to build SINGA,
 
   * If you want to use the latest code, please clone it from
   [Github](https://github.com/apache/incubator-singa.git) and execute
@@ -46,6 +43,9 @@ There are three ways to build SINGA,
         $ ./configure
         $ make
 
+  Note: It is an oversight that we forgot to delete the singa repo under [nusinga](https://github.com/orgs/nusinga)
+  account after we became Apache Incubator project -- the source
+  in that repo was not up to date, and we apologize for any inconvenience.
 
   * If you download a release package, please follow the instructions below,
 
@@ -61,19 +61,20 @@ There are three ways to build SINGA,
         $ ./configure --enable-lmdb
 
 
-  * In case you do not have the GNU auto tools to run `autogen.sh`, SINGA
-  provides a Makefile.example file, which is used as
+The SINGA test is not included by default settings. If you want to run the
+test, please compile with `--enable-test`. You can run:
 
-        $ cp Makefile.example Makefile
-        $ make
 
-    Code depending on lmdb can be added into the compilation by
+    $ ./configure --enable-test
+    $ make
 
-        make -DUSE_LMDB
+After compilation, you will find the binary file singatest. Just run it!
+More details about configure script can be found by running:
 
+		$ ./configure --help
 
-After compiling SINGA successfully, the `libsinga.so` will be generated into
-.lib/ folder and an executable file `singa` is generated under bin/.
+After compiling SINGA successfully, the *libsinga.so* and the executable file
+*singa* will be generated into *.libs/* folder.
 
 If some dependent libraries are missing (or not detected), you can use the
 following script to download and install them:
@@ -83,11 +84,15 @@ following script to download and install
 
 If you do not specify the installation path, the library will be installed in
 the default folder specified by the software itself.  For example, if you want
-to build `zeromq` library in system folder and `gflags` in `/usr/local`, just run:
+to install `zeromq` library in the default system folder, run it as
+
+    $ ./install.sh zeromq
+
+Or, if you want to install it into another folder,
 
-    $ ./install.sh zeromq gflags /usr/local
+    $ ./install.sh zeromq --prefix=YOUR_FOLDER
 
-You can also install all dependencies in `/usr/local` directory:
+You can also install all dependencies in */usr/local* directory:
 
     $ ./install.sh all /usr/local
 
@@ -96,11 +101,9 @@ Here is a table showing the first argume
     MISSING_LIBRARY_NAME  LIBRARIES
     cmake                 cmake tools
     czmq*                 czmq lib
-    gflags                gflags lib
     glog                  glog lib
     lmdb                  lmdb lib
     OpenBLAS              OpenBLAS lib
-    opencv                OpenCV
     protobuf              Google protobuf
     zeromq                zeromq lib
     zookeeper             Apache zookeeper
@@ -109,10 +112,10 @@ Here is a table showing the first argume
 indicate `zeromq` location.
 The installation commands of `czmq` is:
 
-    $./install.sh czmq  /usr/local /usr/local/zeromq
+    $./install.sh czmq /usr/local /usr/local/zeromq
 
-After the execution, `czmq` will be installed in `/usr/local` while `zeromq` is
-installed in `/usr/local/zeromq`.
+After the execution, `czmq` will be installed in */usr/local*. The last path
+specifies the path to zeromq.
 
 ### FAQ
 
@@ -146,7 +149,7 @@ Or as an alternative option, you can als
 Q4:I get `ImportError: cannot import name enum_type_wrapper` from
 google.protobuf.internal when I try to import .py files.
 
-A4:After install google protobuf by "make install", we should install python
+A4:After install google protobuf by `make install`, we should install python
 runtime libraries. Go to protobuf source directory, run:
 
     $ cd /PROTOBUF/SOURCE/FOLDER

Modified: incubator/singa/site/trunk/content/markdown/docs/layer.md
URL: http://svn.apache.org/viewvc/incubator/singa/site/trunk/content/markdown/docs/layer.md?rev=1703880&r1=1703879&r2=1703880&view=diff
==============================================================================
--- incubator/singa/site/trunk/content/markdown/docs/layer.md (original)
+++ incubator/singa/site/trunk/content/markdown/docs/layer.md Fri Sep 18 15:10:58 2015
@@ -1,5 +1,7 @@
 # Layers
 
+---
+
 Layer is a core abstraction in SINGA. It performs a variety of feature
 transformations for extracting high-level features, e.g., loading raw features,
 parsing RGB values, doing convolution transformation, etc.
@@ -12,7 +14,7 @@ implement users' functions.
 
 ### Layer configuration
 
-The configurations of three layers from the [MLP example](http://singa.incubator.apache.org/docs/mlp) is shown below,
+The configurations of three layers from the [MLP example](mlp.html) is shown below,
 
     layer {
       name: "data"
@@ -44,17 +46,17 @@ There are some common fields for all kin
   For user-defined layer subclasses, `user_type` of string should be used instead of `type`.
   The detail is explained in the [last section](#newlayer) of this page.
   * `srclayers`: one or more layer names, for identifying the source layers.
-  In SINGA, all connections are [converted](http://singa.incubator.apache.org/docs/neural-net) to directed connections.
+  In SINGA, all connections are [converted](neural-net.html) to directed connections.
   * `exclude`: an enumerate value of type [Phase](), can be {kTest, kValidation,
   kTrain}. It is used to filter this layer when creating the
-  [NeuralNet](http://singa.incubator.apache.org/docs/neural-net) for the excluding phase. E.g.,
+  [NeuralNet](neural-net.html) for the excluding phase. E.g.,
   the "data" layer would be filtered when creating the NeuralNet instance for test phase.
-  * `param`: configuration for a [Param](http://singa.incubator.apache.org/docs/param) instance.
+  * `param`: configuration for a [Param](param.html) instance.
   There can be multiple Param objects in one layer.
   * `partition_dim`: integer value indicating the partition dimension of this
   layer. -1 (the default value) for no partitioning, 0 for partitioning on batch dimension, 1 for
   partitioning on feature dimension. It is used by
-  [CreateGraph](http://singa.incubator.apache.org/docs/neural-net) for partitioning the neural net.
+  [CreateGraph](neural-net.html) for partitioning the neural net.
 
 Different layers may have different configurations. These configurations
 are defined in `<type>_conf`.  E.g., the "data" layer has `sharddata_conf` and "fc1" layer has
@@ -66,21 +68,28 @@ SINGA has provided many built-in layers,
 These layers are categorized according to their functionalities,
 
   * Data layers for loading records (e.g., images) from [disk], HDFS or network into memory.
-  * Parser layers for parsing features, labels, etc. from records, into [Blob](http://singa.incubator.apache.org/api/classsinga_1_1Blob.html).
-  * Neuron layers for feature transformation, e.g., [convolution](http://singa.incubator.apache.org/api/classsinga_1_1ConvolutionLayer.html), [pooling](http://singa.incubator.apache.org/api/classsinga_1_1PoolingLayer.html), dropout, etc.
+  * Parser layers for parsing features, labels, etc. from records, into [Blob](../api/classsinga_1_1Blob.html).
+  * Neuron layers for feature transformation, e.g., [convolution](../api/classsinga_1_1ConvolutionLayer.html), [pooling](../api/classsinga_1_1PoolingLayer.html), dropout, etc.
   * Loss layers for measuring the training objective loss, e.g., [cross entropy-loss] or [Euclidean loss].
   * Output layers for outputting the prediction results (e.g., probabilities of each category) onto disk or network.
   * Connection layers for connecting layers when the neural net is partitioned.
 
-####Data Layers
+#### Input layers
+
+Input layers load training/test data from disk or other places (e.g., HDFS or network)
+into memory.
+
+##### DataLayer
 
-Data layers load training/testing data and convert them into [Record](http://singa.incubator.apache.org/docs/data)s, which
-are parsed by parser layers. The data source can be disk file, HDFS, database or network.
+DataLayer loads training/testing data as [Record](http://singa.incubator.apache.org/docs/data)s, which
+are parsed by parser layers.
 
 ##### ShardDataLayer
 
-[ShardDataLayer](http://singa.incubator.apache.org/api/classsinga_1_1ShardDataLayer.html) is used to read data from disk file. The file should be created
-using [DataShard](http://singa.incubator.apache.org/api/classsinga_1_1DataShard.html) class. With the data file prepared, users configure the layer as
+[ShardDataLayer](../api/classsinga_1_1ShardDataLayer.html) is a subclass of DataLayer,
+which reads Records from disk file. The file should be created using
+[DataShard](../api/classsinga_1_1DataShard.html)
+class. With the data file prepared, users configure the layer as
 
     type: kShardData
     sharddata_conf {
@@ -105,9 +114,9 @@ loaded from LMDB.
       random_skip: int
     }
 
-#### Parser Layers
+##### ParserLayer
 
-Parser layers get a vector of Records from data layers and parse features into
+It get a vector of Records from DataLayer and parse features into
 a Blob.
 
     virtual void ParseRecords(Phase phase, const vector<Record>& records, Blob<float>* blob) = 0;
@@ -115,12 +124,14 @@ a Blob.
 
 ##### LabelLayer
 
-[LabelLayer](http://singa.incubator.apache.org/api/classsinga_1_1LabelLayer.html) is used to parse a single label from each Record. Consequently, it
+[LabelLayer](../api/classsinga_1_1LabelLayer.html) is a subclass of ParserLayer.
+It parses a single label from each Record. Consequently, it
 will put $b$ (mini-batch size) values into the Blob. It has no specific configuration fields.
 
 
 ##### MnistImageLayer
-[MnistImageLayer] parses the pixel values of each image from the MNIST dataset. The pixel
+[MnistImageLayer] is a subclass of ParserLayer. It parses the pixel values of
+each image from the MNIST dataset. The pixel
 values may be normalized as `x/norm_a - norm_b`. For example, if `norm_a` is
 set to 255 and `norm_b` is set to 0, then every pixel will be normalized into
 [0, 1].
@@ -132,7 +143,8 @@ set to 255 and `norm_b` is set to 0, the
     }
 
 ##### RGBImageLayer
-[RGBImageLayer](http://singa.incubator.apache.org/api/classsinga_1_1RGBImageLayer.html) parses the RGB values of one image from each Record. It may also
+[RGBImageLayer](../api/classsinga_1_1RGBImageLayer.html) is a subclass of ParserLayer.
+It parses the RGB values of one image from each Record. It may also
 apply some transformations, e.g., cropping, mirroring operations. If the
 `meanfile` is specified, it should point to a path that contains one Record for
 the mean of each pixel over all training images.
@@ -147,8 +159,8 @@ the mean of each pixel over all training
 
 #### PrefetchLayer
 
-[PrefetchLayer](http://singa.incubator.apache.org/api/classsinga_1_1PrefetchLayer.html) embeds data layers and parser layers to do data prefeching.
-It will launch a thread to call the data layers and parser layers to load and extract features.
+[PrefetchLayer](../api/classsinga_1_1PrefetchLayer.html) embeds other input layers
+to do data prefeching.  It will launch a thread to call the embedded layers to load and extract features.
 It ensures that the I/O task and computation task can work simultaneously.
 One example PrefetchLayer configuration is,
 
@@ -184,7 +196,7 @@ Neuron layers conduct feature transforma
 
 ##### ConvolutionLayer
 
-[ConvolutionLayer](http://singa.incubator.apache.org/api/classsinga_1_1ConvolutionLayer.html) conducts convolution transformation.
+[ConvolutionLayer](../api/classsinga_1_1ConvolutionLayer.html) conducts convolution transformation.
 
     type: kConvolution
     convolution_conf {
@@ -204,7 +216,7 @@ zeros.
 
 ##### InnerProductLayer
 
-[InnerProductLayer](http://singa.incubator.apache.org/api/classsinga_1_1InnerProductLayer.html) is fully connected with its (single) source layer.
+[InnerProductLayer](../api/classsinga_1_1InnerProductLayer.html) is fully connected with its (single) source layer.
 Typically, it has two parameter fields, one for weight matrix, and the other
 for bias vector. It rotates the feature of the source layer (by multiplying with weight matrix) and
 shifts it (by adding the bias vector).
@@ -219,7 +231,7 @@ shifts it (by adding the bias vector).
 
 ##### PoolingLayer
 
-[PoolingLayer](http://singa.incubator.apache.org/api/classsinga_1_1PoolingLayer.html) is used to do a normalization (or averaging or sampling) of the
+[PoolingLayer](../api/classsinga_1_1PoolingLayer.html) is used to do a normalization (or averaging or sampling) of the
 feature vectors from the source layer.
 
     type: kPooling
@@ -240,12 +252,12 @@ Use the enum AVE and MAX to choose the m
 
 ##### ReLULayer
 
-[ReLuLayer](http://singa.incubator.apache.org/api/classsinga_1_1ReLULayer.html) has rectified linear neurons, which conducts the following
+[ReLuLayer](../api/classsinga_1_1ReLULayer.html) has rectified linear neurons, which conducts the following
 transformation, `f(x) = Max(0, x)`. It has no specific configuration fields.
 
 ##### TanhLayer
 
-[TanhLayer](http://singa.incubator.apache.org/api/classsinga_1_1TanhLayer.html) uses the tanh as activation function, i.e., `f(x)=tanh(x)`.
+[TanhLayer](../api/classsinga_1_1TanhLayer.html) uses the tanh as activation function, i.e., `f(x)=tanh(x)`.
 It has no specific configuration fields.
 
 ##### SigmoidLayer
@@ -255,7 +267,7 @@ It has no specific configuration fields.
 
 
 ##### Dropout Layer
-[DropoutLayer](http://singa.incubator.apache.org/api/asssinga_1_1DropoutLayer.html) is a layer that randomly dropouts some inputs.
+[DropoutLayer](../api/asssinga_1_1DropoutLayer.html) is a layer that randomly dropouts some inputs.
 This scheme helps deep learning model away from over-fitting.
 
     type: kDropout
@@ -264,7 +276,7 @@ This scheme helps deep learning model aw
     }
 
 ##### LRNLayer
-[LRNLayer](http://singa.incubator.apache.org/api/classsinga_1_1LRNLayer.html), (Local Response Normalization), normalizes over the channels.
+[LRNLayer](../api/classsinga_1_1LRNLayer.html), (Local Response Normalization), normalizes over the channels.
 
     type: kLRN
     lrn_conf {
@@ -283,7 +295,7 @@ Loss layers measures the objective train
 
 ##### SoftmaxLossLayer
 
-[SoftmaxLossLayer](http://singa.incubator.apache.org/api/classsinga_1_1SoftmaxLossLayer.html) is a combination of the Softmax transformation and
+[SoftmaxLossLayer](../api/classsinga_1_1SoftmaxLossLayer.html) is a combination of the Softmax transformation and
 Cross-Entropy loss. It applies Softmax firstly to get a prediction probability
 for each output unit (neuron) and compute the cross-entropy against the ground truth.
 It is generally used as the final layer to generate labels for classification tasks.
@@ -297,11 +309,14 @@ The configuration field `topk` is for se
 probabilities as the prediction results. It is tedious for users to view the
 prediction probability of every label.
 
-#### Other Layers
+#### ConnectionLayer
+
+Subclasses of ConnectionLayer are utility layers that connects other layers due
+to neural net partitioning or other cases.
 
 ##### ConcateLayer
 
-[ConcateLayer](http://singa.incubator.apache.org/api/classsinga_1_1ConcateLayer.html) connects more than one source layers to concatenate their feature
+[ConcateLayer](../api/classsinga_1_1ConcateLayer.html) connects more than one source layers to concatenate their feature
 blob along given dimension.
 
     type: kConcate
@@ -311,7 +326,7 @@ blob along given dimension.
 
 ##### SliceLayer
 
-[SliceLayer](http://singa.incubator.apache.org/api/classsinga_1_1SliceLayer.html) connects to more than one destination layers to slice its feature
+[SliceLayer](../api/classsinga_1_1SliceLayer.html) connects to more than one destination layers to slice its feature
 blob along given dimension.
 
     type: kSlice
@@ -321,7 +336,7 @@ blob along given dimension.
 
 ##### SplitLayer
 
-[SplitLayer](http://singa.incubator.apache.org/api/classsinga_1_1SplitLayer.html) connects to more than one destination layers to replicate its
+[SplitLayer](../api/classsinga_1_1SplitLayer.html) connects to more than one destination layers to replicate its
 feature blob.
 
     type: kSplit
@@ -331,11 +346,16 @@ feature blob.
 
 ##### BridgeSrcLayer & BridgeDstLayer
 
-[BridgeSrcLayer](http://singa.incubator.apache.org/api/classsinga_1_1BridgeSrcLayer.html) & [BridgeDstLayer](http://singa.incubator.apache.org/api/classsinga_1_1BridgeDstLayer.html) are utility layers assisting data (e.g., feature or
+[BridgeSrcLayer](../api/classsinga_1_1BridgeSrcLayer.html) &
+[BridgeDstLayer](../api/classsinga_1_1BridgeDstLayer.html) are utility layers assisting data (e.g., feature or
 gradient) transferring due to neural net partitioning. These two layers are
 added implicitly. Users typically do not need to configure them in their neural
 net configuration.
 
+### OutputLayer
+
+It write the prediction results or the extracted features into file, HTTP stream
+or other places. Currently SINGA has not implemented any specific output layer.
 
 ## Advanced user guide
 
@@ -353,19 +373,19 @@ implement a new Layer subclass.
 The base layer class keeps the user configuration in `layer_proto_`. Source
 layers and destination layers are stored in `srclayers_` and `dstlayers_`, respectively.
 Almost all layers has $b$ (mini-batch size) feature vectors, which are stored
-in the `data_` [Blob](http://singa.incubator.apache.org/api/classsinga_1_1Blob.html) (A Blob is a chunk of memory space, proposed in
+in the `data_` [Blob](../api/classsinga_1_1Blob.html) (A Blob is a chunk of memory space, proposed in
 [Caffe](http://caffe.berkeleyvision.org/)).
 There are layers without feature vectors; instead, they use other
 layers' feature vectors. In this case, the `data_` field is not used.
 The `grad_` Blob is for storing the gradients of the
-objective loss w.r.t. the `data_` Blob. It is necessary in [BP algorithm](http://singa.incubator.apache.org/api/classsinga_1_1BPWorker.html),
-hence we put it as a member of the base class. For [CD algorithm](http://singa.incubator.apache.org/api/classsinga_1_1CDWorker.html), the `grad_`
+objective loss w.r.t. the `data_` Blob. It is necessary in [BP algorithm](../api/classsinga_1_1BPWorker.html),
+hence we put it as a member of the base class. For [CD algorithm](../api/classsinga_1_1CDWorker.html), the `grad_`
 field is not used; instead, the layer from RBM may have a Blob for the positive
 phase feature and a Blob for the negative phase feature. For a recurrent layer
 in RNN, the feature blob contains one vector per internal layer.
 
 If a layer has parameters, these parameters are declared using type
-[Param](http://singa.incubator.apache.org/docs/param). Since some layers do not have
+[Param](param.html). Since some layers do not have
 parameters, we do not declare any `Param` in the base layer class.
 
 #### Functions
@@ -384,22 +404,22 @@ layer is a (bottom) data layer, then its
 `b/npartitions` feature vectors; If the source layer is also partitioned on
 dimension 0, then this layer should have the same number of feature vectors as
 the source layer. More complex partition cases are discussed in
-[Neural net partitioning](http://singa.incubator.apache.org/docs/neural-net/#neural-net-partitioning). Typically, the
+[Neural net partitioning](neural-net.html#neural-net-partitioning). Typically, the
 Setup function just set the shapes of `data_` Blobs and Param objects. Memory
 will not be allocated until computation over the data structure happens.
 
 The `ComputeFeature` function evaluates the feature blob by transforming (e.g.
 convolution and pooling) features from the source layers.  `ComputeGradient`
 computes the gradients of parameters associated with this layer.  These two
-functions are invoked by the [TrainOneBatch](http://singa.incubator.apache.org/docs/train-one-batch)
+functions are invoked by the [TrainOneBatch](train-one-batch.html)
 function during training. Hence, they should be consistent with the
 `TrainOneBatch` function. Particularly, for feed-forward and RNN models, they are
-trained using [BP algorithm](http://singa.incubator.apache.org/docs/train-one-batch/#back-propagation),
+trained using [BP algorithm](train-one-batch.html#back-propagation),
 which requires each layer's `ComputeFeature`
 function to compute `data_` based on source layers, and requires each layer's
 `ComputeGradient` to compute gradients of parameters and source layers'
 `grad_`. For energy models, e.g., RBM, they are trained by
-[CD algorithm](http://singa.incubator.apache.org/docs/train-one-batch/#contrastive-divergence), which
+[CD algorithm](train-one-batch.html#contrastive-divergence), which
 requires each layer's `ComputeFeature` function to compute the feature vectors
 for the positive phase or negative phase depending on the `phase` argument, and
 requires the `ComputeGradient` function to only compute parameter gradients.
@@ -409,7 +429,7 @@ displayed periodically.
 
 ### Implementing a new Layer subclass
 
-Users can extend the base layer class to implement their own feature transformation
+Users can extend the Layer class or other subclasses to implement their own feature transformation
 logics as long as the two virtual functions are overridden to be consistent with
 the `TrainOneBatch` function. The `Setup` function may also be overridden to
 read specific layer configuration.
@@ -458,7 +478,7 @@ should be enclosed in brackets.
     layer {
       name: "foo"
       user_type: "kFooLayer"  # Note user_type of user-defined layers is string
-      [singa.foo_conf] {      # Note there is a pair of [] for extension fields
+      [foo_conf] {      # Note there is a pair of [] for extension fields
         a: 10
       }
     }
@@ -467,7 +487,7 @@ should be enclosed in brackets.
 
 The new layer subclass can be implemented like the built-in layer subclasses.
 
-    class FooLayer : public Layer {
+    class FooLayer : public singa::Layer {
      public:
       void Setup(const LayerProto& proto, int npartitions = 1) override;
       void ComputeFeature(Phase phase, Metric* perf) override;
@@ -486,7 +506,6 @@ can be accessed through `layer_proto_` a
 
 The newly defined layer should be registered in [main.cc](http://singa.incubator.apache.org/docs/programming-guide) by adding
 
-    driver.RegisterLayer<FooLayer>("kFooLayer"); // "kFooLayer" should be matched to layer configurations in job.conf.
+    driver.RegisterLayer<FooLayer, std::string>("kFooLayer"); // "kFooLayer" should be matched to layer configurations in job.conf.
 
-After that, the
-[NeuralNet](http://singa.incubator.apache.org/docs/neural-net) can create instances of the new Layer subclass.
+After that, the [NeuralNet](neural-net.html) can create instances of the new Layer subclass.

Modified: incubator/singa/site/trunk/content/markdown/docs/neural-net.md
URL: http://svn.apache.org/viewvc/incubator/singa/site/trunk/content/markdown/docs/neural-net.md?rev=1703880&r1=1703879&r2=1703880&view=diff
==============================================================================
--- incubator/singa/site/trunk/content/markdown/docs/neural-net.md (original)
+++ incubator/singa/site/trunk/content/markdown/docs/neural-net.md Fri Sep 18 15:10:58 2015
@@ -1,5 +1,7 @@
 # Neural Net
 
+---
+
 `NeuralNet` in SINGA represents an instance of user's neural net model. As the
 neural net typically consists of a set of layers, `NeuralNet` comprises
 a set of unidirectionally connected [Layer](http://singa.incubator.apache.org/docs/layer)s.

Modified: incubator/singa/site/trunk/content/markdown/docs/param.md
URL: http://svn.apache.org/viewvc/incubator/singa/site/trunk/content/markdown/docs/param.md?rev=1703880&r1=1703879&r2=1703880&view=diff
==============================================================================
--- incubator/singa/site/trunk/content/markdown/docs/param.md (original)
+++ incubator/singa/site/trunk/content/markdown/docs/param.md Fri Sep 18 15:10:58 2015
@@ -1,5 +1,7 @@
 # Parameters
 
+---
+
 A `Param` object in SINGA represents a set of parameters, e.g., a weight matrix
 or a bias vector. *Basic user guide* describes how to configure for a `Param`
 object, and *Advanced user guide* provides details on implementing users'

Modified: incubator/singa/site/trunk/content/markdown/docs/programmer-guide.md
URL: http://svn.apache.org/viewvc/incubator/singa/site/trunk/content/markdown/docs/programmer-guide.md?rev=1703880&r1=1703879&r2=1703880&view=diff
==============================================================================
--- incubator/singa/site/trunk/content/markdown/docs/programmer-guide.md (original)
+++ incubator/singa/site/trunk/content/markdown/docs/programmer-guide.md Fri Sep 18 15:10:58 2015
@@ -2,103 +2,95 @@
 
 ___
 
-This guide provides instructions of
-implementing a new model and submitting the training job. The programming model
-is made almost transparent to the underlying distributed environment. Hence
-users do not need to worry much about the communication and synchronization of
-nodes, which is discussed in [architecture](architecture.html) in details.
+To submit a training job, users must provide the configuration of the
+four components shown in Figure 1:
 
-### Deep learning training
+  * a [NeuralNet](neural-net.html) describing the neural net structure with the detailed layer setting and their connections;
+  * a [TrainOneBatch](train-one-batch.html) algorithm which is tailored for different model categories;
+  * an [Updater](updater.html) defining the protocol for updating parameters at the server side;
+  * a [Cluster Topology](distributed-training.html) specifying the distributed architecture of workers and servers.
 
-Deep learning is labeled as a feature learning technique, which usually
-consists of multiple layers.  Each layer is associated with a feature transformation
-function. After going through all layers, the raw input feature (e.g., pixels
-of images) would be converted into a high-level feature that is easier for
-tasks like classification.
+The *Basic user guide* section describes how to submit a training job using
+built-in components; while the *Advanced user guide* section presents details
+on writing user's own main function to register components implemented by
+themselves. In addition, the training data must be prepared, which has the same
+[process](data.html) for both advanced users and basic users.
 
-Training a deep learning model is to find the optimal parameters involved in
-the transformation functions that generates good features for specific tasks.
-The goodness of a set of parameters is measured by a loss function, e.g.,
-[Cross-Entropy Loss](https://en.wikipedia.org/wiki/Cross_entropy). Since the
-loss functions are usually non-linear and non-convex, it is difficult to get a
-closed form solution. Normally, people uses the SGD algorithm which randomly
-initializes the parameters and then iteratively update them to reduce the loss.
+<img src="../images/overview.png" align="center" width="400px"/>
+<span><strong>Figure 1 - SINGA overview.</strong></span>
 
 
-### Steps to submit a training job
 
-SINGA uses the stochastic gradient descent (SGD) algorithm to train parameters
-of deep learning models.  For each SGD iteration, there is a
-[Worker](architecture.html) computing gradients of parameters from the
-NeuralNet and a [Updater]() updating parameter values based on gradients. SINGA
-has implemented three algorithms for gradient calculation, namely Back
-propagation algorithm for feed-forward models, back-propagation through time
-for recurrent neural networks and contrastive divergence for energy models like
-RBM and DBM. Variant SGD updaters are also provided, including
-[AdaDelta](http://arxiv.org/pdf/1212.5701v1.pdf),
-[AdaGrad](http://www.magicbroom.info/Papers/DuchiHaSi10.pdf),
-[RMSProp](http://www.cs.toronto.edu/~tijmen/csc321/slides/lecture_slides_lec6.pdf),
-[Nesterov](http://scholar.google.com/citations?view_op=view_citation&amp;hl=en&amp;user=DJ8Ep8YAAAAJ&amp;citation_for_view=DJ8Ep8YAAAAJ:hkOj_22Ku90C).
+## Basic user guide
 
-Consequently, what a user needs to do to submit a training job is
+Users can use the default main function provided by SINGA to submit the training
+job. For this case, a job configuration file written as a google protocol
+buffer message for the [JobProto](../api/classsinga_1_1JobProto.html) must be provided in the command line,
 
-  1. [Prepare the data](data.html) for training, validation and test.
+    ./bin/singa-run.sh -conf <path to job conf> [-resume]
 
-  2. [Implement the new Layers](layer.html) to support specific feature transformations
-  required in the new model.
+`-resume` is for continuing the training from last
+[checkpoint](checkpoint.html).
+The [MLP](mlp.html) and [CNN](cnn.html)
+examples use built-in components. Please read the corresponding pages for their
+job configuration files. The subsequent pages will illustrate the details on
+each component of the configuration.
 
-  3. Configure the training job including the [cluster setting](architecture.html)
-  and [model configuration](model-config.html)
+## Advanced user guide
 
-### Driver program
+If a user's model contains some user-defined components, e.g.,
+[Updater](updater.html), he has to write a main function to
+register these components. It is similar to Hadoop's main function. Generally,
+the main function should
 
-Each training job has a driver program that
+  * initialize SINGA, e.g., setup logging.
 
-  * registers the layers implemented by the user and,
+  * register user-defined components.
 
-  * submit the job by providing the job configuration.
+  * create and pass the job configuration to SINGA driver
 
-An example driver program is like
+An example main function is like
 
+    #include <string>
     #include "singa.h"
-    #include "user-layer.h"  // header for user defined layers
-
-    DEFINE_int32(job, -1, "Job ID");  // job ID generated by the SINGA script
-    DEFINE_string(workspace, "examples/mnist/", "workspace of the training job");
-    DEFINE_bool(resume, false, "resume from checkpoint");
+    #include "user.h"  // header for user code
 
     int main(int argc, char** argv) {
-      google::InitGoogleLogging(argv[0]);
-      gflags::ParseCommandLineFlags(&argc, &argv, true);
-
-      // register all user defined layers in user-layer.h
-      Register(kFooLayer, FooLayer);
+      singa::Driver driver;
+      driver.Init(argc, argv);
+      bool resume;
+      // parse resume option from argv.
+
+      // register user defined layers
+      driver.RegisterLayer<FooLayer, std::string>("kFooLayer");
+      // register user defined updater
+      driver.RegisterUpdater<FooUpdater, std::string>("kFooUpdater");
       ...
+      auto jobConf = driver.job_conf();
+      //  update jobConf
 
-      JobProto jobConf;
-      // read job configuration from text conf file
-      ReadProtoFromTextFile(&jobConf, FLAGS_workspace + "/job.conf");
-      singa::SubmitJob(FLAGS_job, FLAGS_resume, jobConf);
+      driver.Submit(resume, jobConf);
+      return 0;
     }
 
-Users can also configure the job in the driver program instead of writing the
-configuration file
-
-
-      JobProto jobConf;
-      jobConf.set_job_name("my singa job");
-      ... // configure cluster and model
-      singa::SubmitJob(FLAGS_job, FLAGS_resume, jobConf);
+The Driver class' `Init` method will load a job configuration file provided by
+users as a command line argument (`-conf <job conf>`). It contains at least the
+cluster topology and returns the `jobConf` for users to update or fill in
+configurations of neural net, updater, etc. If users define subclasses of
+Layer, Updater, Worker and Param, they should register them through the driver.
+Finally, the job configuration is submitted to the driver which starts the
+training.
 
 We will provide helper functions to make the configuration easier in the
 future, like [keras](https://github.com/fchollet/keras).
 
-Compile and link the driver program with singa library to generate an
-executable file, e.g., with name `mysinga`. To submit the job, just pass the path of
-the executable and the workspace to the singa job submission script
-
-    ./bin/singa-run.sh <path to mysinga> -workspace=<my job workspace>
-
-The default driver (i.e., main.cc) will be complied and linked to generate
-`singa`, which is used as the default executable file (no need to put it in the
-command line)
+Users need to compile and link their code (e.g., layer implementations and the main
+file) with SINGA library (*.libs/libsinga.so*) to generate an
+executable file, e.g., with name *mysinga*.  To launch the program, users just pass the
+path of the *mysinga* and base job configuration to *./bin/singa-run.sh*.
+
+    ./bin/singa-run.sh -conf <path to job conf> -exec <path to mysinga> [other arguments]
+
+The [RNN application](rnn.html) provides a full example of
+implementing the main function for training a specific RNN model.
+

Modified: incubator/singa/site/trunk/content/markdown/docs/quick-start.md
URL: http://svn.apache.org/viewvc/incubator/singa/site/trunk/content/markdown/docs/quick-start.md?rev=1703880&r1=1703879&r2=1703880&view=diff
==============================================================================
--- incubator/singa/site/trunk/content/markdown/docs/quick-start.md (original)
+++ incubator/singa/site/trunk/content/markdown/docs/quick-start.md Fri Sep 18 15:10:58 2015
@@ -1,9 +1,11 @@
 # Quick Start
 
+---
+
 ## SINGA setup
 
 Please refer to the
-[installation](http://singa.incubator.apache.org/docs/installation}) page
+[installation](installation.html) page
 for guidance on installing SINGA.
 
 ### Starting Zookeeper
@@ -31,13 +33,6 @@ default port, please edit the `conf/sing
 Running SINGA in standalone mode is on the contrary of running it using cluster
 managers like [Mesos](http://mesos.apache.org/) or [YARN](http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/YARN.html).
 
-{% comment %}
-For standalone mode, users have to manage the resources manually. For
-instance, they have to prepare a host file containing all running nodes.
-There is no restriction on CPU and memory resources, hence SINGA consumes as much
-CPU and memory resources as it needs.
-{% endcomment %}
-
 ### Training on a single node
 
 For single node training, one process will be launched to run SINGA at
@@ -45,7 +40,7 @@ local host. We train the [CNN model](htt
 [CIFAR-10](http://www.cs.toronto.edu/~kriz/cifar.html) dataset as an example.
 The hyper-parameters are set following
 [cuda-convnet](https://code.google.com/p/cuda-convnet/). More details is
-available at [CNN example](http://singa.incubator.apache.org/docs/cnn).
+available at [CNN example](cnn.html).
 
 
 #### Preparing data and job configuration
@@ -64,7 +59,7 @@ Since all code used for training this CN
 built-in implementation, there is no need to write any code. Instead, users just
 execute the running script (*../../bin/singa-run.sh*) by providing the job
 configuration file (*job.conf*). To code in SINGA, please refer to the
-[programming guide](http://singa.incubator.apache.org/docs/programming-guide).
+[programming guide](programming-guide.html).
 
 #### Training without parallelism
 
@@ -112,16 +107,15 @@ described in the [System Architecture]()
       workspace: "examples/cifar10/"
     }
 
-In SINGA, [asynchronous training](http://singa.incubator.apache.org/docs/architecture) is enabled
-by launching multiple worker groups. For example, we can change the original
-*job.conf* to have two worker groups as shown above. By default, each
-worker group has one worker. Since one process is set to contain two workers.
-The two worker groups will run in the same process.  Consequently, they run
-the in-memory [Downpour](http://singa.incubator.apache.org/docs/frameworks) training framework.
-Users do not need to split the dataset
-explicitly for each worker (group); instead, they can assign each worker (group) a
-random offset to the start of the dataset. The workers would run as on
-different data partitions.
+In SINGA, [asynchronous training](architecture.html) is enabled by launching
+multiple worker groups. For example, we can change the original *job.conf* to
+have two worker groups as shown above. By default, each worker group has one
+worker. Since one process is set to contain two workers.  The two worker groups
+will run in the same process.  Consequently, they run the in-memory
+[Downpour](frameworks.html) training framework.  Users do not need to split the
+dataset explicitly for each worker (group); instead, they can assign each
+worker (group) a random offset to the start of the dataset. The workers would
+run as on different data partitions.
 
     # job.conf
     ...
@@ -149,18 +143,18 @@ The running command is:
       workspace: "examples/cifar10/"
     }
 
-In SINGA, [asynchronous training](http://singa.incubator.apache.org/docs/architecture) is enabled
+In SINGA, [asynchronous training](architecture.html) is enabled
 by launching multiple workers within one worker group. For instance, we can
 change the original *job.conf* to have two workers in one worker group as shown
 above. The workers will run synchronously
 as they are from the same worker group. This framework is the in-memory
-[sandblaster](http://singa.incubator.apache.org/docs/frameworks).
+[sandblaster](frameworks.html).
 The model is partitioned among the two workers. In specific, each layer is
 sliced over the two workers.  The sliced layer
 is the same as the original layer except that it only has `B/g` feature
 instances, where `B` is the number of instances in a mini-batch, `g` is the number of
 workers in a group. It is also possible to partition the layer (or neural net)
-using [other schemes](http://singa.incubator.apache.org/docs/neural-net).
+using [other schemes](neural-net.html).
 All other settings are the same as running without partitioning
 
     ./bin/singa-run.sh -conf examples/cifar10/job.conf
@@ -186,10 +180,9 @@ The running command is the same as for s
 
 ## Running with Mesos
 
-*in working*...
-
+*working*...
 
 ## Where to go next
 
-The [programming guide](http://singa.incubator.apache.org/docs/programming-guide) pages will
+The [programming guide](programming-guide.html) pages will
 describe how to submit a training job in SINGA.

Modified: incubator/singa/site/trunk/content/markdown/docs/rbm.md
URL: http://svn.apache.org/viewvc/incubator/singa/site/trunk/content/markdown/docs/rbm.md?rev=1703880&r1=1703879&r2=1703880&view=diff
==============================================================================
--- incubator/singa/site/trunk/content/markdown/docs/rbm.md (original)
+++ incubator/singa/site/trunk/content/markdown/docs/rbm.md Fri Sep 18 15:10:58 2015
@@ -1,5 +1,7 @@
 # RBM Example
 
+---
+
 This example uses SINGA to train 4 RBM models and one auto-encoder model over the
 [MNIST dataset](http://yann.lecun.com/exdb/mnist/). The auto-encoder model is trained
 to reduce the dimensionality of the MNIST image feature. The RBM models are trained
@@ -11,12 +13,12 @@ from [Hinton's science paper](http://www
 Running scripts are provided in *SINGA_ROOT/examples/rbm* folder.
 
 The MNIST dataset has 70,000 handwritten digit images. The
-[data preparation](http://singa.incubator.apache.org/docs/data) page
+[data preparation](data.html) page
 has details on converting this dataset into SINGA recognizable format (i.e.,
-[DataShard](http://singa.incubator.apache.org/api/classsinga_1_1DataShard.html)). Users can
+[DataShard](../api/classsinga_1_1DataShard.html)). Users can
 simply run the following commands to download and convert the dataset.
 
-    # at SINGA_ROOT/examples/rbm/
+    # at SINGA_ROOT/examples/mnist/
     $ cp Makefile.example Makefile
     $ make download
     $ make create
@@ -39,7 +41,7 @@ The fine-tuning phase trains the auto-en
 
 ### RBM0
 
-<img src="http://singa.incubator.apache.org/images/RBM0_new.PNG" align="center" width="200px"/>
+<img src="../images/RBM0_new.PNG" align="center" width="200px"/>
 <span><strong>Figure 1 - RBM0.</strong></span>
 
 The neural net structure for training RBM0 is shown in Figure 1.
@@ -53,8 +55,8 @@ These two layers are configured as,
       type: kRBMVis
       srclayers:"mnist"
       srclayers:"RBMHid"
-      rbmvis_conf{
-        num_output: 1000
+      rbm_conf{
+        hdim: 1000
       }
       param{
         name: "w0"
@@ -65,7 +67,7 @@ These two layers are configured as,
         }
       }
       param{
-        name: "b0"
+        name: "b01"
         init{
           type: kConstant
           value: 0.0
@@ -77,15 +79,15 @@ These two layers are configured as,
       name: "RBMHid"
       type: kRBMHid
       srclayers:"RBMVis"
-      rbmhid_conf{
-        hid_dim: 1000
+      rbm_conf{
+        hdim: 1000
       }
       param{
         name: "w0_"
         share_from: "w0"
       }
       param{
-        name: "b1"
+        name: "b02"
         init{
           type: kConstant
           value: 0.0
@@ -97,18 +99,18 @@ These two layers are configured as,
 
 For RBM, the weight matrix is shared by the visible and hidden layers. For instance,
 `w0` is shared by `vis` and `hid` layers shown in Figure 1. In SINGA, we can configure
-the `share_from` field to enable [parameter sharing](http://singa.incubator.apache.org/docs/param)
+the `share_from` field to enable [parameter sharing](param.html)
 as shown above for the param `w0` and `w0_`.
 
-[Contrastive Divergence](http://singa.incubator.apache.org/docs/train-one-batch/#contrastive-divergence)
-is configured as the algorithm for [TrainOneBatch](http://singa.incubator.apache.org/docs/train-one-batch).
-Following Hinton's paper, we configure the [updating protocol](http://singa.incubator.apache.org/docs/updater/)
+[Contrastive Divergence](train-one-batch.html#contrastive-divergence)
+is configured as the algorithm for [TrainOneBatch](train-one-batch.html).
+Following Hinton's paper, we configure the [updating protocol](updater.html)
 as follows,
 
     # Updater Configuration
     updater{
       type: kSGD
-      momentum: 0.9
+      momentum: 0.2
       weight_decay: 0.0002
       learning_rate{
         base_lr: 0.1
@@ -121,13 +123,13 @@ configure the `workspace` field to speci
 For example, if we configure it as,
 
     cluster {
-      workspace: "SINGA_ROOT/rbm0/"
+      workspace: "examples/rbm/rbm0/"
     }
 
-Then SINGA will [checkpoint the parameters](http://singa.incubator.apache.org/docs/checkpoint) into *SINGA_ROOT/rbm0/*.
+Then SINGA will [checkpoint the parameters](checkpoint.html) into *examples/rbm/rbm0/*.
 
 ### RBM1
-<img src="http://singa.incubator.apache.org/images/RBM1_new.PNG" align="center" width="200px"/>
+<img src="../images/RBM1_new.PNG" align="center" width="200px"/>
 <span><strong>Figure 2 - RBM1.</strong></span>
 
 Figure 2 shows the net structure of training RBM1.
@@ -143,12 +145,8 @@ The neural net configuration is (with la
       innerproduct_conf{
         num_output: 1000
       }
-      param{
-        name: "w0"
-      }
-      param{
-        name: "b1"
-      }
+      param{ name: "w0" }
+      param{ name: "b02"}
     }
 
     layer{
@@ -160,25 +158,18 @@ The neural net configuration is (with la
     layer{
       name: "RBMVis"
       type: kRBMVis
-      srclayers:"sigmoid1"
+      srclayers:"Sigmoid1"
       srclayers:"RBMHid"
-      rbmvis_conf{
-        num_output: 500
+      rbm_conf{
+        hdim: 500
       }
       param{
         name: "w1"
-        init{
-        type: kGaussian
-        mean: 0.0
-        std: 0.1
-        }
+        ...
       }
       param{
-        name: "b2"
-        init{
-        type: kConstant
-        value: 0.0
-        }
+        name: "b11"
+        ...
       }
     }
 
@@ -186,54 +177,48 @@ The neural net configuration is (with la
       name: "RBMHid"
       type: kRBMHid
       srclayers:"RBMVis"
-      rbmhid_conf{
-        hid_dim: 500
+      rbm_conf{
+        hdim: 500
       }
       param{
         name: "w1_"
         share_from: "w1"
       }
       param{
-        name: "b3"
-        init{
-        type: kConstant
-        value: 0.0
-        }
+        name: "b12"
+        ...
       }
     }
 
-To load w0 and b1 from RBM0's checkpoint file, we configure the `checkpoint_path` as,
+To load w0 and b02 from RBM0's checkpoint file, we configure the `checkpoint_path` as,
 
-    checkpoint_path: "SINGA_ROOT/rbm0/checkpoint/step6000-worker0.bin"
+    checkpoint_path: "examples/rbm/rbm0/checkpoint/step6000-worker0.bin"
     cluster{
-      workspace: "SINGA_ROOT/rbm1"
+      workspace: "examples/rbm/rbm1"
     }
 
-The workspace is changed for checkpointing w1, b2 and b3 into *SINGA_ROOT/rbm1/*.
+The workspace is changed for checkpointing `w1`, `b11` and `b12` into
+*examples/rbm/rbm1/*.
 
 ### RBM2
 
-<img src="http://singa.incubator.apache.org/images/RBM2_new.PNG" align="center" width="200px"/>
+<img src="../images/RBM2_new.PNG" align="center" width="200px"/>
 <span><strong>Figure 3 - RBM2.</strong></span>
 
-
-
 Figure 3 shows the net structure of training RBM2. In this model, a layer with
 250 units is added as the hidden layer of RBM2. The visible units of RBM2
-accepts output from Sigmoid2 layer. Parameters of Inner1 and inner2 are set to
-`w0,b1,w1,b2` which can be load from the checkpoint file of RBM1, i.e., "SINGA_ROOT/rbm1/".
+accepts output from Sigmoid2 layer. Parameters of Inner1 and Innner2 are set to
+`w0,b02,w1,b12` which can be load from the checkpoint file of RBM1,
+i.e., "examples/rbm/rbm1/".
 
 ### RBM3
 
 
-<img src="http://singa.incubator.apache.org/images/RBM3_new.PNG" align="center" width="200px"/>
+<img src="../images/RBM3_new.PNG" align="center" width="200px"/>
 <span><strong>Figure 4 - RBM3.</strong></span>
 
-
-
 Figure 4 shows the net structure of training RBM3. It is similar to Figure 3,
-but according to [Hinton's science
-paper](http://www.cs.toronto.edu/~hinton/science.pdf), the hidden units of the
+but according to [Hinton's science paper](http://www.cs.toronto.edu/~hinton/science.pdf), the hidden units of the
 top RBM (RBM3) have stochastic real-valued states drawn from a unit variance
 Gaussian whose mean is determined by the input from the RBM's logistic visible
 units. So we add a `gaussian` field in the RBMHid layer to control the
@@ -256,34 +241,27 @@ layer omitted),
     layer{
       name: "RBMVis"
       type: kRBMVis
-      srclayers:"sigmoid3"
+      srclayers:"Sigmoid3"
       srclayers:"RBMHid"
-      rbmvis_conf{
-        num_output: 30
+      rbm_conf{
+        hdim: 30
       }
       param{
         name: "w3"
-        init{
-        type: kGaussian
-        mean: 0.0
-        std: 0.1
-        }
-     }
-     param{
-       name: "b6"
-       init{
-       type: kConstant
-       value: 0.0
-       }
-     }
+        ...
+      }
+      param{
+        name: "b31"
+        ...
+      }
     }
 
     layer{
       name: "RBMHid"
       type: kRBMHid
       srclayers:"RBMVis"
-      rbmhid_conf{
-        hid_dim: 30
+      rbm_conf{
+        hdim: 30
         gaussian: true
       }
       param{
@@ -291,11 +269,8 @@ layer omitted),
         share_from: "w3"
       }
       param{
-        name: "b7"
-        init{
-          type: kConstant
-          value: 0.0
-        }
+        name: "b32"
+        ...
       }
     }
 
@@ -303,14 +278,14 @@ layer omitted),
 In the fine-tuning stage, the 4 RBMs are "unfolded" to form encoder and decoder
 networks that are initialized using the parameters from the previous 4 RBMs.
 
-<img src="http://singa.incubator.apache.org/assets/image/autoencoder_new.PNG" align="center" width="500px"/>
+<img src="../images/autoencoder_new.PNG" align="center" width="500px"/>
 <span><strong>Figure 5 - Auto-Encoder.</strong></span>
 
 
 Figure 5 shows the neural net structure for training the auto-encoder.
-[Back propagation (kBP)] (http://singa.incubator.apache.org/docs/train-one-batch/) is
+[Back propagation (kBP)] (train-one-batch.html) is
 configured as the algorithm for `TrainOneBatch`. We use the same cluster
-configuration as RBM models. For updater, we use [AdaGrad](http://singa.incubator.apache.org/docs/updater#adagradupdater) algorithm with
+configuration as RBM models. For updater, we use [AdaGrad](updater.html#adagradupdater) algorithm with
 fixed learning rate.
 
     ### Updater Configuration
@@ -333,9 +308,9 @@ configuration is (with some of the middl
     layer{
       name: "Inner1"
       param{ name: "w0" }
-      param{ name: "b1" }
+      param{ name: "b02" }
     }
-    layer{ name: "sigmoid1" }
+    layer{ name: "Sigmoid1" }
     ...
     layer{
       name: "Inner8"
@@ -347,14 +322,15 @@ configuration is (with some of the middl
         name: "w8"
         share_from: "w1"
       }
-      param{ name: "b0" }
+      param{ name: "b01" }
     }
-    layer{ name: "sigmoid8" }
-    ### Euclidean Loss Layer Configuration
+    layer{ name: "Sigmoid8" }
+
+    # Euclidean Loss Layer Configuration
     layer{
       name: "loss"
       type:kEuclideanLoss
-      srclayers:"sigmoid8"
+      srclayers:"Sigmoid8"
       srclayers:"mnist"
     }
 
@@ -370,9 +346,9 @@ To load pre-trained parameters from the
 ## Visualization Results
 
 <div>
-<img src="http://singa.incubator.apache.org/assets/image/rbm-weight.PNG" align="center" width="300px"/>
+<img src="../image/rbm-weight.PNG" align="center" width="300px"/>
 
-<img src="http://singa.incubator.apache.org/assets/image/rbm-feature.PNG" align="center" width="300px"/>
+<img src="../image/rbm-feature.PNG" align="center" width="300px"/>
 <br/>
 <span><strong>Figure 6 - Bottom RBM weight matrix.</strong></span>
 &nbsp;
@@ -388,5 +364,3 @@ Gabor-like filters are learned. Figure 7
 the top-layer of the auto-encoder, wherein one point represents one image.
 Different colors represent different digits. We can see that most images are
 well clustered according to the ground truth.
-
-



Mime
View raw message