How can I fix a segmentation fault in vasp.5.2 when using mpirun?

[Douasing]

Dear all,
There is a “error report” when I use “mpirun” to run vasp.5.2 (a kind of DFT software) as follows:
"mpirun noticed that process rank 2 with PID 16380 on node wangtc exited on signal 11 (Segmentation fault)."

I can't solve it all the time,can anyone help me ?

Thanks in advance!

 

[jedishrfu]

A lot of things can cause a segmentation fault:

http://web.mit.edu/10.001/Web/Tips/tips_on_segmentation.html

see if any of these apply to your code.

For VASP 5 someone posted a similar query here:

http://cms.mpi.univie.ac.at/vasp-forum/forum_viewtopic.php?3.52

and the admin suggested running the application with different flags.

 

[Douasing]

Thanks for your supplied information.I have ever seen the other web address(i.e.,segmentation fault after 5 iterations) in vasp support site. But, my INCAR is very simple,just a single atom system. Even though,when I change ENCUT=240 to ENCUT=300,the vasp.5.2 can't work.

I asked some people for some suggestions,some said that the Makefile should be added "-heap -arrays 64" to "FFLAGS",

such that FFLAGS = -FR -lowercase -assume byterecl -heap -arrays 64

But when I ran vasp.5.2 again, it still can't work.

Others said that maybe there was something wrong with FFT-function library,but they didn't give a specific solution.

The FFT-function library is displayed in appendix,if necessary,I can update the Makefile here.

Appendix:

#-----------------------------------------------------------------------
# fft libraries:
# VASP.5.2 can use fftw.3.1.X (http://www.fftw.org)
# since this version is faster on P4 machines, we recommend to use it
#-----------------------------------------------------------------------

FFT3D = fft3dfurth.o fft3dlib.o

# alternatively: fftw.3.1.X is slighly faster and should be used if available
#FFT3D = fftw3d.o fft3dlib.o /opt/libs/fftw-3.1.2/lib/libfftw3.a

 

[schrodingerscat11]

I got segmentation fault error when I was trying to run a relatively large system in a 4-core CPU. When I used a CPU with higher memory, the error disappeared. Maybe that could also be a problem?

 

[JorisL]

I got segmentation fault error when I was trying to run a relatively large system in a 4-core CPU. When I used a CPU with higher memory, the error disappeared. Maybe that could also be a problem?

This either meant your RAM was full but with current computers this should rarely if ever happen.

If the program is used on a cluster as 'mpirun' suggests I doubt this example is applicable here.
Douasing, can you request more processors/nodes and/or RAM when submitting your job?
Is there a way you can track how much memory is used?

In general this indicates a bug in the program, any way you can dive into the code and fix/track it?

 

[Douasing]

This either meant your RAM was full but with current computers this should rarely if ever happen.

If the program is used on a cluster as 'mpirun' suggests I doubt this example is applicable here.
Douasing, can you request more processors/nodes and/or RAM when submitting your job?
Is there a way you can track how much memory is used?

In general this indicates a bug in the program, any way you can dive into the code and fix/track it?

In fact,that would solve the problem only if the "ulimit -s unlimited" is used.

And "how much memory is used" is closely related to the stack size.

 

[jim mcnamara]

You are getting stack overflow - for example, large arrays declared on the stack use up most of the stack quota. When the program executes, and generates stack frames you run out of stack space. You have to use heap (static in C) memory instead, then this will not happen. You seem to be in a higher level language environment, so I have no clue what the simple answer is for you. In FORTRAN heap memory objects are created with ALLOCATE, in C , C++ with the 'static' object declaration qualifier. <--- if that helps you at all.

 

[thankz]

time to get comfy with core dumps and gdb

 

[Mark44]

You are getting stack overflow - for example, large arrays declared on the stack use up most of the stack quota. When the program executes, and generates stack frames you run out of stack space. You have to use heap (static in C) memory instead, then this will not happen. You seem to be in a higher level language environment, so I have no clue what the simple answer is for you. In FORTRAN heap memory objects are created with ALLOCATE, in C , C++ with the 'static' object declaration qualifier. <--- if that helps you at all.

The usual way to allocate storage on the heap in C is to use one of the standard library allocation functions, such as malloc(). After the heap storage is no longer needed, it can be freed by using the free() function.

In C++ the usual way to allocate storage on the heap is by using the new operator to allocate memory, and the delete operator to free it.

I'm not certain that static gives you heap memory for objects declared using this specifier. The documentation I looked at didn't mention that the storage was allocated from the heap. It might be that it uses the heap, but I was not able to verify this in my quick search.