San Francisco, CA & Denver, CO – Denver-based Boom Technology is leveraging Rescale’s cloud-based simulation and optimization system to enable a rebirth of supersonic passenger travel.

Boom’s aircraft is faster than Concorde yet dramatically more efficient and affordable.  Concorde was designed 50 years ago, in an era when aerodynamic optimization required painstaking wind tunnel testing, with each iteration costing millions and taking months.  Today, modern computational fluid dynamics (CFD) simulations enable months of wind tunnel testing to be accomplished in minutes of simulation.

Moreover, Rescale’s cloud-based platform enables Boom to access world-class CFD resources without the expenditures required for an on-premises computing cluster or the custom software development required by other cloud platforms.  Boom chose to use Rescale’s HPC platform because they can access massive-scale computing resources while paying just for the results they need, when they need them.

Using Rescale’s cloud HPC platform, Boom is running computational fluid dynamics simulations of their aircraft and propulsion system.  The results help Boom validate the overall cruise performance of the aircraft and confirm that the design meets fuel efficiency targets.  Boom engineers are able to turn around CFD results on the airplane & inlet designs in hours—not months required by traditional wind tunnel testing.

The average simulation runs on hundreds of cores.  Building an internal large data center is a time consuming and expensive process.  Rescale’s platform has saved Boom hundreds of thousands of dollars in server hardware costs.  But even more importantly, Rescale has saved the time, resources, and expertise required to maintain an on premise HPC and multidiscipline simulation software.

For a supersonic company like Boom, the demand for compute resources is unpredictable.  Engineering schedule and time to market are the business driver.  There is always a need to simulate a new condition with results turned around quickly.  The Rescale platform elasticity is a perfect fit for Boom variable demand.

“Rescale’s cloud platform is a game-changer for engineering.  It gives Boom computing resources comparable to building a large on premise HPC center.  Rescale lets us move fast with minimal capital spending and resources overhead,” Joshua Krall, Co-founder & CTO.

“We’re very excited to be working with Boom and helping them move at supersonic development speed”, says Joris Poort, Rescale CEO.  “We understand the variable demand for resources that comes with this work and Rescale’s powerful, on-demand cloud HPC enables Boom to get the results they need quickly and only pay for compute resources when they’re using them.”

Boom is building their prototype aircraft now, which will fly by the end of 2017.

About Boom:
Boom was founded on the philosophy that we need to overcome the challenges to supersonic passenger flight, not surrender to them.  Our first product is a supersonic aircraft affordable for routine business travel.  Our ultimate goal is routine supersonic flight for everyone.  For more information, visit

About Rescale:
Rescale is the world’s leading cloud platform provider of simulation software and high performance computing (HPC) solutions. Rescale’s platform solutions are deployed securely and seamlessly to enterprises via a web-based application environment powered by preeminent simulation software providers and backed by the largest commercially available HPC infrastructure. Headquartered in San Francisco, CA, Rescale’s customers include global Fortune 500 companies in the aerospace, automotive, life sciences, marine, consumer products, and energy sectors.  For more information on Rescale products and services, visit

This article was written by Rescale.

futurefacilities (1)

High performance computing now available through cloud bursting to 6SigmaET and 6SigmaDCX customers around the world

London, UK – Future Facilities today announces a new partnership with Rescale, a cloud-based simulation platform provider.  The relationship will allow facility managers, architects and designers from across the globe to perform the most complex data center modeling quickly, using high performance computing (HPC) in the cloud to keep up with increasing demand for fast and accurate results from the enterprise.

The partnership will allow customers of Future Facilities’ best-in-class 6SigmaET and 6SigmaDCX computational fluid dynamics (CFD) software to access Rescale’s HPC capabilities.  When on premise IT infrastructure is already utilized or incapable of dealing with the size of model, cloud overflow will deliver instant, scalable and secure compute resource.  In addition, customers can choose to use Rescale’s cloud exclusively for solving by storing their solver license with Rescale and then purchasing hardware time on-demand removing the high initial costs of on-site hardware.


Jonathan Leppard, Director at Future Facilities said: “The rapidly growing number of electronic devices known as the internet-of-things is leading to an explosive growth in demand for back-end computing resources.  Equally, data centers are only getting larger and more complex to meet the ever-growing demand for compute power from enterprise applications.  In order to run these large and complex data centers efficiently, our 6SigmaET and 6SigmaDCX suites are vital to truly understand the complex thermal environments inside data centers and electronics.”

