Getting Started



In order to start using Octopus Designer you have to go to Downloads and download octopus-designer-win-0.6-dist.zip file. Installation is very simple - unzip this file into the directory of your choice and you are done.

To run Octopus Designer, go to <installation directory>/octopus-designer/bin folder and run start.bat script.

The following is a step by step instructions how to build and to run a simplest Octopus model, all steps are illustrated with screenshots presented in the image widget bellow.

Step 1. Go to the Octopus palette panel and select "Sources" tab. In the "Sources" tab choose "Test Data Source" source processor and drag it to the canvas.

Step 2. Select "Sinks" tab in the Palette panel and then "Console" sink processor on it. Drag and drop it on the canvas. Now you have two processors on the canvas and you can connect them.

Step 3. Each processor can have inputs and a single output. Source processors have only a single output, sink processors can have multiple inputs, the other processors can have multiple inputs and a single output each. All processors can have an unlimited list of parameters that can be used to specify inputs and an output for each processor. To connect processors the output of one processor should be connected to the input of the other processor. In our case we have only two processors, so we are going to connect output of "Test Data source" processor to the input of "Console" sink processor. Hold Ctrl button and drag mouse from output of "Test Data source" to the input of "Console" sink.

Step 4. Now when we've connected our processors we may want to specify parameters for each of them. Lets start with source processor. "Test Data source" is very simple source processor and it has only one parameter "Number of events" with default value equal 10. We can leave it as is or change it.

Step 5. Just to remind you, Octopus source processors provide data for the model in a form of events. The event definition is the same as an event in Complex Even Processing (CEP) - a collection of "name-value" pairs witch we call attributes. Source processor supplies events to the model one by one when they are getting available. We have to define each attribute of an event by providing attribute name and attribute value type. Click on attribute text box and you'll get an access to the dialog window that Octopus Designer offers to help you to do this work. Slide 5 shows this dialog window. To add new attribute click on green plus icon, to remove existing attribute - click on red icon. Drop-down list box in the "Attribute Type" column provides a list of supported data types.

Step 6. Next lets move to the sink processor and specify parameters for the "Console" sink processor. In the "Show Attributes" parameter we should provide the attribute name that we are going to show in output window (Console window) of Octopus Designer.

Step 7. Now we can compile model. During compilation Octopus Designer generates a detailed description of the model in JSON format. You can see the result of compilation on Slide 7.

Step 8. Finally we can run model by pushing green dot icon - the most right icon on the Octopus designer  top tool bar. The results of model execution are on the slide 8.

Step 9. You can save model in your local db4o Object database that is embedded in your Octopus Designer. But please do not save it on the server - it is not that kind of models that you want to share with others :-)


Interactive Statistical analysis as a Service (iSaaS)

With Octopus CIP we shift  a weight of development effort from the technical (programming and an application development) to the business aspects of the data analysis. In this part of Getting Started we will introduce a possible scenario of performing data analysis with Octopus CIP. The step by step work flow of data analysis with Octopus CIP is presented on the Slide-show bellow.

Slide 1. First, we need to organize our source data. In this example we will use Google spreadsheet "USFutures15" as data source. On slide one you can see this spreadsheet. These are 15 minutes US futures data collected in 2009. Pay attention to the column names, we will use them in our model as arguments.

Slide 2. Here is a template for result data and again check the column names - we will use them in the model.

Slide 3. On this slide you can see "gss-crossing-gss-model_004". You can download it from Octopus CIP Server. To do this go to the "File" menu and select "Open..." option, in dialog box check "Search on Server Repository" check box and push "Search" button, find model in the list. This model implements a very simple trade strategy that is based on analysis of two simple moving averages (SMA): one with a short time window and the other one with a long tome window. The graphics of these two SMA are crossing, if a dynamic of the futures is changing. Crossing from above shows a slow down trend, crossing from under - acceleration of the growth.
On this slide the source processor is highlighted . Examine the properties of this processor - they point to specific Google spreadsheet book and a sheet inside of this book. Click on the value of Output data and you can see a dialog with the list of attributes that we are going to extract from Google spreadsheet (see the next slide).

