[Sakun]

Originally Posted by joshkellyjak

Hello, not sure if there were more attachments but they don't seem to have uploaded, can you include the output to the terminal?

Apologies, website was keep crashing for last 2h.

i have attached them below.

SU2_3D_1_mirrored error file is for mesh no.1 and SU2_3D_2 error files is for mesh no 2.

[joshkellyjak]

First one not entirely sure what is going on but doubt it is an SU2 problem, it seems to be complaining about Lua.


Second one issue seems to occur in writing the flow domain file. Have you tried outputting it in another format? Why specifically use PARAVIEW_LEGACY?

[Sakun]

Originally Posted by joshkellyjak

First one not entirely sure what is going on but doubt it is an SU2 problem, it seems to be complaining about Lua.


Second one issue seems to occur in writing the flow domain file. Have you tried outputting it in another format? Why specifically use PARAVIEW_LEGACY?

Hi Josh,

Regarding the 1st issue, I’ve found out that it is an issue with the HPC and took ages fix that.

I had to use PARAVIEW_LEGACY because usual paraview format gave me an error when I tried to open the file.

So, I gave one last chance for this turbomachinery simulation case by changing the orientation again. Even though flow path is being set in the z-axis, flow direction is not behaving as it supposed to be.

With the latest change, I got what I needed finally after producing 52 meshes. Flow is now hitting directly blade LE that should supposed to be, along with the rest of the periodic flow in the whole domain (New & Old attached pictures).

[Sakun]

(2nd part)

Total 220,000 iterations ran with 1st order (4.5 million mesh) (1stOrder full convergence pic) and problem comes when I change the case into the 2nd Order. Residuals are starting to increase and between 5000-10000 iteration, case crashes (Error picture).
When I check the front face (INLET) it looks having a distorted flow pattern like shock waves (2nd order velocity pic).

Whole simulation started from Co5 and gradually decreased to Co2, Co1 and Co 0.7. and I have kept under-relax-avg as 0.4 and under-relax-fourier as 1 for both INLET and OUTLET.

Started a new simulation with a 7 million mesh with under-relax-avg as 0.4 and under-relax-fourier as 0.55 for both INLET and OUTLET.


Highly appreciate if you can give advises to solve this 2nd order crash.

[joshkellyjak]

Can you share a config file?

[Sakun]

Yesh,

Sure, i have attached the .cfg file in .txt file format.

And my 2nd order simulation with the 7 million mesh recently got crashed as well with the attached error.

[joshkellyjak]

Three things immediately jump out to me, first is using ROE 2nd order from the start can be quite tricky. I would recommend running first order and then restarting, not sure if you re doing that as the solution does ask for a restart. Have you tried any other linear solver schemes? I have used JST with good success in the past.


Second, and what is probably going wrong in your case, is you have AVERAGE_MACH_LIMIT=1.5. As per the documentation, is the limit of Mach number below which the mixed-out algorithm is substituted with an area average algorithm to avoid numerical issues. Essentially all your calculations are performed with an are averaging because you have set this so high. Set it to around 0.05, the default value is 0.03.


Thirdly, and probably a very minor point, is that you use Wang's modification of the Venkatakrishnan limiter but maintain the default value of the limiter coefficient of 0.05. Wang suggests using a value between 0.01 and 0.2, where larger values approach no limiter. I doubt this is causing your issue but if you are expecting any shocks in your flow the first thing I think of is limiters.

[Sakun]

I have started the simulation with 1st order and ran for 220,000 iterations then changed to 2nd order (convergence attachment is on #43 ). Yeah, I have tried JST as well and it gave me the similar divergence.

Alright, I thought “AVERAGE_MACH_LIMIT=1.5” would not allow the simulation to go beyond MACH 1.5. I have changed the default value to 0.7 in the very beginning and increased more with the time.

Reference paper haven’t mention about experiencing any shock waves even during their experiment but I will keep this as the last option.

Much appreciate for your time to have a look on this issue.

[joshkellyjak]

0.7 is still much too large. The default value is 0.03, you should set it to be of similar order of magnitude.

[Sakun]

Tried to run the simulation with the 0.03 value in the AVERAGE_MACH_LIMIT but it just crash. Same when i use JST instead of ROE.

[joshkellyjak]

Two more observations. First, are you restarting from the previous solution when it diverged or are you running from scratch.


Second, looking at your flow field I can see that your domain is not parallel to the z-axis. You have reoriented the mesh to align the flow to the LE of the blade I think, rather than fix the orientation in the config file. The velocity magnitude in the two images you show before and after has almost doubled. In figure 6 of the reference paper the Mach number slightly upstream of the blade is ~0.55 in the experimental campaign, in your result it's closer to 0.95 Mach. the inflow should be at minimum z-coordinate. The outflow should be at maximum z-coordinate. The flow angle at inlet is defined in the Giles boundary condition as



MARKER_GILES= (INLET, TOTAL_CONDITIONS_PT, 115775, 340.2, 0.77, 0.0, 0.63, 0.4, 0.55, OUTLET, STATIC_PRESSURE, 97251, 0.0, 0.0, 0.0, 0.0, 0.4, 0.55)


with components 0.77, 0.0, 0.63 representing the flow-dir normal, flow-dir tangential, flow-dir spanwise. Your flow does not want to vary span-wise. You should change the normal and tangential components to achieve the desired flow angle. I suspect it should look like this


MARKER_GILES= (INLET, TOTAL_CONDITIONS_PT, 115775, 340.2, 0.77, 0.63, 0.0, 0.4, 0.55, OUTLET, STATIC_PRESSURE, 97251, 0.0, 0.0, 0.0, 0.0, 0.4, 0.55)


You have got the flow angle to work by changing the orientation of the mesh, but as previously stated this is a hard assumption in the SU2 turbo kernel. It also could be the case that the original misalignment is due to the avg. Mach limit issue mentioned prior.