He continued: “There is a constant battle between accuracy and speed of results, with some simple tools on the market sacrificing accuracy for faster results – a bad compromise when you consider the critical importance of these environments.  Our partnership with Rescale now allows organizations to have the best of both worlds: true CFD modelling that takes advantage of unlimited compute resource allowing for accuracy as well as quick turnaround”.


Joris Poort, CEO at Rescale said: “Complex simulations have high computing requirements – however this scale of compute demand is usually not needed outside of these simulation scenarios.  Through our partnership with Future Facilities, many more organizations can now use our world-class secured compute capabilities when they are needed.  We look forward to helping enable the next generation of devices and data centers come to life with Future Facilities.”

Future Facilities and Rescale will be hosting a joint webinar on Wednesday 15th June at 16:00 BST, demonstrating how to set up and run 6SigmaDCX and 6SigmaET simulations on Rescale’s cloud platform.

About Future Facilities:

For over a decade, Future Facilities has provided computational fluid dynamics (CFD) software and consultancy services to the world’s largest data center owner-operators and to the industry’s leading consultancies.  With global offices, our managed engineering services and modeling software are relied on to deliver unique insight into the current and future performance of our clients’ mission critical data centers.  We call our approach ‘engineering simulation’.

About Rescale

Rescale is a secure, cloud-based, high performance computing platform for engineering and scientific simulations.  The platform allows engineers and scientists to quickly build, compute, and analyze large simulations easily on demand.  Rescale partners with industry-leading software vendors to provide instant access to a variety of simulation packages while simultaneously offering customizable HPC hardware.  Headquartered in San Francisco, CA, Rescale’s customers include global Fortune 500 companies in the aerospace, automotive, life sciences, and energy sectors.  For more information on Rescale products and services, visit

This article was written by Future Facilities.


React version 15 has deprecated valueLink which was a property on form elements for expressing two-way binding between the value of the form element and a state property of the component using the element. The recommended replacement is to explicitly specify the value as a prop and to supply an onChange handler instead.

At Rescale, we use valueLink a lot. When creating components for modifying business objects—our business objects are usually immutable Record instances of the Immutable library—we use the pattern of passing the business object to the component via props, and then initializing a state property on the component to said object via getInitialState. Here’s pseudocode for illustration:

