search

IBAMR / IBAMR

An adaptive and distributed-memory parallel implementation of the immersed boundary (IB) method
http://ibamr.github.io/
Other
346 stars 144 forks source link

multiphase_flow/ex2 is too long #288

Closed drwells closed 4 years ago

drwells commented 6 years ago

I let this run for a few days. Even though the final time for the test is 10 (not unreasonable), the test has only gotten to about t = 0.8 over the last three days (i.e., this test would need about a month to finish). We should shorten this by as much as possible.

This is also an issue with the example input file input2d.cyl (its identical to input2d.test).

drwells commented 6 years ago

The logfile indicates that the timestep was about 1e-7 for this test; it might be worth seeing if we can get that value up.

amneetb commented 6 years ago

For multiphase_flows/ex1 and multiphase_flows/ex2 the end time should be around 0.7 in input2d.cyl/input2d.test files. The cylinder reaches the bottom domain by then. Any more runtime forces it to impinge on the wall with prescribed velocity, which then leads to reduction of time step size.

screen shot 2018-08-15 at 11 37 04 am
drwells commented 6 years ago

It looks like the time step stays at 5e-05 until about t = 0.74, at which point it starts decreasing a lot.

We still need 14000 time steps to get that far.

amneetb commented 6 years ago

I am wondering if we should split tests into two categories: one that require eyeballing or steady state solutions (long runs) and one that are quick to run and do quantitative number checking? This test is supposed to be long to check for interface evolution and stability.

drwells commented 6 years ago

I think that's reasonable. In principle we do have gtest-long but the tests are really not that different from gtest (and this one, in particular, is in gtest).

boyceg commented 6 years ago

I think that it is worth emphasizing that the gtest tests are software tests, which are different from method verification/validation tests (although they can also be method verification/validation tests if those tests are relatively fast, or they could be short sections of those kinds of tests). The purpose of the gtest tests is to identify regressions in the implementation.

Imagine that someone accidentally did something to reduce the order of a fluid solver. (Who would have ever done such a terrible thing? Well, I did once, and it took me a while to notice it, because I did not have automated regression tests!) One would not need to run for 1000’s of time steps to notice this regression; there would be a change in the output after even a small number of time steps.

In most cases, I think that for the gtests, we just want to run for long enough for something nontrivial to happen, and then compute some statistics about the result that are easy to check.

drwells commented 6 years ago

Boyce is right, and this is a real problem with the current design of the test suite: we really don't have any unit tests. It would be really great if, for example, we had tests for things like slope limiters and other pieces buried in the guts of the library.

The kind of test that we could turn this example into is different: we can check a lot of things at once by computing statistics with this flow.

drwells commented 4 years ago

Now that the gtest tests are all converted this isn't really an issue - its fine to have long examples.