Mark Adams <[email protected]> writes:

...

My real concern with randomness is that results are not reproducible.

My feeling is that this will be small but it will finite in exact arithmetic, which is not ideal.

If the solve is sensitive to this then I think the you are in trouble anyway (if a plane craters you don't really care how deep the hole is).

I'm more concerned with the process users go through. If they are solving a borderline system and it sometimes converges and sometimes fails, they may well conclude "PETSc is flaky software". Especially if attempts to reduce aren't reproducible. I don't look forward to getting a matrix in the mail with a report "I tried ex10 with these options and it failed twice in 20 runs". We have an idea of where to start, but it's much worse if the user doesn't write us.

If it did indeed lead to an irreplaceable error then you can look at the verbose output and see that the failures had lower estimates. At least it is debuggable and since it has never actually happened, has it, then I think we could live with the possibility.

There is also the issue that some people simulate unstable systems with rare events, such as certain failure modes in fracture or transitions in climate. In order to investigate the rare events, sometimes they need to be reproducible. We shouldn't let this prevent us from choosing a more robust default, but we should strive to document every point of non-reproducibility and how to make results reproducible. This is extra cognitive load and more to maintain, so it would be nice to keep the number of such points small.

You can compute it before you create the RHS, no?

Depends on the problem.

Perhaps we add a SetVectos(Vec[],numvec) that you call before setup() to if you really care about memory?

No, too much to think about.