Resource Size Selection Guidance

When running models in Cosmic Frog, users can choose the size of the resource the model’s scenario(s) will be run on in terms of available memory (RAM in Gb) and number of CPU cores. Depending on the complexity of the model and the number of elements, policies and constraints in the model, the model will need a certain amount of memory to run to completion successfully. Bigger, more complex models typically need to be run using a resource that has more memory (RAM) available as compared to smaller, less complex models. The bigger the resource that is being used, the higher the billing factor which leads to using more of the available cloud compute hours available to the customer (the total amount of cloud compute time available to the customer is part of customer’s Master License Agreement with Optilogic). Ideally, users choose a resource size that is just big enough to run their scenario(s) without the resource running out of memory, while minimizing the amount of cloud compute time used. This document guides users in choosing an initial resource size and periodically re-evaluating it to ensure optimal usage of the customer’s available cloud compute time.

Resource Size and its Components

Once a model has been built and the user is ready to run 1 or multiple scenarios, they can click on the green Run button at the right top in Cosmic Frog which opens the Run Settings screen. The Run Settings screen is documented in the Running Models & Scenarios in Cosmic Frog Help Center article. On the right-hand side of the Run Settings screen, user can select the Resource Size that will be used for the scenario(s) that are being kicked off to run:

1. On the right-hand side of the Run Settings screen, user can select the Resource Size.
2. The Resource Size drop-down shows all resource sizes available for selection, from Mini (smallest) to Supernova (biggest). A resource size is a combination of the number of CPU cores and the amount of memory (RAM) that is available when using that resource. Using more cores leads to shorter runtimes as certain tasks can be handled simultaneously instead of sequentially. In the above screenshot, Resource Size S has been selected. This resource has 4 CPU cores available and up to 16 Gb (Gigabytes) RAM. The resource size drop-down also lists the Billing Factor of the resource. For example, the 3XS resource size has a Billing Factor of 0.5. This means that if a scenario run takes 2 minutes, 1 minute is billed to the user and subtracted from the total cloud compute time still available. The 3XS resource is a small resource (1 CPU core and up to 2 Gb of RAM), and therefore cheaper to run on. As another example, the 2XL resource size has a billing factor of 2, meaning that a run taking 15 minutes will be billed as 30 minutes of cloud compute time used. This resource has 8 CPU cores, so will be able to perform quite a few tasks in parallel, and up to 128Gb of RAM, which is why it is more expensive to run.
3. Note that in order to use Supernova, the biggest resource available with 32 CPUs, 2,000 Gb of RAM and a billing factor of 50, users need a professional business account (see also the compare plans webpage). To ensure a user wants to go ahead with using this large and more expensive resource, an additional message confirming the choice will be shown to the user; this message reads: “Supernova is our most powerful resource size (billing factor 50x), designed for extremely large and complex models. Please ensure this size is appropriate before proceeding”:

1. The Supernova resource size has been selected. To warn the user they have done so, the font color of Supernova is gold, and there is a gold exclamation mark icon next to it.
2. The text of the warning is displayed at the bottom of the run screen.
3. Users can also click on the Resource Size Selection Guide link to open this Help Center article.

Choosing an Initial Resource Size

In this section, we will guide users on choosing an initial resource size for the different engines in Cosmic Frog, based on some model properties. Before diving in, please keep following in mind:

• One can more quickly home in on the most appropriate resource size for a scenario by starting with one that is too large, rather than too small. A scenario run will end in an error if not enough memory is available with no indication of how much memory is required. In the logs of a successful run, maximum memory usage will be listed, which users can use to select the most appropriate resource size for their next run(s). See more on where to find this information in the "Evaluating the Resource Size" section further below.
• It is not possible to predict exactly how much memory a scenario needs to run to completion successfully. However, we can make an educated best estimate based on test models run by Optilogic. This is intended to be a starting point from which users can finetune the resource size further by taking the steps described in the “Evaluating the Resource Size” section further below.

Neo (Optimization)

There are quite a few model factors that influence how much memory a scenario needs to solve a Neo run. These include the number of model elements, policies, periods, and constraints. The type(s) of constraints used may play a role too. The main factors, in order of impact on memory usage, are:

1. The number of lanes. This is the number of source-destination-product-period combinations that are considered in the model.
2. The number of demand records.
3. The number of constraints.

These numbers are those after expansion of any grouped records and application of scenario items, if any.

‍

The number of lanes can depend on the Lane Creation Rule setting in the Neo (Optimization) Parameters:

