Definitions and Concepts: 

Following terms are using in this document as well as on the SS Solution pages:

• CONNECTed Project is a project created by an Organization administrator or Project administrator using Bentley CONNECT portal or desktop interface. Note that Scenario Services does not offer ability to create or manage CONNECTed projects. However, a Scenario Services Solution must be associated with a CONNECTed project. A CONNECTed project is not limited to Scenario Services, but can contain other services such as PW Transmittal service, Project Sharing service, Content Services and so on.

• Solution refers to a specific problem the user is trying to solve, such as designing a hospital building, or designing a stadium with curved roof. There may be three types of Solutions:

• Optioneering Solutions involve designing multiple options (or Scenarios) of the same engineering model (such as a designing a specific bridge) and manually comparing performance of these scenarios to attain the best design. Scenario Services offers tools for comparing the performance of multiple scenarios.

• QA Solutions are used to compare results produced by two versions of a software. The same set of models are run on both versions and differences in design results are highlighted when the difference exceed a pre-set threshold.

• Optimization Solutions (not offered in first version of Scenario Services) involve automatic parametric generation of different scenarios by varying a set of “decision variables” to attain one or more “objectives”.  

• Scenario represents a specific configuration or option of an engineering model, which will be compared with other configurations. For example, a plant building model with less number of bays but more bay width can represent one scenario; and another model with more bays but less bay width can represent another scenario. A scenario is “run” using a specified type of Cluster on the cloud. We shall use the term “job” and “scenario” interchangeably in this document.

• Cluster refers to a group of virtual machines on the cloud together performing a specific set of tasks – such that the whole cluster behaves as a single machine, providing increased redundancy and reliability. In Scenario Services, machines in a cluster have the same hardware and OS configuration. Scenario Services mainly uses two types of clusters:

Default Cluster: This a cluster which is shared by multiple users for multiple tasks. By default, this cluster has four virtual machines. Scalable Processing Service or SPS, which is a part of Scenario Services responsible for actually running jobs on the cloud, scales up the cluster by adding more machines (Nodes) when jobs start getting queued up. When the queue becomes lighter, SPS removes some nodes from the cluster. Running jobs in Default cluster is the fastest provided there is not a lot of load on the system. However, scaling up of a cluster takes about 10 minutes. Therefore, if the users are trying to run scenarios in an overloaded cluster, they need to wait for a maximum of 10 minutes while the cluster scales up. However, it is quite possible for some nodes to become free while the cluster is scaling up and pick up the job submitted by the user.

Dedicated Clusters: These clusters come in three sizes: Small, Medium and Large. SPS always provisions (creates) these clusters on demand. As a result, the user has to wait for a minimum of 12-15 minutes to use a dedicated cluster. However, once the cluster is active, SPS reserves all the nodes of the cluster for the job the user has submitted. Once the whole job is complete, SPS takes down the whole cluster. Typically, dedicated clusters are useful for long running jobs.  

Currently all virtual machines in all clusters have 2-Core processors. Small, Medium and Large clusters have 16, 32 and 64 machines (nodes ?) respectively. Note that these conventions may change in future. Also, a reserved cluster is exclusive to the user (e.g. Sam’s Small, Sam’s Large etc). Reserved clusters may not be shared by multiple users.

• Solution Template, Discipline, Application and Version: Solution Templates determine the exact computational workflow to be used to run a Design Simulation job. In other words, Templates tell Scenario Services which specific executables need to be run and in what sequence. Template also determines the type and number of Inputs needed to run these executables and outputs that are produced by these executables. Note that output of an executable can be taken as Input for the next executable.

• Here are examples of some possible templates using Structural design using STAAD.Pro

1. Run a STAAD model using version SS6 engine and produce performance indicators and outputs

2. Start with an i-Model. Run iModel-STAAD transformation engine version xx to produce a STAAD model. Run a model validator engine version nn to validate the integrity of the model. Then run STAAD engine version SS6 and produce performance indicators and outputs.

3. To perform a multi-disciplinary optimization, start with an i-Model capable of creating a STAAD model as well as an Energy model. Run iModel-STAAD transformation engine version xx to produce a STAAD model. Run iModel-Energy transformation engine version yy to produce an Energy (AES) model. Note that the transformation engines can be run in parallel.
   Run a STAAD model validator engine version nn to validate the integrity of the STAAD model. Run an AES model validator engine version pp to validate the AES model. Note that the validation engines can be run in parallel.
   Run STAAD engine version SS6 using the validated file(s) and produce performance indicators and outputs. Run AES engine version SS4 using the validated file(s) and produce performance indicators and outputs. Note that these steps can also be run in parallel.
