[CPMD-list] Upon compilation of cpmd2cube...

[Axel Kohlmeyer]

On Thu, 27 May 2004 kohsj at ihpc.a-star.edu.sg wrote:

AK> Hi,
AK> 
AK> The attached Makefile was used for compilation of the cpmd2cube code.  
AK> The value for bmaxdata was changed accordingly, and compilation was
AK> successful.
AK> 
AK> But upon calling the executable file "./cpmd2cube -rho DENSITY", the following error message appeared:
AK> 
AK> 
AK> > cpmd2cube.x -rho DENSITY                                                      
AK> exec(): 0509-036 Cannot load program cpmd2cube.x because of the following errors
AK> :                                                                               
AK>         0509-026 System error: There is not enough memory available now.        

(sigh) this is a becoming a neverending story. 

ok, please try turning off all 'special' linker options,
i.e. remove '-qmaxmem=32768' from FFLAGS and
'-bmaxdata:3276800000 -bmaxstack:1500000000' from LFLAGS.
does this work?

AK> 

AK> Another observation that I'd like to make is that, in an attempt to
AK> delete the "cpmd2cube-v.0.1.1" folder, there's always this file
AK> ".nfsXXXXX" which is not deletable.  The reason for this
AK> "non-deletability" is that the suffixes "XXXXX" keeps changing in
AK> value upon deletion attempts.
AK> 
AK> My IT man suggested that it could probably be:
AK> 
AK> 
AK> "Since you are the one who create the folder, you shall have the right to
AK> remove anything in the folder. However, you claim that you delete the
AK> file and it come back again. This is mostly likely due to your program.
AK> You may have write a program and this program may need to write
AK> something in this folder everytime it is running and therefore the file
AK> come back after you delete it. I just make a guess and I do not have any
AK> evidence to support my point. Hope that clear your doubt."

well, this is close to the explanation. the reason for the .nfsXXXXX files
is 'feature' of NFS in order to emulate posix style file access semantics.
to explain: if you delete a file on a posix/unix machine, the file is
initially only removed from the directory listing but not deleted if there
is still a process, that has an open file descriptor pointing to that
file. only if the last process accessing the file has ended, that file is
really deleted. this is btw a very convenient way of creating 'invisible'
scratch files, that get automatically deleted, when the process terminates
or dies (you open(2)/fopen(3) a file with a unique name for writing and 
immediately unlink(2) it). back to the .nfsXXXX file: the NFS filesystem,
however is basically 'stateless', i.e. the connection to the NFS server 
can be interrupted any time and later reconnected (in some cases it can 
even survive an intermediate reboot with replacing the hardware and 
resizing the filesystem). so to implement the 'file-stays-even-if-deleted'
semantics, the nfs server daemon acts as a proxy for the processes 
accessing the file, but to make this work even in case of a reboot, the
.nfsXXXX files are created. the XXXXX is an hash, that allows the server
to detect the process needing to access the 'file with no name'.
most frequently this happens if you open a file in an editor, that
keeps an open file descriptor to the file it opens (or to the 
associated backup/undo file).



axel.

AK> 
AK> 
AK> Is there anything worthy of concern in the "Makefile"?  Seeking your kind advice :).  Thank you very much.
AK> 
AK> 
AK> Adrian.
AK> 
AK> P.S.     The machine I use is:  IBM p690 AIX 5L v5.1
AK> 

-- 


=======================================================================
Dr. Axel Kohlmeyer                        e-mail: axel.kohlmeyer at rub.de
Lehrstuhl fuer Theoretische Chemie          Phone: ++49 (0)234/32-26673
Ruhr-Universitaet Bochum - NC 03/53         Fax:   ++49 (0)234/32-14045
D-44780 Bochum  http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/
=======================================================================