1. After clicking on the Run button at the right top in Cosmic Frog, the Run screen opens.
2. When Neo is selected as the Engine, the Neo (Optimization) Parameters will be applied. To view these, expand this section in case it is collapsed.
3. One of the parameters users can select is the Lane Creation Rule and this will impact the total number of lanes that the scenario(s) will contain. There are 4 options here:
   
   1. Transportation Policy Lanes Only: the lanes that are set up on the Transportation Policies table will be part of the scenario(s); any records on the Sourcing Policies tables will not be used for lane creation.
   2. Sourcing Policy Lanes Only: the lanes that are set up on the Sourcing Policies tables will be part of the scenario(s); any records on the Transportation Policies tables will not be used for lane creation.
   3. Intersection: lanes that exist both in the Transportation Policies and Sourcing Policies tables will be part of the scenario(s); any lanes that only exist in either the Transportation Policies table or a Sourcing Policies table will not be used (this is like an inner join).
   4. Union: all lanes that exist in the Transportation Policies table and all lanes that exist in the Sourcing Policies tables will be used for lane creation (any duplicates will be removed).

Note that for lane creation, expansion of grouped records and application of scenario item(s) need to be taken into account too to get at the number of lanes considered in the scenario run.

‍

Users can use the following list to choose an initial resource size for Neo runs. First, calculate the number of demand records multiplied with the number of lanes in your model (after expansion of grouped records and application of scenario items). Next, find the range in the list, and use the associated recommended initial resource size:

‍

# demand records * # lanes: Recommended Initial Resource Size

• <1*10³: Mini
• ~1*10³ – 1*10⁸: 4XS – 3XS
• ~1*10⁸ – 1*10¹⁰: 2XS – S – M
• ~1*10¹⁰ – 1*10¹¹: L - XL
• ~1*10¹¹ – 5*10¹⁴: 2XL – 3XL
• ~5*10¹⁴ – 5*10¹⁵: 4XL
• >5*10¹⁵: Overkill

Throg (Simulation) & Dendro (Inventory)

A good indicator for Throg and Dendro runs to base the initial resource size selection on is the order of magnitude of the total number of policies in the model. To estimate the total number of policies in the model, add up the number of policies contained in all policies tables. There are 5 policies tables in the Sourcing category (Customer Fulfillment Policies, Replenishment Policies, Production Policies, Procurement Policies, and Return Policies), 4 in the Inventory category (Inventory Policies, Warehousing Policies, Order Fulfillment Policies, and Inventory Policies Advanced), and the Transportation Policies table in the Transportation category. The policy counts of each table should be those after expansion of any grouped records and application of scenario items, if any. The list below shows the minimum recommended initial resource size based on the total number of policies in the model to solve models using the Throg or Dendro engine.

‍

Number of Policies: Minimum Resource

• 1000: XS
• 10,000: S
• 50,000: M
• 100,000: L
• 500,000: XL
• 1,000,000: 2XL
• >10,000000: 4XL

Hopper (Transportation)

For Hopper runs, memory is the most important factor in choosing the right resource, and the main driver of memory requirements is the number of origin-destination (OD) pairs in the model. OD pairs are determined primarily by all possible facility-to-customer, facility-to-facility, and customer-to-customer lane combinations.

‍

Most Hopper models have many more customers compared to facilities, and so we often can use the number of customers in a model as a guide for resource size. The list below shows the minimum recommended initial resource size to solve models using Hopper.

‍

Customers: Minimum Resource Size

• 100: mini
• 500: 4XS
• 1,000: 3XS
• 2,000: 2XS
• 3,000: XS
• 4,000 – 5,000: S
• 6,000 – 8,000: L
• 9,000 – 10,000: XL
• 15,000: 2XL
• 20,000: 3XL
• >20,000: Contact Support

Triad (Greenfield)

Most Triad models should solve very quickly, typically under 10 minutes. Still, choosing the right resource size will ensure your Triad model solves successfully, without paying for unneeded compute resources.

‍

As with Hopper, memory is the most important factor in resource selection. In Triad, the main driver of memory requirements is the number of customers, with a smaller secondary effect from the number of greenfield facilities.

‍

The list below shows the minimum recommended initial resource size to solve models using Triad where the number of facilities is assumed to be between 1 and 10:

‍

Customers: Minimum Resource Size

• ‍‍100: 3XS
• 500: 2XS
• 1,000: XS
• 2,000: S
• 3,000: S–L*

Please note:

• Models with more facilities than customers are infeasible.
• S and M resources have the same memory, so S can almost always be used in place of M.
• When running Triad with 3,000 or more customers, try an S resource first. If you encounter an “out of memory” error, then try an L resource. Triad implements clustering to reduce the memory requirement for each run. This is based on how far apart your customers are, and how well they naturally cluster – if your customers are close together and cluster naturally, a smaller resource size may be used.

Evaluating the Resource Size

