[mlatour]

Hi everyone,

I'm currently working on adding body force modeling capabilities to SU2, which would require the reading of a file (see attachment) with values so that they can be stored in an array and used in the numerics class. I understand how to add simple list, double, or string options to the source code, but am having difficulty understanding how to read a file and store it in an array that can be used in the numerics class.

A new class will have to be created, but where would I add this? A file is read for the inlet profile option, but that code is quite extensive and more complicated to understand.

Any help would be appreciated.

Kind Regards,
Marc

[pcg]

Would those values be used to compute some source term? Are they constant over time and space? Or do you have different values for different nodes/regions?

If the answers to the above are: yes, yes, no. Then:

Look into numerics_direct_mean.cpp and CSourceXXXX

If you can get away with modifying an existing class it would save you some time, for example take CSourceBodyForce, read your file in its constructor and then modify the ComputeResidual method.

Source term numerics are used by method CEulerSolver::Source_Residual, this method of the solver goes over all nodes, passes some data of each node to the numerics class and then calls ComputeResidual on it.
Make sure this method is passing all the data you need to the numerics class.

[mlatour]

Hey Pedro,

The source term values are spatially varying and I have been able to hard-code an implementation that seems to be working. I've adapted the CSourceBodyForce code to compute my force at each node according to the theory.

I was thinking of having CSourceBodyForce read the file, but wouldn't this mean it will be done at every node? Although it may only be a simple file, this would add more computational time to each loop. Is there a way to have it read the file outside this loop and then have the CSourceBodyForce class accept an additional variable, in this case an array with the data from the file?

Regards,
Marc

[pcg]

Hi Marc,

Ah! That is why I asked if they are constant.

There is no automated way...
The numerics classes get their data from CGeometry and CVariable, the "SU2 way" to do what you want is to add the fields you need to CVariable (since they vary with space) and then set the data in numerics in the SourceResidual loop.

You could read and set that data in CVariable in the solver constructor (executed only once) or in the solver preprocessing method (executed every iteration).
If you just want to prototype you could also avoid CVariable and add a few vectors directly to CSolver...

Cheers,
Pedro

[gaurav11]

Hello! I have recently started working on a project using SU2, that involves adding a spatially varying source term in the Momentum equation for a steady, incompressible RANS solver. Can anyone provide some guidance on how to go about it? I also need to optimize this source term by comparing my RANS results with the DNS data. Is it possible to do it using SU2's adjoint-based optimizers? I have programming experience in C, MATLAB, and python.

[bigfootedrockmidget]

what kind of source term is it?



You can start by looking in flow_sources.cpp, have a look at CSourceGravity for instance for a simple example.

If the number of control variables is small, then it's probably better to just do a couple of simulations with different values for the parameters.

[gaurav11]

The source term is a correction term, applied in the x-momentum equation. The "true" velocity field is from a DNS solution. The source term, which is spatially varying, has to be adjusted so that the RANS simulation can match the DNS solution.

[bigfootedrockmidget]

So you have a source term S(x,y,z) that needs to be added in every cell, and adjusted such that it matches a DNS?


What's the physics behind this source term? Is it turbulence related? If so, then why not use a turbulence model? Whatever the origin of the source term is, it is better to implement the physics behind it.

[gaurav11]

No, the source term does not have to match with the DNS. The corrected values of the RANS simulation (velocity and pressure), should match with the DNS data. The source term is a mathematical construct, acting as a model corrector.
There is no physics behind it. The paper below might be useful to get the idea
behind the approach
https://www.sciencedirect.com/scienc...21999115007524

[bigfootedrockmidget]

This paper does not describe what you just said. So do you want to use field inversion in a machine learning approach to find the stochastic field S, which is the corrective source term that you are talking about? This is still physics based, with many assumptions, the first one being: what does the stochastic field model? In the paper of Duraisamy for instance their term"beta" models a correction to the turbulent production term in the boundary layer.

If you add a source term in the momentum equation, what you want to do, what does it model? A correction to the viscous stress term? You still need a turbulence model or else you will never get any useful results, so better move the correction to the turbulence source terms because that's where the uncertainty is. Else the field will act as a correction to the turbulent viscosity, for which you are already solving a pde.

[gaurav11]

Ok. I think this is not helping to solve any problem. I am not replicating that paper, I have already done a part of it. The bigger picture of that paper is though, exactly what I am trying to do. The correcting "Beta" is indeed like a source term, which is inferred by comparing an "inferior model" to a "superior model". The whole project has different steps.
The first step is to be able to provide a "source term" to each node. There is no formula for the source term. That is not the end goal. That is just a "proof of concept" to show that a spatially varying source term can indeed be read from a file and applied to the momentum equation, at each cell (or node). Whether I am getting a useful result or not is not the point I am concerned about right now.