We sat down with customer Stewart Bible, co-founder of boutique engineering consulting firm Resolved Analytics, to talk about how his company uses Rescale, their motivation for computing on the cloud, and their plans for the future. Read the conversation below to hear how they’re using Rescale to remove computational bottlenecks and expand their client-serving abilities.

Q: Can you start by introducing yourself, your company, and your line of business?

A: My name is Stewart Bible and I’m one of the co-founders and a principal engineer at Resolved Analytics. We’re a boutique computational engineering and optimization consultant firm where we help customers improve product and process performance with CFD, finite element analysis, and other dynamical simulation tools.

Q: Can you describe your simulation needs and your computing environment before you started using Rescale?

A: Our simulation needs fluctuate depending on the number of customers that we have at any one time and the computational demands that the customers’ problems require. That’s why we find the cloud particularly interesting and useful: because one month we may need 64 processors to run two big problems or 128 processors to run a few big problems, and then the next month we have very low requirements. Owning a stand-alone software license capable of handling the highest workloads  doesn’t make a whole lot of sense during those months when you only need 8 or 16 processors because it ends up being a stranded asset. Our internal capability before Rescale was 16 processors.

Q: You kind of touched on this, but can you describe the pain points that led you to consider Rescale?

A: We ran the cost analysis on last year’s compute requirements and projected 2017 compute requirements. If you add up all the licensing costs for executing those jobs solely internally versus some internally and some in the cloud, it makes economic sense for us to run in the cloud. Plus, 16 processors just doesn’t get a complex multi-physics problems done very quickly. You need 64 or 128 processors.

Q: How do you use Rescale today?

A: So far we’ve used STAR-CCM+, and we found it very convenient. I was surprised at the ease of setup and how easy it was to get going. In the future, we plan to explore the new ANSYS partnership and probably a lot more open software like OpenFOAM.

We don’t have a typical workload. It varies a lot. We’re a small company. We’re only three people, so sometimes it’s very busy with four or five customer projects and we might have three or four simulations running at a time. We can run some of it internally, but then we run into the issue where all our licenses and processors are taken up and we need to run something in the cloud. The cloud knocks off the peaks of the demand for us. We’re using it for overflow and big jobs that we can’t run here.

Q: How has using Rescale changed the way that you approach simulation overall?

A: I think 2017 is going to bring some changes. What I see potentially happening in 2017 is that we reserve our 8 or 16 cores here to run the hard problems that require STAR-CCM+ and we run some of our more basic CFD analysis (for example, external aerodynamics) on OpenFOAM on Rescale resources. Another thing I see happening is that we used to be very conservative or picky about how many processors we would run a problem on because we might have three or four problems going and no one job was more important than the other three clients’ jobs so we would partition those equally. It’s always a pain in the butt to have to run on fewer processors than you’d want. Now that we have access to as many processors as we want, we’re just going to throw a lot of processors at jobs and get them done so much more quickly, and we’ll be able to run many more iterations on trials and optimization because we’re doing it that way. It’s taken the high capital requirements out of being able to run things on a lot of processors.

Q: It sounds like what’s really important to you is the ability to scale out and to have elastic resources available to you, but is there anything else that you really like about Rescale?

A: Versus the other simulation platforms, I found that Rescale was amongst the easiest to use.

Q: How do you expect your use of Rescale to impact your business?

A: It’s definitely going to allow us to have and to advertise greater capabilities, and it’s also going to allow us to have a better bottom line and cost savings. I see Rescale or any other cloud provider being a long-term part of our business.  Cloud computing allows us to cost-effectively execute the most complex simulations, and we’ll be able to help more clients because we have access to supercomputing resources.

This article was written by Mika Pegors.

The Rescale platform provides end-to-end file management backed by storage offerings from the major public cloud vendors. This includes optimized client-side transfer tools as well as in-transit and at-rest encryption. In this model, Rescale controls the object store layout and encryption key management. In order to retrieve the decrypted file content, users must use Rescale tooling. While this can be convenient if you are starting from scratch and looking for a totally managed secure solution, one scenario that comes up is how to use the platform with input data that has already been uploaded to the cloud. Another use case that we see is integrating with an existing data pipeline that operates directly on simulation output files sitting in a customer-controlled storage location. For cost and performance reasons it is important to try and keep your compute as close to the storage as possible. One of the benefits of Rescale’s platform is that we support a number of different cloud providers and can bring the compute to any cloud storage accounts that you might already be using.

In this post, we will show how customers can transfer input and output files from a user-specified location instead of using the default Rescale-managed storage. For this example, we’ll focus on Amazon S3, however a similar approach can be used with any provider. In the following, we will go through the setup of a design of experiments job where the input and output files reside in a customer-controlled bucket. Let’s assume that the bucket is called “my-simulation-data”, the input files are all prefixed “input”, and all output files generated by the parameter sweep should be uploaded to a path prefixed by “output”.

