Why choosing SU2
I've seen some companies in our sector (radial turbomachinery) using open source software, expecially OpenFOAM which seems to have the largest user base among the open source CFD codes. All the examples I have seen were related to optimization: the reason is that optimization for centrifugal compressors needs to be multidisciplinary, multiobjective and multipoint, so a huge number of parallel runs are needed. Here, open source software has the clear advantage that licenses are free, so you're only limited by available computational power.
Since changing CFD philosophy in a company is not a trivial task, I'd like to have some information about SU2. Is there a list of companies which use it (possibly radial turbomachinery companies)? Can I ask you what are the reasons that prompted you to write a new open source software? I mean, what are the features which set SU2 apart from other software? Looking at the documentation, the code seems to have a strong native support for gradient-based optimization, a large number of discretization methods (many upwind/flux splitting methods, along with classical JST method) and two turbulence models. Does the adjoint solver work with turbulence models, or only for laminar flow? Does it work with the sliding mesh BC (I'm thinking to multistage computations here)? Are scalable wall functions available, or should one implement them himself? How sensitive is the compressible turbulent solver to mesh quality, for example to grids containing highly skewed tetras? Thanks,
I'm new to SU2, so I haven't got a lot of answers for you. I have tried SU2 briefly though and it was very easy to get started with. If you just have a grid for a typical case that you would like to test SU2 on it should not take too much work to get SU2 running on your test-case.
One major difference between the CFD codes SU2 and OpenFOAM is that SU2 from the start is a compressible code, whereas OpenFOAM mainly is an incompressile code.
If your application is high-speed and involves shocks I would guess that SU2 will be the better code. If your application is incompressible, or just mildly compressible without any shocks, I would guess that OpenFOAM will be faster than SU2.
From what I have read SU2 uses artificial compressibility a'la Chorin to run incompressible cases. That works but from my experience gives a fairly slow code that will have problems in highly resolved boundary layers etc. I saw that the new version 2 had some new line implicit and low Mach preconditioning methods implemented. This is probably to reduce the problems with low mach numbers and well resolved boundary layers. But this is just my speculations. Those with more information please correct my thinking if I'm wrong. Is SU2 a code that also is fast and works well on incompressible cases with well-resolved boundary layers?
Many questions. Let me see if I can help answer them, and apologies for the long post. Please let us know if you need more information. I will also invite other members of the SU2 development group to chime in.
Why SU2? A good question. Our lab (Aerospace Design Lab at Stanford University Aero & Astro) has had a long tradition of creating numerical tools for analysis and design/optimization of problems governed by the equations of fluid flow, but our most recent code, SUmb (Stanford University multi block), was (a) mostly hardwired for the RANS/URANS equations with several turbulence models, and (b) relied on multi-block meshes to describe the flow domain.
We found this limiting because we wanted to continue our work on:
1. Complex configurations of industrial interest and the mesh generation process was slowing our students down.
2. More multi-disciplinary problems that required additional equation sets (PDEs) to be solved.
3. Trying different numerical schemes for various equation sets.
4. Minimizing the required effort to add capabilities for new research/development situations.
Frankly and believe it or not, in a university laboratory we are also very concerned about the efficiency with which students pursue their own research projects: must every student write his/her own solver from scratch? This is very inefficient. Thus SU2.
But there are many other solvers out there. Why not start with one of them? As was mentioned, most of our work involves compressible flows and, therefore, a compressible solver makes more sense to us. Most of our work involves design/optimization and, thus, a methodology that can be used to obtain gradients is very important to us (and an integral part of SU2): we believe this is a capability that sets SU2 apart. Also, there is quite a breadth of projects in our lab that are not simply based on Euler and/or RANS: students are interested in flow/acoustics interactions, flow/structure interactions, combustion and plasmas, etc: we needed a flexible set of classes to enable us to easily do our work and a C++ framework made more sense.
Finally, we also fully endorse the spirit of the open source movement: we are happy to develop the initial capabilities and support the efforts in the community, but would really like to see contributions of all kinds to SU2, from graduate students around the world running the tutorials and reporting compilation / running problems that we need to fix, to students/researchers/engineers adding capabilities (like some of the ones you mention) that we would not have the chance/time/resources to add ourselves. Everyone benefits in this way.
Some specific answers to your questions:
1. List of companies using SU2: SU2 is fairly new. We released the initial version last January and the second version today. Since Jan 2012 there have been 3,000+ downloads of the code, many from industrial organizations. We ask for an organization name when the code is downloaded to understand our user base, but we do not divulge it. I am not aware of any centrifugal compressor companies using it as their main solver at the moment. To be fair, some development would be required to have all the capability that you would need.
2. Adjoint solvers: the continuous adjoint solver does work with the Spalart-Allmaras model. The SST model continuous adjoint still needs to be developed. The discrete adjoint solver (new in this release) is only Euler at the moment, but we are developing viscous capabilities. The adjoint solvers are currently working with the 2D sliding mesh capabilities but not in 3D settings.
3. Adaptive wall functions: these are not in the current release, but they are on our list of requested capabilities and we hope to have them in by this summer. We would welcome help in implementing them but we did have a very robust formulation in SUmb that we would like to use to inspire the SU2 implementation.
4. Compressible, high Re solutions: SU2 is a vertex-based, dual control volume, spatially second-order accurate solver. The solution accuracy and convergence properties for highly-stretched meshes are documented in many articles in the literature. For highest accuracy, a quadrilateral (or prismatic) layer in the boundary layer is recommended.
Why SU2 for my PhD?
The reason I chose to use SU2 for my PhD studies was that it offered a great flexibility of implementing a new set of equations. I need to solve chemically reacting, hypersonic flows under the influence of electromagnetic forces, and there are no hi-fidelity, open-source softwares for that.
SU2 has an object-oriented class structure which makes it very easy to implement new set of equations, due to which I was able to develop and tested a multi-species plasma solver in SU2 in about 4 months time (which otherwise would have taken me more than a year, if I had started from scratch).
All I needed to do was to code up my equations and everything else, including the IO, unstructured mesh format, a number of linear solvers, discretization techniques, convergence acceleration techniques amongst others, was already available. This whole gamut of techniques made the solver robust, easy to use on different problems and user friendly. It also saved me a considerable amount of time and effort in my PhD.
Thank you for the very interesting explanation. I think this is a great discussion on the whole.
Could you please explain what you mean by a 'dual control volume' , in point 4 ?
I'd be glad if you direct me to any material/resources to understand this better.
Why choose SU2? Well, it's a good question and I'll try to summarize the factors that influenced me as a basis for discussion.
My particular field of research is similar to Amrita's and requires accurate simulation of high Mach number flows with multiple chemical species in thermodynamic and chemical non-equilibrium. It's quite challenging and requires significant extension of standard CFD tools to accommodate the extra governing equations and source terms, and it also requires special consideration in the numerical implementation (often times requiring extra dissipation in the presence of strong, detached shocks, among other numerical minutiae).
Other codes exist that can simulate these kinds of problems, but for various reasons we cannot run them on our university's machines, necessitating my own implementation. Starting from scratch was not an idea that I was really excited about, and would amount to a substantial, multi-year effort that would almost certainly delay my graduation. As it turns out, SU2 has many features that are really well-suited for these kinds of problems, and I'll do my best to enumerate them.
First, the object-oriented nature of the code allowed me to leverage the existing class structures to rapidly implement the additional equations necessary for my unique problem within the existing solver framework. This is also the case for the additional source terms needed, and gives me great flexibility moving forward to quickly code up new thermo-chemical models.
Second, the code architecture offers great flexibility to handle a wide variety of tightly-coupled multi-physics problems and makes an excellent test-bed for implementing new numerical methods. Multiple different equation sets can be solved simultaneously within the solver and all information is encapsulated (called 'solution containers') within the software. At all time steps, the information contained in each of these solution containers is readily accessible, making integration of different solvers trivially easy (my particular problem requires solving flow equations in conjunction with electrostatic equations on the computational domain, but a host of other coupled analyses are possible to enable the simulation of aeroelastic, aeroacoustic, combustion, etc. problems). As I mentioned before, some numerical trickery is needed for my problem, and the numerics are separated entirely from the physical modeling of the problem. This allows for very quick implementation of new spatial discretization schemes.
Third, the strong, native support for optimization and sensitivity analysis has direct utility to me, since a major component of my dissertation will include design, sensitivity analysis, error estimation, and uncertainty quantification. With much of this architecture already in place, there's no need for me to seek out third-party optimizers (or write my own) and integrate it with the solver. Again, another feature that shaves time off my expected graduation date and software integration headaches.
Last, the solver is under rapid, ongoing development to include features on the cutting-edge of CFD research (convergence acceleration techniques, linear solvers, pre-conditioners, etc.). These features can be convenient or even game-changing when tackling the toughest, newest problems that are facing the community.
Anyways, a long post (and sales pitch) for SU2. As part of the development team, I certainly have a biased opinion, but there's a good reason that I chose to join the group. I've seen what the code is capable of and am a strong believer that it's the right approach to tackle the toughest and most interesting aerospace problems. I urge you to try it out and see for yourself.
We have written a paper about SU2
In this paper you will find a complete description of the numerical methods and the V&V process.
|All times are GMT -4. The time now is 17:53.|