SU2 improve runtime speed

haukne · March 11, 2019, 14:58

Hi,
I'm using SU2 for my research and comparing the run time and accuracy to NSU2D. I'm testing a NASA SC(2)-0710 airfoil with 4000 iterations at Ma = 0.75, Re = 10E6, Aoa = 0. I'm using the same mesh file from NSU2D converted to be compatible with SU2, around 68000 triangular elements. Running NSU2D with 4 threads currently takes 3m30s to run while SU2 at its fastest takes 3m45s, and this is with 32 threads. From what I understand, SU2 should be faster.

Are there some options in the configuration file I should adjust to speed up the runtime? I've seen other posts that recommend changing MGLEVEL and CFL_ADAPT, but after a few tests it hasn't done much to speed it up, and the accuracy seems to have gotten worse. My cfg file is attached below.

Thank you!

NASASC20710.cfg.txt

pcg · April 2, 2019, 10:57

Hi Nathan,
You are using JST with the second order dissipation factor set to 0.0, the recommended value is 0.5.
This may explain partially why you get bad convergence, and may also result in non physical solutions.
For that size grid I would recommend:
MGLEVEL= 3
MGCYCLE= V_CYCLE
MG_PRE_SMOOTH= ( 1, 2, 3, 3 )
MG_POST_SMOOTH= ( 0, 2, 3, 3 )
MG_CORRECTION_SMOOTH= ( 1, 1, 1, 1 )
MG_DAMP_RESTRICTION= 0.7
MG_DAMP_PROLONGATION= 0.7

I hope your mesh is not all triangles and has some quads in the boundary layer otherwise your solution will not be very good at that Re.

Finally, CFL 25 may be to high if you try to run on that many (32) cores, as the linear solver may stop converging (the linear preconditioners in SU2 are of the additive Schwarz type, so they lose effectiveness with more partitions).

Soon-ish I will propose some simple changes that should help speed things up on a future version of the code.

Cheers,
Pedro

atelcikti1 · April 11, 2019, 02:48

Hi,

First of all, I think 32 thread is too much for this kind of simulation since your mesh size is 68000 so 1 thread takes 68000/32 = 2125 cells which is very few, but interestingly you say this is the fastest configuration.

So, I focus MGLVL option. I use always MGLVL = 0 if it is able to converge. Multigridding slows the analysis remarkably.

March 11, 2019, 14:58	SU2 improve runtime speed	#1
haukne New Member Nathan Hauk Join Date: Oct 2018 Posts: 3 Rep Power: 7	Hi, I'm using SU2 for my research and comparing the run time and accuracy to NSU2D. I'm testing a NASA SC(2)-0710 airfoil with 4000 iterations at Ma = 0.75, Re = 10E6, Aoa = 0. I'm using the same mesh file from NSU2D converted to be compatible with SU2, around 68000 triangular elements. Running NSU2D with 4 threads currently takes 3m30s to run while SU2 at its fastest takes 3m45s, and this is with 32 threads. From what I understand, SU2 should be faster. Are there some options in the configuration file I should adjust to speed up the runtime? I've seen other posts that recommend changing MGLEVEL and CFL_ADAPT, but after a few tests it hasn't done much to speed it up, and the accuracy seems to have gotten worse. My cfg file is attached below. Thank you! NASASC20710.cfg.txt

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Introducing SU2 International Developers Society (IDS)	fpalacios	SU2 News & Announcements	1	June 17, 2019 22:38
SU2 cfg file and runtime problems	hedley	SU2	19	January 26, 2016 04:17
Any suggestion about improving the convergence speed of SU2?	dasssj	SU2	5	November 5, 2015 04:08
SU2 runtime error: cannot find value of GMRES in given map	bruzerravi	SU2	1	May 1, 2013 07:11
Welcome to the Stanford University Unstructured (SU2) forum!	economon	SU2	0	January 7, 2013 02:48

April 2, 2019, 10:57		#2
pcg Senior Member Pedro Gomes Join Date: Dec 2017 Posts: 466 Rep Power: 13	Hi Nathan, You are using JST with the second order dissipation factor set to 0.0, the recommended value is 0.5. This may explain partially why you get bad convergence, and may also result in non physical solutions. For that size grid I would recommend: MGLEVEL= 3 MGCYCLE= V_CYCLE MG_PRE_SMOOTH= ( 1, 2, 3, 3 ) MG_POST_SMOOTH= ( 0, 2, 3, 3 ) MG_CORRECTION_SMOOTH= ( 1, 1, 1, 1 ) MG_DAMP_RESTRICTION= 0.7 MG_DAMP_PROLONGATION= 0.7 I hope your mesh is not all triangles and has some quads in the boundary layer otherwise your solution will not be very good at that Re. Finally, CFL 25 may be to high if you try to run on that many (32) cores, as the linear solver may stop converging (the linear preconditioners in SU2 are of the additive Schwarz type, so they lose effectiveness with more partitions). Soon-ish I will propose some simple changes that should help speed things up on a future version of the code. Cheers, Pedro

April 11, 2019, 02:48		#3
atelcikti1 Member Join Date: Mar 2017 Posts: 61 Rep Power: 9	Hi, First of all, I think 32 thread is too much for this kind of simulation since your mesh size is 68000 so 1 thread takes 68000/32 = 2125 cells which is very few, but interestingly you say this is the fastest configuration. So, I focus MGLVL option. I use always MGLVL = 0 if it is able to converge. Multigridding slows the analysis remarkably.