|
[Sponsors] |
May 14, 2024, 09:08 |
Looking for advice on debugging SU2
|
#1 |
New Member
Tongtong
Join Date: Jan 2024
Posts: 24
Rep Power: 2 |
Hello everyone,
I am a programming novice with some experience using commercial CFD software, so I have a basic understanding of the CFD simulation process. Recently, I decided to improve my CFD skills by learning the SU2 code. To that end, I have supplemented my knowledge with basic C++ and learned how to use VSCode for debugging. Specifically, I have configured the launch.json file and used gdb to debug the SU2_CFD code. However, I am currently struggling with how to effectively debug such a large open-source codebase and feel a bit lost. Could anyone provide me with some specific advice and guidance on what steps to take next? I would greatly appreciate any help in making progress with debugging and understanding the SU2 code. Thank you all! |
|
May 14, 2024, 17:00 |
|
#2 |
Senior Member
bigfoot
Join Date: Dec 2011
Location: Netherlands
Posts: 676
Rep Power: 21 |
What would you like to debug? I believe the best approach is to focus on a specific aspect of the code and look at that in more detail.
|
|
May 14, 2024, 22:32 |
|
#3 |
New Member
Tongtong
Join Date: Jan 2024
Posts: 24
Rep Power: 2 |
I am glad to receive your reply. I want to build an adjoint-based shape optimization platform for an impeller using SU2. I believe SU2 can definitely achieve this, as I have seen many successful cases in various papers. As a beginner, my strategy is to first familiarize myself with SU2_CFD by debugging the quick start cases, and then move on to more advanced modules, such as the adjoint module. I am posting this to seek some experience on how to debug such large codebases. Any resources, papers, or videos would be greatly appreciated.
Additionally, I completely agree with your suggestion to focus on specific parts of the code, as this is the best way to improve. |
|
May 15, 2024, 10:56 |
|
#4 |
Member
Josh Kelly
Join Date: Dec 2018
Posts: 34
Rep Power: 8 |
I think you will struggle with the case you describe, the adjoint turbomachinery side of the code has lagged behind the remainder of the code, and there is limited development time and effort going into it currently. Whilst it is an area of research there are still some issue we need to overcome. I think if you consider only a single blade-row the case you describe could be possible however you will likely encounter issues when trying to select a suitable FFD box and then further issues when you deform your mesh near the endwalls. Also this case will be reasonably computationally expensive due to the convergence requirements of the primal solver, so a limiting factor could be your computational resources. I would suggest starting with a single-zone 2D case in the testcase repo and going from there.
|
|
May 15, 2024, 11:22 |
|
#5 |
New Member
Tongtong
Join Date: Jan 2024
Posts: 24
Rep Power: 2 |
Thank you for your kind response. As you mentioned, the SU2 primal solver seems to perform quite mediocrely when calculating impellers. I once used Autogrid to complete the mesh for Rotor 67 and imported it into SU2 through Gmsh, with the mesh size being approximately 500,000. Initially, I used CFX and calculated the case with a back pressure of 120 kPa. The monitored quantities (pressure ratio, efficiency) stabilized after about 300 steps. However, with SU2, it took around 3000-5000 steps to barely achieve a similar effect. If considering optimization problems, this disadvantage would be further magnified. My colleague tested the performance of SU2 v7.5.1 on turbine calculations and described that flow fields at the tip clearance and interstage interface often had issues (possibly due to his improper use of SU2, as he is also a novice with SU2). As you pointed out, I should initially consider only a single blade row. Regarding the mesh deformation issue you mentioned, I wonder if there could be an alternative to the FFD box. Essentially, mesh deformation is about the replacement of node sets. If we calculate the mesh nodes after the SU2 program and then replace them in the mesh file, it could be a strategy. However, I am still concerned about SU2's tolerance for mesh quality (the same mesh might work fine in CFX but not in SU2). Additionally, if not SU2, are there any other open-source codes I could try? I don't know much about OpenFOAM. In my impression, OpenFOAM originated from incompressible fluid solvers. Although compressible solvers have emerged with its development, SU2 should be stronger in the compressible field.
|
|
May 22, 2024, 15:25 |
|
#6 |
Member
Josh Kelly
Join Date: Dec 2018
Posts: 34
Rep Power: 8 |
Yes it's certainly possible to modify the mesh deformation to not use FFD boxes, to what extent this is exists within the current release I am unsure of however it is something I have done in the past. Interface and tip clearance gaps often present issues but these issues can usually be resolved with experiences. Admittedly there lacks some 'best practices' for turbo sims in SU2 although this is something we hope to remedy soon. If you are looking for a turbo CFD code with adjoint features I don't know of anything open-source.
|
|
Tags |
debug, su2 code |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
su2 optimization tutorial problem | kh3 | SU2 | 2 | April 3, 2024 06:54 |
Tutorials not working | abby10 | SU2 Installation | 1 | December 28, 2021 07:35 |
Introducing SU2 International Developers Society (IDS) | fpalacios | SU2 News & Announcements | 1 | June 17, 2019 23:38 |
debugging su2 | wangqi198877 | SU2 | 2 | December 8, 2014 10:39 |
Welcome to the Stanford University Unstructured (SU2) forum! | economon | SU2 | 0 | January 7, 2013 03:48 |