"Merge Conflicts Resolution"

client/README.md

@@ -43,14 +43,9 @@ yarn test -e   #run end-to-end tests
 ## Authentication
 
 The react client website uses OAuth authentication.
-<<<<<<< HEAD
 The [authentication page](../docs/admin/client/auth.md)
 provides details on setting up oauth authentication for
 the client application.
-=======
-The [authentication page](../docs/admin/client/auth.md) provides details
-on setting up oauth authentication for the client application.
->>>>>>> feature/distributed-demo
 
 ## Custom configuration
 

docs/developer/system/architecture.md

@@ -1,8 +1,4 @@
-<<<<<<< HEAD
-# System Overview
-=======
 # :european_castle: System Overview
->>>>>>> feature/distributed-demo
 
 ## User Requirements
 

docs/user/digital-twins/create.md

@@ -1,64 +1,24 @@
 # Create a Digital Twin
 
-<<<<<<< HEAD
 The first step in digital twin creation is to use the available
 assets in your workspace. If you have assets / files
 in your computer that need to be available in the DTaaS workspace,
 then please follow the instructions provided in
 [library assets](../servers/lib/assets.md).
-=======
-The first step in digital twin creation is to use the available assets
-in your workspace. If you have assets / files in your computer that need
-to be available in the DTaaS workspace, then please follow the instructions
-provided in [library assets](../servers/lib/assets.md).
->>>>>>> feature/distributed-demo
 
 There are dependencies among the library assets. These dependencies
 are shown below.
 
 ![Relation between reusable assets](asset-relationship.png)
 
-<<<<<<< HEAD
-A digital twin can only be created by linking the assets
-in a meaningful way. This relationship can be expressed using a mathematical equation:
-=======
 A digital twin can only be created by linking the assets in
 a meaningful way. This relationship can be expressed using
 a mathematical equation:
->>>>>>> feature/distributed-demo
 
 $$
 D_t: \{ D{^*},M^{*},(FT)^{+} \}C_{dt}
 $$
 
-<<<<<<< HEAD
-where D denotes data, M denotes models, F denotes functions,
-T denotes tools, $C_{dt}$ denotes DT configuration and $D_t$
-is a symbolic notation for a digital twin itself. The
-$\{ D{^*},M^{*},(FT)^{+} \}C_{dt}$ expression denotes
-composition of DT from D,M,T and F assets. The $*$
-indicates zero or one more instances of an asset and
-$+$ indicates one or more instances of an asset.
-
-The DT configuration specifies the relevant assets to use,
-the potential parameters to be set for these assets.
-If a DT needs to use RabbitMQ, InfluxDB like services
-supported by the platform, the DT configuration needs
-to have access credentials for these services.
-
-This kind of generic DT definition is based on the DT
-examples seen in the wild. You are at liberty to deviate
-from this definition of DT. The only requirement is the
-ability to run the DT from either commandline or desktop.
-
-!!! tip
-    If you are stepping into the world of Digital Twins,
-    you might not have distinct digital twin assets.
-    You are likely to have one directory of everything
-    in which you run your digital twin.
-    In such a case we recommend that you upload this monolithic
-    digital twin into **digital twin/your_digital_twin_name** directory.
-=======
 where D denotes data, M denotes models, F denotes functions, T denotes tools,
 $C_{dt}$ denotes DT configuration and $D_t$ is a symbolic notation for
 a digital twin itself. The  $\{ D{^*},M^{*},(FT)^{+} \}C_{dt}$ expression
@@ -83,7 +43,6 @@ or desktop.
     of everything in which you run your digital twin. In such a case we
     recommend that you upload this monolithic digital twin into
     **digital twin/your_digital_twin_name** directory.
->>>>>>> feature/distributed-demo
 
 ## Example
 
