You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A number of configs under TestCases/ cannot be parsed by current develop.
They abort in CConfig::SetConfig_Parsing with invalid option name or invalid option value. This happens before the mesh is read, so they fail
immediately for anyone who tries to run them. The expected behaviour is that a
config shipped in TestCases/ runs with the version of SU2 it ships with.
None of the affected files are registered in serial_regression.py or parallel_regression.py, which is why CI does not catch this. @bigfooted
already noted in #2524 that some testcases are not regression tested; this is
the full extent of it for the parse-failure category.
Reproducing. No mesh from the TestCases repository is needed, since parsing
fails before the mesh is opened. From the root of the SU2 repo:
The iteration-control, grid-movement and misc groups look like straightforward
renames. The FSI group is different: SOLVER= FLUID_STRUCTURE_INTERACTION is no
longer a valid solver value, so fea_fsi/SquareCyl_Beam/config.cfg may need to
be removed rather than updated.
Related, not a parse error.nicf/LS89/turb_SST_PR.cfg sets SOLVER= NAVIER_STOKES with KIND_TURB_MODEL= SST, which has been rejected in SetPostprocessing since 2019 (f30a8bf). It parses but aborts at startup. Same
root cause — a config that no longer matches the API and is not regression
tested.
I would like to start working on this. I would rather be pointed at the right
part of it than pick for myself:
Which group would you like done first? The grid-movement and
iteration-control renames are the most mechanical and I can verify those
locally. The turbomachinery markers I am less sure about.
For configs using a removed feature (FSI_*, SOLVER= FLUID_STRUCTURE_INTERACTION), should they be deleted, or is the feature
reachable under a different solver name?
Should these be registered in the regression scripts as part of the same PR,
or separately? From Test cases unsteady does not work #2524 and Update deprecated EXT_ITER option in test configs #2866 I am aware that a config which merely
parses is not the same as one that converges usefully, and the second part is
the slower one.
Happy to work through it in small PRs in whatever order suits review.
Updating to the newest version of SU2 (either develop, master, or the pre-built executables https://su2code.github.io/download.html). Desktop (please complete the following information):
OS: Fedora 42
C++ compiler and version: g++ (GCC) 15.2.1
MPI implementation and version: n/a (built with -Dwith-mpi=disabled)
Describe the bug
A number of configs under
TestCases/cannot be parsed by currentdevelop.They abort in
CConfig::SetConfig_Parsingwithinvalid option nameorinvalid option value. This happens before the mesh is read, so they failimmediately for anyone who tries to run them. The expected behaviour is that a
config shipped in
TestCases/runs with the version of SU2 it ships with.None of the affected files are registered in
serial_regression.pyorparallel_regression.py, which is why CI does not catch this. @bigfootedalready noted in #2524 that some testcases are not regression tested; this is
the full extent of it for the parse-failure category.
Reproducing. No mesh from the
TestCasesrepository is needed, since parsingfails before the mesh is opened. From the root of the SU2 repo:
Smallest single example:
cd TestCases/turbomachinery/centrifugal_blade SU2_CFD centrifugal_blade.cfggives
Affected files (excluding those already covered by #2874, #2865 and #2866):
The options involved group into a few API changes:
EXT_ITER,UNST_TIME,UNST_INT_ITERGRID_MOVEMENT_KIND,ROTATION_RATE_X/Y/Z,MOTION_ORIGIN_X/Y/Z,PITCHING_OMEGA_X/Y/Z,PITCHING_AMPL_X/Y/Z,GRID_MOVEMENT= YESMARKER_NRBC,MARKER_MIXINGPLANE,MIXING_PROCESS_TYPE,MARKER_TURBO_PERFORMANCEFSI_*family,*_STRUCTURE_FILENAME,NONLINEAR_FEM_INT_ITER,CONV_RESIDUAL_MINVAL_FSI,SOLVER= FLUID_STRUCTURE_INTERACTIONREF_LENGTH_MOMENT,FROZEN_VISC,GEO_AXIS_STATIONS,GEO_WING_BOUNDS,SOLUTION_LIN_FILENAME,RESTART_LIN_FILENAME,SURFACE_LIN_FILENAMEThe iteration-control, grid-movement and misc groups look like straightforward
renames. The FSI group is different:
SOLVER= FLUID_STRUCTURE_INTERACTIONis nolonger a valid solver value, so
fea_fsi/SquareCyl_Beam/config.cfgmay need tobe removed rather than updated.
Related, not a parse error.
nicf/LS89/turb_SST_PR.cfgsetsSOLVER= NAVIER_STOKESwithKIND_TURB_MODEL= SST, which has been rejected inSetPostprocessingsince 2019 (f30a8bf). It parses but aborts at startup. Sameroot cause — a config that no longer matches the API and is not regression
tested.
I would like to start working on this. I would rather be pointed at the right
part of it than pick for myself:
iteration-control renames are the most mechanical and I can verify those
locally. The turbomachinery markers I am less sure about.
FSI_*,SOLVER= FLUID_STRUCTURE_INTERACTION), should they be deleted, or is the featurereachable under a different solver name?
or separately? From Test cases unsteady does not work #2524 and Update deprecated EXT_ITER option in test configs #2866 I am aware that a config which merely
parses is not the same as one that converges usefully, and the second part is
the slower one.
Happy to work through it in small PRs in whatever order suits review.
Bug report checklist
Desktop (please complete the following information):
-Dwith-mpi=disabled)