It may well depend on your MATLAB version as well, since low level implementation can change.

More generally, parallelization has an effect on round-off errors as the operation sequence is not controlled at very low level.

For example, depending on your implementation you may have 10^-8 relative difference for a pinv command. If you perform numerical integration these round-off errors might get significant over large spans if your simulation is sensitive.

Your computation is therefore not reproductible if you compare your numerical full-digits. My bet would be that if you simulate once more on your supercomputer, you will get yet 'another result' strictly speaking.

We all know that not all the digits are meaningfull anyway, at least due to convergence matters, so you may want to quantify your results discrepancy with some tolerance.

Hello Abdullah,

As you are probably aware, since you are not using MatlabMPI or similar methods, your use of a supercomputer could only be

benefited from higher memory-per-node; high number of cores would not make a difference.

How do they compare? If memory and clock speed (single core) both are same, then they ideally should take same time.

Without jumping to conclusions, I would check whether on the supercomputer completed the job properly. Not so long ago, I stuck in a (somewhat) similar problem where job was killed by LSF scheduler as it reached permitted wall-time.

If you program is killed before it could conclude the computation/analysis, it is possible that, you are looking at a partial result, not complete result.

As for your results, how different they are? You mentioned, "significant difference". Is it significant for your experiment or is it significant from computational perspective?

Even considering various data types you may be using, results should not be extremely out of proportion.

Best Regards

Thanks for your thoughts. The computational time is not important right now but I want to know about the differences in result.

Sorry, I couldn't understand LSF scheduler and program killing, do you mean program stopping or halting before completing? if this is the case no the programs completed 100 iterations in both cases.

The differences are significant in computational perspectives.

I am assuming you are using an UNIX system. Most (if not all) high-performance-computing facility makes use of a "Load Sharing Facility". This is to ensure safe and smooth running of the facility.  If not "Platform LSF", some form of the mechanism is used. 

In short, what happens is, the system architect/administrator assigns a limit on how many core you can use per job (i.e. per run from start to finish), how long can you run the job, how much memory you can use etc.

In one of the clusters I am using, the soft limit is maximum 90 processors for a maximum period of 7days. Now, if my process is going to take longer than 7 days, and I did not apply any bypass methods (usually admins do that), then a system controller will terminate the job, irrespective to whether the job (run/computation/simulation etc) is done. Something like, switching off the service.

Now, say, to run full job it would take 10 days, but, my job is killed (or terminated) at 7 days, then, depending on my programme, it may store results from 7days only. Clearly, this result would be different from 10 days' result.

Before jumping into any conclusion, I would recommend you to check your log files for the process. 

By the way, are you using ScREC system?

https://oit.ncsu.edu/hpc/faq-load-sharing-facility

Scheduling systems aside, you should start with the simple things.

Is your code fully deterministic? Even very trivial things, like parallelization causing the terms of a sum to be added in a different order, can be enough to change results - especially so if the underlying method is unstable. Did you completely disable threading, or do you by "not using parallel computing" just refer to not explicitly employing parallelism? If you just give it the cores, Matlab will scale beyond a single core for a serial script containing larger matrix operations.

Are you running the same operating system on the machines? More importantly, are you using the same version of Matlab, including any toolboxes or external libraries that you are referencing. The Mathworks have been changing the default behavior of several old mainstay functions quite aggressively over the last few years. The new defaults and algorithms are frequently more sensible. Sitll, that means that the same code with the same data can give different results on different machines.

Thank you again Mehedi Hassan, as I will ask the questions you mentioned to computer administrator.

Mr. Nettelblad, thank you for your answer as well. I think the reasons you mentioned are the cause of the different results so might be due to different system architecture and operating systems it is happening. On my PC I am using windows 7 and MATLAB version is R2013b while on the super computer the operating system is Ubuntu 10.10 and MATLAB version is 2013a.

If you can recommend any research article related to this issue it will be great.

Regards,

Abdullah

Hello Abdullah

I have found that significant differences can occur in large scale (especially deeply nested loops) problems due mainly to internal machine floating point precision. You may find this useful:

Java/C++/Fortran cross-platform performance and

consistency issues for large simulation codes

(Proceedings of the 10th International Conference

on Computational and Mathematical Methods

in Science and Engineering, CMMSE 2010

27–30 June 2010 pp. 121-132)

There should not be a significant difference (if there is, it invalidates the method, because you have no way to know which of your results is correct). As noted by other posters, problems with parallization and floating point errors can cause trouble.

A couple of things to consider:

My humble opinion. Two options. A real mistake or the length of variables is different in the two machines. 

