After reviewing the compiler flags and validator code, we have determined that compliance with IEEE-754 should not be expected, which was probably a deliberate choice for the sake of performance. It is common in HPC to lean towards performance if possible. Most notably, the use of -fp-model precise as opposed to -fp-model strict and optimization level 3 with -O3 suggest there would be variance in floating point arithmetic between different architectures in the production build of ARP1.

The validation logic for the ARP1 validators includes a comparison of the md5sum of the result.out files produced by the ARP1 workunits being compared, and we would therefore certainly expect that differences could cause these invalids. It is also possible that this stricter check acts as a heuristic to keep the accumulation of rounding error low, so that subsequent generations and the final dataset are within tighter tolerances to the potential floating point error - but this is just speculation as we did not write the code.

Thank you Savas.

My understanding is that the rounding algorithms vary slightly between AMD and Intel chips. This is why CPDN use a statistical analysis to decide which results to include in the scientific research rather than having more than one computer complete the task and looking for exact matches.

To test another variable on the same machine I ran some tasks both using WINE and using Windows in a VM. Both operating systems produced identical results. Currently CPDN tasks are all single OS,i.e. windows, Linux or MacOS so it is not possible to do comparison on whether the executables for the different operating system make a difference.

I would suggest the invalid results are most likely to be related to the rounding differences However as noted above WCG doesn't let you see your wingmen's computers to check this. I will try and find on the CPDN boards what Glenn wrote about the code used for the ARP tasks as he knows something about it.