Problem when replacing fields during RANS with combustion module on

[fracenvi]

Hello everyone,

I'm trying to run a simulation of a simple combustion case where after a certain number of iterations, calculation of certain fields is "moved" to a certain subroutine, that implements a neural network. The newly computed fields are then used to replace the actual CFD fields inside the code. During that time, all of the dedicated routines for their calculation are turned off (d3pint.f90, pppdfr in d3pphy.f90). What is strange is that each of the modified fields seems to be reset in the following iteration, and the pressure field explodes towards non-feasible values for that instance.

I tracked down the problem to something that happens in the cs_pressure_correction subroutine in navstv.f90 (the one for Navier-Stokes resolution).

Does anybody know what can posssibly cause this issue inside that routine?

I attached a snapshot of the field values on cells present in the log file to show you the variables of interest (the one signed with *ANN_o) together with some other outputs of the same log file to try to give more context. I also attached a copy of the modified routines in cs/src.

Thanks to everybody,
Francesco

[Yvan Fournier]

Hello,

Which fields are you trying to turn off ? Whatever you do in d3pint, pppdfr, and d3pphy, some physical properties are updated elsewhere, and all solved combustion fields are still solved in the loop on scalars (which used to be scalai.f90 in older versions, and is now in cs_solve_transported_variables.cpp.

In the future, we should be adding a pointer to an optional cs_time_control_t structure to each solved field, so as to be able to finely control which fields are updated and when, but the mechanism is only very partially setup and used at this stage.

Best regards,

Yvan

[fracenvi]

Hello Yvan,

I'm trying to turn off density, temperature and mass fraction calculations (those for ym_fuel, ym_oxyd and ym_prod). Should i be checking then in scalai.f90? I saw that the routine calls upon covofi for resolution of the scalars, hence i run some checks in covofi.f90 and this was the output:

Pinzo covofi.f90: Getting source term for -> mixture_fraction
Pinzo covofi.f90: Getting source term for -> mixture_fraction_variance
Pinzo covofi.f90: Getting source term for -> enthalpy

Regards,
Francesco

[Yvan Fournier]

Hello,

Temperature is computed based on enthalpy, so if you change one without changing the other, I am not too

Also, the computation of rho requires specific precautions in combustion cases, and there is a relaxation parameter (check for srrom) in this regards.

I would not expect a computation in which you change the density using another model to work, at least not without a compressible solver. Using the unsteady variable density flow option (idilat 2) may help if you are not already using this option (as perhaps would switching to a Boussinesq model), but I doublt it is enough.

It is not possible to use the compresible model with combustion, as it requires a specific thermal variable (total energy instead of enthalpy). In v9.0, there is a new compressible model based on H. Amino's PhD work (https://theses.fr/2022ENPC0022), which can be used with enthalpy as a thermal variable, so might work better in your case, but I am not sure we have example on how to activate it yet.

Best regards,

Yvan

[fracenvi]

Hello Yvan,

Thanks for the tip on the temperature and the density. From what i understood you think the possible "explosion" of the pressure values may also be attributed to the wrong density algorithm chosen, am i right?

I will now try to see what happens in both cases with idilat set to 2 and the Boussnesq approximation.

Regards,
Francesco