@@ -132,40 +91,6 @@ workspace/
         maestro-2.3.0-jar-with-dependencies.jar
 ```
 
-<<<<<<< HEAD
-The `workspace/data/mass-spring-damper/` contains
-`input` and `output` data for the mass-spring-damper digital twin.
-
-The two FMU models needed for this digital twin are in `models/` directory.
-
-The co-simulation digital twin needs Maestro co-simulation orchestrator.
-Since this is a reusable asset for all the co-simulation based DTs, the
-tool has been placed in `common/tools/` directory.
-
-The actual digital twin configuration is specified in
-`digital twins/mass-spring-damper` directory. The co-simulation
-configuration is specified in two json files, namely `cosim.json`
-and `time.json`. A small explanation of digital twin for its users
-can be placed in `digital twins/mass-spring-damper/README.md`.
-
-The launch program for this digital twin
-is in `digital twins/mass-spring-damper/lifecycle/execute`.
-This launch program runs the co-simulation digital twin.
-The co-simulation runs till completion and then ends.
-The programs in `digital twins/mass-spring-damper/lifecycle`
-are responsible for lifecycle management of this digital twin.
-The [lifecycle page](lifecycle.md) provides more explanation on these programs.
-
-!!! Abstract "Execution of a Digital Twin"
-    A frequent question arises on the run time characteristics of a digital twin.
-    The natural intuition is to say that a digital twin must operate as long as
-    its physical twin is in operation.
-    **If a digital twin runs for a finite time and then ends, can it be called a digital twin?**
-    **The answer is a resounding YES**.
-    The Industry 4.0 usecases seen among SMEs have digital twins
-    that run for a finite time.
-    These digital twins are often run at the discretion of the user.
-=======
 The `workspace/data/mass-spring-damper/` contains `input` and
 `output` data for the mass-spring-damper digital twin.
 
@@ -198,41 +123,11 @@ The [lifecycle page](lifecycle.md) provides more explanation on these programs.
 
     **If a digital twin runs for a finite time and then ends, can it be
     called a digital twin?**
->>>>>>> feature/distributed-demo
 
     **The answer is a resounding YES**. The Industry 4.0 usecases seen among
     SMEs have digital twins that run for a finite time. These digital twins
     are often run at the discretion of the user.
 
-<<<<<<< HEAD
-1. Go to Workbench tools page of the DTaaS website
-   and open VNC Desktop. This opens a new tab in your browser
-1. A page with VNC Desktop and a connect button comes up.
-   Click on Connect.
-   You are now connected to the Linux Desktop of your workspace.
-1. Open a Terminal (black rectangular icon in the top left region of your tab)
-   and type the following commands.
-1. Download the [example files](https://github.com/INTO-CPS-Association/DTaaS-examples/archive/refs/heads/main.zip)
-
-   ```
-   $wget https://github.com/INTO-CPS-Association/DTaaS-examples/archive/refs/heads/main.zip
-   $unzip main.zip
-   ```
-
-1. Open a file browser and copy the files from this uncompressed
-   folder into your workspace folder (`/workspace`).
-   Make sure that the file placement matches the one given above.
-1. Go to the digital twin directory and run
-
-   ```
-   $cd /workspace/digital twins/mass-spring-damper
-   $lifecycle/execute
-   ```
-
-   The last command executes the mass-spring-damper
-   digital twin and stores the co-simulation output
-   in `data/mass-spring-damper/output`.
-=======
 **You can run this digital twin by**,
 
 1. Go to Workbench tools page of the DTaaS website and open VNC Desktop.
@@ -261,4 +156,3 @@ matches the one given above.
 
     The last command executes the mass-spring-damper digital twin and stores
     the co-simulation output in `data/mass-spring-damper/output`.
->>>>>>> feature/distributed-demo

docs/user/digital-twins/lifecycle.md

@@ -1,16 +1,8 @@
-<<<<<<< HEAD
-# Digital Twin Lifecycle
-=======
 # :recycle: Digital Twin Lifecycle
->>>>>>> feature/distributed-demo
 
 The physical products in the real world have product lifecycle.
 A simplified four-stage product life is illustrated here.
 
-<<<<<<< HEAD
-A DT lifecycle consists of **explore, create, execute, save, analyse, evolve**
-and **terminate** phases.
-=======
 A digital twin tracking the physical products (twins) need
 to track and evolve in conjunction with the corresponding
 physical twin.
@@ -28,7 +20,6 @@ undertaken in each phase are outlined in this section.
 
  A DT lifecycle consists of **explore, create, execute, save, analyse, evolve**
  and **terminate** phases.
->>>>>>> feature/distributed-demo
 
 | Phase | Main Activities |
 |:----|:----|
@@ -45,10 +36,6 @@ support all the phases. It is also possible for digital twin engineers to add
 more phases to digital they are developing. Thus it is important for
 the DTaaS software platform needs to accommodate needs of different DTs.
 
-<<<<<<< HEAD
-Even though not mandatory, having a coding structure makes it easy
-to manage DT lifecycle phases. It is recommended to have the following structure
-=======
 A potential linear representation of the tasks undertaken in
 a digital twin lifecycle are shown here.
 
@@ -66,7 +53,6 @@ of the DTaaS software platform.
 Even though not mandatory, having a matching coding structure makes it easy to
 for users to create and manage their DTs within the DTaaS.
 It is recommended to have the following structure:
->>>>>>> feature/distributed-demo
 
 ```text
 workspace/
