Hi,developers!
When I run the following case, I get the error shown in the picture and I can’t click on the path, I’ve tried many things but still can’t solve it, can you please help me?
Thank you very much!
Hi @wangjinjing
I can replicate this crash running your case on Windows. The reason clicking on the error line doesn’t work is that this code is not part of MFiX - it’s part of a math library MinGW-w64 which we get from conda-forge as part of the infrastructure for running Unix code like MFiX on Windows - you can read more about MinGW-w64 here if you are interested. The path C:/repo/... is the path on the machine where this library was built, on some conda-forge server, and got “baked in” to the library when the code was built. If this error was in MFiX or your usr_* routines, we would have been able to find the code.
Unfortunately, on Windows, due to the limitation of the available tools, we are only able to obtain information about the line where the error occurred, but not the entire stack of functions which called that function - this error in lround in the math library was caused by an invalid call from a higher level in the stack (MFiX code) but we are only seeing the bottom of the stack.
Linux is a better development environment and on Linux we obtain full stack traces. So usually when a case fails on Windows I try it on Linux … however, on Linux I am not seeing the same behavior … the math library is different, we’re using glibc rather than using mingw-64, and I do not get the same solver crash in lround
What I do see on Linux is a much more ordinary divergence:
t= 0.0000 Dt= 0.5575E-12 NIT= 25MbErr%= 0.6353 : Run diverged/stalled :-(
Error from time_step.f:198
DT < DT_MIN. Recovery not possible!
So it is not possible to run this model in windows? I’ve tried many ways to help the model converge but none of them work, can you help me?
I’m not saying it’s impossible to run on Windows, just that it is typically harder to debug this kind of solver crash. I usually use Linux to debug solver crashes, but on Linux this does not trigger a crash, just a normal convergence failure. I suspect that the crash is an unfortunate symptom of the convergence failure - I’d like to track it down but this may not be possible. But if we solve the convergence failure, perhaps the crash will go away.
So the next question is - why does the model not converge? Typical reasons: reaction rates too high or poor mesh quality. What happens if you turn the reactions off?
When I turn off the chemical reaction, I still have the same problem as in the previous picture.