I recently noticed that the somewhat chaotic results produced in a system using TFM are quite different when repeatedly run. I need repeatable results for some research, at least in the visual representations of the flow. After some inspection, it seems like some randomness is coming from the initial condition of the linear system solver. I am hoping that, for 2D TFM, this is the main source of the randomness.
Assuming that it is mainly the linear solver making the flow random, I am planning on changing the tolerances to minimize this effect, but there are a lot of options in the “Numerics” menu (Tabs for “Residuals”, “Discretization”, “Linear Solver”, “Preconditioner”, and “Advanced”).
I do not need a more accurate solution necessarily, just a consistent one. What should I toggle?
I am fully aware of the chaotic nature of the problem, etc. I see no discussion on limiting the effect of random linear solutions or other particular sources of randomness for identical runs.
If I were to plot some cell’s void fraction over time from twenty identical simulations, the curves would begin in a tight group and gradually diverge into some random distribution. I understand that this is not necessarily a bug, as it shows the chaos in the system. However, I am trying to narrow the grouping in these curves, such that they are grouped together for longer.
However, it would take me a couple of days to develop an exhaustive understanding of the linear solver and all of the code’s uses of random numbers such that an appropriate measure could be taken to limit the randomness.
If there is something more particular in the referenced discussion on randomness control that I missed, please let me know.
I don’t know this for certain, but I don’t think there is any randomness in MFiX’s standard BiCGStab method. You should* be able to run the exact same TFM simulation (including inputs, code, arch, hardware) over and over and get the same results. One *caveat to this might be domain decomposition. If you want to try and get the same result, I would suggest running in serial. Another caveat might be the solids stress model which is prone to returning large numbers, you might want to make that something more numerically friendly.
! determine an initial guess for the residual = residual + small random
! number (so it could be set to anything). note that since random_number
! is used to supply the guess, this line could potentially be the source
! of small differences between runs. the random number is shifted below
! between -1 and 1 and then scaled by factor 1.0D-6*Rnorm0
call random_number(Rtilde(:))
I am sure I could modify the code to an explicitly seeded pseudorandom method here.
For now I am using a greatly reduced solver tolerance to minimize the run variation. I was hoping there was some input controls I could use to seed, but I don’t see an option like this.
If anyone else would appreciate it, I think a gui-accessible option to seed runs manually could be offered in future versions. However, this would require a different random method and may not work well with multiprocessing.