-
Notifications
You must be signed in to change notification settings - Fork 3
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
comparing two output files #20
Comments
Here is a possible strategy. Please let me know what do you think. Assume that I take the output geometry of one run and use it as initial guess for the other run, and the code considers that the system is in equilibrium and force imbalance still f~1e-15.
A possible way of quantifying this without additional runs is to use the following fact: the force, f, is essentially proportional to [[B^2]], and B^2 is roughly proportional to the metric g, which is roughly proportional to R^2. Thus
where Dabs=dR and Drel~dR/R. This means that if we find that Dabs^2 / Drel < 1e-15 then the difference in geometry, dR, is irrelevant since it preserves force-balance. For the example I examined, that gives
which anticipates that both equilibria are "the same equilibrium". Let me know if that makes sense to you. |
Whatever makes sense to you is fine by me. |
I agree that this is an interesting test. However, it should not matter how high is the numerical accuracy in the input: if an input (say, with low accuracy) is run with two executables that presumably perform the same calculation, then no matter the accuracy, if the input is the same, the output should be the same, up to machine precision. Of course, if one changes the input (say, higher accuracy) then one expects a different output, even for the same exact executable. However, it could be that there are differences arising because of how the compilation has been done. Below the result of some tests that confirm these thoughts. I have been briefly investigating differences in the output when running: Conclusions |
This short study shows me that the differences between running the two branches master and ma00aa are as small as when comparing runs from the same branch compiled in different environments. Thus, we can consider that the branch ma00aa produces "the same" results as master (although faster). I will merge the ma00aa branch into the master branch. Also, I will upload the matlab routine for comparing output files, so that we can use it each time before merging branches. This will give us confidence and avoid (some) hidden bugs. |
Thanks for this study. It is enlightening, and I can see why many still consider numerics to be the "dark magic" of science! |
When we make changes to the code, sometimes we expect that the code should reproduce the same result for a given input file, e.g. if we are simply working on code-cleaning, or speeding up. However, bugs can non-intentionally be inserted while making these changes.
For this reason, it is good to have some automatic checking-procedure against a "control case". I wrote a simple matlab routine (which should be uploaded some time soon) that compares 2 output files from SPEC, "fname1.sp.h5" and "fname2.sp.h5", and calculates the maximum difference in the geometrical coefficients of all interfaces. One can calculate the absolute maximum difference, Dabs, and the relative maximum difference, Drel.
If the geometry was exaclty the same we would have Dabs=Drel=0. Also, if Dabs~1e-16, then we should still consider them "the same" because of machine precision. However, when I tried to apply this to the l2stell testcase, run with (1) the master branch, and (2) the ma00aa branch, I get
which could be due to the fact that depending on the compiler, the algorithm loop order, etc., the accumulated errors can be different for two versions of the code that "presumably do the same".
So the question is "how to decide whether two outputs are to be considered the same"?
The text was updated successfully, but these errors were encountered: