|
|
Joined: Feb 2009
Posts: 83
Forum Member
|
OP
Forum Member
Joined: Feb 2009
Posts: 83 |
Hi again. I know handling NAMD stuff is not one of the top priorities of CHARMM, but since the io.doc suggests that it should work, I dare to ask. While I tried to read a binary coordinate file from NAMD (with the original PSF/EXPLOR.PSF created with CHARMM) I get the following weird error: CHARMM> read NAMD FILE "../../run400/memb30.restart.coor"
Reading as namd binary file"../../run400/memb30.restart.coor"
opening file ../../run400/memb30.restart.coor
number of atoms does not match; in psf 68120, in file 68120 ; exiting...
***** LEVEL -5 WARNING FROM <MAINIO> *****
***** Error reading binary file
****************************************** Atoms in the PSF looks very equal to 68120 Atoms in the "file". And yes, there are exactly 68120 Atoms in my setup.  It does not make any difference if I read "memb30.coor" or "memb30.restart.coor". Any suggestions? Here's my test script: open read card unit 10 name ../../top_all27_prot_lipid.rtf
read rtf card unit 10
open read card unit 20 name ../../par_all27_prot_lipid.prm
read para card unit 20
stream ../../toppar_all27_lipid_cholesterol.str
open read card unit 10 name ../../step5_assembly.psf
read psf unit 10 card
!read NAMD FILE "../../run400/memb30.coor"
read NAMD FILE "../../run400/memb30.restart.coor"
coor stat
!energy
stop
Cheers Bjoern
|
|
|
|
|
Joined: Sep 2003
Posts: 8,650 Likes: 26
Forum Member
|
|
Forum Member
Joined: Sep 2003
Posts: 8,650 Likes: 26 |
CHARMM can read NAMD DCD files as CHARMM binary coordinate trajectories, given that the original PSF was made with CHARMM and then exported to NAMD. Individual coordinate sets are addressable and can be read singly.
Rick Venable
computational chemist
|
|
|
|
|
Joined: Feb 2009
Posts: 83
Forum Member
|
|
OP
Forum Member
Joined: Feb 2009
Posts: 83 |
CHARMM can read NAMD DCD files as CHARMM binary coordinate trajectories, given that the original PSF was made with CHARMM and then exported to NAMD. I know. I am using CHARMM to evaluate my NAMD DCD files.
Individual coordinate sets are addressable and can be read singly.
I am afraid I don't understand what you want to tell me here: To read the last coordinate set of a NAMD DCD files instead of using the coor file? What I was referring to was the following from "io.doc"
[...]
In addition, NAMD program
binary restart coordinates (and velocities) files can be read (only into main set)
[...]
(example:
read namd file "myfile.coor.rst")
[...]
And this does not work with the previously posted error.
Last edited by blubbi; 08/03/10 09:49 AM.
|
|
|
|
|
Joined: Sep 2003
Posts: 8,650 Likes: 26
Forum Member
|
|
Forum Member
Joined: Sep 2003
Posts: 8,650 Likes: 26 |
READ NAMD appears to be broken, in addition to being minimally documented. I am suggesting using NAMD DCD files for both trajectory analysis, and to read any single coordinate set, such as the last one.
Rick Venable
computational chemist
|
|
|
|
|
Joined: Feb 2009
Posts: 83
Forum Member
|
|
OP
Forum Member
Joined: Feb 2009
Posts: 83 |
Mmmh, I took a look in the src code and was wondering what is going wrong with the comparison: if (n != (*ptr_natom)) {
printf("number of atoms does not match; in psf %d, in file %d ; exiting...\n", n, *ptr_natom);
free(filename);
*ptr_ier = -1;
return;
}Since the error message suggest that "n" and "ptr_natoms" contains the same amount of Atoms and both variables were declared as INT. number of atoms does not match; in psf 68120, in file 68120 ; exiting...
I'll play a bit with this function, lets see what I can figure out, if anything at all. Cheers Bjoern
Last edited by blubbi; 08/09/10 04:04 PM.
|
|
|
|
|
Joined: Sep 2003
Posts: 8,650 Likes: 26
Forum Member
|
|
Forum Member
Joined: Sep 2003
Posts: 8,650 Likes: 26 |
I suggest a new post in the "Bug Reports & Fixes" for any followups ...
Rick Venable
computational chemist
|
|
|
|
|
Joined: Dec 2005
Posts: 1,535
Forum Member
|
|
Forum Member
Joined: Dec 2005
Posts: 1,535 |
In Metcalf, Reid & Cohen: The range of the default integers [in Fortran] is not specified in the language, but in a computer with a word size of n bits, it is often from -2n-1 to +2n-1-1". (Emphasis on "often" added.) In machdep/cstuff.c :
#ifdef i8
#define INT long
#else
#define INT int
#endif
This is a bit a risky thing to do. What is probably happening is that the INT data type defined above is larger than the Fortran INTEGER data type on your particular architecture using your particular fortran compiler. When C dereferences ptr_natom for the purpose of comparing with n, it overflows the Fortran integer and reads some garabage bits (or bits that belong to a different variable). However, the subsequent printf statement is not affected because printf doesn't read all the bits. Indeed, "man 3 printf" says:
l (ell) A following integer conversion corresponds to a long int or unsigned long int argument, or a following n conversion corresponds to a
pointer to a long int argument, or a following c conversion corresponds to a wint_t argument, or a following s conversion corresponds to a
pointer to wchar_t argument.
ll (ell-ell). A following integer conversion corresponds to a long long int or unsigned long long int argument, or a following n conversion
corresponds to a pointer to a long long int argument.
|
|
|
|
|
Joined: May 2009
Posts: 125
Forum Member
|
|
Forum Member
Joined: May 2009
Posts: 125 |
In c36a4's emap I used the F2003 iso_c_binding, e.g. integer(c_int32_t) in Fortran and int32_t in C, to nail that stuff down. Maybe the NAMD I/O needs that too?
|
|
|
|
|
Joined: Sep 2003
Posts: 8,650 Likes: 26
Forum Member
|
|
Forum Member
Joined: Sep 2003
Posts: 8,650 Likes: 26 |
There's been an issue with C compiler options; for beta releases (c35b4 or prior) make sure '-Di8' is included as an option in the CC definition of the appropriate makefile.
Rick Venable
computational chemist
|
|
|
|
|
Joined: Feb 2009
Posts: 83
Forum Member
|
|
OP
Forum Member
Joined: Feb 2009
Posts: 83 |
There's been an issue with C compiler options; for beta releases (c35b4 or prior) make sure '-Di8' is included as an option in the CC definition of the appropriate makefile. No, thats not the case: (I only added -Wall -pedantic for testing purpose) gcc -O -Dgnu -DLINUX -Di8 -Wall -pedantic -c /home/blub/.soft/usr/local/charmm/c34b2/source/machdep/cstuff.c Could we lock this thread here? Since I opened a new thread in the bug section: http://www.charmm.org/ubbthreads-7-5-5/ubbthreads.php?ubb=showflat&Number=25101
Last edited by blubbi; 08/17/10 11:57 AM.
|
|
|
|
|