There is the option that random numbers are involved. Matlab always starts with the same random number, and if you run it twice you get the same result twice, which might mislead you into believing this is always the case. 

Try for a problem which solution known in exact form. 

Or may be you know which numerical solution is correct

Instead of running the whole code and wait for the final results, yo could introduce inner-loop tests in order to assure that the intermediate calculations are as expected.

This way, you can find out when the results start to be different and maybe extract some conclusions.

You should know the floating point representation for real numbers used by each computer. (http://en.wikipedia.org/wiki/IEEE_floating_point)

If your problem is ill conditioned (http://en.wikipedia.org/wiki/Condition_number) and if the real number representations are different, then it is possible to obtain different results.

I guess you should do some kind of benchmark like Mr. Galván said. Run a well-know benchmark problem and perform inner-loop tests. You should notice if there is something wrong.

If you are solving  a code that approximates a set of diff eqs as a set of algebraic equations over space for specified BCs or sequentially over time for specific I and BC's, it is likely that the solution will depend upon both the I and BCs and the precision with which those values are internally represented by the computer..As it ahs been pointed out by some, you need to ensure that your computations are solved with the same accuracy and floating point approximation first.  Slightly different values may lead to larger differences in the final results.  

If your screen your computations as noted above (perhaps using a benchmark case), and still see differences in the final results due to small differences in the I & BCs, you may actually be dealing with  bifurcations similar to those found in chaos; see Bifurcation diagram of the logistic map x → r x (1 – x) at(http://en.wikipedia.org/wiki/Chaos_theory).

Hope this helps,

Juan

I have experienced differences in the computed results of 32bit and 64bit build executables of the same FORTRAN code. Never was very significant though.

Supercomputers are built with the same components as PCs.

They use either Intel or AMD processors., and presumable the MatLab program was the same,  so how did you get results faster?

The answer is that the supercomputer probably has MATLAB compiled with a different compiler, probably with code optimizations enabled.  These cause minor differences in the computer arithmetic, which can cause major changes in your answers for some problems that are either chaotic, or not well-posed.

Of course, you could have a different version of MatLab on the two computers.

Can you verify that one or perhaps both answers are correct?

(I never believe computed results unless I can somehow physically verify them, or at least verify that they are in a correct range.)

It depends on the architecture of the hardware. In std pc, the hardware performances, for example of the GPU, are strongly dependent from the operating temperature, while in clusters normally the temperature is more stable. When the temperature of your pc increase, some error can arise and this minor errors can modify your result. Try again on the cluster... you should get the same result as before.

Franco

MatLab is an enormous mathematical resource just like other engineering software which are critical for our use these days such as Ansys, Fluent, etc.

These companies have protected their software so that in the case of supper computing you are forced to buy the software (or write your own code!). As a result, MatLab is able to identify parallel processing (& very complicated calculations) and it is able to cause error in the calculations.

So if this is the case there is no way you can avoid error in your results.

Error can be caused by the RAM. In normal PC you have the non error correcting RAM but in servers and Supercomputers it is error correcting RAMs which could influence the results

Hello, I agree that the numerical difference shall depend on the rapresentation and accurancy and errors of the two computer. Nevertheless the difference should be negligible. Could be that the algorithm is sensitive to calculation aproximation. It could be an idea to review the algorithm constrains? Just another point of view.

Thank you all for your valuable answers and comments.

The difference could be due to the parallel algorithm used. You can only compare the results when the number of CPU's are identical. On the same system, with the same number of processors used, the results should be identical up-to machine accuracy. Otherwise, this can be a symptom of poor parallel implementation. General parallel algorithms will not provide identical results when run on different number of processors. However, if the solution is properly converged, in theory, they should create results with same physics, and the differences should be within the accuracy of the numerical scheme and the parallel (non)linear solvers used.

It may well depend on your MATLAB version as well, since low level implementation can change.

More generally, parallelization has an effect on round-off errors as the operation sequence is not controlled at very low level.

For example, depending on your implementation you may have 10^-8 relative difference for a pinv command. If you perform numerical integration these round-off errors might get significant over large spans if your simulation is sensitive.

Your computation is therefore not reproductible if you compare your numerical full-digits. My bet would be that if you simulate once more on your supercomputer, you will get yet 'another result' strictly speaking.

We all know that not all the digits are meaningfull anyway, at least due to convergence matters, so you may want to quantify your results discrepancy with some tolerance.

I am using particle swarm optimization using Matlab 2017b on 2 computers (64bit each). Each one gives an answer. even if i got the answer of one of them and subtituted with it in my function file, i don't get the same function value.

i read the above answers, but what is the solution??