Changes of sliding plane for turbomachinery

[FabianYan2010]

Adaption of the interpolation method NearestNeighbor to turbomachinery applications when rotating frame is used.

Proposed Changes

If the flow is solved in a rotating frame, the grid is not actutally rotating. But the interpolation for a sliding interface should be done with an actually rotated boundary. The proposed changes add the function of rotating grid points on the boundary of a zone solved in rotating frame before the interpolation is executed. Currently, this is only implemented in CNearestneighbor class, other interpolation method should be changed as well in the near future.

Related Work

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.

• [ yes ] I am submitting my contribution to the develop branch.
• [ yes ] My contribution generates no new compiler warnings (try with --warnlevel=3 when using meson).
• [ yes ] 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.

[bigfooted]

Our working branch is 'develop', so you should have started from that and also merge into it. Every 6 months or so we then make the current develop into master. I changed the target branch to develop, and also updated your branch with current develop.
Can you have a look at the failed check for clang-format coding style and format the changed file accordingly? https://su2code.github.io/docs_v7/Style-Guide/

[pcarruscag]

If the mesh is not moving, why are you rotating the search coordinates?

[bigfooted]

Should we close this pull request?

[FabianYan2010]

If the mesh is not moving, why are you rotating the search coordinates?

I'm so sorry for the belated response! I was trying to debug and test the new feature and to give a proper pull-request. As for the question: Because we are using rotating frame for rotor. In rotating frame we consider the rotating effect by adding source terms in governing equations so that the mesh movement is spared. But when we transfer data between rotor and stator for unsteady simulation, the rotor side has to be rotated to match the reality. The rotor is actually rotating, so as the flow phenomena, like rotor wakes passing through the interface. Otherwise, we will see non-rotating wakes in the stator frame of reference. Every time step, the matching grid points between two sides need to be updated as well.

[FabianYan2010]

Our working branch is 'develop', so you should have started from that and also merge into it. Every 6 months or so we then make the current develop into master. I changed the target branch to develop, and also updated your branch with current develop. Can you have a look at the failed check for clang-format coding style and format the changed file accordingly? https://su2code.github.io/docs_v7/Style-Guide/

Thanks a lot! It's very much appreciated. I have implemented the clang-format according to the guide and force formatting all files by using 'pre-commit run -a'. I think the new commits should be conformed to the coding style but not sure if the previous commit is also changed.

[pcarruscag]

That's not consistent with any code I know, when using the MRF approach you either get frozen rotor or mixing plane interfaces. If you want a more accurate simulation you move the mesh and update the interfaces, there are several advantages to not dealing with the MRF source terms. There are also practical aspects of not updating the interface when doing transient MRF, for example it lets you handle interfaces that are not cylindrical, people use this to model car wheels. MRF is also less restrictive for time step size than moving mesh, but if you move the interface you bring some of the moving mesh restrictions to MRF. So my impression is that this strategy combines some of the downsides of both approaches...

[FabianYan2010]

Thanks for your comments! Except for mixing plane and frozen rotor, sliding plane is also pretty common in turbomachinery simulation, it is indeed implemented in some, if not all, in-house codes. MRF is quite useful in turbomachinery simulation, expecially when we deal with transient simulation. Actually it is really rare to move the rotor mesh like in reality. One reason is that MRF is more efficient and accurate. Otherwise, you introduce new disturbance into the transient flow field every physical time step, which is not good. Because when you rotate the mesh, the velocity direction of each grid point inherited from last time step is not rotated. To make it more clear, you will have a flow going towards casing instead of parallel to, at the start of next physical time step. So you need more pseudo time steps to get a proper velocity variable. As a result, you get a zig-zag shape in the residual history. I'm not actually moving the interface. The rotor mesh is not rotated, so as the interface at rotor zone. I'm just virtually rotating the rotor interface to find the new matching points between rotor and stator for each physical time step, so that the variable could be passed across the interface. In other words, only the passing variables are actually rotated. If I understand it correctly, there is no additional moving mesh restriction introduced here.

[pcarruscag]

Updating the interface creates relative motion and thus you have blade-passing frequencies to resolve, which require more detail to resolve than just rotation. If you want this as a different option that's fine, but it's not going to be the default.

[FabianYan2010]

Sorry about that, I didn't know new commits somehow go into this PR automatically. I'll open new PRs for each of them

Pedro Gomes @.***> 于2024年6月3日周一 12:38写道：

@.**** commented on this pull request.

@FabianYan2010 https://github.com/FabianYan2010 can you separate the different features you are working on into different PRs please? I think I count 4 quite large ones already.

— Reply to this email directly, view it on GitHub https://github.com/su2code/SU2/pull/2173#pullrequestreview-2092778271, or unsubscribe https://github.com/notifications/unsubscribe-auth/BEECKG2UOQUSK2WEASMBYOLZFPXLRAVCNFSM6AAAAAA7UN6HYOVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDAOJSG43TQMRXGE . You are receiving this because you were mentioned.Message ID: @.***>