Slide 4. The names of the attributes are the same as in the spreadsheet except they are in low case - during data exchange column names are converted to the low case. We added the "index" attribute which values are automatically generated and can be used in navigation between different rows.

Slide 5. On this slide you can see properties of the SMA processor that calculates short simple moving average (it uses 7 last values to calculate average).

Slide 6. Here is SMA processor for the long moving average with time window equal 10.

Slide 7. Crossing processor compares two SMA's to determine if they are crossing. The output of this processor: 1 - crossing happened from under; -1 - crossing happened from above; 0 - in other cases.

Slide 8. Sink processor "Output to GSS" returns result data back to the Google Spreadsheet. In properties sheet you can see parameters of this processor. Important parameter "Output field list" is a list of attributes that we are going to return to GSS. This list includes attributes that we defined in Source processor and also attributes that we generated during calculations ("short" and "long" - from SMA processors and "isCrossed" - from "Crossing" processor. You should pay attention to the attributes in the model and columns in Spreadsheet - they should be the same.

Slide 9. Result sheet of the model execution.

Slide 10. Graph chart that visualizes results of calculations.



Interactive Optimization as a Service (iOaaS)

Constraint Programming (CP) is a relatively new direction in software development that is addressing optimization problems in the field of Enterprise Resource Planning.

There are several established implementations available as Open Source Software or with commercial licensing (Choco, Constrainer are OSS; Gurobi, IBM ILOG require commercial licensing). Most of these systems are developed in Java or can be used as part of Java applications. JSR-331 (Java Constraint Programming API) is a standard base that provides compatibility between applications, developed using different implementations of Constraint Programming.

iOaaS provides support for the Octopus optimization models. CP functionality is implemented as a set of Octopus processors.
iOaaS can work with all JSR-331 compatible APIs.

We using Google s spreadsheets for source data. Slides 1 - 3 represent three major parts of source data:

  • product description (Slide 1);
  • machine/resource description (Slide 2);
  • description of technological steps that should be performed in order to make a final product  (Slide 3).
​
To access these spreadsheets login to one of Google demo accounts using following User Id's:
demo1@lisa-park.com, demo2@lisa-park.com, demo3@lisa-park.com, demo4@lisa-park.com or demo5@lisa-park.com - and use the same password for all of them: isasdemo.

​Slide 4 represent a sheet for results of an optimal solution.

The general idea of iOaaS is pretty simple - we are using Neo4j graph data base to store and manage all relations between different elements of an Optimization task. Three special processors were developed to support conversion of source data (presented as Google spreadsheets) to the set of nodes in Neo4j graph database. There is also  one processor that creates relationships between those nodes. Finally, having set of nodes that represent source data and relations between them we can build a Solution Model and search for the optimal solution.

There are three stages in this process:

  1. Source data conversion from Google spreadsheets to Neo4j database.  Three separate models transfer data from Google spreadsheet to  Neo4j database (Slides 5 - 10);
  2. Relationship's building. One model builds all relationships (Slides 11 and 12);
  3. Searching for the optimal solution. Optimization Model builds Solution Model (we are using Choco - Open Source Constraint Programming Framework). This model is presented on Slides 13 and 14.
​All optimization processors come with default values for most of the parameters. The only parameters that are needed to be adjusted are Google spreadsheet related. The "Optimization with Neo4j" sink processor is the most complicated among these processors, but it also comes with defaults that are good for many cases. Detailed instructions on how to use iOaaS and best practices are provided with iOaaS User Guide that in the "work in progress" status right now.

The last slide (15) shows Solution graph how it is defined in the Neo4j database.

We are constantly working on improvement of our samples and as a result the model's names may be changed in the future. All optimization models can be run from Octopus designer or from Model Runner on this site. Web server and Model Runner server are located within the same local area network and therefore they need to use local IP addresses. When you run these models from Octopus designer we have to use external IP. On Octopus server repository we have two version of each model to support both cases. Models that are configured to run in Octopus designer have "from-designer" as a part of model name suffix. The current names for all five optimization models as they presented on Octopus Server repository are:
  1. opti-machines-2Neo4j_003 (opti-machines-2Neo4j-from-designer_003);
  2. opti-product-2Neo4j_001 (opti-product-2Neo4j-from-designer_001);
  3. opti-technologySteps-2Neo4j_001 (opti-technologySteps-2Neo4j-from-designer_001);
  4. opti-Relations-2Neo4j_001 (opti-Relations-2Neo4j-from-designer_001);
  5. opti-solution-2GSS_001 (opti-solution-2GSS-from-designer_001).
All models are working over http connection and as a result sometimes it takes a few seconds to complete a task. The
opti-solution-2GSS_002 is set for 15 seconds timeout, so you should be aware about this too.



In Octopus CIP everything is a model. If something is not a model - it is a processor. Model is a very powerful and simple abstraction to represent data processing. Octopus models are self descriptive. Model description is an JSON object that incorporates all model parameters and parameters of all model processors. Octopus uses a model description to build and to maintain Octopus Model Semantic Web. This semantic web allows a simple querying for related models and also data sources and sinks that are connected to those models. Of course, all these manipulations on the model are performed with the models. You could see this kind of models in provided videos (check it under Downloads option in the page top menu).

Processors are building blocks for the models. As you already know, there are three types of processors: source processors, processors and sink processors. In terms of functionality we have a much wider spectrum of different processors. But among them there is a very special kind of processors that designed to run models. We are using these processors to build models that can run other models locally or remotely. Connected together these processors allow us to create a model that can run other models. From Octopus designer point of view this model is a regular model, so we can use Octopus designer as a tool to build such compound (connected, chained) models that would provide a support for model chaining.

On the slide-show below you can see an example of the model that runs other models in specified order. This model resides on the Octopus Server Repository, it's name is "opti-pipeline-from-designer_001" and you can open it in Octopus designer using "Search on Server Repository" option.

RTC (Run Time Container) Source processor initiates model's execution by sending "start" signal to the first in the line RTC Controller. Each RTC Controller is responsible of running a specified list of models. It runs them in parallel. Next in the line RTC Controller takes control only after the previous finished it's job.

As you can learn from the RTC Controller's properties, we are running all five optimization models that we described in the previous tab. You can download this compound model from Octopus Server Repository - use the "Open ..."  option fron the top menu bar and check "Search on Server Repository" option in the dialog box.

Be aware, the model execution takes some time - about 20 second due to settings of the time-out (set for 15 sec) parameter on the "Optimization with Neo4j" processor in the "opti-solution-2GSS_002" model.




To acquire an Octopus model from the server side all you need is mark "Search on Server Repository" check box in the Open model dialog box and you get Server side model list in your Octopus designer. In most cases you'll be able to run these models without any modifications. However in some cases you will need to make some adjustments.

All Octopus models that are located in Server Repository are configured to run on server side. As a result some parameters for the models acquired from the Server needed to be adjusted. For example, all optimization models are using processors that work with a Neo4j Graph database located on Local Area Network (LAN) and therefore they are using a local IP address. If you want to run these models using Octopus designer installed outside of Octopus Server LAN, you have to replace local IP address with an external IP address. Currently Internet accessible IP address for Octopus server is 173.12.48.14 and the local IP address is 10.1.10.11. You also can use optimization models specifically configured for run from Octopus designer. Those models marked with "from-designer" in the suffix of the model name.

There are other set of models that are working with Neo4j database - octopus semantic web models. In addition these models also work with db4o database, located on server side. To make these models run on client side from Octopus designer you need to replace local IP addresses with external Internet address for Octopus server that is 173.12.48.14.