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

[WIP] Preconditioning for multicomponent flows #2426

Open
wants to merge 38 commits into
base: develop
Choose a base branch
from

Conversation

Cristopher-Morales
Copy link
Contributor

@Cristopher-Morales Cristopher-Morales commented Jan 18, 2025

Proposed Changes

This pull request aims to extend the preconditioning for incompressible multicomponent flows, specifically when FLUID_MIXTURE model is used and energy equation is solved. Changes introduced in this pull request aim to solve directly for the sensible enthalpy instead of temperature. Specifically, the energy equation that is going to be solved for multicomponent flows is given as follows:

image

and the sensible enthalpy is:
image

Currently $C_{p}$ does not depend on temperature for FLUID_MIXTURE, but it depends on the mixture composition. So the sensible enthalpy simplifies to $C_{p}*(T-T_{0})$. For problems where $C_{p}$ strongly depends on the temperature, Cantera library will be coupled to SU2. After this pull request is completed, a pull request with a fluid model using Cantera will be done where an energy equation for the total enthalpy will be solved.
A pdf document will be attached in the coming days for giving more details about this pull request.

Related Work

Currently fluid mixture does not work correctly when the energy equation is on, this is mainly due to the fact that the energy equation that must be solved for multicomponent flows is the one mentioned above for the sensible enthalpy and not the energy equation for a perfect gas that is currently solved in SU2.

PR Checklist

  • 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.

@Cristopher-Morales Cristopher-Morales changed the title [WIP] Preconditioning fro multicomponent flows [WIP] Preconditioning for multicomponent flows Jan 18, 2025
Comment on lines +1335 to +1336
lim_i = 1.0; // nodes->GetLimiter_Primitive(iPoint, iVar);
lim_j = 1.0; // nodes->GetLimiter_Primitive(jPoint, iVar);

Check notice

Code scanning / CodeQL

Commented-out code Note

This comment appears to contain commented-out code.
Comment on lines +358 to +363
/*!
* \brief Virtual member.
* \param[in] val_enthalpy - Enthalpy value at the point.
*/
virtual void ComputeTempFromEnthalpy(su2double val_enthalpy, su2double* val_temperature,
const su2double* val_scalars = nullptr) {}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems inconsistent with the SetTDState_* functions.
Should this be SetTDState_h and then you use GetTemperature to get the temperature?

Copy link
Contributor Author

@Cristopher-Morales Cristopher-Morales Jan 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the pull request made by evert regarding preferential diffusion, he also used the same function for the flamelet solver. The only difference is that that function is in the CSpeciesFlameletSolver.cpp and I cannot access to that function when I set the primitives in SetPrimVar in CIncNSVariable.cpp

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My point is again to keep an abstract interface.
Evert's function is a private function of a specific solver which is perfectly fine, and it uses the fluid model... If you need a similar function, move it somewhere higher up in the hierarchy to make it accessible. For example the scalar solver. Or even the fluid model but implemented in a way that keeps it useful for all fluids.

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

Successfully merging this pull request may close these issues.

2 participants