-
Notifications
You must be signed in to change notification settings - Fork 153
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Same input code but different result sometimes. #328
Comments
Hi, Mumax is not deterministic in that way, I'm almost sure it's because of CPU/GPU floating point precision mismatch. This leads to tiny variations of the starting magnetizations between runs which can lead to huge changes if you have an unstable system. A workaround is to save the starting magnetization and load it, the loaded magnetization will always lead to the same outcome of the similation. |
Hiii, Thanks for your explaination ! I will learn and try to save the initial magnetization and reload it. But I still confuse that the floating point precision mismatch may always lead the same mistake for the same input. This may not explain the different output in this system. I guass this behaviour may be caused by some randomness in the mumax? |
Hi, For questions about scripts, it's best to post them in the mumax group here (it is named after mumax2, but is still active for mumax3). That said: mumax is indeed deterministic up to single precision. So using the same input will always give the same output, unless your system is sensitive. There are a few psuedo-RNGs, but you can control the seeds using variables like randSeed, RandomMagSeed, and ThermSeed. In your case, these aren't affecting your simulation, just mentioning for completeness. Very occasionally, you will have problems that are sensitive to the precision. It's usually pretty rare, however. I think it usually happens when there is a symmetry that isn't broken. In those cases, it's like a marble on top of a hill- it's an unstable equilibrium, and the noise from single precision is enough to get it rolling one way or the other. You should probably save and compare the total energies to see which is the true ground state. Can you give some more details, like what version of mumax are you using, and how often you see the different results? And what the magnetization states look like? Guessing from just the average magnetizations, I would suspect the (0.35691237, -0.00039410926,1.0477379e-09) state is probably two layers are anti-parallel. So probably minimize can't decide if they should be anti-parallel or parallel, or something. Looking at your output, it seems like there are different initial states in the table even before run(). Probably minimize() is having trouble deciding which state is better (you're also not setting an initial magnetization, so you're starting from a high energy state. You would probably be better of starting with relax() first, or initializing something close to the expected state. There is a warning in the Examples page about this. You might still run into issues, relax still has sensitivity to numerical rounding but it might help). Also/alternatively, you can probably nudge it towards the proper ground state by applying a small static field component in the y-direction (keeping in mind that minimize/relax disable excitations, so the sinc you provide is disabled when relax/minimize are running). If either of those two things doesn't solve it, there are some other tricks like adding some noise you can do to try to nudge it towards the correct state. -Separately, you might want to fully simulate your system, instead of using PBC. But that I am less sure about. Also, you can look to issues like this one, which discuss similar things: Numerical rounding is a known issue, and it's further compounded since GPU tasks aren't always deterministic, either. As for mumax using both double/single precision: It's true that some of the CPU calculations are done in double precision (and then truncated), and the GPU are done in single. But I think this was an intentional design decision, and hard to avoid. Single precision is necessary to optimize mumax for performance on consumer-grade GPUs. Unfortunately decent double-precision performance is locked behind workstation tier cards (with a few discontinued exceptions). Best, |
@jplauzie Very thanks for your detailed explaination and suggestions. I set the a proper initial magnetization. And mumax gave the reasonable output. Again, thank you for your help !! |
I run my code above serval times. But I can get different output sometimes.
I am very confuse that why I can get different output when the input code is same.
It is a bug or I set some wrong parameters?
My source code is below.
The output of table.txt
I got two different output. The first one is:
I got different output after I re-run the same code.
I run my code above serval times. In most of time, the output would be the second output.
I just very confuse why I can get different output when the input code is same. It is a bug or I set some wrong parameters?
other information
I call mumax and analysis the data by python. The source code is:
My environment is:
Processor Intel(R) Xeon(R) W-2225 CPU @ 4.10GHz 4.10 GHz
Installed RAM 64.0 GB (63.6 GB usable)
System type 64-bit operating system, x64-based processor
GPU Quadro P2200(5119MB), CUDA Driver 12.2, cc=6.1, using cc=61 PTX
The text was updated successfully, but these errors were encountered: