JBAY Model in SU2

[Aashna-chopra]

Hi everyone,
I am trying to use the SU2 JBAY vortex generator model for a single triagnular vortex generator on a flat plate, but the simulation diverges. Has anyone here actually used and validated jBAY (PR #2273, maxi120 fork) before, for a single VG specifically? Or is anyone able to help me work through this? I've narrowed down part of the cause myself but want to check whether the remaining behavior is a known limitation or something I should keep digging into.

A bit of context on what I'm seeing, in case it's useful. The setup description:

• Model: jBAY (PR [WIP] jBAY and BAY vortex generator model #2273, maxi120 fork)
• Geometry: single isolated triangular VG on a flat plate (not a counter-rotating/diverging pair)
• Turbulence model: SST (SA causes memory corruption on initialization for this fork)
• Time integration: Euler implicit
• Const=10, CFL=10

The problem I have found so far:

Invalid edge-VG intersections- In 'CSourceBAYModel::UpdateSource', 'jDistance' is computed as 'pointDistance - iDistance', where iDistance comes from GeometryToolbox::LinePlaneIntersection. For some edges this came out negative or larger than pointDistance, i.e. the intersection point wasn't actually clamped to lie between the edge's two nodes. These edges fed directly into Get_redistributionConstant, where iDistance/jDistance appears as a ratio in the denominator. A negative/invalid value there can push the denominator through zero, producing an unbounded coefficient. Adding a validity guard in UpdateSource (reject the edge if iDistance <= 0 || jDistance <= 0 || iDistance > pointDistance || jDistance > pointDistance, before it's inserted into EdgesBay) fixed the immediate blow-up: the run went from diverging in 6 iterations to running stably out to 2500–2700 iterations before diverging again.

[bigfooted]

Hi, as suggested in the PR, this can be done entirely in python. Here is an example where a user defined source term is defined in python and added to the species solver. Better use that approach.
https://su2code.github.io/tutorials/TFC_python/
So just recompile with python wrapper support, test with this tutorial, then change the source term and give it to the correct index of the flow solver,
SU2Driver.Solution(iFLOWSOLVER).Set(iPoint,index,value)
index = 0,1,2,3,4, for P,U,V,W,T

[Aashna-chopra]

Thanks for the solution.

The jBAY model does not only involve a specific source-term formulation, but also applies the source in a very specific way, through VG/mesh intersection, interpolation, and redistribution. So if I try to use PYTHON_CUSTOM_SOURCE and customize the source term, I would probably need to code all of that application logic as well.

Is there another recommended solution for this? For example, is there a way to properly enable/use the native jBAY implementation? I did manage to run jBAY without divergence by using a lower CFL, but the effect on the flow field is still not as expected.