[WIP] Multizone adjoints for turbomachinery

[joshkellyjak]

Proposed Changes

This is a cleaned up PR of the fixes needed for multizone adjoints for turbomachinery from the previous PR of @oleburghardt and I's work.

This hopefully is useable, so if you would like to test and report please feel free to contact me on Slack.

TODO:

• Fix eddy viscosity tape issue in CNSSolver
• Add turbomachinery objective functions + constraints
• Include MZ testcase

Related Work

Now closed PR #2317

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.

• [ X ] 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]

What is the difference between ending the preaccumulation before or after?

[pcarruscag]

Suggested change

	SU2_MPI::Error(string("OUTPUT_WRT_FREQ cannot be specified for this solver "
	SU2_MPI::Error("OUTPUT_WRT_FREQ cannot be specified for this solver "

[pcarruscag]

Hmmm I'm pretty sure it is possible

[joshkellyjak]

This is one for @oleburghardt

[oleburghardt]

Yes and no, writing the files is fine, but the continuation of the multi-zone discrete adjoint solver is erratic. My guess is that some indices aren't cleared properly before re-recording the tape. (Writing adjoint solution variables to file only, without re-recording at all and without sensitivities, might give us some hints.)
The debug mode could eventually pin down where exactly things go wrong.

[pcarruscag]

Why are these wrong but not the others that follow the same pattern?

[joshkellyjak]

This threw a tagging error, and if I remember correctly it's because in the other sections the variables it accesses are directly used in the solver, whereas in the Giles implementation they are not, creating a mismatch in tags.

[pcarruscag]

Can we fix it in a way that keeps a clear pattern for doing this type of thing?

[joshkellyjak]

I can give it a go

In general, to fix a “long switch case” issue, you extract the lengthy logic into a dedicated helper function and have the case body invoke that function with the required inputs, returning or mutating data as needed. This shortens the case body, makes the switch easier to read, and isolates the complex behavior into a function that can be tested or modified independently.

Here, the best approach is to move the logic inside case LINEAR_INTERPOLATION: into a new private helper method of CMixingPlane, e.g. ComputeLinearInterpolationSpan(...). This helper will:

• Take as parameters all the data it needs:
  • the target span index iSpanTarget,
  • the donor and target span values arrays spanValuesDonor and spanValuesTarget,
  • donor span count nSpanDonor,
  • the targetSpan struct reference (to write donorSpan and coefficient),
  • and rank (for warning output).
• Implement exactly the same logic that is currently in the LINEAR_INTERPOLATION case: bounds checks with clamping, interval search, coefficient computation, and conditional warning printing.
• Be defined as a member function in CMixingPlane.cpp (and declared in the corresponding header CMixingPlane.hpp, but we are not allowed to edit it here, so we will implement it as a static or anonymous‑namespace helper function in the .cpp instead, using only what we see). Since we cannot change the header, the safest is to define a static free helper function inside CMixingPlane.cpp near SetTransferCoeff and use it directly there.

However, we are constrained to only modify shown snippets and remain within Common/src/interface_interpolation/CMixingPlane.cpp. We can therefore:

1. Introduce a static helper function above the switch within the same snippet, e.g.:

   static void ComputeLinearInterpolationSpan(
       int iSpanTarget,
       const su2double* spanValuesDonor,
       const su2double* spanValuesTarget,
       int nSpanDonor,
       int rank,
       decltype(targetSpans[0][0])& targetSpan);

   (With the exact implementation copied from the current LINEAR_INTERPOLATION case.)

2. Replace the body of case LINEAR_INTERPOLATION: with a single call to that helper, passing in iSpanTarget, spanValuesDonor, spanValuesTarget, nSpanDonor, rank, and targetSpan.

All existing behavior (including the warning messages and value clamping) will remain identical, because we will not change the logic, only relocate it. No new imports or external dependencies are required.

In general, to avoid overflow when a multiplication result is intended to be stored in or used as a larger integer type, at least one operand should be explicitly cast to that larger type before the multiplication. This promotes the entire multiplication to be performed in the larger type, ensuring that intermediate results cannot overflow the smaller type.

In this specific case, the problematic expression is in the nested loop where values are copied from buffDonorVar into sendDonorVar:

for (auto iSpan = 0; iSpan < nSpanDonor + 1; iSpan++){
  for (auto iVar = 0u; iVar < nMixingVars; iVar++)
    sendDonorVar[iSpan * nMixingVars + iVar] =
      buffDonorVar[static_cast<size_t>(iSize) * nSpanDonorVars +
                   iSpan * nMixingVars + iVar];
}

The product iSpan * nMixingVars is computed in the default integer type and then used as part of a size_t index expression on the right-hand side; a similar computation is used for the left-hand side index. The best fix is to promote iSpan (or nMixingVars) to a wide type such as size_t (or unsigned long, consistent with nearby code) before multiplication, ensuring that the multiplication happens in the wider type. Concretely, we should:

• Cast iSpan to size_t (or unsigned long) in both index expressions where iSpan * nMixingVars appears.
• Optionally, also cast nMixingVars to the same wide type for clarity and type consistency, but this is not strictly necessary; promoting just one operand is enough.

No new methods or external libraries are required; we only add explicit casts in the relevant expressions. All changes are confined to SU2_CFD/src/interfaces/cfd/CMixingPlaneInterface.cpp in the shown region.