Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MARKER_ENGINE_INFLOW seems to be not working as intended. #2274

Open
BerkeCan97 opened this issue May 6, 2024 · 3 comments
Open

MARKER_ENGINE_INFLOW seems to be not working as intended. #2274

BerkeCan97 opened this issue May 6, 2024 · 3 comments
Labels

Comments

@BerkeCan97
Copy link

Hi,

While working with Marker_Engine_Inflow, I have noticed that the boundary condition is not working as intended with the option ENGINE_INFLOW_TYPE= FAN_FACE_MACH. The solutions rapidly diverge when I use FAN_FACE_MACH, but they converge if I use FAN_FACE_PRESSURE and set the pressure to a reasonable value. Looking at the source code, I believe this cause by not reevaluating the marker's Mach Number.

Looking at the source code, I would suggest adding the following line of code to CEulerSolver.cpp after line 2932 which is where it seems to update other marker parameters.

config->SetInflow_Mach(iMarker_Inlet, Inlet_Mach_Total[iMarker_Inlet]);

@BerkeCan97 BerkeCan97 added the bug label May 6, 2024
@pcarruscag
Copy link
Member

If you could submit the fix and a small testcase to use as regression it would be great.

@BerkeCan97
Copy link
Author

Hi again,

I am using the the Inviscid Bump in a Channel tutorial as a test case by changing the outlet boundary condition to Marker_Engine_Inflow. However, the boundary condition is still seems unstable even with very low damping values. It seems that the evaluation frequency of the marker's properties is tied to the screen write frequency through the following line:

bool Evaluate_BC = ((((config->GetInnerIter() % (config->GetScreen_Wrt_Freq(2)*40)) == 0)) || (config->GetInnerIter() == 1) || (config->GetDiscrete_Adjoint()));

which makes the minimum evaluation frequency 40. I believe 40 iteration seems to be too high, at least for this case. I have since added a new option to the code to control the evaluation frequency. I been experimenting with the evaluation frequency and the damping factor to get the marker to converge on the Mach Number on some of the cases. I will test this on larger case next week and i can get back to you on how those go as well.

Finally, I am a bit of a novice and it is my first time ever using something like git. I have already created a fork of the master branch. Do i just make pull request to submit my changes or is there something else I should do?

@pcarruscag
Copy link
Member

The github process is described in our docs https://su2code.github.io/docs_v7/Gitting-Started/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants