Following attached Code is Useful as Performance Major to Find Out Total Simulation Time in Different Scenarios. treenode datanode = param(1); double tm = time(); return tm;

This article borrows from @jordan.johnson's original guide for deploying a distributed experiment/optimization with Amazon. Distributed Terminology Please be familiar with the terminology related to experiments and optimizations. Replication - a distinct model run. We'll use this term below for both replications (experimenter) and solutions (optimizer). Instance - a system, whether virtual or bare-metal, local or remote, meeting FlexSim's recommended requirements, and used for running distributed replications. Main PC - the system from which the user configures and initiates the distributed experiment or optimization. The Cloud - a shorthand term for remote servers/systems hosted in a data center, sometimes by a 3rd party such as Amazon, Microsoft, Google, or others. Background Concepts In discussing distributed experiments or optimization, you should start with a good understanding of both the Experimenter and the Optimizer. Please read and understand this user manual entry which includes explanations of key concepts that will be important as you continue. Other user manual articles provide additional guidance on configuring your own experiments or optimizations. Search the online user manual and this community if you have additional questions regarding experiments or optimizations, as needed. Using the experimenter requires a FlexSim license. The optimizer requires a license for the OptQuest add-on. Please contact your local distributor for more information or to request a test license for FlexSim and/or OptQuest. What are distributed experiments or optimizations? Experiments or optimizations can create dozens, hundreds, or even thousands of distinct model runs (or replications) to test various scenarios, build confidence intervals of the results, or zero-in on an optimal solution. A distributed experiment or optimization takes those individual model runs and assigns them (distributes them) to run across a group of computers. If you needed to run 1000 replications, and you have 4 computers available, each computer could run 250 replications, getting your results 4 times faster. When should you distribute? Using distributed replications can significantly reduce the required time to run an experiment if: The single-run time for your model is high (a couple minutes or more) You anticipate running a high number of replications If the time per replication is short, then the increased communication overhead may outweigh the benefit of using distributed replications. The communication overhead increases because all distributed replications still report results to a single FlexSim process on the Main PC, and that communication occurs over the network (local instances) or internet (remote instances), rather than on a single computer. If an experiment or optimization completes in an acceptable amount of time, you may not need to use distributed replications. Financial Costs 3rd party cloud providers such as Amazon, Microsoft, Google, and others, charge for their services. Your cost is usually based on the hardware you provision for your Windows instances, and the length of time those instances are live. Typically you only run your instances when running your experiment or optimization, and cancel or decommission your instances when your replications are complete. In this way you minimize the cost of your distributed experiment or optimization. The costs and process of decommissioning your provisioned instances differ based on which 3rd party cloud provider you use. You may have access to local computing resources that could be configured for use in your FlexSim experiments or optimizations. In this case you may avoid additional costs relating to 3rd party cloud providers by using your own on-premises computers. Licensing for distributed Windows instances Windows instances used solely for distributed replications DO NOT need an individual FlexSim license. Only the FlexSim installation on the Main PC must be licensed. System requirements for distributed Windows instances Graphics A Windows instance should meet or exceed FlexSim's recommended requirements. However, because replications run as background processes without graphics, they need not meet the graphics requirements and do not need hardware accelerated graphics. CPU An instance can run as many concurrent replications as it has CPU cores. If, for example, an instance has 32 CPU cores, it can run 32 replications of your model simultaneously. RAM For this example of a 32-CPU Windows instance, if you want FlexSim to run 32 replications simultaneously - one on each core - then the instance must also have enough RAM to handle 32 concurrent model runs. On your Main PC, use Windows Task Manager to watch a single model run's RAM usage to determine its peak RAM utilization. If your model's RAM utilization peaks at 3GB throughout the course of a model run, you should make sure your 32-CPU system has at least 32*3 = 96GB of RAM for replications alone, along with a good ~10% more for additional overhead used for the Webserver and the statistics gathering and reporting from all the replications (this number could be more or less, depending on the model's stats gathering). In addition, you must account for your system's baseline RAM utilization - how much RAM it uses just to run the operating system and all its background processes. You can find this baseline by checking the Task Manager at a moment when you're not running any simulations. Add all these together to see how much RAM would be necessary to run a replication on each core of the instance. If your instance doesn't have enough RAM to handle that many simultaneous replications, you'll need to limit the number of CPUs FlexSim will use when configuring your Cloud Computing settings from the Main PC. Disk Disk space is usually not an issue. However, if you are using the Store Data on Hard Drive option in the Statistics Collector, you will need to be sure that there is enough disk space to run the model to completion on the hard drive, multiplied by the number of cores. The amount of disk space on each instance may affect the total cost of using a 3rd party cloud provider. More information See the related sections in the article Recommended System Requirements for a more in-depth discussion of system components such as CPU and RAM, and how they relate to running your simulations and experiments. Provisioning distributed Windows instances The process of provisioning 3rd party cloud instances for running distributed FlexSim replications will differ from provider to provider. FlexSim has guides for the following cloud providers: Amazon Web Services Wherever you decide to host your instances, the important part is that eventually you end up with a group of Windows instances, each with a unique IPv4 address accessible from the Main PC. A custom Windows image Your 3rd party cloud provider probably allows you to save a custom Windows image that can include software and settings that you need for each Windows instance. Doing this once for a custom Windows image saves you time when starting new instances - each instance will start with the software and settings preconfigured for your purpose. On your custom image, do the following Download and install FlexSim. Use the same version of FlexSim as is licensed on the Main PC. Remember, you DO NOT need to activate a license. Run FlexSim. This creates a directory that is needed later. After FlexSim finishes its first start, close FlexSim. Download and install the FlexSim Webserver for your installed version of FlexSim. Edit the Webserver's configuration file appropriately for your situation. Default location is here: "C:\Program Files (x86)\FlexSim Web Server\flexsim webserver configuration.txt" Start the FlexSim Webserver from your Windows Start menu, or manually from the default location here: "C:\Program Files (x86)\FlexSim Web Server\flexsimserver.bat". The Webserver will download necessary files the first time it is run. Close the Webserver after it has completed its initial startup. Allow both FlexSim and node.js through the Windows Firewall. To do so, use Windows' Allow an App through the Windows Firewall tool. You will need to browse for both FlexSim and Node.js. Example locations (exact locations may vary by version): C:\Program Files\FlexSim 2023\program\flexsim.exe C:\Program Files\nodejs\node.exe If you are not familiar with the FlexSim Webserver, please review its documentation and test it out on a local machine to understand what it does, its configuration options, etc. If you cannot configure a custom Windows image, you will need to do the above on each instance individually. Initialize instances Launch your instances. On each instance, do the following: Log in to the instance with Remote Desktop or some other solution. Start the FlexSim Webserver from your Windows Start menu, or manually from the default location here: "C:\Program Files (x86)\FlexSim Web Server\flexsimserver.bat". Note the instance's IPv4 address. Once all instances are running the Webserver, you are ready to configure a distributed experiment or optimization from the Main PC. Author's Note: There is probably a way to make it so that when instances start up, they automatically run the Webserver, so that you don't have to manually connect to each one. I welcome any suggestions or steps for how to make that happen. Configuring a distributed experiment or optimization Once you have a list of running instances available, launch FlexSim on the Main PC. Open the experimenter interface from FlexSim's Main Menu > Statistics > Experimenter. Configure your experiment. As part of your configuration, under the Advanced tab, select the option to Use Distributed CPUs. Press the button to Configure Cloud Nodes. This will open the Global Preferences' Environment tab. Enter the IP addresses of your instances into FlexSim. Enter the port numbers you configured in their FlexSim Webservers. If your instances will max out RAM before CPUs, enter a CPU count representing the maximum number of concurrent replications your instance can handle. For more information on using remote computers for Experiment Jobs, see Running Jobs on the Cloud for more information.

One of the new features in FlexSim 2018 Update 2 is the ability to use distributed CPUs for the Experimenter or Optimizer. Those cores can exist on any machine that meets the following requirements: The machine is accessible by IPv4 address The machine has FlexSim installed The machine is running the FlexSim Webserver (version 18.2.0 or later) on port 80 The machine meets hardware requirements to support running the specified number of simultaneous replications. This article describes how to use Amazon Web Services to create remote machines that meet the above requirements. Using AWS, you can launch and connect to as many servers as you want, and pay only for the time used on those instances. Anticipated Use Case Using distributed CPUs can significantly reduce the required time to run an experiment if: The time to run a single replication is high (a couple minutes or more) The number of replications to run is high If the time per replication is short, then the increased communication overhead may outweigh the benefit of using distributed CPUs. The communication overhead increases because all CPUs still report results to a single FlexSim process, and that communication occurs over the internet, rather than on a single machine. If an Experiment or Optimization completes in an acceptable amount of time, you may not need to use distributed CPUs. Financial Costs Amazon charges for its services. Costs for running instances (and transferring data out of them) are found here : https://aws.amazon.com/ec2/pricing/on-demand/ Costs for storing data (including AMIs) are found here: https://aws.amazon.com/ebs/pricing/ These instructions include steps to create an AMI, which will likely cost around $1 per month at current rates. It also includes steps for launching high-performance instances, which have an hourly cost. Suitable instances can be as cheap as $0.50 per hour. Note that there are also charges for transferring data from an instance to another computer. Step 0: Complete an EC2 Tutorial If you are not already familiar with EC2 instances, you should complete the following tutorial: https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/EC2_GetStarted.html Step 1: Create a Security Group You will need to create a security group with the following rules: Allow HTTP traffic on port 80. This allows incoming connections to the FlexSim Webserver. You can choose which inbound IP addresses to accept. You should make this as strict as possible. The strictest setting is to only allow incoming connections from the current IP address. Allow TCP traffic on ports 9000-9200. This is a Custom TCP rule. Note that you can make this range smaller, if all machines that use this Security Group have fewer than 200 cores. For example, if the biggest machine launched with this Security group has 72 cores, you would only need ports 9000-9072 in this rule. Allow RDP traffic on the default RDP port. This allows you to connect to the instance using remote desktop. Name the Security Group something that shows that this group is related to running FlexSim instances, and add a description if you want. Here is an example Security Group that works, but allows all TCP traffic, and so should only be used for testing purposes: Step 2: Create a Custom Amazon Machine Image (AMI) You will need to create a custom AMI. A custom AMI allows you to launch an instance that has the software you need already installed. To create one, follow these steps: Download the FlexSim installer and the Webserver installer. If your upload speed is slow, you can skip this step. Launch the cheapest instance available, with the Windows 2016 Server Base image. There are probably free-tier instances available in the list Connect to that Instance with Remote Desktop Copy (or download, if upload speed is slow) the FlexSim installer to the remote machine, and run it to install FlexSim. You do NOT need to activate a license. Run FlexSim. This creates a directory that is needed later. Then close FlexSim. Copy (or download, if your upload speed is slow) the Webserver installer to the remote machine, and run it to install the webserver. If using the 2018 Update 2 Beta, be sure to change the Webserver configuration file accordingly. Run the Webserver. It will download a bunch of files the first time it is run. Allow both FlexSim and node.js through the Windows Firewall. To do so, use the Allow an App through the Windows Firewall tool. You will need to browse for both FlexSim and Node.js. Both are in the ProgramFiles directory. Disconnect the Remote Desktop session Go to the list of Instances in the AWS Console From the Actions menu, select Image, then select Create Image: Add a name and description. Click the Create Image button On the next dialog, click the View Pending link, or navigate to the list of AMIs: Once the image becomes Available, terminate the running instance. Step 3: Launching Usable Instances Before running an Experiment or Optimization, you need to be sure that all remote instances you will use are current running. To launch and initialize these instances, follow these steps: In the EC2 Console, choose Launch Instance Select the AMI you created, from the list of My AMIs Choose the Instance Type and quantity Set the Security Group to use the Security Group you created Launch the instance Once each instance is initialized, connect to each one with Remote Desktop. Note that when you launch an instance with a given Key File, the password for each instance will be the password associated with that Key File, so you only need to decrypt the file once. Start the FlexSim Webserver in each instance Once all instances are running the Webserver, you are ready to run an Experiment or Optimization. Author's Note: There is probably a way to make it so that when instances start up, they automatically run the Webserver, so that you don't have to manually connect to each one. I welcome any suggestions or steps for how to make that happen. Step 4: Using the Instances in FlexSim Once you have a list of running instances available, you just need to input their IP Addresses into FlexSim, on the Advanced tab of the Experimenter: Once you have input this information, you just need to click the Experiment or Optimize button. FlexSim will then use the remote CPUs for running replications. Considerations Spot Pricing Amazon offers two pricing models: On Demand and Spot Pricing. FlexSim recommends On Demand instances. Spot instances can be significantly cheaper, but they can also be shut down by Amazon and given to an On Demand user at any time, if On Demand requests exceed the number of available machines. FlexSim does not try to recover from this kind of error, and it may lead to unexpected behavior. CPU Count, RAM, and Disk Space When you pick an instance type, be sure to understand how much ram you will need. If a model requires 4 GB of RAM while running, and you use an instance with 128 cores, be sure that the instance has at least 512 GB of RAM, or don't use all 128 cores. Disk space is usually not an issue. However, if you are using the Store Data on Hard Drive option in the Statistics Collector, you will need to be sure that there is enough disk space to run the model to completion on the hard drive, multiplied by the number of cores. The amount of disk space on each instance also affects the total cost of using this service.

In this article, you will learn how to export data from individual replications to an external database. This is an advanced tutorial, and assumes some exposure to databases and SQL. It also assumes that you are familiar with the Experimenter and/or Optimizer feature in FlexSim. This tutorial uses PostgreSQL, but should be compatible with the most popular SQL database engines. Model Description Let's assume you have a model with at least one Statistics Collector, as well as an experiment ready to go. The model used in this example is fairly simple: As the model runs, a Statistics Collector fills in a table. The table makes a new row for every item that goes into the Sink, recording the time, and the Type label of the item: For the experiment, we don't have any variables, but we do have one Performance Measure: Input of the Sink. Of course, an actual model would have many Variables, Scenarios, and Performance Measures, but this model leaves out those details. For reasons which come up later, this model also has two global variables, called g_scenario and g_replication. We will use these during the experiment phase. Connecting to the Database To connect to a database, you can use the Database Connector tool. Each Database Connector handles the connection to a single database. If you need to connect to more than one database, you will need more than one Database Connector. For this model, I have added a Database Connector, and configured the connection tab as follows: This configuration allows me to connect to a PostgreSQL database called "flexsim_test" running on my computer at port 9001. You can test the connection by clicking the "Test Connection" button. The test attempts to connect, as well as query the list of tables found in the database. Setting Up the Export Next, take a look at the Export tab: This tab specifies that we are exporting data from StatisticsCollector1 to the table called experiment_results in the database (this table should exist before you set up the export). The Append to Table box means that when the export occurs, the data will be added to the table. Otherwise, the data would be cleared from the target table. The other interesting thing here is that we are exporting more columns than the Statistics Collector has, namely the Scenario and Replication number. However, the expression in the From FlexSim Column column must be valid FlexQL (FlexSim's internal SQL language). Wrapping the values in Math.floor() leaves the values unchanged, and works well with FlexQL. Setting up the Experimenter Finally, let's take a look at just a little bit of code that makes the Experimenter dump data to a database. There is code in Start of Experiment, Start of Replication, and End of Replication: In the Start of Experiment, we need to clear the table. The code in this trigger connects to the database, runs the necessary query, and the closes the connection to the database. In the Start of Replication trigger, the code simply copies the replication and scenario values into the global variables we created for this purpose. In the End of Replication trigger, the code uses function_s to call "exportAll" on the database connector that we created. This uses the settings on the Export tab to dump the data from StatisticsCollector1 to the database table, including the replication and scenario columns. These same triggers run during an optimization, so the same logic will apply. Run the Experiment Finally, you can run the experiment. When each replication ends, the Statistics Collector data will be exported to the database. Databases can handle many connections simultaneously. This is important, because the child processes that run replications will all open individual connections to the database at the end of each replication. This leads to many concurrent connections, which most databases are designed to handle. But how can we tell that it worked? If you connect to the database with another tool, you can see the result table. Note that there are 1700 rows, and that data from Replication 5 is included. Additionally, you could use the Import tab to import all the data, or summary of the data data, into FlexSim. Conclusion Storing data in a database during an experiment is not difficult to do. There are many excellent tools for analyzing and visualizing database tables, which you could then use to further explore and understand your system. postgresqlexperimentdemo.fsm

Quando desenvolvemos um modelo de simulação que possua diversas ou até mesmo elevado número de variáveis de entrada, faz-se necessário analisar diversos cenários dentro de um simulador para termos o maior número de detalhes possíveis com relação ao comportamento do sistema. No FlexSim, o recurso que permite esse tipo de análise é o Experimenter. Com ele, podemos estimar como as variáveis de entrada, afetam as respostas de um experimento e pode-se planejar de forma racional os cenários a serem executados. O vídeo explicando um pouco sobre experimentos e também falando sobre o Experimenter, encontra-se em nosso Canal no Youtube.