search

cuspaceflight / firefish

CFD simulation software for Martlet 3
Apache License 2.0
5 stars 4 forks source link

Supersonic wedge example runs slowly #26

Closed rjw57 closed 8 years ago

rjw57 commented 8 years ago

On my machine, the supersonic flow example takes around 60s to run. @jb803: is there any way to speed this up? Otherwise running the test suite becomes tedious.

jb803 commented 8 years ago

We could run it for only a couple of iterations but when you view it with paraview the solution won't have converged to the actual physical solution

rjw57 commented 8 years ago

Could we add an iteration count to main() then? And have the test just run a couple of iterations. After all we care only that OpenFOAM manages to parse and run the simulation.

jb803 commented 8 years ago

Ok.

At some point when doing this I had a Courant number above 1. This caused the solution to diverge and OpenFoam to crash. This didn't happen instantly though and it ran happily for a while. Should we just be testing that OpenFoam parses it or should we test that the example works and converges? Ideally we'd have a way to check for convergence so as soon as it converges we stop the process so we don't run it for an excessive period of time

rjw57 commented 8 years ago

It's a bit of a hard thing to call. I envisaged the example tests to essentially check that we don't end up with stale code in the examples directory. (I.e. that the examples do still run.) "Correctness" of the example is a harder thing to automatically verify.

Certainly for stuff which is run on each and every pull request and often during development we want the tests to run in a few seconds. Maybe we want some more involved "correctness" tests which we run manually every so often.

I'm not sure what's the best way with this given we don't really have a QA department we can set to running examples and looking at the outcome :). My feeling is that the tests which run by default should be quick.

Maybe we can postpone the problem until we've got a MVP which can generate plots of the output. Then we can include a pretty supersonic flow plot in the docs and, hopefully, visually notice if it goes screwy. (Like the fin-flutter plot.)