[AMBER] Clarification in HBond analysis

From: kureeckal ramesh <kureeckalramesh.yahoo.co.in>
Date: Tue, 23 Nov 2010 08:43:29 +0530 (IST)

I am carrying out MD simulation for a protein (155 aa residues) under explicit condition for a time period of 10 ns. Due to memory shortage in my CPU and based on the suggestion I got earlier from other AMBER users, instead of analyzing the mdcrd files generated for the entire 10 ns, I am breaking the time (upto 4 ns each) and then subjecting it to HBond analysis.

I have couple of doubts with this
(i) For final interpretation of H bond analysis for the whole protein in explicit solvent, can I combine the results of 3 sets: i. e, the results analyzed from (1- 4 ns) , (4 - 8 ns) and (9 - 10 ns)
(ii) Will the HBond results vary, IF the entire mdcrd files of 10 ns been analyzed at one stretch with high performance computing system (such as silicon graphics ?


Looking forward for a reply

with best of regards
Ramesh K V



--- On Thu, 18/11/10, kureeckal ramesh <kureeckalramesh.yahoo.co.in> wrote:

From: kureeckal ramesh <kureeckalramesh.yahoo.co.in>
Subject: [AMBER] Clarification in HBond analysis
To: "AMBER Mailing List" <amber.ambermd.org>
Date: Thursday, 18 November, 2010, 12:05 PM

Hi AMBER users
I am carrying out MD simulation for a protein (155 aa residues) under explicit condition for a time period of 10 ns. Due to memory shortage in my CPU and based on the suggestion I got from other AMBER users, instead of analyzing the mdcrd files generated for entire 10 ns, I am breaking the time (upto 8 ns) and then subjecting it to HBond analysis.

I have couple of doubts with this
(i) For final interpretation of H bond analysis for the whole protein in explicit solvent, can I combine the results of 2 sets: i. e, the results analyzed from (1- 8 ns) with that (9 - 10 ns).
(ii) Will the HBond results change, had the entire mdcrd files of 10 ns been analyzed at one stretch with high performance computing ?


Your rsponse to this query will be appreciated

with best of regards
Ramesh K V






--- On Thu, 18/11/10, Scott Brozell <sbrozell.rci.rutgers.edu> wrote:

From: Scott Brozell <sbrozell.rci.rutgers.edu>
Subject: Re: [AMBER] Amber 11 installation problems
To: "AMBER Mailing List" <amber.ambermd.org>
Date: Thursday, 18 November, 2010, 9:07 AM

Hi,

On Wed, Nov 17, 2010 at 01:36:00PM -0500, case wrote:
> On Wed, Nov 17, 2010, Linus Johannissen wrote:
> >  /opt/software/gaussian/d02/g03/bsd/install -c -m 644 './netcdf_f90.3' '/home/linusj/amber/amber11/AmberTools/src/netcdf/share/man/man3/netcdf_f90.3'
>
> This is pretty suspicious, but I am just guessing.  You are using the Guassian
> "install" program, and the netcdf script is expecting something like
> "/usr/bin/install".

Yes, this is a known bug.


On Wed, Nov 17, 2010 at 06:17:28PM -0500, Jason Swails wrote:
> On Wed, Nov 17, 2010 at 5:34 PM, Linus Johannissen <
> Linus.Johannissen.manchester.ac.uk> wrote:
>
> I'm going to side with Dave Case on this one.  What you should do before you
> install Amber is *unload* your Gaussian module, since it's plopping an
> "install" into your path that I'm guessing is mucking up the install
> process.  I have never seen an error in the NETCDF build (which is where
> this is occurring) before, and I've installed it on a lot of different
> systems/clusters.

I have seen this error before.
While Jason's advice is correct, it is incomplete:
it may not be a user action or a user script that is altering the PATH
- a system script may be the culprit.
Thus, follow Dave's advice:
modify your PATH variable so that /usr/bin/install becomes the result of
which install.

scott


> As long as you see the "phrase":  /opt/software/gaussian/d02/g03/bsd/install
> -c -m 644
>
> then the compilation process is using the *wrong* install which is likely
> breaking stuff.
>
> As a note to general users:  Do NOT source Gaussian files that set up your
> environment in normal shell environments.  ONLY source them in PBS scripts
> that specifically run Gaussian.  The reason is that their profile scripts
> that set up environment variables are effectively poison to every other
> package that uses these variables (notably LD_LIBRARY_PATH).  These scripts
> set up the environment variables properly for Gaussian, so g03/g09 will run
> properly, but it could easily break other packages (this drove me insane for
> some time before I figured it out).  Therefore, source the Gaussian scripts
> and/or load the Gaussian module only in sessions that you are actually
> running a Gaussian job.

_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber


_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber


_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Mon Nov 22 2010 - 19:30:03 PST
Custom Search