Skip to content
Snippets Groups Projects
Commit 5d584be4 authored by Vaggelis Papoutsis's avatar Vaggelis Papoutsis Committed by Andrew Heather
Browse files

ENH: adjustments to the efficiency of the adjoint code

- ATCstandard, ATCUaGradU:
  the ATC is now added as a dimensioned field and not as an fvMatrix
  to UaEqn. This get rid of many unnecessary allocations.

- ATCstandard:
  gradU is cached within the class to avoid its re-computation in
  every adjoint iteration of the steady state solver.

- Inlined a number of functions within the primal and adjoint solvers.
  This probably has a negligible effect since they likely were inlined
  by the compiler either way.

- The momentum diffusivity at the boundary, used by the adjoint boundary
  conditions, was computed for the entire field and, then, only the
  boundary field of each adjoint boundary condition was used. If many
  outlet boundaries exist, the entire nuEff field would be computed as
  many times as the number of boundaries, leading to an unnecessary
  computational overhead.

- Outlet boundary conditions (both pressure and velocity) use the local
  patch gradient to compute their fluxes. This patch gradient requires
  the computation of the adjacent cell gradient, which is done on the
  fly, on a per patch basis. To compute this patch adjacent gradient
  however, the field under the grad sign is interpolated on the entire
  mesh. If many outlets exist, this leads to a huge computational
  overhead. Solved by caching the interpolated field to the database and
  re-using it, in a way similar to the caching of gradient fields (see
  fvc::grad).

WIP: functions returning references to primal and adjoint boundary
fields within boundaryAdjointContributions seem to have a non-negligible
overhead for cases with many patches. No easy work-around here since
these are virtual and cannot be inlined.

WIP: introduced the code structure for caching the contributions to
the adjoint boundary conditions that depend only on the primal fields
and reusing. The process needs to be completed and evaluated, to make
sure that the extra code complexity is justified by gains in
performance.
parent c9ca6b9f
Branches
Tags
1 merge request!518ENH: adjoint code review
Showing
with 335 additions and 382 deletions
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment