Wrong spanwise sections calculation in Turbomachinery simulation

[LorenzoFabris]

Describe the bug
A general centrifugal compressor multi-zone case is simulated.

The computational domain is composed by the following zones (for this case, no return channel geometry is included):

1. Inlet channel
2. Impeller
3. Diffuser
4. Cavity

The code prints out the following error:

Error in "virtual void CPhysicalGeometry::ComputeNSpan(CConfig*, short unsigned int, short unsigned int, bool)":
-------------------------------------------------------------------------
 At the moment only turbomachinery with the same amount of span-wise section can be simulated
nSpan inflow 0, nSpan outflow 57
------------------------------ Error Exit -------------------------------

However, spanwise nodes are indeed 57 (checked manually and on Autogrid).

A possible solution is indicated here, but it is not a definitive one as it's dependent on the spanwise nodes number hard-coding.
Different SU2 version were tested, both on Win10 and Ubuntu 20.04, but the issue persisted only to be resolved similarly to the way showed here below.

Additional files
error.txt -> SU2 initialization up to the error

Bug report checklist

• [✔ ] Consulting the build instructions (https://su2code.github.io/docs_v7/Build-SU2-Linux-MacOS/).
• [✔ ] Looking for similar problems on GitHub or CFD-Online (https://www.cfd-online.com/Forums/su2/).
• [✔ ] Updating to the newest version of SU2 (either develop, master, or the pre-built executables https://su2code.github.io/download.html).

Desktop:

• OS: UBUNTU 20.04 / Windows 10
• C++ compiler and version: g++ 9.4.0 / gcc 8.1.0
• MPI implementation and version: Open MPI 4.1.5
• SU2 Version: v7.3.0 - v7.4.0 - v7.5.0 - v7.5.1 - v8.0.0 - v8.0.0 new_turbo_outputs

Thank you in advance for your help.

[bigfooted]

I am not so familiar with turbomachinery but it looks like all spanwisesection initialization is done in CPhysicalGeometry.cpp. I think it initializes in the function ComputeNSpan. This function is called in CDriver like this:

geometry[iZone][INST_0][MESH_0]->ComputeNSpan(config[iZone], iZone, INFLOW, true);
geometry[iZone][INST_0][MESH_0]->ComputeNSpan(config[iZone], iZone, OUTFLOW, true);

So you should get an initialized value for inflow and outflow.
Maybe you can check what is going on there and see if this function does what is expected.

[LorenzoFabris]

I am not so familiar with turbomachinery but it looks like all spanwisesection initialization is done in CPhysicalGeometry.cpp. I think it initializes in the function ComputeNSpan. This function is called in CDriver like this:

geometry[iZone][INST_0][MESH_0]->ComputeNSpan(config[iZone], iZone, INFLOW, true);
geometry[iZone][INST_0][MESH_0]->ComputeNSpan(config[iZone], iZone, OUTFLOW, true);

So you should get an initialized value for inflow and outflow. Maybe you can check what is going on there and see if this function does what is expected.

Hi Nijso! Thanks for your suggestion.
Indeed, CPhysicalGeometry.cpp is where the initialization is done. I'll also report this to the SU2 Turbo Group, to check whether we can find a solution.

Currently I just hardcoded a section of that script as follows:

.
.
if(marker_flag == OUTFLOW){
	nSpanWiseSections[INFLOW - 1] = 57;
	nSpanWiseSections[OUTFLOW - 1] = 57; 
      if(nSpanWiseSections[INFLOW -1] != nSpanWiseSections[OUTFLOW - 1]){
        char buf[100];
        SPRINTF(buf, "nSpan inflow %u, nSpan outflow %u", nSpanWiseSections[INFLOW], nSpanWiseSections[OUTFLOW]);
        SU2_MPI::Error(string(" At the moment only turbomachinery with the same amount of span-wise section can be simulated\n") + buf, CURRENT_FUNCTION);
      }
      else{
        config->SetnSpanWiseSections(nSpanWiseSections[OUTFLOW -1]);
      }
    }

  }

}
void CPhysicalGeometry::SetTurboVertex(CConfig *config, unsigned short val_iZone, unsigned short marker_flag, bool allocate) {
.
.
.

This modification was firstly suggested by @MKursatUzuner but I'm pasting it in here to have another source in case the topic opened in CFD Online gets deleted.

[joshkellyjak]

Adding here for future reference, I have also encountered this before and ususally it is a mesh issue, I have solved this by regenerating my mesh and running the .cgns to .su2 conversion again and this resolved the issue. I have also experienced an issue where the NSpan is calculated is much larger (maybe max value of unisgned short I'm not sure). @LorenzoFabris if you notice this issue with any meshes try regenerating but keep the original and we can try and determine the difference between the two? I will also keep an eye out for this problem and do the same.

[LorenzoFabris]

Adding here for future reference, I have also encountered this before and ususally it is a mesh issue, I have solved this by regenerating my mesh and running the .cgns to .su2 conversion again and this resolved the issue. I have also experienced an issue where the NSpan is calculated is much larger (maybe max value of unisgned short I'm not sure). @LorenzoFabris if you notice this issue with any meshes try regenerating but keep the original and we can try and determine the difference between the two? I will also keep an eye out for this problem and do the same.

Sure, we'll keep an eye on that.
I also noticed that the wrong set up of MARKER_TURBOMACHINERY leads to similar error (though this is not the case).

[aryan0931]

The issue likely stems from CPhysicalGeometry.cpp, where spanwise sections are initialized. A snippet from #1219 shows:

if (nSpanWiseSections[INFLOW - 1] != nSpanWiseSections[OUTFLOW - 1]) { char buf[100]; SPRINTF(buf, "nSpan inflow %u, nSpan outflow %u", nSpanWiseSections[INFLOW], nSpanWiseSections[OUTFLOW]); SU2_MPI::Error(string("At the moment only turbomachinery with the same amount of span-wise section can be simulated\n") + buf, CURRENT_FUNCTION); }
This check enforces identical section counts, which is too restrictive.

Instead of failing, the code should:

Determine the maximum number of spanwise sections between inflow and outflow.
Interpolate data (e.g., flow variables) from the boundary with fewer sections to match the higher count, ensuring continuity across zones.
Update the configuration with the resolved section count.

[aryan0931]

Please review my suggestions.

[joshkellyjak]

The spanwise sections is computed automatically based on the number of nodes in a mesh along the edge on a periodic boundary that connects the hub to the shroud. The original issue posted occurs when the ComputeNSpan function cannot determine the location of the nodes along this edge, it is usually a mesh issue that can be resolved by regenerating the mesh.

Not entirely sure what you mean by interpolate to ensure continuity but the issue with this method would be that you are trying to extract solver information between vertices that don't exist in the solution. If, for example, you have a boundary with 10 spanwise section and its corresponding boundary has 20 elements, how do you extract solution variables that exist in the spaces between the elements of the boundary with lesser sections? The reason why this error throws is because large sections of the turbomachinery code run on this assumption of equal spanwise sections due to simplicity of implementation. It would be quite tricky to refactor large sections of the code to enable INFLOW/OUTFLOW boundaires with different spanwise sections, and it is uncommon for dedicated turbomachinery meshing software to output meshes like this anyway.

[aryan0931]

The error stems from ComputeNSpan failing to detect nodes along the periodic boundary edge due to a malformed mesh, and the solver correctly requires equal sections. We can Enhance ComputeNSpan to throw a descriptive error

[joshkellyjak]

I agree, feel free to open a PR. Additionally there is a Google Summer of Code project that aims to remove some of the assumptions present in setting the turbovertex structre you may be interested in.

https://www.cfd-online.com/Forums/su2-news-announcements/259420-gsoc-2025-projects.html

[aryan0931]

I am gathering more details on this issue and will open a PR soon.
Yes sir, I am really looking forward for contributing to this organization through Google Summer of Code. I am already reviewing the GSoC project ideas for SU2 and will share a detailed proposal soon.

[aryan0931]

After doing some research I found that:

Given the issue appears with multiple cores, check how ComputeNSpan handles distributed meshes using MPI. It seems likely that the function fails to gather data correctly across processors, leading to nSpan inflow being 0.

Related issues (#990 , #1219 ) suggest that mesh partitioning causes incorrect counts, possibly due to boundary nodes being split across processors, leading to undercounting.

Can you review these suggestions as I am working on this issue.

[joshkellyjak]

Yes it could well be an MPI issue. The whole ComputeNSpan function is a bit of a mess and quite difficult to debug. It would be useful to find some case where we encounter this error to being attempting to debug it. I think it needs bit of reformatting which is a potentially very challenging task.