Change for sliding plane when relative frame is used

[FabianYan2010]

Proposed Changes

In some cases we use relative frame for rotor zone to perform URANS, e.g., in aeroelasticity analysis, we want the grid movement comes only from blade deformation. The problem is that the sliding plane in SU2 works only for absolute frame. In relative frame, the grid is not rotating, so the interpolation at sliding interface is not changed as time step is marching. The proposed changes rotate the sliding interface in accordance with physical time steps to perform interpolation. This function is activated only for relative frame. The grid itself is not rotating.
Currently, this is only implemented in CNearestneighbor class, other interpolation method should be changed as well in the near future.

Related Work

Resolve any issues (bug fix or feature request), note any related PRs, or mention interactions with the work of others, if any.

PR Checklist

Put an X by all that apply. You can fill this out after submitting the PR. If you have any questions, don't hesitate to ask! We want to help. These are a guide for you to know what the reviewers will be looking for in your contribution.

• I am submitting my contribution to the develop branch.
• My contribution generates no new compiler warnings (try with --warnlevel=3 when using meson).
• My contribution is commented and consistent with SU2 style (https://su2code.github.io/docs_v7/Style-Guide/).
• I used the pre-commit hook to prevent dirty commits and used pre-commit run --all to format old commits.
• I have added a test case that demonstrates my contribution, if necessary.
• I have updated appropriate documentation (Tutorials, Docs Page, config_template.cpp), if necessary.

[pcarruscag]

Can you make this a config option as I mentioned before?
The large solution files need to be in the TestCases repo instead of together with the code.

[pcarruscag]

Rebased this branch onto current develop and applied a few fixes found during review:

Bug fixes

• The donor-velocity rotation in CInterface::BroadcastData was gated only on donor_config->GetBoolRelFrame_SlidingPlane(), while the coordinate rotation in CNearestNeighbor::SetTransferCoeff uses donor OR target. Made the velocity gate match (OR), otherwise a config that only sets the flag on the target zone gets correctly-matched coordinates but unrotated velocities.
• GetDonor_Velocity_RotatingFrame's target-side branch read TimeIter from donor_config instead of target_config.
• The per-target-vertex rotation matrix (and rotated target coordinate) in CNearestNeighbor::SetTransferCoeff was being recomputed inside the innermost per-donor-candidate loop; hoisted it out since it's invariant across all donor candidates for a given target vertex/zone pair. This matters because this feature makes the interpolation recompute every time step.
• CMultizoneDriver now only treats a ROTATING_FRAME zone as needing a per-timestep transfer-coefficient refresh when RELATIVE_FRAME_SLIDINGPLANE is actually enabled, so existing ROTATING_FRAME + sliding-interface setups that don't use this feature don't pay a new per-timestep cost.
• Fixed copy-pasted Doxygen comments (target_config/target_geometry were both labeled "the donor mesh") and cleaned up trailing whitespace.

Test case / data files

• TestCases/sliding_interface/inlet_distortion_relative_frame/'s .dat mesh/solution/profile files were committed directly into this repo, but TestCases/.gitignore reserves that pattern for the sibling su2code/TestCases data repo (same as every other sliding_interface/* case, e.g. rotating_cylinders.su2). Moved them there: Add inlet distortion data for relative-frame sliding-plane test case TestCases#204 (also recovered the mesh files and initial restart solutions, which existed in this branch's history — commit 3f5d63d — but had been dropped before the PR's current state, so the case couldn't actually run at all as submitted).
• Also found the inlet-profile filenames didn't match RESTART_ITER=1 (SU2's existing multizone/unsteady file-naming convention expects Inlet_Distortion_<zone>_00001.dat for RESTART_ITER=1, not _00000) — fixed by renaming in the TestCases PR.
• Wired the case into parallel_regression.py/serial_regression.py (with a reduced TIME_ITER=5 for CI, following the existing uniform_flow pattern) using test_vals from an actual local run with the fixes applied.

Still needed before this can pass CI as-is: su2code/TestCases#204 needs to merge first (or regression.yml's -c develop temporarily pointed at that branch) since the new regression entry's mesh/solution/profile data lives there, not in this repo.

🤖 Generated with Claude Code

[pcarruscag]

I removed the test because it was too large, almost 1 minute.