Commit Graph

7 Commits

Author SHA1 Message Date
e98dcc5aa8 solvers: Added ddtCorr support in MRF regions by extending the use of Uf and rhoUf
to provide the old-time absolute flux.  This avoids possible
pressure-velocity-flux decoupling (staggering) within the MRF region using
ddtCorr to better couple the velocity and flux fields.
2023-03-24 17:23:14 +00:00
d9ba28b427 momentumTransportModels: Added a new predict() function in addition to the existing correct() function
Some momentumTransportModels like the laminar Stokes and generalisedNewtonian
models do no solve transport equations and the transport coefficients they
provide can be predicted at the beginning of the time-step rather than corrected
at the end, after conservative fluxes are available.  A particular advantage of
this approach is that complex data cached in the momentumTransportModels
can now be deleted following mesh topology changes and recreated in the
predict() call which is more efficient than attempting to register and map the
data.

Currently the predict() function is only used for the Stokes and
generalisedNewtonian models but it will be extended in the future to cover many
LES models which also do not require the solution of transport equations.

All solvers and solver modules have been update to call the
momentumTransportModel::predict() function at the beginning of the time-step,
controlled by the new PIMPLE transportPredictionFirst control as appropriate.
2022-12-16 10:12:22 +00:00
ce42ebc5d7 thermophysicalTransportModel: added predict() function
None of the current thermophysicalTransportModels solve transport equations in
order to evaluate the thermophysical transport properties so it makes more sense
that the evaluation occurs at the beginning of the time-step rather than at the
end where conservative fluxes are available for transport solution.  To enable
this the correct() functions have been renamed predict() and called in the
prePredictor() step of foamRun and foamMultiRun and at the beginning of the
time-step in the legacy solvers.  A particular advantage of this approach is
that complex data cached in the thermophysicalTransportModels can now be deleted
following mesh topology changes and recreated in the predict() call which is
more efficient than attempting to register and map the data.

An empty correct() function is included in addition to the new predict()
function in thermophysicalTransportModel to support scalar flux transport
closure in the future if needed.

Additionally the two transport model corrector function calls in foamRun and
foamMultiRun have been combined into a single postCorrector() call to allow
greater flexibility in transport property prediction and correction in the
modular solvers.
2022-12-15 14:59:44 +00:00
a6456cdd73 solvers/modules: turbulence -> momentumTransport
Momentum transport in the modular solvers is generalised and run-time
selectable, supporting laminar, generalised laminar or non-Newtonian as well LES
or RAS turbulence modelling so it is clearer to name the momentum transport
model instance 'momentumTransport' rather than 'turbulence'.
2022-12-07 14:45:49 +00:00
e8078ca235 multiphaseEuler::MomentumTransferPhaseSystem:alphaDByAf: multiphase consistent replacement for DByAfs
In order that the phase-fractions sum to 1 it is necessary that the same
diffusivity is used for ALL phases in the implicitPhasePressure option.  This is
guaranteed by the new alphaDByAf function which returns a single
surfaceScalarField diffusivity to be used when forming the Laplacian term in the
implicit phase-fraction diffusion correction equation in phaseSystemSolve.

The phase-pressure and turbulent dispersion interface terms are summed over all
phases and interfaces in alphaDByAf to form a single diffusivity.
2022-12-01 21:12:04 +00:00
084097bab9 solvers/modules: Updated correctPhi logic so that it is not required following topology change
Now fluxes are updated from the mapped fields following mesh topology change
with or without implicit continuity correction enabled by the optional
correctPhi switch.
2022-11-20 20:22:59 +00:00
29b82422d7 applications/solvers/modules: Reorganised to match the structure of tutorials/modules
Given that the number of solid solver modules is currently 1 and unlikely to
exceed 3 it is not very useful to maintain solid and fluid sub-directories and
easier to see the correspondence between the solver modules and tutorial cases
without.
2022-11-16 23:28:59 +00:00