What’s good about this pattern is that since our business objects are immutable, the company passed into the component ( will be guaranteed not to change in the course of modifying the company within this component, but the company referenced by state ( may change when handleNameChange gets called. With this pattern, the state of the component can be thought of as a “staging” area for changes to the model. We can do stuff like compare the company referenced by state with the company referenced by props to determine whether any changes were made, and we can easily revert changes or abandon changes.

As you can see though, it gets a bit tedious creating handlers for every field of the model that can be modified by the form. In our example we needed handlers for changes to name and changes to budget. But, it’s not too hard to create a function that will generate an object with an appropriate { requestChange, value } pair and then feed that object to valueLink. Indeed that’s what react-addons-linked-state-mixin and reactlink-immutable is used for.

However, in React 15, we are to use value and onChange instead of valueLink. Switching over to use value isn’t that big of a deal, we just write it out like in the example above. The only caveat is that for checkboxes we need to use checked instead of value.

Creating a factory that generates handlers for onChange is something we decided to implement ourselves since we use a mix of simple component states (states with simple string or boolean values) and states that reference Immutable objects. Here’s such a factory for generating onChange handlers (named linkState, not to be confused with the this.linkState given by react-addons-linked-state-mixin):

We can use this to replace the valueLinks in the above example:

What’s nice about our implementation is that we don’t need to use mixins which may be deprecated in the future, and we’re using the same factory function for creating handlers that deal with simple states as well as for deep modifications of immutable objects. This means we can remove the react-addons-linked-state-mixin and reactlink-immutable dependencies in our projects.

This article was written by Kenneth Chung.


Rescale’s Design-of-Experiments (DOE) framework is an easy way to optimize the performance of machine learning models.  This article will discuss a workflow for doing hyper-parameter optimization on deep neural networks.  For an introduction to DOEs on Rescale, see this webinar.

Deep neural networks (DNNs) are a popular machine learning model used today in many many applications including robotics, self-driving cars, image search, facial recognition, and speech recognition.  In this article we will train some neural networks to do image classification and show how to use Rescale to maximize the performance of your DNN models.


For an introduction on training an image classification DNN on Rescale, please see this previous article.  This article will expand on the basic model training example and show how to improve the performance of your network through a technique called hyper-parameter optimization.

Hyper-Parameter Optimization

A typical starting point for a task using DNNs is to select a model published in the literature and implement it in the neural network training framework of your choice, or even easier, download an already-implemented model from the Caffe Model Zoo.  You might then train the model on your training dataset and find that the performance (classification accuracy, training time, etc.) is not quite good enough.  At this point, you could go back and look for a whole new model to train, or you can try tweaking your current model to get the additional performance you desire.  The process of tweaking parameters for a given neural network architecture is known as hyper-parameter optimization.  Here is a brief list of hyper-parameters people often vary:

  • Learning rates
  • Batch size
  • Training epochs
  • Image processing parameters
  • Number of layers
  • Convolutional filters
  • Convolutional kernel size
  • Dropout fractions


Given the large list hyper-parameter choices above, even once we set the model architecture, there are still a large number of similar neural network variants.  Our task is to find a variant that performs well enough for our needs.

Randomized Hyper-Parameter Search DOE

Using the Rescale platform, we are now going to create a Design-of-Experiments job to sample hyper-parameters and then train these different network variants using GPUs.

For our first example, we will start with one of the example convolutional networks from the Keras github repository to train an MNIST digit classifier.  Using this network, we will vary the following network parameters:

  • nb_filters: Number of filters in our convolutional layer
  • nb_conv_size: Size of convolutional kernel

We modified the example to have the template values above and here is an excerpt from the script with the templated variables:

Note the nb_filters and nb_conv_size parameters surrounded by ${}.  We are now ready to create a DOE job on the Rescale platform that uses this template.

If you want to follow along, you can clone the example job:



First, we select the DOE job type in the top right corner and upload the mnist.pkl.gz dataset from the Keras github repository.


Next, we specify that we are running a Monte Carlo DOE (lower left), that we want to do 60 different training runs, and we specify our template variables.  We somewhat arbitrarily choose both parameters to be sampled from a uniform distribution.  The convolutional kernel size ranges from 1 to 10 (each image size is 28×28, so more than 28 would not work), and the number of convolutional filters ranges from 16 to 256.

Note, we could specify our template variable ranges with a CSV instead.  For this example, we would manually sample random values for our variables and the CSV would look like this:


Next, we need to upload the Keras script template that we created above.  At this point, we can also specify a new name for the script with the values inserted.  It is also fine if you just want to keep the name the same, as we have done here.  The materialized version will not overwrite the template.


Time to select the training library we want to use. Search for “Keras” in the search box and select it. Then, we select the K520/Theano compatible version.  Finally, we enter the command line to run the training script.  The first part of the command is just copying the MNIST dataset archive into a place where Keras can find it.  Then, we are just calling the python script.


Since we selected a version of Keras configured to work with K520s, our hardware type is already narrowed down to Jade.  We can now size each training cluster on the left.  The count here is in number of CPU cores.  For the Jade hardware type, there are 4 CPU cores for every GPU.  On the right, we set the number of separate training clusters we will provision.  In this case we are using 2 training clusters with a single GPU per cluster.


The last step is to specify the post-processing script.  This script is used to parse the output of our training jobs and make any metrics available to Rescale to show in the results page we will see later.  The expected output format is a line for each value:

Since the training script already prints the properly formatted accuracy as the last line of its output, result.out, our post-processing script just needs to parse out that last line.

You can now submit the job in the upper right and we move to the real-time cluster status page.


Once the clusters are provisioned and the job starts, we can view the progress of our training jobs.  In the live tailing window, select a run and select process_output.log.  If the training has already started, you can view the training progress and the current training accuracy.  Individual runs can be terminated manually by selecting the “x” next the select run number.  This enables the user to stop a run early if the parameters are clearly yielding inferior accuracy.


Once our job completes, the results page summarizes the hyper-parameters used for each run and the accuracy results.  In the above case, the initial model we took from the Keras examples had an accuracy of 99.1% and the best result we obtain has an accuracy of about 99.4%, a small improvement.  If we want to download the weights for the most accurate model, we can sort by accuracy and then select the run details.


Among other results files is mnist_model.json and mnist_model.h5, which are the model architecture and model weights files needed to reload the model back into Keras.  We can also download all the data from all runs as one big archive or download the results table as a CSV.


Our accuracy results can also be visualized in the charting tab.

Bring Your Own Hyper-Parameter Optimizer

Rescale supports use of 3rd party optimization software as detailed here.  We will now discuss creating a Rescale optimization job to run a black-box optimizer from the machine learning literature.

Using the Rescale optimization SDK, we choose to plug in the Sequential Model-based Algorithm Configuration (SMAC) optimizer from the University of British Columbia.  The SMAC optimizer builds a random forest model of our neural network performance, based on the hyper-parameter choices.  We use version 2.10.03, available here.

The optimizer is a Java application which takes the following configuration:

  • “scenario” file: specifies the command line for the optimizer to run, in this case this is our network training script
  • parameter file: specifies the names of our hyper-parameters and ranges of values

When SMAC runs the training script, it passes the current hyper-parameter selections to evaluate as command line flags.  It expects to receive results from the run in stdout, formatted as a string like this:

Result of this algorithm run: , , , , ,

To start, we create a parameter file for the hyper-parameters we will vary in this experiment:

Now, in addition to varying the convolutional filter count and convolutional kernel size, we are also varying the dropout fractions and the size of the pooling layer.

Now we look at modifications made to our previous training script to accommodate SMAC input and results:

Rather than injecting hyper-parameter values in as a template, we now just use argparse to parse the flags that are provided by SMAC.

Since we are feeding errors into an optimizer that then selects new parameters based on that error, we now keep separate validation and test datasets.  Above we are splitting the original training data into a training and validation set.  It is important to hold out a separate test dataset so we have an error metric to evaluate that is not in danger of being overfit by the optimizer.  The optimization algorithm only gets to see the validation error.

Here we train the model, evaluate it on the validation and test datasets, and then output the results in the SMAC-specific format (“Result of algorithm…”).  Note, we also catch any errors in training and validation and mark that run as “UNSAT” to SMAC so that SMAC knows that it is an invalid combination of parameters.


In order for SMAC to call the Rescale python SDK, we write a wrapper script, which we will call, and specify for SMAC to call it in the scenario file.  The wrapper then submits the training script to be run.

Some important excerpts from the wrapper script:

To start, we take all the command line flags passed into the script and pass them directly to our objective function.  This is the objective function that will be called for each set of hyper-parameters.

To start the objective function, we package up the input files for this training run into a .zip file.

Here, we format the training script command we will run.  Note, that we are just passing the flags from SMAC (variable X) through to the training script.  Then, we call the submit command which sends the input files to the training cluster and starts training.  We also now call the format_results script ourselves.

We parse the output file from the training script to get the expected SMAC results line (“Result of algorithm run…”), as well as the error on the test dataset.

Finally, we need to specify the scenario file that tells SMAC to call our wrapper script.

The important parts here are:

pcs-file: specifies the parameters
algo: wrapper script to run
numberOfRunsLimit: sets the number of training runs
check-sat-consistency: tells the optimizer that for the same training dataset, different parameter selections might lead to a feasible or infeasible model

So now that we have all of our input files, we are ready to create a job.

You can clone the job to run yourself here:

Keras MNIST SMAC Optimizer


The input.tar.gz archive consists of an input/ directory with the our training script and the post-processing script.

We select the same software as before, Keras configured for Theano on a K520.


Hardware selection is roughly the same as well. We again select 2 task slots to train 2 networks in parallel.


For the optimizer, we select “Custom Optimization” and then enter the command line to run SMAC.  This command is made complicated by the fact that each SMAC process only runs one iteration at a time.  To run multiple trainings in parallel, we must use SMAC’s “shared model mode”.  Turning on this mode tells SMAC to periodically check its current directory for optimizer results from other SMAC processes and incorporate those results.  This mode requires we set the “-seed” to a different value for each SMAC process.

Since we need to run multiple optimizer processes at once, we background all the calls and then sleep for the maximum amount of time we would want to run this optimizer for.  In this case, we are waiting for 4 hours.

This job is now ready to submit.  Once running, you can live tail current iterations, and at the end, view results just as in the previous randomized case.  The results will now show both the validation and test errors for each set of hyper-parameters.


In this article, we showed 2 ways to search the space of hyper-parameters for a neural network.  One used randomized search and the other used a more sophisticated optimization tool, making use of the Rescale optimization SDK.

This article was written by Mark Whitney.