This DOE will run over the HSDI and Pintle Injector examples for CONVERGE CFD found on our support page (https://support.rescale.com/customer/en/portal/articles/2579932-converge-examples) in parallel. Normally, the DOE framework is used to change specific numerical values within an input file but here we will use it to select completely different input.zips per run.

First, upload the converge input zips (hsdi_fb_2mm.zip and pintle_injector.zip) to the s3://my-simulation-data/input/ directory in s3.

Next, create a file locally called inputs.csv that looks like the following:

In order to give Rescale compute nodes to access to the bucket, an IAM policy needs to be created that provides read-access to the input directory and full access to the output directory:

Note that another way to accomplish this is to setup cross-account access (http://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html). This is a preferable way to configure access if all compute nodes will run in AWS. However, the above approach will work regardless of where the compute nodes are executing.

Now, attach this policy to an IAM user and generate an access key and secret key. This access key and secret key should then be placed into a AWS config file that you save to a local file:

Save the above to a file called config.

The last file that needs to be created locally is the run script template. We will reference the s3_input and s3_output variables from the inputs.csv created above in a shell script template file that will be executed for each run. Create a file called run.sh.template that looks like:

There are a couple things to point out in the above script. Normally, the Rescale platform will automatically unarchive zip files however in this case we need to handle that ourselves since we are bypassing Rescale storage for our inputs. The rm -rf * at the end of the script deletes all of the output files after uploading them to the user-specified S3 location. If we omit this step, then output files will also be uploaded to Rescale storage after the script exits.

Now that the necessary files have been created locally, we can configure a new DOE job on the platform that references them. From the New Job page, change the Job Type to DOE and configure the job as follows:

  1. Input Files: Upload config
  2. Parallel Settings: Select “Use a run definition file” and upload input.csv
  3. Templates: Upload run.sh.template. Use run.sh as the template name
  4. Software: Select converge 2.3.X and set the command to run.sh
  5. Hardware: Onyx, 8 cores per slot, 2 task slots

Submit the job. When the job has completes, all of the output files can be found in the s3://my-simulation-data/output/hsdi/ and s3://my-simulation-data/output/pintle/ directories.

In this DOE setup, the ancillary setup data (eg: the AWS config file, csv file, and run script template) are encrypted and stored in Rescale-managed storage. The meat of the job, the input and output files, are stored in the user-specified buckets.

We do recognize that the above setup requires a little manual work to get configured. One of the things on our roadmap is to provide better integration with customer provided storage accounts. Stay tuned for details!

This article was written by Ryan Kaneshiro.

As a long-time GNU Emacs user, I have come to take C-x C-e (eval-last-sexp) for granted. That is, in almost any file that I’m editing, I can insert a parenthesis expression wherever I am, hit C-x C-e, and get a result displayed in the minibuffer (or if programming in a lisp, in the REPL).

Many other languages provide console interfaces or REPLs, but they usually come as separate features of the language, rather than an assumed mode of interaction. I’ll admit that this is a superficial observation, but one could reframe this terms of a “script-centric” or a “REPL-centric” approach to user interaction. Imagine yourself learning a new programming language. A “script-centric” approach would quickly introduce you how to run a hello world program from a terminal (or IDE), whereas a “REPL-centric” approach would quickly introduce you how to drop into a REPL and evaluate the requisite expressions to achieve the hello world effect.

In other words, a “script-centric” approach conceptually separates the editing and evaluation cycles, whereas the “REPL-centric” approach is designed around a single flow of expression, evaluation, and feedback. Each method has its strengths and weaknesses, but for prototyping and experimentation, it’s hard to beat the feeling of “being with the code” from evaluating code right at the cursor. In Emacs, for languages in the lisp family, this is generally the expected method of interaction.

How might we demonstrate this? Well, my colleague Mark wrote a tutorial on setting up a Keras training job back in February. The software has been updated since then, so we’ll create an updated version of that job; but instead of raw python, we’ll use hylang, which is basically a lisp for the Python interpreter.


Assuming you have a recent version of Emacs running (say, version 24 and up) with the Emacs package manager set up, you would want to install hy-mode (M-x package-install RET hy-mode RET), and one of the many lispy paren packages, e.g. paredit, smartparens, lispy.

In our new file, cifar10_cnn.hy, make sure you are on Hy mode. Then use M-x inferior-lisp to start a hy repl! Scroll to the bottom for a video demonstration of Emacs interaction.

1 First let’s take care of the imports 

1.1 Python

1.2 Rewriting this in hy:

51 words to 39. Not bad for succinctness!

2 Then let’s rewrite the constants

2.1 Python

2.2 Hy

Hylang takes inspiration from Clojure, but unlike Clojure, allows multiple variable def-s by default. In this case it’s quite handy.

3 The functions

Note that the input_shape argument ordering has changed since the previous version from (channels, rows, columns) to (rows, columns, channels)

3.1 Python

3.2 Hy

In the code below, we could have written the variable destructuring for TRAIN and TEST with a single step like so:

(let [ [[X-train y-train] [X-test y-test]] (cifar10.load_data) ] )

Notice how using doto here really simplifies repetitive assignment. Since expressions evaluate to the final form inside them, which gets passed through by doto, our model setup in make-network doesn’t even require a variable name.

Hylang also supports the handy threading macros (->) a la clojure, which makes it easy to chain statements together; in this example we just thread the format string through the .format function, then print it.

4 The main runner block

4.1 Python

4.2 Hy

5 A quick video

In this short video you can see how one might load the resulting hylang file into emacs and run it through the hy REPL, evaluating the statement on point (which show up as ^X ^E in the key overlay), and otherwise switching back and forth between the REPL and the edit buffer.

Towards the end, you can see how I missed the numpy import, added the import to the (import ...) form, and re-evaluated the entire import form. I moved the cursor to the end of the form and used eval-last-sexp for evaluate the expression, but could have also used Ctrl Alt x or lisp-eval-defun, which would evaluate the top level expression surround the cursor.

Since load-dataset and make-network take no arguments, it is convenient to wrap the function bodies in a let or doto expression (or form), repeatedly evaluating the block at-point, checking the REPL output, and when satisfied, wrap the let block into a defn form.

6 Running it on the platform

The video stops right after I start the actual model training, because my computer doesn’t have a good GPU, and the training would take a long time. So instead we’ll put it back on the Rescale platform to complete, first installing the hy compiler by running

then simply calling hy cifar10_cnn.hy to replicate Mark’s previous example output.

(note that in this example, we’re running the latest version (version 0.11.0, commit 0abc218) of hylang directly from github). If you installed hy using pip install hy it may be using an older assignment let/with syntax.

A ready-to-run example can be found here. In addition, a tanglable version of this post can be found on github.

7 Pardon the pun

But is it hy time? As you can see, the REPL integration into Emacs has its quirks. Debugging errors from deep stack traces is also a bit more challenging due to less support from mature debugging tools. But if you enjoy working with lisps and want or need to work with the python ecosystem, hy is a functional, powerful, and enjoyable tool to use, for web development, machine learning, or plain old text parsing. Did I mention you can even mix and match hy files and py files?

This article was written by Alex Huang.


If you’ve ever wanted to be the next Andy Warhol, but just didn’t have the artistic talent, now AI can do it for you. Style transfer neural networks enable you to apply an artistic style to an image. They are created by taking an existing image classification network and using it as a loss function in training the transfer network, comparing transformation output to training images and an example style image, such as a painting. Intuitively, we are using a pre-trained network to train a new network to mix semantic features of a target image with textures from a style image.

We make use of JC Johnson’s fast-neural-style implementation of this process, using his pre-trained VGG16 network to calculate the loss during training. We use K80 GPUs on Rescale to efficiently train the transformation network and then apply the network to new images.

Style transfer happens in two steps: 1) training the style transfer network itself and 2) applying the transfer model to new images. Below, we show how to set up a Rescale job to perform each step.

