dougshidong
commented
1 year ago I would go a step further and say that physics should not receive Parameters that contains everything needed for PHiLiP. NavierStokes should probably receive a NavierStokesParameters object, Euler should receive an EulerParameters, etc. (or whatever better suffix like Dimensionalization/Input/Properties/Characteristics). Each of them derived from some PhysicsBaseParameters class, that would contain your non-physical handling flags.
When I first wrote PHiLiP, I did a bad job by passing lots of parameters through functions, when I should have been passing around structs/data classes. We should try and encapsulate this data, so that passing around a new parameter can be done by adding to the data class rather than the function.
As of PR #214 , all physics have access to the parameters object. We should therefore access physics parameters (for instance, reference length, mach inifinity, etc) from the parameters object rather than by adding more arguments to the constructor.
It may be useful to overload the contructors such that existing tests aren't changed. Furthermore, it would be nice if a physics object could be constructed without the need for a parameters object, e.g. in unit tests.