I think we're getting somewhere...

when I look at the *.tpr file, under the line

nosehoover_xi:                  0

I have the x[ 0] etc. lines, but they are as you described single precision should look like (the last two digits are all zeros). This is despite the fact that at the top it says

Reading file topol.tpr, VERSION 3.3.3 (double precision)

So, when I tried to run the files you sent me (I used the exact commands you wrote) I got infinite forces as I usually do.

(Interestingly, for a small molecule (Dichloromethane) I did not get segfaults, but also couldn't minimize below a maximal force of about 1e-3 kJ / mole nm .)

What does this mean?




Thanks

Inon.


Quoting "Ran Friedman" <[EMAIL PROTECTED]>:

Inon Sharony wrote:
Hi Ran.
I looked up your suggestions, and got the following:

0. The parameters in the *.tpr file appear in " 0.00000000e+00 "
format. How can I tell if this is a float or double? Also, I could
not
see if the position coordinates of the molecule appear in the
*.tpr
file (and if so, if they are in double-precision). Where do the
coordinates appear? (in the *.gro file only?)
When you run gmxdump it should right e.g.:
Reading file em.tpr, VERSION 3.3.3 (double precision)

As for the coordinates, you have e.g.:
      x[    0]={ 1.35920e+01,  1.80590e+01,  1.79780e+01}
      x[    1]={ 1.31410e+01,  1.77710e+01,  1.75260e+01}
      x[    2]={ 1.30070e+01,  1.78390e+01,  1.68430e+01}

This is double precision. In single precision you'd get only 3
digits,
and the rest will be zeroes.

1. I do not get any step*.pdb files after the mdrun. In fact, I
skip
the *.pdb file altogether (using PRODRG). Could this be a problem?
It doesn't matter if you use pdb or gro. step*.pdb files are
sometimes
given in the output when the system explodes.

It can be that the parameters from PRODRG are not exactly what you
want
- you should compare with the force field paramters and charges,
though
I'm not sure this can be the source of this behaviour.

2. The simulation is done in vacuo.

3. I examined the input *.gro file (as well as the
single-precision
mdruns) using ngmx, and it looks great for those runs that work
(i.e.,
single precision).


I will now try repeating the whole minimization-NormalMode process
for
a simple diatomic, to see if I have any problems. Could you send a
working set of files for me to compare with? Assuming you've run
Normal Mode analyses in the past...
I'm not sure a diatomic system is good for this - not enough
degrees on
freedom.
I'll send you an example made with GMX 3.2.1 - I'm not doing NMA
too
often, but it should work.


Thanks very much again,

Inon.


Quoting "Ran Friedman" <[EMAIL PROTECTED]>:

Inon Sharony wrote:

 Hi Ran, thanks for the reply

I ran "make tests" after compiling with double precision, and it
came
out fine.

Could it be that this, second, compilation might have caused
some
problems -- I had GROMACS compiled in single-precision, and it
worked
fine -- could compiling in double-precision after the initial
single-precision overrun some files? I'm not sure anymore...

Also, the grompp in double-precision works fine (no warnings,
etc.)
but I get the segfault from mdrun (also in double-precision).
Sometimes this happens in the first minimization step, and
sometimes
in the second. I was told that this might hint that the input
file/s
(e.g. the *.gro file) were input in single- and not
double-precision.
However, since the files have coordinates written in nanometers
to
four significant digits, I can't see how the input numbers could
be in
single or double precision. It was suggested that I insert a
"print to
screen" line in the source code immediately after the *.gro file
is
read, to see if the printed data is in single-precision or
double-precision format. What do you think?

The tpr should contain the data in double precision. You can
check
this
with gmxdump.

Other things that you may want to consider:

1. Do you get step*.pdb files after running mdrun? This may point
out to
something wrong in the input.
2. Are you using a solvated system? Normally NMA is done in
vacuo,
maybe
with some scaling of the dielectric.
3. Did you examine the system that you use in the input? Does it
make
sense to you?

Ran.
_______________________________________________
gmx-users mailing list    gmx-users@gromacs.org
http://www.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before
posting!
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to [EMAIL PROTECTED]
Can't post? Read http://www.gromacs.org/mailing_lists/users.php


--Inon   Sharony
×™× ×•×Ÿ     שרו×
י
+972(3)6407634
atto.TAU.ac.IL/~inonshar
Please consider your environmental responsibility before printing
this e-mail.

_______________________________________________
gmx-users mailing list    gmx-users@gromacs.org
http://www.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before
posting!
Please don't post (un)subscribe requests to the list. Use thewww
interface or send it to [EMAIL PROTECTED]
Can't post? Read http://www.gromacs.org/mailing_lists/users.php


_______________________________________________
gmx-users mailing list    gmx-users@gromacs.org
http://www.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before
posting!
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to [EMAIL PROTECTED]
Can't post? Read http://www.gromacs.org/mailing_lists/users.php


--
Inon   Sharony
ינון     שרוני
+972(3)6407634
atto.TAU.ac.IL/~inonshar
Please consider your environmental responsibility before printing
this e-mail.

_______________________________________________
gmx-users mailing list    gmx-users@gromacs.org
http://www.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to [EMAIL PROTECTED]
Can't post? Read http://www.gromacs.org/mailing_lists/users.php

Reply via email to