Below are four of Rescale’s team members styled to various artworks, including Jackson Pollock, Takashi Murakami, and photo of a skyscraper in Hong Kong. See if you can guess which is which.  


Style Transfer can be easily achieved on Rescale’s cloud computing platform with our new K80 GPU hardware. We’ve included a tutorial along with sample files for you to generate your own neural network artistically rendered images. In this tutorial, you will be able to style Jackson Pollock’s “On Arches” onto a portrait of Clint Eastwood, Darth Vader, David Bowie, and a corgi.

Performing Style Transfer on Rescale
We will now show you how to run your own style transfer job on Rescale. We will create a Torch network training job and run jcjohnson’s fast-neural-style package. This job can then be cloned to train new styles or style new images. You can clone this job on Rescale here.

To start, we upload the following files as input:

fast-neural-style.tar.gz: tarball with jcjohnson’s software downloaded from GitHub.

coco2014.h5.gz: Microsoft COCO 2014 image-in-context training dataset in hdf5 format (this repository is actually a random selection of 1/10 of the original images in COCO 2014).

clint.jpg: image we will style

pollock.jpg: image (artwork) used to style image

vgg16.t7.gz: trained VGG16 model in Torch’s t7 format

Next, we specify that we will be running Torch and which script to run. We first run train.lua. to build the style transfer model using VGG16 as the base model, COCO 2014 as the training dataset, and pollock.jpg as the style. Once the style transfer model, model.t7 is created, we call fast_neural_style.lua to style clint.jpg. After styling is complete, we clean up files we do not need to keep in Rescale storage.


We are almost ready to run. Now, select the Obsidian core type, 2 CPU cores (which corresponds to 1 K80 GPU), then hit Submit.


Once our cluster starts and our inputs are synced to the cluster, the initial style model training begins and we see a view like below: 


After training and image styling completes, the result files are synced back and we can view our styled Clint Eastwood:


Notice that we also have model.t7 in our output files. This is the Pollock style transfer neural network which we use to style further images. Let’s first make this model file available as an input file:


Now we create a new job with the same code repository, our new model file, and some more images to style. You can clone this job on Rescale here.


This time, we have uploaded our images as an archive, which will get unpacked after upload and we run fast-neural-style on the resulting input directory. Note how we no longer need to run the more compute-intensive training process.


Once the training completes, the styled images appear in output_imgs in the results:


*Special thanks to Mark Whitney for setting up the technical and instructional aspects for this blog post. 

This article was written by Daphne Su.