This change lets the solver be looked up from the region database, so
that aspects of the solution algorithm can be accessed by
functionObjects and fvModels and similar. For example, a fluid solver
could be looked up as follows:
const solvers::fluid& s =
mesh().lookupObject<solvers::fluid>(solver::typeName);
executed with foamRun for single region simulations of foamMultiRun for
multi-region simulations. Replaces solidDisplacementFoam and
solidEquilibriumDisplacementFoam and all the corresponding tutorials have been
updated and moved to tutorials/modules/solidDisplacement.
Class
Foam::solvers::solidDisplacement
Description
Solver module for steady or transient segregated finite-volume solution of
linear-elastic, small-strain deformation of a solid body, with optional
thermal diffusion and thermal stresses.
Solves for the displacement vector field D, also generating the stress
tensor field sigma, including the thermal stress contribution if selected.
SourceFiles
solidDisplacement.C
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.
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.