@@ -81,16 +67,6 @@ workspace/
         terminate
 ```
 
-<<<<<<< HEAD
-A dedicated program exists for each phase of DT lifecycle.
-Each program can be as simple as a script that launches other
-programs or sends messages to a live digital twin.
-
-## Examples
-
-Here are the programs / scripts to manage three phases
-in the lifecycle of **mass-spring-damper DT**.
-=======
 A dedicated program exists for each phase of DT lifecycle. Each program
 can be as simple as a script that launches other programs or sends messages
 to a live digital twin.
@@ -99,7 +75,6 @@ to a live digital twin.
 
 Here are the programs / scripts to manage three phases in
 the lifecycle of **mass-spring-damper DT**.
->>>>>>> feature/distributed-demo
 
 ```bash title="lifecycle/execute"
 #!/bin/bash
@@ -111,37 +86,22 @@ java -jar /workspace/common/tools/maestro-2.3.0-jar-with-dependencies.jar \
     output-dir>debug.log 2>&1
 ```
 
-<<<<<<< HEAD
-The execute phases uses the DT configuration, FMU models and Maestro
-tool to execute the digital twin. The script also stores the output of
-cosimulation in `/workspace/data/mass-spring-damper/output`.
-
-It is possible for a DT not to support a specific lifecycle phase.
-This intention can be specified with an empty script and a helpful
-message if deemed necessary.
-=======
 The execute phases uses the DT configuration, FMU models and Maestro tool
 to execute the digital twin. The script also stores the output of
 cosimulation in `/workspace/data/mass-spring-damper/output`.
 
 It is possible for a DT not to support a specific lifecycle phase.
 This intention can be specified with an empty script and a helpful message
 if deemed necessary.
->>>>>>> feature/distributed-demo
 
 ```bash title="lifecycle/analyze"
 #!/bin/bash
 printf "operation is not supported on this digital twin"
 ```
 
-<<<<<<< HEAD
 The lifecycle programs can call other programs in the code base.
 In the case of `lifecycle/terminate` program, it is calling another
 script to do the necessary job.
-=======
-The lifecycle programs can call other programs in the code base. In the case of
-`lifecycle/terminate` program, it is calling another script to do the necessary job.
->>>>>>> feature/distributed-demo
 
 ```bash title="lifecycle/terminate"
 #!/bin/bash

files/README.md

@@ -1,13 +1,5 @@
-<<<<<<< HEAD
-# Directory Structure Template
-
-This directory contains directory structure template for
-user files of the platform.
-These files are served by `servers/lib` microservice.
-=======
 # User files
 
 This directory contains directory structure template for
 storing the user files of the platform. These files are
 mapped to `/workspace` directory in user workspaces.
->>>>>>> feature/distributed-demo