[gmx-users] Units for VIRIAL
Tandia, Adama
TandiaA at Corning.com
Wed Feb 1 19:55:36 CET 2006
Dear ALL,
I would like to know the units of the virial
(Sum_{i<j} [F(r_ij) . r_ij])
calculated with g_energy.
Is it [kg][nm*nm]/[ps*ps]?
In advance, I thank you all for your prompt answer.
regards,
Adama
Adama Tandia
Modeling & Simulation
Corning INC
SP TD 01-01
Corning NY 14831 USA
Tel: 607 248 1036
Fax: 607 974 3405
www.corning.com
-----Original Message-----
From: gmx-users-bounces at gromacs.org
[mailto:gmx-users-bounces at gromacs.org] On Behalf Of
gmx-users-request at gromacs.org
Sent: Wednesday, February 01, 2006 1:40 PM
To: gmx-users at gromacs.org
Subject: gmx-users Digest, Vol 22, Issue 5
Send gmx-users mailing list submissions to
gmx-users at gromacs.org
To subscribe or unsubscribe via the World Wide Web, visit
http://www.gromacs.org/mailman/listinfo/gmx-users
or, via email, send a message with subject or body 'help' to
gmx-users-request at gromacs.org
You can reach the person managing the list at
gmx-users-owner at gromacs.org
When replying, please edit your Subject line so it is more specific than
"Re: Contents of gmx-users digest..."
Today's Topics:
1. Re: SGI installation problem: forcing the compilation with
gcc (Erik Lindahl)
2. Re: manual inconsistency (David Mobley)
3. Re: manual inconsistency (Mark Abraham)
4. RE: manual inconsistency (Berk Hess)
5. Re: MPI scaling (was RE: MPI tips) (David Mathog)
6. Re: MPI scaling (was RE: MPI tips) (David Mobley)
7. Re: SGI installation problem: forcing the compilation with
gcc (dastmalchi.s at tbzmed.ac.ir)
----------------------------------------------------------------------
Message: 1
Date: Wed, 1 Feb 2006 16:21:44 +0100
From: Erik Lindahl <lindahl at sbc.su.se>
Subject: Re: [gmx-users] SGI installation problem: forcing the
compilation with gcc
To: <dastmalchi.s at tbzmed.ac.ir> <dastmalchi.s at tbzmed.ac.ir>
Cc: gmx-users at gromacs.org
Message-ID: <CF9EB3F2-DC6E-43F0-8336-C013A1AEE497 at sbc.su.se>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
My bad - the include should have been
#include "fftgrid.h"
Cheers,
Erik
On Feb 1, 2006, at 10:54 PM, <dastmalchi.s at tbzmed.ac.ir>
<dastmalchi.s at tbzmed.ac.ir> wrote:
> Hi,
>
> Many thanks for the reply.
> I have tried both setting the CC to gcc and also adding the #include
> "shift_util.h" in the ghat.c file. In either case I am getting the
> same
> error message as I was getting before.
> I was wondering if there is any thing else that I can try.
> Many thanks for your kind attention.
>
> Cheers, Siavoush
>
>
>
>> Hi,
>>
>> You can always set the environment variable CC to the compiler you
>> want to use before running configure.
>>
>>
>> However, the error you're getting is really easy to fix - it just
>> happens because we changed a header file, and forgot to do
>>
>> #include "shift_util.h"
>>
>> in the header of ghat.c. Add that, and it should hopefully compile
>> fine with the IRIX compilers too.
>>
>> Cheers,
>>
>> Erik
>>
>> On Jan 31, 2006, at 6:10 AM, Dastmalchi wrote:
>>
>>> Hi there,
>>>
>>> Is there a configure flag to force the use of GCC?
>>> Do you think this may fix the problem that I have in
>>> installation of
>>> GROMACS on my sgi machine? As I posted my problem before I am
>>> getting the following error message:
>>>
>>> ....
>>> ghat.lo ghat.c
>>> cc -DHAVE_CONFIG_H -I. -I. -I../../src -I../../include "-DGMXLIBDIR=
>>> \"/usr/people/siavoush/programs/gromacs-3.3/share/top\"" -I/usr/
>>> local/include -r12000 -mips4 -O3 -OPT:IEEE_arithmetic=3
>>> -OPT:rsqrt=ON -SWP:loop_overhead -INLINE:=ON -LNO:opt=1 -
>>> LNO:ou_further=3 -OPT:Olimit=0:roundoff=3:alias=typed -woff 1174 -
>>> D__INLINE_INTRINSICS -c
>>> ghat.c -Wp,-MDupdate,.deps/ghat.TPlo -o ghat.o
>>> cc-1515 cc: ERROR File = ghat.c, Line = 233
>>> A value of type "int" cannot be assigned to an entity of type
>>> "real ***".
>>>
>>> gh = mk_rgrid(ix,iy,iz);
>>> ^
>>>
>>> 1 error detected in the compilation of "ghat.c".
>>> *** Error code 1 (bu21)
>>> *** Error code 1 (bu21)
>>> *** Error code 1 (bu21)
>>> *** Error code 1 (bu21)
>>>
>>> Best regards,
>>> Siavoush
>>> _______________________________________________
>>> gmx-users mailing list gmx-users at gromacs.org
>>> http://www.gromacs.org/mailman/listinfo/gmx-users
>>> Please don't post (un)subscribe requests to the list. Use the www
>>> interface or send it to gmx-users-request at gromacs.org. Can't post?
>>> Read http://www.gromacs.org/mailing_lists/users.php
>>
>> -----------------------------------------------------------
>> Erik Lindahl <lindahl at sbc.su.se> Backup address:
>> <erik.lindahl at gmail.com>
>> Assistant Professor, Computational Structural Biology Stockholm
>> Bioinformatics Center, Stockholm University, SE 106 91 Stockholm
>> Phone: +46 8 5537 8564 Fax: +46 8 5537 8214
>
>
-----------------------------------------------------------
Erik Lindahl <lindahl at sbc.su.se> Backup address:
<erik.lindahl at gmail.com>
Assistant Professor, Computational Structural Biology
Stockholm Bioinformatics Center, Stockholm University, SE 106 91
Stockholm
Phone: +46 8 5537 8564 Fax: +46 8 5537 8214
------------------------------
Message: 2
Date: Wed, 1 Feb 2006 07:54:48 -0800
From: David Mobley <dmobley at gmail.com>
Subject: Re: [gmx-users] manual inconsistency
To: Discussion list for GROMACS users <gmx-users at gromacs.org>
Message-ID:
<bc2c99750602010754v4c2faf72l98131203d0bdd98a at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Mark,
Is the 3.3 manual out yet? I still don't see it anywhere; I thought it
was being released with 3.3.1.
David
On 1/31/06, Mark Abraham <Mark.Abraham at anu.edu.au> wrote:
> Hi,
>
> In section 5.6.1 of the gromacs 3.3 manual (which deals with the
> description of the format of the .top topology file), table 5.3
implies
> that the lines following the dihedraltypes directive must have the
form
> of two atom types, followed by the function type, followed by the
> parameters.
>
> In fact, as made clear in kernel/toppush.c, lines with four atom
types,
> function type and parameters are also read.
>
> What is the behaviour of gromacs when dealing with such four atom-type
> dihedrals? Does it implement them correctly by matching all four
atoms,
> or does it drop the extra information and only match dihedraltypes on
> the central two atoms? Can the manual please be updated to reflect
> whichever of these is true?
>
> Regards,
>
> Mark
>
> _______________________________________________
> gmx-users mailing list gmx-users at gromacs.org
> http://www.gromacs.org/mailman/listinfo/gmx-users
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-users-request at gromacs.org.
> Can't post? Read http://www.gromacs.org/mailing_lists/users.php
>
------------------------------
Message: 3
Date: Thu, 02 Feb 2006 03:29:52 +1100
From: Mark Abraham <Mark.Abraham at anu.edu.au>
Subject: Re: [gmx-users] manual inconsistency
To: Discussion list for GROMACS users <gmx-users at gromacs.org>
Message-ID: <43E0E200.6020108 at anu.edu.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
David Mobley wrote:
> Mark,
>
> Is the 3.3 manual out yet? I still don't see it anywhere; I thought it
> was being released with 3.3.1.
You can get the cvs manual somehow or other... I got it and built it
myself. Check the webpage, I don't remember exactly how, but "cvs co
manual" after doing the login was probably it.
Mark
------------------------------
Message: 4
Date: Wed, 01 Feb 2006 17:46:23 +0100
From: "Berk Hess" <gmx3 at hotmail.com>
Subject: RE: [gmx-users] manual inconsistency
To: gmx-users at gromacs.org
Message-ID: <BAY110-F37E5EB641C347AE463AECE8E0B0 at phx.gbl>
Content-Type: text/plain; format=flowed
>From: Mark Abraham <Mark.Abraham at anu.edu.au>
>Reply-To: Discussion list for GROMACS users <gmx-users at gromacs.org>
>To: Gromacs Users <gmx-users at gromacs.org>
>Subject: [gmx-users] manual inconsistency
>Date: Wed, 01 Feb 2006 15:52:15 +1100
>
>Hi,
>
>In section 5.6.1 of the gromacs 3.3 manual (which deals with the
>description of the format of the .top topology file), table 5.3 implies
>that the lines following the dihedraltypes directive must have the form
of
>two atom types, followed by the function type, followed by the
parameters.
>
>In fact, as made clear in kernel/toppush.c, lines with four atom types,
>function type and parameters are also read.
>
>What is the behaviour of gromacs when dealing with such four atom-type
>dihedrals? Does it implement them correctly by matching all four atoms,
or
>does it drop the extra information and only match dihedraltypes on the
>central two atoms? Can the manual please be updated to reflect
whichever of
>these is true?
It matches all four atoms (otherwise there would have also been
no point in implementing this feature).
The person who implemented this should add it to the manual.
Berk.
>
>Regards,
>
>Mark
>
>_______________________________________________
>gmx-users mailing list gmx-users at gromacs.org
>http://www.gromacs.org/mailman/listinfo/gmx-users
>Please don't post (un)subscribe requests to the list. Use the www
interface
>or send it to gmx-users-request at gromacs.org.
>Can't post? Read http://www.gromacs.org/mailing_lists/users.php
------------------------------
Message: 5
Date: Wed, 01 Feb 2006 08:50:21 -0800
From: "David Mathog" <mathog at caltech.edu>
Subject: Re: [gmx-users] MPI scaling (was RE: MPI tips)
To: Discussion list for GROMACS users <gmx-users at gromacs.org>
Message-ID: <E1F4LBV-0004Sk-00 at mendel.bio.caltech.edu>
Content-Type: text/plain; charset=iso-8859-1
Mark Abraham wrote:
> David Mathog wrote:
> > Presumably I'm doing something wrong here but so far the
> > gromacs MPI performance has been abysmal.
(snip)
> >
> > It was suggested that the gmxdemo example was too small so today
> > I tried changing the original -d .5 value used with editconf to
> > -d 2, -d 4, and finally -d 8. Details are:
>
> It was also suggested that the simulations are too short.
You lost me there. The number of steps was the same, the times went up
and up and up, but the scaling didn't improve all that much. I also
tried (since my last post) adding coulombtype=cut-off to the parameter
files but that made no difference whatsoever. Using the alternative
Scaling formula of:
S = t_1/(N * t_N)
at -d=8 for the 1st mdrun (energy minimization) I measured:
t_1=695, t_20=336 => S=.103 or 10.3%, which is just dreadful
t_1=695, t_4=377 => S=.461 or 46.1% which is better
but still not anywhere near the 94% listed on the link below for
a similar hardware configuration.
> There is
> overhead in setting up the MPI system, as well as in each
communication.
> You want to run benchmarks that aren't dominated by this setup time.
Unless the volume being simulated is actually that size, then the
benchmark is appropriate for the task at hand.
> I
> suggest looking on the gromacs web page for the benchmarks section and
> running the benchmark systems you can get from there. Then you will
have
> a basis for comparison with the results there, and people here will
have
> more confidence that your problem isn't you making an error through
> inexperience with gromacs.
Actually I did download those benchmarks and while they provide
parameters and raw data they don't also provide the command line
parameters used for the runs. So would whoever ran the one on this
page:
http://www.gromacs.org/benchmarks/scaling.php
labeled "Scaling (100Mb Ethernet)" please send me the script
he/she used to obtain those numbers? Specifically, which MPI was
it and which mpirun parameters were used?
Thanks,
> My interconnects are
> a lot better than 10baseT however.
It's 100baseT but your point is still valid. Since there was no
functional demo_mpi provided and I had to write one myself I'm wondering
if I might not have some mpirun parameter set appropriate for lam-mpi
running with this program.
Thanks,
David Mathog
mathog at caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech
------------------------------
Message: 6
Date: Wed, 1 Feb 2006 09:05:00 -0800
From: David Mobley <dmobley at gmail.com>
Subject: Re: [gmx-users] MPI scaling (was RE: MPI tips)
To: Discussion list for GROMACS users <gmx-users at gromacs.org>
Message-ID:
<bc2c99750602010905g3918ccdagbe80f0b861bb1e33 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
>
> > It was also suggested that the simulations are too short.
>
> You lost me there. The number of steps was the same, the times went
up
> and up and up, but the scaling didn't improve all that much. I also
> tried (since my last post) adding coulombtype=cut-off to the parameter
> files but that made no difference whatsoever. Using the alternative
> Scaling formula of:
You are running an extremely short number of timesteps, but increasing
the
system *size* to make the simulations take longer. That most likely
means
you're *mostly* increasing the overhead involved in setting up the
system.
So of course scaling is abysmal -- you're still running trivially short
calculations, just *really big* trivially short calculations. Try
running
reasonable sized calculations that are long (MORE STEPS) and then check
out
scaling. And, as already suggested, you may want to do this on one of
the
standard benchmark systems that was just pointed to.
> It's 100baseT but your point is still valid. Since there was no
> functional demo_mpi provided and I had to write one myself I'm
wondering
> if I might not have some mpirun parameter set appropriate for lam-mpi
> running with this program.
Again, it looks most likely that you're simply running really short
(that
is, FEW TIMESTEPS) runs which are dominated by the system setup time.
I would point out that anytime I submit even a non-MPI job to the queue
here, it takes a few seconds (sometimes 30-60) for it to start. If I
only
run a few timesteps, I would conclude it's extremely slow. I'm pretty
sure
that the bigger the system, the longer this initial overhead time before
it
starts doing anything. And this is for non-MPI jobs; the overhead is
probably larger for MPI jobs. So I still don't see why you think running
really short simulations of just a few timesteps should give you good
benchmarks. If you want something really easy to set up, just put a
protein
in a box of water, or something, and then try running it for an hour or
two.
David
Thanks,
>
> David Mathog
> mathog at caltech.edu
> Manager, Sequence Analysis Facility, Biology Division, Caltech
> _______________________________________________
> gmx-users mailing list gmx-users at gromacs.org
> http://www.gromacs.org/mailman/listinfo/gmx-users
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-users-request at gromacs.org.
> Can't post? Read http://www.gromacs.org/mailing_lists/users.php
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.gromacs.org/pipermail/gmx-users/attachments/20060201/6783f64b
/attachment-0001.html
------------------------------
Message: 7
Date: Wed, 1 Feb 2006 23:07:00 -0300 (GMT+3)
From: <dastmalchi.s at tbzmed.ac.ir>
Subject: Re: [gmx-users] SGI installation problem: forcing the
compilation with gcc
To: <gmx-users at gromacs.org>
Message-ID:
<21275.192.168.127.3.1138846020.squirrel at webmail.tbzmed.ac.ir>
Content-Type: text/plain; charset=iso-8859-1
Hi Erik,
I am not sure if this is right but I have changed the
gh = mk_rgrid(ix,iy,iz);
to
gh =(real ***)mk_rgrid(ix,iy,iz);
in the source file ghat.c and it was compiled.
then I got the error compiling gmx-_fft_fftw3.c file:
cc-3316 cc: ERROR File = gmx-_fft_fftw3.c, Line = 100 (and many other
lines as well)
The expression must be a pointer to a complete object type.
pv += 8;
^
...
...
12 errors detected in the .....
Finally I gave up and installed version 3.1.4 of gromacs.
Cheers, Siavoush
> Hi,
>
> You can always set the environment variable CC to the compiler you
> want to use before running configure.
>
>
> However, the error you're getting is really easy to fix - it just
> happens because we changed a header file, and
> forgot to do
>
> #include "shift_util.h"
>
> in the header of ghat.c. Add that, and it should hopefully compile
> fine with the IRIX compilers too.
>
> Cheers,
>
> Erik
>
> On Jan 31, 2006, at 6:10 AM, Dastmalchi wrote:
>
>> Hi there,
>>
>> Is there a configure flag to force the use of GCC?
>> Do you think this may fix the problem that I have in installation
of
>> GROMACS on my sgi machine? As I posted my problem before I am
>> getting the following error message:
>>
>> ....
>> ghat.lo ghat.c
>> cc -DHAVE_CONFIG_H -I. -I. -I../../src -I../../include "-DGMXLIBDIR=
>> \"/usr/people/siavoush/programs/gromacs-3.3/share/top\"" -I/usr/
>> local/include -r12000 -mips4 -O3 -OPT:IEEE_arithmetic=3
>> -OPT:rsqrt=ON -SWP:loop_overhead -INLINE:=ON -LNO:opt=1 -
>> LNO:ou_further=3
>> -OPT:Olimit=0:roundoff=3:alias=typed -woff 1174 -
>> D__INLINE_INTRINSICS -c
>> ghat.c -Wp,-MDupdate,.deps/ghat.TPlo -o ghat.o
>> cc-1515 cc: ERROR File = ghat.c, Line = 233
>> A value of type "int" cannot be assigned to an entity of type
>> "real ***".
>>
>> gh = mk_rgrid(ix,iy,iz);
>> ^
>>
>> 1 error detected in the compilation of "ghat.c".
>> *** Error code 1 (bu21)
>> *** Error code 1 (bu21)
>> *** Error code 1 (bu21)
>> *** Error code 1 (bu21)
>>
>> Best regards,
>> Siavoush
>> _______________________________________________
>> gmx-users mailing list gmx-users at gromacs.org
>> http://www.gromacs.org/mailman/listinfo/gmx-users
>> Please don't post (un)subscribe requests to the list. Use the
>> www interface or send it to gmx-users-request at gromacs.org.
>> Can't post? Read http://www.gromacs.org/mailing_lists/users.php
>
> -----------------------------------------------------------
> Erik Lindahl <lindahl at sbc.su.se> Backup address:
> <erik.lindahl at gmail.com>
> Assistant Professor, Computational Structural Biology
> Stockholm Bioinformatics Center, Stockholm University, SE 106 91
> Stockholm
> Phone: +46 8 5537 8564 Fax: +46 8 5537 8214
------------------------------
_______________________________________________
gmx-users mailing list
gmx-users at gromacs.org
http://www.gromacs.org/mailman/listinfo/gmx-users
End of gmx-users Digest, Vol 22, Issue 5
****************************************
More information about the gromacs.org_gmx-users
mailing list