4. Since there may be a large number Templates along with Template versions, users are asked to select Engineering Discipline (such as Structural, Energy, or Multi-Discipline with Structural and Energy) first. Each Engineering Discipline can have several Applications with Application Versions. The user may select one or more Application Versions and search for Templates that include all of the selected Application Versions. Once the Template is selected, the user also has to select a Template version that caters to any change in the engineering workflow using the same engines.
5. Several hypothetical examples are given below to make the concept clear,

• Select Discipline: select Structural for cases (a) and (b) above

Select Application with Version

List of Application with versions appear, such as

STAAD.Pro
   o Version x1.y1 (SS5)
   o Version x2.y2 (SS6)
iModel-STAAD Transformation
o Version a1.b1
o Version a2.b2

• For case (a) select a version of STAAD.Pro. For (b) select a STAAD.Pro version as well as an i-Model transformation engine version
• Search for Templates for selected Application Versions
• For (a), the following Templates may show up, since both contain STAAD.Pro Analysis and Design

STAAD.Pro Analysis and Design
STAAD.Pro Analysis and Design from i-Model

• For (b), the following Template may show up STAAD.Pro Analysis and Design from i-Model
• Once the Template is selected, the Template version needs to be specified.
• Say, in STAAD.Pro Template version 1.0 the wrapper around STAAD.Pro engine could extract about 10 performance indicators from STAAD result files. The wrapper engine has been now been updated and it can extract 5 more indicators. The new wrapper engine will result in a new Template version (2.0) to be created even if the Application Version remains the same.
• Solutions that are run using Template Version 1.0 will see 10 indicators that can be compared. Those with Template Version 2.0 will get 15 indicators to compare.

Here is another hypothetical example of using Templates for multiple disciplines, Structural and Energy as in case (c) above - using iModel transformation engines.

1. Select Discipline: select Structural and Energy

2. Select Applications with Versions. Note that at least one Structural and one Energy version need to be selected

STAAD.Pro
   o Version x1.y1 (SS5)
   o Version x2.y2 (SS6)

AES

   o Version p1.q1
   o Version p2.q2

iModel-STAAD Transformation Engine
o Version a1.b1
o Version a2.b2

iModel-Energy Transformation Engine
o Version c1.d1

• Note that we have a possibility of 8 Templates, (2 x 2 x 2 x 1). However, there may be some practical limits. For example, iModel-STAAD Transformation Engine version p1.q1 may only work with STAAD.Pro version x1.y1.

3.When the Templates are searched, we may only have one Template showing up

Multi-Disciplinary Optioneering using Structural and Energy via iModel

However, there will be quite a few Template versions, such as

1.0: STAAD ver x1.y1, AES ver p1.q1, iModel-STAAD ver a1.b1

2.0: STAAD ver x1.y1, AES ver p2.q2, iModel-STAAD ver a1.b1

3.0: STAAD ver x2.y2, AES ver p1.q1, iModel-STAAD ver a2.b2, etc.

• Storing Results: Scenario Services must “prepare” data so these are readily (and persistently) available for comparison, visualization or downloading. SPS runs engineering analysis and design tasks on the cloud using Virtual Machines (or Nodes). These Nodes are transient in nature, i.e. these are taken down after a specific job is done. Therefore, results produced by the application must be moved to a permanent storage from where user can access it later.
• Currently Scenario Services uses two strategies to store results. The results, which need to be compared or visualized, are stored in Azure tables, formatted in a way that is optimized for quick retrieval and display. The raw output files produced by the application are stored as-is on Azure Blob allowing the users to download these files later on demand.
• Users must specify which comparison results and which output files will be needed in future. All other data are lost once the Scenario run is completed.

• Performance Indicators: Performance Indicators are used to evaluate the overall performance of an engineering model. For example, in a tall building, the Story deflection will be one Indicator. The engineer will try to minimize the story deflection. Utilization Index, which denotes how effectively material is used in a model, may be another Indicator. The engineer will try to maximize the Utilization Index. User needs to evaluate a group of such Indicators needs to arrive at the most optimal design.
  
  Note that Performance Indicators are retrieved from the results produced by the application and stored in tables for easy retrieval. Sometimes a bit of data mining is needed to produce an indicator. For example, in a structural model, to get the number and length of all W12x26 beams, individual beam number and lengths need to be added up. This type of data mining or post-processing is done by the “wrapper” application for the specific discipline and forms an integral part of a Scenario run. Scenario Services does not perform any type of data mining at this point.

• Detailed Input/Output Data: Detailed Data harvested from application outputs, typically used in QA solutions to compare results between two application versions.
  
  Example for a structural model will be nodal deflections for specific load combinations. This result set may store Node number, Nodal coordinates, load combination number and deflections for three axial directions.

• App Output Files: These are the result files produced by the application(s) and stored as-is in Blob storage so these can be retrieved later on demand. For example, STAAD.Pro produces .anl file, which contains the basic analysis steps and some output tables, .bmd file contains the bending moment values of members. User may download these files for post processing using desktop version of STAAD.Pro.