Previous Thread
Next Thread
Print Thread
Page 1 of 2 1 2
Joined: Feb 2009
Posts: 83
B
blubbi Offline OP
Forum Member
OP Offline
Forum Member
B
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:

Code:
 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
      ******************************************


68120 Atoms in the PSF looks very equal to 68120 Atoms in the "file". And yes, there are exactly 68120 Atoms in my setup. crazy

It does not make any difference if I read "memb30.coor" or "memb30.restart.coor".

Any suggestions?

Here's my test script:
Code:
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,605
Likes: 23
rmv Offline
Forum Member
Offline
Forum Member
Joined: Sep 2003
Posts: 8,605
Likes: 23
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
B
blubbi Offline OP
Forum Member
OP Offline
Forum Member
B
Joined: Feb 2009
Posts: 83
Originally Posted By: rmv
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.

Originally Posted By: rmv

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"
Originally Posted By: 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,605
Likes: 23
rmv Offline
Forum Member
Offline
Forum Member
Joined: Sep 2003
Posts: 8,605
Likes: 23
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
B
blubbi Offline OP
Forum Member
OP Offline
Forum Member
B
Joined: Feb 2009
Posts: 83
Mmmh, I took a look in the src code and was wondering what is going wrong with the comparison:

Code:
  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.
Quote:
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,605
Likes: 23
rmv Offline
Forum Member
Offline
Forum Member
Joined: Sep 2003
Posts: 8,605
Likes: 23
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
Offline
Forum Member
Joined: Dec 2005
Posts: 1,535
In Metcalf, Reid & Cohen:
Quote:
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 :
Code:
#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:
Code:
       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
Offline
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,605
Likes: 23
rmv Offline
Forum Member
Offline
Forum Member
Joined: Sep 2003
Posts: 8,605
Likes: 23
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
B
blubbi Offline OP
Forum Member
OP Offline
Forum Member
B
Joined: Feb 2009
Posts: 83
Originally Posted By: rmv
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)
Code:
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.
Page 1 of 2 1 2

Moderated by  lennart, rmv 

Link Copied to Clipboard
Powered by UBB.threads™ PHP Forum Software 7.7.5
(Release build 20201027)
Responsive Width:

PHP: 7.3.31-1~deb10u1 Page Time: 0.009s Queries: 35 (0.005s) Memory: 0.7859 MB (Peak: 0.8823 MB) Data Comp: Off Server Time: 2022-09-27 02:39:39 UTC
Valid HTML 5 and Valid CSS