axisymmetric and gravity source terms

[bigfooted]

For turbulence, axisymmetry is implemented as an inline function ResidualAxisymmetric.

But there is also the indices source_first_term and source_second_term for source terms. Here is a piece of code from CDriver.cpp below. For the flow solver, it looks like axisymmetry and gravity source terms both use the same index source_first_term and are mutually exclusive.
Does this mean I cannot use axisymmetry and gravity sources at the same time?
Does this mean that implementing axisymmetry in the same way for turbulence as we did for flow (not an inline function), we should place it at the index source_second_term, since we put the regular turbulence source terms at source_first_index?
Is it OK to keep the inline function or better to move to this source_first_term and source_second_term approach?
There is only source_first_term and source_second_term, does this mean that currently we only support max. 2 source terms?

else if (config->GetAxisymmetric() == YES) {
        if (incompressible)
          numerics[iMGlevel][FLOW_SOL][source_first_term] = new CSourceIncAxisymmetric_Flow(nDim, nVar_Flow, config);
        else if (ideal_gas)
          numerics[iMGlevel][FLOW_SOL][source_first_term] = new CSourceAxisymmetric_Flow(nDim, nVar_Flow, config);
        else
          numerics[iMGlevel][FLOW_SOL][source_first_term] = new CSourceGeneralAxisymmetric_Flow(nDim, nVar_Flow, config);
}
else if (config->GetGravityForce() == YES) {
        numerics[iMGlevel][FLOW_SOL][source_first_term] = new CSourceGravity(nDim, nVar_Flow, config);
}

[pcarruscag]

Yes we only have space for 2 source numerics, but you can add simple sources directly in the solver (Source_Residual). It would actually be more efficient to implement simple body forces like that.

It is better (simpler, more efficient) to compute the axisymmetric turbulence source together with the plain turbulence source, as we do for SST.

Gravity is not compatible with axisymmetry because we hardcode the direction as y or z in 2D / 3D respectively.
Body force, in the x direction, could be used if implemented as a simple loop.

[bigfooted]

Thanks! We still need to add axisymmetry sources for species, and for the combustion we have additional source terms for species. So a plan of attack would then be:

• add axisymmetry for species as we did for SST with an inline function
• add combustion source term using source_first_term
• if we want axisymmetry + gravity (body force) then we need to put one of these terms in source_second_term?
  [Not sure what you mean with the comment on the simple loop]

[pcarruscag]

You did not mention species before, I thought you were talking about SA.
It's not an inline function, it's just part of the turbulence source which is always there, there is no turbulence without the turbulence source term, that's why it makes sense to put it together.
For example in the IncSolver you'll find:

    SU2_OMP_FOR_STAT(omp_chunk_size)
    for (iPoint = 0; iPoint < nPointDomain; iPoint++) {
      // Using numerics
      second_numerics->SetRadVarSource(solver_container[RAD_SOL]->GetNodes()->GetRadiative_SourceTerm(iPoint));
      second_numerics->SetVolume(geometry->nodes->GetVolume(iPoint));
      auto residual = second_numerics->ComputeResidual(config);
      LinSysRes.AddBlock(iPoint, residual);
      if (implicit) Jacobian.AddBlock2Diag(iPoint, residual.jacobian_i);

      // Including a simple source directly
      if (vol_heat) {
        if(solver_container[RAD_SOL]->GetNodes()->GetVol_HeatSource(iPoint)) {
          auto Volume = geometry->nodes->GetVolume(iPoint);
          LinSysRes(iPoint, nDim+1) -= config->GetHeatSource_Val()*Volume;
        }
      }
    }
    END_SU2_OMP_FOR

[bigfooted]

but we have in turb_sources.hpp:
inline void ResidualAxisymmetric(su2double alfa_blended, su2double zeta) {

So my question basically boils down to: do we keep it like that for the other scalars?
So for species, and also for SA, we would then add a similar routine and avoid the hassle of the source_first_term and source_second_term?

[pcarruscag]

It depends, will you always have a source term for species like we do in turbulence? If so, yes, it makes sense to include axisymmetry directly, in the "default" species source.
If not, then no, it should be standalone to allow combining it with other possible species sources.

[bigfooted]

OK, I see, so we could do it 'directly' for the reacting species (source term) but not for the (in general nonreacting) species transport.