Solution History Support for Derived Parts in STAR-CCM+ v11.04
Please note: Original publication date 07-16-2016
When less is more … it’s like déjà vu all over again!
A while back, I published a blog on a significant improvement to our Solution History (.simh) capability delivered in STAR-CCM+ v10.04 where, instead of having to work with the entire volume representation of a .sim file, you could store boundary surface information only and work with that instead. This led to a substantial reduction in .simh file size, increased your productivity and enabled a much more practical ability to analyze your data. So, what’s new again? Solution History support for derived parts! In STAR-CCM+ v11.04, you’ll be able to store iso-surfaces and all section types (plane, constrained plane, cylinder, sphere, and arbitrary section) in your Solution History files.
Anyone who has set up and run a CFD study will likely be able to relate to this: “In theory there is no difference between theory and practice. In practice there is.” As a practical case study then, let’s look at a device called a caterpillar micromixer.
Caterpillar micromixer
The mixing section length of this device is about as big as a dime, yet it’s capable of producing several liters of product per hour. Two feed streams are introduced upstream and the unique static geometry of the device effects the mixing. In order to confidently predict our mixing behavior, we’re likely to run this case at several different mesh resolutions, producing several .sim files. The mixing tracer concentration is shown on two derived part plane sections below for three different mesh refinements.
Side-by-side comparison of mixing for different mesh sizes
This side-by-side illustration gives us a way to effectively compare these cases. In theory, we could load each sim file one at a time and generate our illustrations and figures of merit. In practice, we’ll create a solution history file for several simulations, saving only tracer concentration on the derived part planes. Comparing the .simh file versus the .sim file size we see a general file size reduction factor of two orders of magnitude. And as the .sim file size increases (due to an increasingly finer mesh) the file size reduction factor gets better – the bigger your cases are, the bigger the potential benefit when you use derived part based .simh files.
simh file size compared to the sim file it is derived from
Here’s yet another benefit: you can load multiple representations on top of the underlying simulation that they are derived from – that means you can do side-by-side comparisons for multiple cases using only one STAR-CCM+ license.
Let’s extend our caterpillar micromixer analysis by running it unsteady, imposing alternating sinusoidal pulses on the feed inlets to improve overall mixing. We’ll set up three Field Monitors based on the mixing tracer: one for the maximum, another for the running average for all time steps and, a third sliding average with a window matching the sinusoidal period for the field inlets. Stepping back for a moment, Field Monitors collect data, and when we are working with sliding monitors, this can generate a “scary” amount of data. If you’re thinking this kind of transient data analysis is prohibitively expensive, without .simh for derived parts, you’d be correct. But, here’s what we achieve in practice. The single.sim file after 400 time steps is ~6.4GB. The corresponding .simh file, with all three Field Monitors plus the instantaneous tracer concentration, stored along a mid-plane derived part, for all 400 time steps, is ~5.0GB. By not having to save all the transient time steps as .sim files, we realize over a 500X reduction in terms of file storage.
We appreciate you typically don’t have time to re-run transient cases. Let’s say you want to check something you noticed in the middle of your simulation – “you can observe a lot just by watching after all.” Still, you’re faced with a tough decision – do you go with what you have or, re-run your case to the timestep of interest? Consider your options with Solution Histories. Back to our practical problem, to run 400 timesteps it took ~9 hours with my modest resources. Working with the .simh data, generating the transient animation took just 15 minutes. OK, you only realize the time savings (a factor of 35X) if you need to re-do your animation by re-running your transient case. However, in 15 minutes, you can create a completely new animation using just your .simh content. Or, improve the effectiveness of an existing animation, adjusting the scalar values to a range more appropriate for all your timesteps. Finally, let’s say you need to quickly review results in a presentation to your peers or customers. Navigate to the desired state from a list of all your stored states – the time to update your results is typically a few seconds since you’re already working with just the derived parts. So, how much time can you save?
Time savings when using a simh based workflow
The bottom line here is that the smaller .simh files need fewer resources and working with them is simply faster. Fundamentally, this supports one of the key objectives of efficient data analysis: Work with the smallest possible data representation needed to make effective decisions. While the list of derived parts being delivered with STAR-CCM+ v11.04 is not complete, it does cover the ones we tend to use the most often. “After all, if STAR-CCM+ was perfect, it wouldn’t be” – I’m paraphrasing Yogi Berra, and kindly acknowledge his wisdom and humor (there are three other quotes attributable to him herein). And, to close things off, spoiler alert, look for broader .simh support for derived parts in the STAR-CCM+ v11.06 release, with still further enhancements planned after that!
