“Don’t it always seem to go, that you don’t know what you’ve got till it’s gone…” sang the words out of the stereo with surprising clarity; I am in the process of replacing my ancient car (inherited from my grandmother) with something a little more modern. Being able to decipher lyrics over the cacophony of other road noises is something of a novelty as I test-drive a couple of candidates. I am blown away by just how refined and pleasant these newer models feel.
Nowadays, there is so much choice that choosing a car can be a deeply challenging process. The differentiating factors often come down to a je-ne-sais-quoi, a feeling rather than numbers that can be put down on paper, and that makes me uncomfortable; I am an engineer, and I make decisions backed up with cold, hard facts & figures. How am I supposed to quantify a feeling?
As Joni-Mitchell’s famous lyrics sang out, I considered their meaning – about how we take so much in this world for granted. This is not the first time I have been in a modern car, but it is the first time I have sat back and really tried to absorb the feeling. Obviously it is a much more pleasant environment than my outgoing transport… but why?
Of course, it is no accident; Automotive manufacturers go to great lengths to minimize noise, eliminate vibration & harshness, optimise the sound quality, consider the ergonomics and feel of everything you touch… the list goes on. How do they know if they have been successful? It is when you don’t notice anything. You don’t notice the noise of the road. You don’t notice the weight of the pedals . You don’t notice the position of the A-Pillar. Everything just feels right. You often only notice any of these things if the engineers and designers get it wrong, and that is why we take all of these things for granted nowadays.
As I said earlier; it is hard to quantify a feeling… but it is even harder to engineer one! We have come to expect this level of refinement, and we rarely notice the effort taken.
The same is true in software. If you reading this, the chances are that you are a CAE engineer, and much of your day is spent in front of various software packages. Engineering workflows can be complex processes, and their success depends on easy adoption and robustness. In the simplest possible terms, this means they just “work” as we expect, and when this happens, we don’t notice. It is only when a process is really tedious, or something goes wrong that we sit up and take note, and when that happens, the process is dead in the water.
Working in a single tool is one thing, but nowadays, as the coverage of simulation increases, so does the amount of data that must come together to build the digital twin. No single software tool can be responsible for the vast array of analysis types required, and rarely do results of a given analysis stay confined to the tool where they were generated. The data output from one tool becomes the input for another, and it is the combined analysis which design engineers use to make decisions when developing their products.
This ability for a software application to exchange data with another tool is known as interoperability, and is a key capability for a software package to exist in the ecosystem of tools in a modern CAE process.
At Siemens PLM, we understand the importance of streamlined workflows. We know we are getting it right when actions are intuitive and processes are smooth … and users just adopt them, often without noticing.
When something works well, people want to use it, whether it is a new car, or a software process. A smooth, intuitive workflow means you can be more productive as an engineer – you can try more designs and explore more of the design space. More exploration of the design space means you can find better designs and do it faster. Better designs means you can beat your competitors in the marketplace. Beating your competitors means more profit for your company. Making more profit for your company puts you in a great position to negotiate that pay rise, and perhaps even buy that new car!
In order to support you in your mission, we are continuously looking for ways to improve the interoperability capabilities of our tools, and the latest release of STAR-CCM+ (version 12.06) is no exception. We have extended our file export capability to be able to write files which can be read directly by Virtual.Lab, enabling a full end-to-end workflow for the analysis of noise caused by aerodynamic, hydrodynamic or electromagnetic excitation.
The new file format is based on the general-purpose *.CGNS file, with all of the settings hard-coded to the requirements of Virtual.Lab. There is no guesswork involved in selecting the right options. Gone are the days of waiting nervously to see if you missed a setting and need to re-run your simulation. Only the essential data is stored, and a binary format is used, which keeps the file size to a minimum.
Virtual.Lab has a frequency domain structural-vibro-acoustics solver, for simulating the propagation of noise sources through structures as well as internal and external radiation.
When sound quality is the differentiator between your products and those of your competitors, you need a tool like Virtual.Lab to maintain your competitive advantage. The ability to use simulation to rapidly evaluate how design changes affect the acoustic performance of your products is a cost-effective method to identify and eliminate poor designs as early as possible.
The old adage “garbage in, garbage out” holds true here. To accurately predict the acoustic propagation, you need the highest quality input. STAR-CCM+ v12.06 and Virtual.Lab therefore form a formidable combination: STAR-CCM+ performs a high-fidelity transient simulation to generate the excitation field, generated by fluid or electromagnetic forces. The results of this simulation are passed (via the new form of .cgns file) to Virtual.Lab. Virtual.lab then transposes to the frequency domain to solve. The fact that the files are optimised to keep data size low lessens the burden when transporting over networks or storing.
So let’s look in a little more detail how this process works when simulating wing mirror noise
Generate the acoustic flow field
Set up high-fidelity transient DES simulation in STAR-CCM+ to simulate the turbulent wake behind the wing mirror.
DrivAer Model courtesy of TU Munich
The main noise transmission path for wind noise from the wing mirror to the driver is through the side window. Pressure fluctuations on the outer surface of the window cause it to vibrate. The vibrating surface of the window acts as a noise source within the car. In order to capture the effect, the pressure field on the window is saved and exported for each time step of the transient simulation.
DrivAer Model courtesy of TU Munich
Auto-export is set up in STAR-CCM+. The new “Siemens Virtual.Lab Custom CGNS” is selected as the format, as well as the wall boundary on the window surface as the exported part, and Time Step as the update trigger. Selecting “Export Solution Data Only” is appropriate in this case as the mesh is static.
The simulation is now ready to run. A separate *.cgns file is written for each time step of the transient solution. The simulation must be run for an appropriate number of time steps, as dictated by the length of the time step and the highest frequency of interest.
After completing the run, a deck of output files are now ready for import into Virtual.Lab. After import, the transient pressure fluctuation field on the window is transposed into the frequency domain, and used to create surface dipoles.
DrivAer Model courtesy of TU Munich
Finally, dipoles are converted into acoustic velocity boundary conditions, and the acoustic solution is generated.
So next time you are enjoying a quiet drive through the countryside with the radio playing your favourite songs, take a moment to consider the attention to detail that has made your experience so pleasurable!