Handle pressure scaling consistently and document how in the relevant interfaces

[Martin Sandve Alnæs]

Since physical pressure and solver pressure is different by a factor rho, we run the risk of forgetting to scale and using the wrong values. I've added a ppfield PhysicalPressure which scales the solver pressure by rho to get the correct value for visualization, however for restarting we still need to store the solver pressure. Or maybe we can just store the physical pressure and scale it back when restarting? In one sense it would be natural for the problem BC and IC to be specified in physical units, but that might not be the most efficient since they then have to be scaled in addition. We need to discuss this and find a consistent solution.

[Martin Sandve Alnæs]

We need to resolve this and make it intuitive. It's better to fix it now before the first release.

There are two "pressures", the physical pressure and the scaled pressure.

The schemes work with scaled pressure.

The user interface interacts with pressure values at two ends: IC/BC and postprocessing. I think these should be consistent to avoid confusion.

If we make "pressure" at the user side mean physical pressure (which I think is most natural), we need to scale the IC and BC functions in the schemes. Replay must be handled consistently.

Opinions?

[Øyvind Evju]

The cost of scaling the BC-functions has to be negligible, right? The scaling of pressure in the postprocessing can be done by the convert-function, and is more or less negligible as well.

Handling it in replay and restart is trivial, as long as the postprocessor does it's job.

I completely agree that every "pressure" the user sees should be physical pressure.

We could alternatively have a parameter in NSScheme to allow the user to input "solver pressure" when better performance is desired.

[kentand]

I agree that it make sense to store everything in real units and that restarting should require a scaling.

[Øyvind Evju]

How should we handle this in the schemes? I guess the easiest way would be to scale the solver pressure to physical pressure (and vice versa) when needed. This would be before applying boundary conditions and callback to update. It's not a bottle neck, however not free. Also very little sexy...

[Martin Sandve Alnæs]

I don't see a way around that.

[Øyvind Evju]

Fix issue #24: Scale solver pressure to physical pressure in official schemes

→ <<cset 50306722f4a3>>