After running a scenario with the initially selected resource size, users can evaluate if it is the best resource size to use or if a smaller or larger one is more appropriate. The Run Manager application on Optilogic’s platform can be used to assess resource size:

1. Go to the Run Manager application by clicking on its icon on the left-hand side when logged in to the Optilogic platform on cosmicfrog.com. Should you not see the Run Manager here, then click on the icon with 3 dots to show all applications; the Run Manager application should now be visible too.
2. Under Type at the top of the screen, filter for Scenario.
3. Find the scenario you want to evaluate the resource size of in the list of jobs, click on it to select it.
4. The Job Info for this scenario will be displayed on the right hand-side.
5. If not already selected, click on the i-icon to show the Job Info, other details of the job can be viewed by clicking on the icons to the right of the i-icon.
6. Part of the job information listed is what resource size the job was run on, in this case resource size 2XS was used, which has 2 CPU cores and up to 4Gb of RAM.
7. Next, click on the bar chart icon to see the Job Usage Metrics:

1. The legend tells us that the red bar represents the percentage of CPU that was used at peak usage and the yellow bar the percentage of memory used at peak usage.
2. 26.6% of the available memory was used at peak usage. This is with 4Gb of RAM available, so about 0.266 * 4 Gb = 1.064 Gb of RAM was used.

Using this knowledge that the RAM required at peak usage is just over 1 Gb, we can conclude that going down to resource size 3XS, which has 2Gb of RAM available should still work OK for this scenario. The expectation is that going further down to 4XS, which has 1Gb of RAM available, will not work as the scenario will likely run out of memory. We can test this with 2 additional runs. These are the Job Usage Metrics after running with resource size 3XS:

As expected, the scenario runs fine, and the memory usage is now at about 54% (of 2Gb) at peak usage.

‍

Trying with resource size 4XS results in an error:

1. The State of the job now says "error" instead of "done".
2. View the Job Error Log by clicking on the 6^th icon at the top of the right panel.
3. The Job Error Log contains a warning that the job ran out memory, which is what we expected as the scenario requires a bit over 1Gb of RAM at peak usage and the 4XS resource size has up to 1Gb of RAM available.

Note that when a scenario runs out of memory like this one here, there are no results for it in the output tables in Cosmic Frog if it is the first time the scenario is run. If the scenario has been run successfully before, then the previous results will still be in the output tables. To ensure that a scenario has run successfully within Cosmic Frog, user can check the timestamp of the outputs in the Optimization Network Summary (Neo), Transportation Summary (Hopper), or Optimization Greenfield Output Summary (Triad) output tables, or review the number of error jobs versus done jobs at the top of Cosmic Frog (see next screenshot). If either of these 2 indicate that the scenario may not have run, then double-check in the Run Manager and review the logs there to find the cause.

In the status bar at the top of Cosmic Frog, user can see that there were 2 error jobs and 13 done jobs within the last 24 hours.

‍

In conclusion, for this scenario we started with a 2XS resource size. Using the Run Manager, we reviewed the percentage of memory used at peak usage in the Job Usage Metrics and concluded that a smaller 3XS resource size with 2Gb of RAM should still work fine for this scenario, but an even smaller 4XS resource size with 1Gb of RAM would be too small. Test runs using the 3XS and 4XS resource sizes confirmed this.

Summary of Resource Size Selection Guidelines

1. When building out your model and its scenarios, be cognizant of the size of your model, and base your initial resource size on the appropriate table in the section “Choosing an Initial Resource Size” above. Remember that:
   
   1. If you choose a resource size that is too large, the scenario will run to completion fine and you can determine the more appropriate smaller resource size using the job usage metrics of this run.
   2. If you choose a resource size that is too small, the scenario will end in an error that will indicate that there is not enough memory available, but it will not tell you how much more it needs. In this case a good approach can be to select a resource 2 or 3 sizes bigger and then scale back again from there if the scenario runs fine and the job usage metrics indicate a smaller resource size should suffice.
   3. By using groups, it is easy to for example create all to all policies by just populating 1 record in the sourcing and/or transportation policies tables. However, these can make a model unnecessarily big and in need of more RAM to solve. Try to be aware of the number of enumerated records a grouped record will result in and ensure no more options than those realistically under consideration are included in your model.
2. Use the Job Usage Metrics that can be found in the Run Manager to assess if the resource size used is appropriate. Based on the peak RAM usage you can determine if you could use a smaller resource size and if so, which one should be the smallest one that has sufficient RAM.
   
   1. You can do this for each scenario that may be re-run frequently in future to see if it is worthwhile to run different scenarios with different resource sizes.
3. It is recommended to periodically re-assess if the resource size(s) used are still appropriate, this is especially important after making changes to your model.

‍