McStasMcXtrace / McCode

The home of the McStas (neutrons) and McXtrace (x-rays) Monte-Carlo ray-tracing instrument simulation codes.
https://github.com/McStasMcXtrace/McCode/wiki
GNU General Public License v3.0
78 stars 54 forks source link

Issues with MPI on Win7 x64 #407

Closed haodengfrm2 closed 7 years ago

haodengfrm2 commented 7 years ago

For parallel computing with my own multicore desktop, I installed MPICH2 (mpich2-1.4.1p1-win-x86-64), perl (strawberry-perl-5.18.4.1-64bit), and replaced Mcstas.exe with 64-bit cold generator (http://download.mcstas.org/mcstas-2.3/windows/64-bit_code_generator/). All of these were done with a Administrator. After all of these, I can run parallel computing with Mcstas 2.3 for windows. However, when I start a parameter scan, the computing drop from parallel to serial.

What's more, when I plot figures with PgPlot, I can only plot one result in only one window. It's not possible to show different simulation results in different windows simultaneously.

Computer: Dell Precision Tower 3620, CPU Xeon E3-1240, RAM 16GB,

willend commented 7 years ago

How are you running the parameter scan? From within mcgui or from the commandline using mcrun?And if you are using mcgui, what exact mcrun command is issued in the terminal?

My feeling is that there could be a problem on windows in some aspects of the communication between mcgui and mcrun, including the transfer of mpi parameters.

Does your simulation run properly if executed on the mcstas-2.3-environment terminal with something like:

mcrun -c --mpi=4 BNL_H8.instr lambda=2.36,2.37 -N3 

?

For the plotting, this may very well be - in which case it is a limitation of PGPLOT on windows. A workaround could be (also on the terminal) to issue

mcplot simfolder/mccode.sim -psc

(or -png or -gif ... use mcplot --help for the full list)

Both of the above problems will be implicitly addressed with the next release of McStas where we are moving to a modernised set of Python tools.

Let me know how things work out with the above workarounds.

Peter

haodengfrm2 commented 7 years ago

Hi Peter,

I'm running parameter scan within mcgui.

When I start the scan, in terminal it shows as follows,

mcrun1

and stuck. After I press close window button, it shows like this:

mcrun2

I just tried mcrun in terminal, but the same problem as shown up there.

Thank you for your kindly reply and best regards!

Hao

willend commented 7 years ago

Hi again Hao,

Just to make sure - what output do you get if you start the mcstas-shell-2.3, cd to your simulation folder and directly run the below command?

Heidi-slit.exe  --help

(My main point is knowing if the executable reports "This instrument has been compiled with MPI support." or not...)

Also, how are you sure that the parallelisation works in the non-scan setting? My test would here be to try running (also in the mcstas-shell-2.3)

mpirun -np2 Heidi-slits.exe 

Best, Peter

haodengfrm2 commented 7 years ago

Hi Peter,

it seems to be the problem of perl. Because when I change to another version (strawberry-perl-5.24.1.1-64bit), I cann't even run Mcstas.

I'm sure the parallelisation works in the non-scan setting, because of these: qq 20170221114230 qq 20170221114243

I can see it's using a lot of CPU sources. When running scan, only 12% of CPU were used.

I'm sorry I'm not familiar with mcrun model. After several times of uninstalling and installing Mcstas and Perl, I cann't reproduce in terminal any more.

Best regards!

Hao

haodengfrm2 commented 7 years ago

Hi Peter,

What's more, I recently installed a Ubuntu x64 system and found something interesting. The same parallel simulation that takes 6 hours in Linux system, would take only 3.3 hours in Windows system.

I don't know the difference in detail, but if there is no bug, it means I can save half time by just using Windows. Is that true?

Best, Hao

willend commented 7 years ago

Dear @haodengfrm2,

I assume the hardware is identical in the two cases? What about the version of the c-compiler used, this can have a great impact on the performance. And of course compiler optimisation (e.g. -O2) in the CFLAGS should be activated, may cause longer compilation time, but should shorten runtime.

In the past I had exactly the opposite experience, running on Windows would be half the speed of running under Linux with the same hardware... I also found that the generally most optimal c-compiler to use was Intel C, which easily gave a factor of 2 in performance over the same instrument, same OS, same hardware but gcc...

Best,

Peter

haodengfrm2 commented 7 years ago

Dear Peter,

Aha, it's a trick. Your response remind me that you already mentioned this case in the Manual. I will try icc in Linux, maybe then I will get same or even better performance than in Windows. In that case, I can run parallel parameter scan in Linux instead of windows.

Thanks for your kindly reply and best regards,

Hao

haodengfrm2 commented 7 years ago

What's more, you are right, I have been using icc in Windows. I installed MPICH2 in Windows, so my MPI Compiler is mpicc.bat. I think that's why it have better performance.

willend commented 7 years ago

I belive this can be closed @haodengfrm2 ?