From jji at cgl.ucsf.edu  Thu Nov  1 10:50:28 2007
From: jji at cgl.ucsf.edu (John J. Irwin)
Date: Thu, 01 Nov 2007 10:50:28 -0700
Subject: [Dock-fans] Fixing protonation state
In-Reply-To: <20071026151658.akhue00740s44ss0@webmail.ualberta.ca>
References: <20071026151658.akhue00740s44ss0@webmail.ualberta.ca>
Message-ID: <472A11E4.2000001@cgl.ucsf.edu>

Hi Asdrubal

That molecule has more rotatable bonds (13 in a row, 17 total, + limited
sampling on the 2 amides) than I feel comfortable with. It also has
molecular weight > 600. These are two reason why the ZINC upload server
just won't take it. I have to draw the line somewhere, and I regret to
say you have hit it.

I would be skeptical of anyone who docks a molecule having 17 (or even
13) rotatable bonds and gets the crystallographic pose within 2A rmsd.
Actually, my skepticism starts at around 8 rotatable bonds, but I keep
it mostly to myself till we get past 12. ;-)

Almost for sure, you are trying to dock into two distinct pockets, and
the long aliphatic chain is a linker between them. My suggestion is
therefore to dock each end separately. Shoot for something with 7
rotatable bonds, even a bit less if you can. Then you can model in the
rest of the linker between them.

Good luck, and sorry to disappoint.

John


burgosgu at ualberta.ca wrote:
> Hi everybody,
>
> I need to have a compound correctly protonated to dock it. I tried to  
> use the resource of
> "upload sets" of ZINC, but it seems that it does not have the required  
> charactersitics of
> bioavailability and non-toxicity, because it gives me no output as it  
> did with other
> compounds.
>
> The smile for this compound is:
> C1=C(C=CC2=C1C(=C[N]2)CC(=O)NCCCNCCCCNCCCNC(=O)CC3=C[N]C4=C3C=C(C=C4)Br)Br
>
> Any suggestions??
>
> THANKS,
>
> Asdrubal
>
> _______________________________________________
> Dock-fans mailing list
> Dock-fans at docking.org
> http://blur.compbio.ucsf.edu/mailman/listinfo/dock-fans
>   

From chiendarret at yahoo.com  Thu Nov  1 14:08:49 2007
From: chiendarret at yahoo.com (Francesco Pietra)
Date: Thu, 1 Nov 2007 14:08:49 -0700 (PDT)
Subject: [Dock-fans] Fixing protonation state
In-Reply-To: <472A11E4.2000001@cgl.ucsf.edu>
Message-ID: <85431.22609.qm@web57614.mail.re1.yahoo.com>

Is your skepticism only about the precision of docking (with large, flexible
molecules) or is any evidence that also the region of receptor where docking is
found may be false? E.g. helix S5 instead of S6 in a pore?
Thanks
francesco pietra

--- "John J. Irwin" <jji at cgl.ucsf.edu> wrote:

> Hi Asdrubal
> 
> That molecule has more rotatable bonds (13 in a row, 17 total, + limited
> sampling on the 2 amides) than I feel comfortable with. It also has
> molecular weight > 600. These are two reason why the ZINC upload server
> just won't take it. I have to draw the line somewhere, and I regret to
> say you have hit it.
> 
> I would be skeptical of anyone who docks a molecule having 17 (or even
> 13) rotatable bonds and gets the crystallographic pose within 2A rmsd.
> Actually, my skepticism starts at around 8 rotatable bonds, but I keep
> it mostly to myself till we get past 12. ;-)
> 
> Almost for sure, you are trying to dock into two distinct pockets, and
> the long aliphatic chain is a linker between them. My suggestion is
> therefore to dock each end separately. Shoot for something with 7
> rotatable bonds, even a bit less if you can. Then you can model in the
> rest of the linker between them.
> 
> Good luck, and sorry to disappoint.
> 
> John
> 
> 
> burgosgu at ualberta.ca wrote:
> > Hi everybody,
> >
> > I need to have a compound correctly protonated to dock it. I tried to  
> > use the resource of
> > "upload sets" of ZINC, but it seems that it does not have the required  
> > charactersitics of
> > bioavailability and non-toxicity, because it gives me no output as it  
> > did with other
> > compounds.
> >
> > The smile for this compound is:
> > C1=C(C=CC2=C1C(=C[N]2)CC(=O)NCCCNCCCCNCCCNC(=O)CC3=C[N]C4=C3C=C(C=C4)Br)Br
> >
> > Any suggestions??
> >
> > THANKS,
> >
> > Asdrubal
> >
> > _______________________________________________
> > Dock-fans mailing list
> > Dock-fans at docking.org
> > http://blur.compbio.ucsf.edu/mailman/listinfo/dock-fans
> >   
> _______________________________________________
> Dock-fans mailing list
> Dock-fans at docking.org
> http://blur.compbio.ucsf.edu/mailman/listinfo/dock-fans
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

From jji at cgl.ucsf.edu  Thu Nov  1 14:35:37 2007
From: jji at cgl.ucsf.edu (John J. Irwin)
Date: Thu, 01 Nov 2007 14:35:37 -0700
Subject: [Dock-fans] Fixing protonation state
In-Reply-To: <85431.22609.qm@web57614.mail.re1.yahoo.com>
References: <85431.22609.qm@web57614.mail.re1.yahoo.com>
Message-ID: <472A46A9.7080805@cgl.ucsf.edu>

Hi Francesco

Here are three arguments to try to convince you that big floppy
molecules make poor candidates for docking.

[I was unaware of the target of that compound, and based my comments
about the unsuitability for docking purely upon the molecule itself. ]

1. The number of conformations to be sampled goes up exponentially as a
function of the number of rotatable bonds. Let's assume three
conformations around each bond for the sake of simplicity. Thus 3^7 =
2187 , 3^10 = 59,049 and  3^17 = 129,140,163. These are the number of
conformations to be sampled, even by very coarse sampling, for molecules
with 7, 10 and 17 rotatable bonds, respectively. That's very coarse,
fix-interval sampling. At 1 second per conformation (and that's
considered fast by the standards of the field) that makes 4.1 years for
17 rotatable bonds. for one *%^* molecule.

2. If you have a molecule like the one suggested by Asdrubal, a
"dumbell" with 19 bonds between the aromatics at the end, then a
movement of just a degree or two around the central bond can result in a
relative shift of the extremities (and thus the overall shape of the
molecule) by 5A or more. This hypersensitivity of shape to central bonds
means that you cannot hope to sample all the "right" conformation given
fixed increment angle sampling, which is all you can afford to do. If
you try to sample more finely, say 10 angles around a bond instead of 3,
then you're stuck with 10^17 conformations. Even being clever and doing
10 points around central bonds decreasing to 3 points at the extremities
would necessitate sampling an implausibly large number of conformations.

3. This molecule has terrible entropy problems. It is common practice to
remove molecules from virtual screening libraries with more than 6
methylene's in a row, for this reason. Large numbers of rotatable bonds
tend to have bioavailability problems too (Veber, J Med Chem, 2002), in
case you are still unconvinced.

By the way, there are many drugs that break the rules I just laid
outlined. I am not saying these molecules cannot be drugs. I am saying
they are problematic candidates for molecular docking, and very likely,
as *starting points* for ligand discovery.

I hope this is clear and helpful.

John



Francesco Pietra wrote:
> Is your skepticism only about the precision of docking (with large, flexible
> molecules) or is any evidence that also the region of receptor where docking is
> found may be false? E.g. helix S5 instead of S6 in a pore?
> Thanks
> francesco pietra
>
> --- "John J. Irwin" <jji at cgl.ucsf.edu> wrote:
>
>   
>> Hi Asdrubal
>>
>> That molecule has more rotatable bonds (13 in a row, 17 total, + limited
>> sampling on the 2 amides) than I feel comfortable with. It also has
>> molecular weight > 600. These are two reason why the ZINC upload server
>> just won't take it. I have to draw the line somewhere, and I regret to
>> say you have hit it.
>>
>> I would be skeptical of anyone who docks a molecule having 17 (or even
>> 13) rotatable bonds and gets the crystallographic pose within 2A rmsd.
>> Actually, my skepticism starts at around 8 rotatable bonds, but I keep
>> it mostly to myself till we get past 12. ;-)
>>
>> Almost for sure, you are trying to dock into two distinct pockets, and
>> the long aliphatic chain is a linker between them. My suggestion is
>> therefore to dock each end separately. Shoot for something with 7
>> rotatable bonds, even a bit less if you can. Then you can model in the
>> rest of the linker between them.
>>
>> Good luck, and sorry to disappoint.
>>
>> John
>>
>>
>> burgosgu at ualberta.ca wrote:
>>     
>>> Hi everybody,
>>>
>>> I need to have a compound correctly protonated to dock it. I tried to  
>>> use the resource of
>>> "upload sets" of ZINC, but it seems that it does not have the required  
>>> charactersitics of
>>> bioavailability and non-toxicity, because it gives me no output as it  
>>> did with other
>>> compounds.
>>>
>>> The smile for this compound is:
>>> C1=C(C=CC2=C1C(=C[N]2)CC(=O)NCCCNCCCCNCCCNC(=O)CC3=C[N]C4=C3C=C(C=C4)Br)Br
>>>
>>> Any suggestions??
>>>
>>> THANKS,
>>>
>>> Asdrubal
>>>
>>> _______________________________________________
>>> Dock-fans mailing list
>>> Dock-fans at docking.org
>>> http://blur.compbio.ucsf.edu/mailman/listinfo/dock-fans
>>>   
>>>       
>> _______________________________________________
>> Dock-fans mailing list
>> Dock-fans at docking.org
>> http://blur.compbio.ucsf.edu/mailman/listinfo/dock-fans
>>
>>     
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
>   

From chiendarret at yahoo.com  Thu Nov  1 15:12:09 2007
From: chiendarret at yahoo.com (Francesco Pietra)
Date: Thu, 1 Nov 2007 15:12:09 -0700 (PDT)
Subject: [Dock-fans] Fixing protonation state
In-Reply-To: <472A46A9.7080805@cgl.ucsf.edu>
Message-ID: <842837.3509.qm@web57602.mail.re1.yahoo.com>

Hi John:
My question was not restricted to the case in point, and nature is not faced by
the limitations the computational medicinal chemist is. There are a number of
dockings in nature - known or elusive - where the ligand is large and flexible.
My question was, is any chance to identify the right pocket when the ligand is
large and flexible? By DOCK or any other docking program?

That computational minimization of large, flexible molecules remains a
challenge, we know.

Thanks
francesco

--- "John J. Irwin" <jji at cgl.ucsf.edu> wrote:

> Hi Francesco
> 
> Here are three arguments to try to convince you that big floppy
> molecules make poor candidates for docking.
> 
> [I was unaware of the target of that compound, and based my comments
> about the unsuitability for docking purely upon the molecule itself. ]
> 
> 1. The number of conformations to be sampled goes up exponentially as a
> function of the number of rotatable bonds. Let's assume three
> conformations around each bond for the sake of simplicity. Thus 3^7 =
> 2187 , 3^10 = 59,049 and  3^17 = 129,140,163. These are the number of
> conformations to be sampled, even by very coarse sampling, for molecules
> with 7, 10 and 17 rotatable bonds, respectively. That's very coarse,
> fix-interval sampling. At 1 second per conformation (and that's
> considered fast by the standards of the field) that makes 4.1 years for
> 17 rotatable bonds. for one *%^* molecule.
> 
> 2. If you have a molecule like the one suggested by Asdrubal, a
> "dumbell" with 19 bonds between the aromatics at the end, then a
> movement of just a degree or two around the central bond can result in a
> relative shift of the extremities (and thus the overall shape of the
> molecule) by 5A or more. This hypersensitivity of shape to central bonds
> means that you cannot hope to sample all the "right" conformation given
> fixed increment angle sampling, which is all you can afford to do. If
> you try to sample more finely, say 10 angles around a bond instead of 3,
> then you're stuck with 10^17 conformations. Even being clever and doing
> 10 points around central bonds decreasing to 3 points at the extremities
> would necessitate sampling an implausibly large number of conformations.
> 
> 3. This molecule has terrible entropy problems. It is common practice to
> remove molecules from virtual screening libraries with more than 6
> methylene's in a row, for this reason. Large numbers of rotatable bonds
> tend to have bioavailability problems too (Veber, J Med Chem, 2002), in
> case you are still unconvinced.
> 
> By the way, there are many drugs that break the rules I just laid
> outlined. I am not saying these molecules cannot be drugs. I am saying
> they are problematic candidates for molecular docking, and very likely,
> as *starting points* for ligand discovery.
> 
> I hope this is clear and helpful.
> 
> John
> 
> 
> 
> Francesco Pietra wrote:
> > Is your skepticism only about the precision of docking (with large,
> flexible
> > molecules) or is any evidence that also the region of receptor where
> docking is
> > found may be false? E.g. helix S5 instead of S6 in a pore?
> > Thanks
> > francesco pietra
> >
> > --- "John J. Irwin" <jji at cgl.ucsf.edu> wrote:
> >
> >   
> >> Hi Asdrubal
> >>
> >> That molecule has more rotatable bonds (13 in a row, 17 total, + limited
> >> sampling on the 2 amides) than I feel comfortable with. It also has
> >> molecular weight > 600. These are two reason why the ZINC upload server
> >> just won't take it. I have to draw the line somewhere, and I regret to
> >> say you have hit it.
> >>
> >> I would be skeptical of anyone who docks a molecule having 17 (or even
> >> 13) rotatable bonds and gets the crystallographic pose within 2A rmsd.
> >> Actually, my skepticism starts at around 8 rotatable bonds, but I keep
> >> it mostly to myself till we get past 12. ;-)
> >>
> >> Almost for sure, you are trying to dock into two distinct pockets, and
> >> the long aliphatic chain is a linker between them. My suggestion is
> >> therefore to dock each end separately. Shoot for something with 7
> >> rotatable bonds, even a bit less if you can. Then you can model in the
> >> rest of the linker between them.
> >>
> >> Good luck, and sorry to disappoint.
> >>
> >> John
> >>
> >>
> >> burgosgu at ualberta.ca wrote:
> >>     
> >>> Hi everybody,
> >>>
> >>> I need to have a compound correctly protonated to dock it. I tried to  
> >>> use the resource of
> >>> "upload sets" of ZINC, but it seems that it does not have the required  
> >>> charactersitics of
> >>> bioavailability and non-toxicity, because it gives me no output as it  
> >>> did with other
> >>> compounds.
> >>>
> >>> The smile for this compound is:
> >>>
> C1=C(C=CC2=C1C(=C[N]2)CC(=O)NCCCNCCCCNCCCNC(=O)CC3=C[N]C4=C3C=C(C=C4)Br)Br
> >>>
> >>> Any suggestions??
> >>>
> >>> THANKS,
> >>>
> >>> Asdrubal
> >>>
> >>> _______________________________________________
> >>> Dock-fans mailing list
> >>> Dock-fans at docking.org
> >>> http://blur.compbio.ucsf.edu/mailman/listinfo/dock-fans
> >>>   
> >>>       
> >> _______________________________________________
> >> Dock-fans mailing list
> >> Dock-fans at docking.org
> >> http://blur.compbio.ucsf.edu/mailman/listinfo/dock-fans
> >>
> >>     
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around 
> > http://mail.yahoo.com 
> >   
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

From jji at cgl.ucsf.edu  Thu Nov  1 15:27:36 2007
From: jji at cgl.ucsf.edu (John J. Irwin)
Date: Thu, 01 Nov 2007 15:27:36 -0700
Subject: [Dock-fans] Fixing protonation state
In-Reply-To: <842837.3509.qm@web57602.mail.re1.yahoo.com>
References: <842837.3509.qm@web57602.mail.re1.yahoo.com>
Message-ID: <472A52D8.60700@cgl.ucsf.edu>

Francesco

Francesco Pietra wrote:
> Hi John:
> My question was not restricted to the case in point, and nature is not faced by
> the limitations the computational medicinal chemist is. There are a number of
> dockings in nature - known or elusive - where the ligand is large and flexible.
> My question was, is any chance to identify the right pocket when the ligand is
> large and flexible? By DOCK or any other docking program?
>   
Identifying the binding site is of course possible, using mutagenesis,
crystallography, and all that. We start with docking once we know the
binding site. Are you asking if docking can be used to rank binding
sites by the likelihood that one binds a particular ligand? Sure, why
not, give it a try. But given the famously high false positive rate of
docking, the odds are against you.
> That computational minimization of large, flexible molecules remains a
> challenge, we know.
>
> Thanks
> francesco
>
> --- "John J. Irwin" <jji at cgl.ucsf.edu> wrote:
>
>   
>> Hi Francesco
>>
>> Here are three arguments to try to convince you that big floppy
>> molecules make poor candidates for docking.
>>
>> [I was unaware of the target of that compound, and based my comments
>> about the unsuitability for docking purely upon the molecule itself. ]
>>
>> 1. The number of conformations to be sampled goes up exponentially as a
>> function of the number of rotatable bonds. Let's assume three
>> conformations around each bond for the sake of simplicity. Thus 3^7 =
>> 2187 , 3^10 = 59,049 and  3^17 = 129,140,163. These are the number of
>> conformations to be sampled, even by very coarse sampling, for molecules
>> with 7, 10 and 17 rotatable bonds, respectively. That's very coarse,
>> fix-interval sampling. At 1 second per conformation (and that's
>> considered fast by the standards of the field) that makes 4.1 years for
>> 17 rotatable bonds. for one *%^* molecule.
>>
>> 2. If you have a molecule like the one suggested by Asdrubal, a
>> "dumbell" with 19 bonds between the aromatics at the end, then a
>> movement of just a degree or two around the central bond can result in a
>> relative shift of the extremities (and thus the overall shape of the
>> molecule) by 5A or more. This hypersensitivity of shape to central bonds
>> means that you cannot hope to sample all the "right" conformation given
>> fixed increment angle sampling, which is all you can afford to do. If
>> you try to sample more finely, say 10 angles around a bond instead of 3,
>> then you're stuck with 10^17 conformations. Even being clever and doing
>> 10 points around central bonds decreasing to 3 points at the extremities
>> would necessitate sampling an implausibly large number of conformations.
>>
>> 3. This molecule has terrible entropy problems. It is common practice to
>> remove molecules from virtual screening libraries with more than 6
>> methylene's in a row, for this reason. Large numbers of rotatable bonds
>> tend to have bioavailability problems too (Veber, J Med Chem, 2002), in
>> case you are still unconvinced.
>>
>> By the way, there are many drugs that break the rules I just laid
>> outlined. I am not saying these molecules cannot be drugs. I am saying
>> they are problematic candidates for molecular docking, and very likely,
>> as *starting points* for ligand discovery.
>>
>> I hope this is clear and helpful.
>>
>> John
>>
>>
>>
>> Francesco Pietra wrote:
>>     
>>> Is your skepticism only about the precision of docking (with large,
>>>       
>> flexible
>>     
>>> molecules) or is any evidence that also the region of receptor where
>>>       
>> docking is
>>     
>>> found may be false? E.g. helix S5 instead of S6 in a pore?
>>> Thanks
>>> francesco pietra
>>>
>>> --- "John J. Irwin" <jji at cgl.ucsf.edu> wrote:
>>>
>>>   
>>>       
>>>> Hi Asdrubal
>>>>
>>>> That molecule has more rotatable bonds (13 in a row, 17 total, + limited
>>>> sampling on the 2 amides) than I feel comfortable with. It also has
>>>> molecular weight > 600. These are two reason why the ZINC upload server
>>>> just won't take it. I have to draw the line somewhere, and I regret to
>>>> say you have hit it.
>>>>
>>>> I would be skeptical of anyone who docks a molecule having 17 (or even
>>>> 13) rotatable bonds and gets the crystallographic pose within 2A rmsd.
>>>> Actually, my skepticism starts at around 8 rotatable bonds, but I keep
>>>> it mostly to myself till we get past 12. ;-)
>>>>
>>>> Almost for sure, you are trying to dock into two distinct pockets, and
>>>> the long aliphatic chain is a linker between them. My suggestion is
>>>> therefore to dock each end separately. Shoot for something with 7
>>>> rotatable bonds, even a bit less if you can. Then you can model in the
>>>> rest of the linker between them.
>>>>
>>>> Good luck, and sorry to disappoint.
>>>>
>>>> John
>>>>
>>>>
>>>> burgosgu at ualberta.ca wrote:
>>>>     
>>>>         
>>>>> Hi everybody,
>>>>>
>>>>> I need to have a compound correctly protonated to dock it. I tried to  
>>>>> use the resource of
>>>>> "upload sets" of ZINC, but it seems that it does not have the required  
>>>>> charactersitics of
>>>>> bioavailability and non-toxicity, because it gives me no output as it  
>>>>> did with other
>>>>> compounds.
>>>>>
>>>>> The smile for this compound is:
>>>>>
>>>>>           
>> C1=C(C=CC2=C1C(=C[N]2)CC(=O)NCCCNCCCCNCCCNC(=O)CC3=C[N]C4=C3C=C(C=C4)Br)Br
>>     
>>>>> Any suggestions??
>>>>>
>>>>> THANKS,
>>>>>
>>>>> Asdrubal
>>>>>
>>>>> _______________________________________________
>>>>> Dock-fans mailing list
>>>>> Dock-fans at docking.org
>>>>> http://blur.compbio.ucsf.edu/mailman/listinfo/dock-fans
>>>>>   
>>>>>       
>>>>>           
>>>> _______________________________________________
>>>> Dock-fans mailing list
>>>> Dock-fans at docking.org
>>>> http://blur.compbio.ucsf.edu/mailman/listinfo/dock-fans
>>>>
>>>>     
>>>>         
>>> __________________________________________________
>>> Do You Yahoo!?
>>> Tired of spam?  Yahoo! Mail has the best spam protection around 
>>> http://mail.yahoo.com 
>>>   
>>>       
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
>   

From sbrozell at scripps.edu  Thu Nov  1 19:07:21 2007
From: sbrozell at scripps.edu (Scott Brozell)
Date: Thu, 1 Nov 2007 18:07:21 -0800 (PST)
Subject: [Dock-fans] Combining DOCK with AMBER
In-Reply-To: <968467.27646.qm@web57613.mail.re1.yahoo.com>
Message-ID: <Pine.LNX.4.44.0711011326180.20140-100000@loyd.scripps.edu>

On Wed, 31 Oct 2007, Francesco Pietra wrote:

> --- Scott Brozell <sbrozell at scripps.edu> wrote:
> 
> > On Tue, 30 Oct 2007, Francesco Pietra wrote:
> > 
> > > --- Scott Brozell <sbrozell at scripps.edu> wrote:
> > > 
> > > > On Mon, 29 Oct 2007, Francesco Pietra wrote:
> > > > 
> > > > > --- Scott Brozell <sbrozell at scripps.edu> wrote:
> > > > > 
> > > > > > On Mon, 29 Oct 2007, Francesco Pietra wrote:
> > > > > > 
> > > > > > > I posted previously that, with DOCK6.1, dock-prep for my protein,
> > after
> > > > > > > repeated fixing, arrived at fractional charges for the residues.
> > Either
> > > > > > some
> > > > > > > were still misnamed, or some were lacking. This was the best I
> > could
> > > > do.
> > > > > > > 
> > > > > > > Accepting the suggestion to go to Amber (someone was even skeptical
> > > > that
> > > > > > the
> > > > > > > fractional charges for this large receptor could be assigned by
> > > > > > Antechamber), I
> > > > > > > have now loaded the pdb to leap (Amber9), whereby heavy atoms were
> > > > added
> > > > > > (where
> > > > > > > I had set TER records) and H/lone pairs also added. Both prmtop and
> > > > inpcrd
> > > > > > > could be saved (and opened correctly with VMD). Of perhaps major
> > > > concern
> > > > > > > (leap.log attached):
> > > > > > > 
> > > > > > > (Residues lacking connect 0/ connect 1 -
> > > > > > > These don't have chain types marked:
> > > > > > > res  total affected
> > > > > > > CTHR 4
> > > > > > > NSER 4
> > > > > > 
> > > > > > These are innocuous.  They indicate that some residues are not
> > connected.
> > > > > > And those should correspond to your insertion of TER cards.  See
> > > > > > http://amber.ch.ic.ac.uk/archive/200502/0264.html
> > > > > > http://amber.ch.ic.ac.uk/archive/200505/0290.html
> > > > > 
> > > > > In fact, prepare_amber.pl lig.mol2 rec.pdb produced the expected files,
> > > > though
> > > > > 
> > > > > mpirun -np 4 dock6.mpi -i dock.in -o dock.out
> > > > > 
> > > > > after the "Initialing MPI Routines for all nodes, said
> > > > > 
> > > > > "getpdb: can't open file 0.amber.pdb"
> > > > > 
> > > > > The dock.out.# don't tell much.
> > > > 
> > > > 
> > > > http://dock.compbio.ucsf.edu/DOCK_6/6.1/bugfix.2
> > > 
> > > Ah! I failed to look at dock-fans. Sorry. However, the edited file
> > (attached
> > > base_mpi.cpp) gives the same error (getpdb: can't open file 0.amber.pdb) as
> > the
> > > original file (attached original_base_mpi.cpp).
> > > 
> > > Probably I was unable to follow the recipe, and there is no one around here
> > > capable of C or C++. I simply deleted a line of program from the original
> > file.
> > > 
> > > I have checked that the prmtop and inpcrd files generated by
> > prepare_amber.pl
> > > produce the correct representation in both VMD and Chimera.
> > 
> > 
> > base_mpi.cpp has been correctly patched.  Reinstall dock:
> > cd install; make dock
> 
> OK, thanks. However, reminding for installations where MPICH points to OpenMpi,
> to proceed as follows:


Yes, good point; bugfix 2 is for mpi.


> MPICH_HOME='/usr/loc' (or other appropriate location)
> export MPICH_HOME
> cd install
> make clean
> make dock # builds only the dock program
> 
> (otherwise errors arise about MPICH)
> 
> Now amber_score with option "ligand" 
> 
> mpirun -np 4 dock6.mpi -i dock.in -o dock.out
> 
> produced in a few minutes the expected files.
> 
> 
> > 
> > Scott
> > 
> > > > > This rec.pdb failed with Dock-prep in Chimera. Again, the program
> > believes
> > > > that
> > > > > there are non-standard residue, assigning them to Antechamber, which
> > > > produces
> > > > > fractional charges for the residues.
> > > > > 
> > > > > In other words, I did not succeed in getting Chimera and DOCK talking 
> > > > > together.
> > > > 
> > > > 
> > > > I probably do not understand exactly what you are doing,
> > > > why run Dock-prep again ?
> > > 
> > > It was to check if the pdb fixed by LEAP was now OK for DockPrep. It was
> > not.
> > > 
> > > Thanks
> > > francesco
> > > 
> > > > Perhaps you should open the amberized receptor files in Chimera:
> > > > rec.amber.pdb
> > > > rec.prmtop
> > > > etc
> 
> 
> That did not succeed (assuming that I kave implemented correctly the
> suggestion, which should be verified)
> 
> I created a directory, copying in the prmtop and inpcrd file for the receptor
> as obtained from LEAP (just the files that worked out perfectly for
> amber_score). Dock-prep (from Chimera, accepting defaults, i.e. everything
> selected except "Delete non complexed ions", and considering H-bonds, reported
> errors "Value error: underlying C++ Molecule object is missing", which is
> documented in the attacher error.log. 


Please post this small episode to Chimera-users.
Probably, this is an issue of operator error, but maybe not and
anyways it may help them improve robustness.


> However, the error is different from that obtained with the pdb file created
> from the above prmtop and inpcrd using "ambpdb" of Amber9. In the latter case,
> apparently, some standard amino acid was erroneously taken by Dock-Prep as
> non-standard residue and passed to Antechamber, which failed to do correctly,
> reporting fractional charges for the residue. For the present protein, the
> relevant window that was presented, was
> 
> ASH+ALA+ASN  +0
> ASH+ALA+PRO +0
> ASH+GLY+MET +0
> GLH+ALA++ALA +0
> GLH+ARG++LEU +1
> GLH+ARG+THR +0
> 
> accepting that, fractional charges were calculated for the residues. Any change
> to the values (+0 or +1) presented led to crashing.
> 
> What I was trying was to run some simple docking before amber_score. The


This is mandatory since Amber_score cannot be used for docking,
only for rescoring (as well as for serious MD but as indicated before
it is better to use the Amber package itself for serious MD).

> tutorial passed without problems. Even my protein passes correctly Dock-prep,
> if prepare from Chimera is accepted, and I could run all dockings as in the
> tutorial. However, the protein handled by Chimera is not accepted by Amber9 or
> amber_score.


This is not surprising since Amber's LEaP (which is the vehicle for
amberization under the hood of DOCK's prepare_amber.pl)
is the sole mechanism for Amber input preparation.


Here is the usual sequence:
Do docking (along the lines of tutorials 
Structure Preparation,
Sphere Generation and Selection,
Grid Generation,
Docking );
Then rescore with Amber_score (along the lines of tutorial
Structure Preparation & AMBER Score ).
Note that Amber_score has receptor input files distinct 
from DOCKing receptor input files.

Typically, one has an original pdb which is the starting point for 
dock prep, and the resulting mol2 file (from step 2f in the
Structure Preparation tutorial) also can be saved as a pdb;
it is this later pdb that is usually the starting point for
prepare_amber.  However, one can imagine several ways to
obtain the actual receptor input files; for example, one might
take the pdb file from step 2g and use that for prepare_amber.
This would be a simple consistency test for protonation
between the DOCKing receptor and the Amber_score receptor.

It seems to me that you are performing various consistency checks
between DOCKing inputs and Amber_score inputs.
That is a sound approach, but human inspection will play a 
dominant role since the DOCK and the Amber packages are
not input compatible (despite the appearance through the
magic of amberization).

[Note to Amber/DOCK superexperts: there are several caveats
that I have ignored for pedagogical purposes.]

Scott

> > > > Scott
> > > > 
> > > > > > > Should all that be OK, how to go to DOCK now? I have prmtop and
> > inpcrd
> > > > > > files
> > > > > > > also for the ligand, obtained from prepare_amber.pl, though,
> > obviously,
> > > > no
> > > > > > such
> > > > > > > files for the complex receptor-ligand.
> > > > > > 
> > > > > > If prepare_amber.pl was run, there should be all the Amber files
> > (prmtop,
> > > > > > etc)
> > > > > > for all three (ligand, receptor, complex).
> > > > > > See step 3 in
> > > > > >
> > http://dock.compbio.ucsf.edu/DOCK_6/tutorials/amber_score/amber_score.htm
> > > > > > Once amberization is complete and verified then use step 4 of that
> > > > tutorial
> > > > > > as a template for creating your own dock input file for rescoring.
> > > > > > 
> > > > > > > Also, the receptor has 24.000000 charge: should docking be carried
> > out
> > > > with
> > > > > > > this charged receptor or should it be first neutralized (in leap?).
> > > > > > 
> > > > > > DOCK's Amber_score uses an implicit solvent model in which case
> > > > > > charge neutralization with explicit ions is usually not performed.


From sbrozell at scripps.edu  Thu Nov  1 22:21:14 2007
From: sbrozell at scripps.edu (Scott Brozell)
Date: Thu, 1 Nov 2007 21:21:14 -0800 (PST)
Subject: [Dock-fans] grid too small error
In-Reply-To: <47284F8B.60706@pharmacy.ac.uk>
Message-ID: <Pine.LNX.4.44.0711012100210.20140-100000@loyd.scripps.edu>

Hi,

On Wed, 31 Oct 2007, Samantha Kaye wrote:

> I keep getting a problem whilst trying to dock some molecules of 
> interest. The error suggests that the grid is too small to contain the 
> molecule, see below:
> 
>  Elapsed time:  0 seconds
> 
>  ERROR:  Could not complete growth.
>          Confirm grid box is large enough to contain
>          ligand and try increasing max_orients.
> 
> 1 Molecules Processed
> Total elapsed time:     0 seconds
> 
> I have tried increasing max-orients and I have tried expanding the box 
> (in showbox) 25A (which presumably makes the grid larger). I also tried 
> using a tiny molecule as a test to see if it would dock. Nothing seems 
> to work.
> 
> This isn't the first time I've use Dock but I am fairly new to it so any 
> advice you can offer would be much appreciated.

It seems that you have tried the usual suspects:
http://blur.compbio.ucsf.edu/pipermail/dock-fans/2007-January/000852.html
Have you visualized the various pieces: receptor, spheres, grid box ?
Did you use the tutorials as input templates ?

Are you bump filtering and
what version of DOCK are you using ?
http://blur.compbio.ucsf.edu/pipermail/dock-fans/2006-December/000837.html

More details may help track down the problem.

Scott



From sbrozell at scripps.edu  Thu Nov  1 22:39:49 2007
From: sbrozell at scripps.edu (Scott Brozell)
Date: Thu, 1 Nov 2007 21:39:49 -0800 (PST)
Subject: [Dock-fans] amber_score
In-Reply-To: <618618.42726.qm@web57601.mail.re1.yahoo.com>
Message-ID: <Pine.LNX.4.44.0711012122560.20140-100000@loyd.scripps.edu>

Hi,

I answered some of these in the latest 'Combining DOCK with AMBER'
but reproduce them for simplicity.

On Wed, 31 Oct 2007, Francesco Pietra wrote:

> I open a new thread (amber_score) because previous thread (Combining Dock with
> Amber) was becoming too complex, in the hope to get some general guidelines.
> 
> To summarize
> 
> (1) With a pore protein model and a flexible 150-atoms ligand (working with
> Dock6.1 and Chimera 17 Oct build) I could carry out both rigid_docking and
> flex_docking along the default lines of the tutorials. The ligand is seen
> inside the pore, roughly the same view in both cases.

Good.

> (2) As prepared with Chimera, the protein did not allow to get (via dock-prep)
> the prmtop and inpcrd files needed for amber_score. Therefore, I prepared the
> protein with Leap in Amber9, getting prmtop and inpcrd, which allowed a correct
> graphical representation in both Chimera and VMD.

This is not surprising since Amber's LEaP (which is the vehicle for
amberization under the hood of DOCK's prepare_amber.pl)
is the sole mechanism for Amber input preparation.

Here is the usual sequence:
Do docking (along the lines of tutorials
Structure Preparation,
Sphere Generation and Selection,
Grid Generation,
Docking );
Then rescore with Amber_score (along the lines of tutorial
Structure Preparation & AMBER Score ).
Note that Amber_score has receptor input files distinct
from DOCKing receptor input files.

Typically, one has an original pdb which is the starting point for
dock prep, and the resulting mol2 file (from step 2f in the
Structure Preparation tutorial) also can be saved as a pdb;
it is this later pdb that is usually the starting point for
prepare_amber.  However, one can imagine several ways to
obtain the actual receptor input files; for example, one might
take the pdb file from step 2g and use that for prepare_amber.
This would be a simple consistency test for protonation
between the DOCKing receptor and the Amber_score receptor.

It seems to me that you are performing various consistency checks
between DOCKing inputs and Amber_score inputs.
That is a sound approach, but human inspection will play a
dominant role since the DOCK and the Amber packages are
not input compatible (despite the appearance through the
magic of amberization).

[Note to Amber/DOCK superexperts: there are several caveats
that I have ignored for pedagogical purposes.]

> (3) The pdb file for the protein created in Amber9 from prmtop and inpcrd with
> ambpdb proved unsuitable for Chimera dock-prep (standard amino acids were
> mis-viewed as non-standard residues and assigned to Antechamber, which wrongly
> calculated fractional charge for the residues). I changed strategy, loading the
> protein to Chimera from the Leap-created prmtop and inpcrd files. That also
> failed (dock-prep), but for a different reason, Value Error: underlying C++
> Molecule object is missing (I have documented that with an error.log on
> previous thread), which I do not understand.

Please post this small episode to Chimera-users.
This may be an issue of operator error, but maybe not and
anyways it may help them improve robustness.


> Now the files from Leap (2 above) allowed amber_scoring. I carried out both a
> rapid (few minutes) "ligand" option and a longer (4 hours) "everything" option.
> In both cases, from the complex "final_pose.amber.pdb", the ligand is immersed
> into the protein, though not along the pore walls, unlike with the rigid and
> flex docking mentioned in (1). The bad point is that the ligand was broken into
> two major fragments, and minor CH2 fragments. At a rough inspection, the
> protein does not appear to have suffered any major damage, in both options. I
> must add that breakage of the ligand is surprising because it is a thermally
> very stable molecule.


Something is amiss - covalent bonds should not break.
Did you run prepare_amber.pl ?

> I am much confused about the line to follow for amber_score. As carried out
> above, the receptor has no spheres, while the ligand mol2 file was taken from
> the tutorial-like procedures. Does the receptor pass through the stages of
> spheres/grid also for amber_score?

Amber_score only uses a sphere representation of the receptor
for the distance-movable-region.  Otherwise Amber_score does not use
any spheres, and it never uses any grids.
Perhaps my comments to (2) are useful here ?

Scott



From chiendarret at yahoo.com  Fri Nov  2 00:31:52 2007
From: chiendarret at yahoo.com (Francesco Pietra)
Date: Fri, 2 Nov 2007 00:31:52 -0700 (PDT)
Subject: [Dock-fans] amber_score
In-Reply-To: <Pine.LNX.4.44.0711012122560.20140-100000@loyd.scripps.edu>
Message-ID: <657987.56172.qm@web57612.mail.re1.yahoo.com>

Thanks indeed for comments and guidelines. As to amber_score, please see my
answer at penultimate paragraph.

--- Scott Brozell <sbrozell at scripps.edu> wrote:

> Hi,
> 
> I answered some of these in the latest 'Combining DOCK with AMBER'
> but reproduce them for simplicity.
> 
> On Wed, 31 Oct 2007, Francesco Pietra wrote:
> 
> > I open a new thread (amber_score) because previous thread (Combining Dock
> with
> > Amber) was becoming too complex, in the hope to get some general
> guidelines.
> > 
> > To summarize
> > 
> > (1) With a pore protein model and a flexible 150-atoms ligand (working with
> > Dock6.1 and Chimera 17 Oct build) I could carry out both rigid_docking and
> > flex_docking along the default lines of the tutorials. The ligand is seen
> > inside the pore, roughly the same view in both cases.
> 
> Good.
> 
> > (2) As prepared with Chimera, the protein did not allow to get (via
> dock-prep)
> > the prmtop and inpcrd files needed for amber_score. Therefore, I prepared
> the
> > protein with Leap in Amber9, getting prmtop and inpcrd, which allowed a
> correct
> > graphical representation in both Chimera and VMD.
> 
> This is not surprising since Amber's LEaP (which is the vehicle for
> amberization under the hood of DOCK's prepare_amber.pl)
> is the sole mechanism for Amber input preparation.
> 
> Here is the usual sequence:
> Do docking (along the lines of tutorials
> Structure Preparation,
> Sphere Generation and Selection,
> Grid Generation,
> Docking );
> Then rescore with Amber_score (along the lines of tutorial
> Structure Preparation & AMBER Score ).
> Note that Amber_score has receptor input files distinct
> from DOCKing receptor input files.
> 
> Typically, one has an original pdb which is the starting point for
> dock prep, and the resulting mol2 file (from step 2f in the
> Structure Preparation tutorial) also can be saved as a pdb;
> it is this later pdb that is usually the starting point for
> prepare_amber.  However, one can imagine several ways to
> obtain the actual receptor input files; for example, one might
> take the pdb file from step 2g and use that for prepare_amber.
> This would be a simple consistency test for protonation
> between the DOCKing receptor and the Amber_score receptor.
> 
> It seems to me that you are performing various consistency checks
> between DOCKing inputs and Amber_score inputs.
> That is a sound approach, but human inspection will play a
> dominant role since the DOCK and the Amber packages are
> not input compatible (despite the appearance through the
> magic of amberization).
> 
> [Note to Amber/DOCK superexperts: there are several caveats
> that I have ignored for pedagogical purposes.]
> 
> > (3) The pdb file for the protein created in Amber9 from prmtop and inpcrd
> with
> > ambpdb proved unsuitable for Chimera dock-prep (standard amino acids were
> > mis-viewed as non-standard residues and assigned to Antechamber, which
> wrongly
> > calculated fractional charge for the residues). I changed strategy, loading
> the
> > protein to Chimera from the Leap-created prmtop and inpcrd files. That also
> > failed (dock-prep), but for a different reason, Value Error: underlying C++
> > Molecule object is missing (I have documented that with an error.log on
> > previous thread), which I do not understand.
> 
> Please post this small episode to Chimera-users.
> This may be an issue of operator error, but maybe not and
> anyways it may help them improve robustness.
> 
> 
> > Now the files from Leap (2 above) allowed amber_scoring. I carried out both
> a
> > rapid (few minutes) "ligand" option and a longer (4 hours) "everything"
> option.
> > In both cases, from the complex "final_pose.amber.pdb", the ligand is
> immersed
> > into the protein, though not along the pore walls, unlike with the rigid
> and
> > flex docking mentioned in (1). The bad point is that the ligand was broken
> into
> > two major fragments, and minor CH2 fragments. At a rough inspection, the
> > protein does not appear to have suffered any major damage, in both options.
> I
> > must add that breakage of the ligand is surprising because it is a
> thermally
> > very stable molecule.
> 
> 
> Something is amiss - covalent bonds should not break.
> Did you run prepare_amber.pl ?

Yes, I did. The procedure is reported to allow checking if there were opetator
mistakes before running prepare_amber.pl:

(1) After several adjustments (HID in place of HIS, GLH in place of GLU and
swap of oxygen names and rename H, etc., the protein was fed to Leap in Amber 9
(leaprc.ff99SB), whereby missing heavy atoms were added where I had placed TER
records, and "38 H / lone pairs" were also added. I could save prmtop and
inpcrd, being advised that there are 4 separate chains with N and C termini.

(2) From these prmtop and inpcrd  I got the rec.pdb file using ambpdb program.

(3) I run 

prepare_amber.pl lig.mpl2 rec.pdb

where lig.mol2 had been obtained along tutorial-like dock procedures.

The rec.lig.1.final_pose.amber.pdb was defective as to the ligand as reported
above. Messing of coordinate ligand must have occurred. Values must be wrong,
otherwise the section for the ligand is correctly ordered at the end of the pdb
file, separated by "TER" from the standard residues and ending with "TER".

I checked that

lig.1.final_pose.amber.pdb

showed the structure of the ligand intact.

All that occurred with either "ligand" or "everything" option in dock.in, which
was otherwise like on amber_score tutorial.

Either I did some operator mistake, or there may be problems with large ligands
in amber_score.

Thanks

francesco






> > I am much confused about the line to follow for amber_score. As carried out
> > above, the receptor has no spheres, while the ligand mol2 file was taken
> from
> > the tutorial-like procedures. Does the receptor pass through the stages of
> > spheres/grid also for amber_score?
> 
> Amber_score only uses a sphere representation of the receptor
> for the distance-movable-region.  Otherwise Amber_score does not use
> any spheres, and it never uses any grids.
> Perhaps my comments to (2) are useful here ?
> 
> Scott
> 
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

From chiendarret at yahoo.com  Fri Nov  2 03:28:16 2007
From: chiendarret at yahoo.com (Francesco Pietra)
Date: Fri, 2 Nov 2007 03:28:16 -0700 (PDT)
Subject: [Dock-fans] amber_score
In-Reply-To: <Pine.LNX.4.44.0711012122560.20140-100000@loyd.scripps.edu>
Message-ID: <616671.65215.qm@web57605.mail.re1.yahoo.com>

I am hurriedly replying the second time this message to inform that the
suggestion "take the pdb file from step 2g and use that for prepare_amber"
solved the problem, as reported below (while pdb from step 2f failed).

--- Scott Brozell <sbrozell at scripps.edu> wrote:

> Hi,
> 
> I answered some of these in the latest 'Combining DOCK with AMBER'
> but reproduce them for simplicity.
> 
> On Wed, 31 Oct 2007, Francesco Pietra wrote:
> 
> > I open a new thread (amber_score) because previous thread (Combining Dock
> with
> > Amber) was becoming too complex, in the hope to get some general
> guidelines.
> > 
> > To summarize
> > 
> > (1) With a pore protein model and a flexible 150-atoms ligand (working with
> > Dock6.1 and Chimera 17 Oct build) I could carry out both rigid_docking and
> > flex_docking along the default lines of the tutorials. The ligand is seen
> > inside the pore, roughly the same view in both cases.
> 
> Good.
> 
> > (2) As prepared with Chimera, the protein did not allow to get (via
> dock-prep)
> > the prmtop and inpcrd files needed for amber_score. Therefore, I prepared
> the
> > protein with Leap in Amber9, getting prmtop and inpcrd, which allowed a
> correct
> > graphical representation in both Chimera and VMD.
> 
> This is not surprising since Amber's LEaP (which is the vehicle for
> amberization under the hood of DOCK's prepare_amber.pl)
> is the sole mechanism for Amber input preparation.
> 
> Here is the usual sequence:
> Do docking (along the lines of tutorials
> Structure Preparation,
> Sphere Generation and Selection,
> Grid Generation,
> Docking );
> Then rescore with Amber_score (along the lines of tutorial
> Structure Preparation & AMBER Score ).
> Note that Amber_score has receptor input files distinct
> from DOCKing receptor input files.
> 
> Typically, one has an original pdb which is the starting point for
> dock prep, and the resulting mol2 file (from step 2f in the
> Structure Preparation tutorial) also can be saved as a pdb;
> it is this later pdb that is usually the starting point for
> prepare_amber.

That pdb resulted in the same failure to create prmtop and inpcrd files. The
log told that many standard residues did not have a valid name.



>  However, one can imagine several ways to
> obtain the actual receptor input files; for example, one might
> take the pdb file from step 2g and use that for prepare_amber.
> This would be a simple consistency test for protonation
> between the DOCKing receptor and the Amber_score receptor.

That proved to work with my protein. The noH.pdb from the suggested step 2g,
together with the same mol2 file for the ligand, allowed prepare_amber.pl to
produce valid prmtop and inpcrd files. (As all warning suggested, it was a
problem of protonation state. With Leap in Amber9 I did not succeed to get back
compatibility of files with Chimera; now amber_prepare.pl has done the Leap
work for me). So that, I have now hierarchical continuity in scoring and
rescoring. Actually, the rec.pdb version used in the scoring is not the best
version, still containing long bonds (I had not yet placed the TER records to
get rid of them). It still also contains a molecule of HOH inside the pore (in
the real world, the pore should contain much water and K+ ions that I
artificially remove for docking; one might try to leave also K+). At any event,
from now on it is to the operator to avoid mistakes.
Thanks
francesco



> 
> It seems to me that you are performing various consistency checks
> between DOCKing inputs and Amber_score inputs.
> That is a sound approach, but human inspection will play a
> dominant role since the DOCK and the Amber packages are
> not input compatible (despite the appearance through the
> magic of amberization).
> 
> [Note to Amber/DOCK superexperts: there are several caveats
> that I have ignored for pedagogical purposes.]
> 
> > (3) The pdb file for the protein created in Amber9 from prmtop and inpcrd
> with
> > ambpdb proved unsuitable for Chimera dock-prep (standard amino acids were
> > mis-viewed as non-standard residues and assigned to Antechamber, which
> wrongly
> > calculated fractional charge for the residues). I changed strategy, loading
> the
> > protein to Chimera from the Leap-created prmtop and inpcrd files. That also
> > failed (dock-prep), but for a different reason, Value Error: underlying C++
> > Molecule object is missing (I have documented that with an error.log on
> > previous thread), which I do not understand.
> 
> Please post this small episode to Chimera-users.
> This may be an issue of operator error, but maybe not and
> anyways it may help them improve robustness.
> 
> 
> > Now the files from Leap (2 above) allowed amber_scoring. I carried out both
> a
> > rapid (few minutes) "ligand" option and a longer (4 hours) "everything"
> option.
> > In both cases, from the complex "final_pose.amber.pdb", the ligand is
> immersed
> > into the protein, though not along the pore walls, unlike with the rigid
> and
> > flex docking mentioned in (1). The bad point is that the ligand was broken
> into
> > two major fragments, and minor CH2 fragments. At a rough inspection, the
> > protein does not appear to have suffered any major damage, in both options.
> I
> > must add that breakage of the ligand is surprising because it is a
> thermally
> > very stable molecule.
> 
> 
> Something is amiss - covalent bonds should not break.
> Did you run prepare_amber.pl ?
> 
> > I am much confused about the line to follow for amber_score. As carried out
> > above, the receptor has no spheres, while the ligand mol2 file was taken
> from
> > the tutorial-like procedures. Does the receptor pass through the stages of
> > spheres/grid also for amber_score?
> 
> Amber_score only uses a sphere representation of the receptor
> for the distance-movable-region.  Otherwise Amber_score does not use
> any spheres, and it never uses any grids.
> Perhaps my comments to (2) are useful here ?
> 
> Scott
> 
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

From chiendarret at yahoo.com  Fri Nov  2 09:41:36 2007
From: chiendarret at yahoo.com (Francesco Pietra)
Date: Fri, 2 Nov 2007 09:41:36 -0700 (PDT)
Subject: [Dock-fans] Fixing protonation state
In-Reply-To: <472A52D8.60700@cgl.ucsf.edu>
Message-ID: <404442.11141.qm@web57605.mail.re1.yahoo.com>


--- "John J. Irwin" <jji at cgl.ucsf.edu> wrote:

> Francesco
> 
> Francesco Pietra wrote:
> > Hi John:
> > My question was not restricted to the case in point, and nature is not
> faced by
> > the limitations the computational medicinal chemist is. There are a number
> of
> > dockings in nature - known or elusive - where the ligand is large and
> flexible.
> > My question was, is any chance to identify the right pocket when the ligand
> is
> > large and flexible? By DOCK or any other docking program?
> >   
> Identifying the binding site is of course possible, using mutagenesis,
> crystallography, and all that. We start with docking once we know the
> binding site. Are you asking if docking can be used to rank binding
> sites by the likelihood that one binds a particular ligand? Sure, why
> not, give it a try. 

That is just what I am doing. The experimental results are controversial, so
that I wanted to predict from DOCK. I know that is is particularly difficult to
predict what is not known. However, if not else, this first-time approach to
DOCK will introduce me to docking. How could I build a complex for Amber
otherwise?


>But given the famously high false positive rate of docking, the odds are
>against you.

Is any criterion to detect, or suspect (on the basis of DOCK + Amber) false
positives? 

Thanks
francesco 


> > That computational minimization of large, flexible molecules remains a
> > challenge, we know.
> >
> > Thanks
> > francesco
> >
> > --- "John J. Irwin" <jji at cgl.ucsf.edu> wrote:
> >
> >   
> >> Hi Francesco
> >>
> >> Here are three arguments to try to convince you that big floppy
> >> molecules make poor candidates for docking.
> >>
> >> [I was unaware of the target of that compound, and based my comments
> >> about the unsuitability for docking purely upon the molecule itself. ]
> >>
> >> 1. The number of conformations to be sampled goes up exponentially as a
> >> function of the number of rotatable bonds. Let's assume three
> >> conformations around each bond for the sake of simplicity. Thus 3^7 =
> >> 2187 , 3^10 = 59,049 and  3^17 = 129,140,163. These are the number of
> >> conformations to be sampled, even by very coarse sampling, for molecules
> >> with 7, 10 and 17 rotatable bonds, respectively. That's very coarse,
> >> fix-interval sampling. At 1 second per conformation (and that's
> >> considered fast by the standards of the field) that makes 4.1 years for
> >> 17 rotatable bonds. for one *%^* molecule.
> >>
> >> 2. If you have a molecule like the one suggested by Asdrubal, a
> >> "dumbell" with 19 bonds between the aromatics at the end, then a
> >> movement of just a degree or two around the central bond can result in a
> >> relative shift of the extremities (and thus the overall shape of the
> >> molecule) by 5A or more. This hypersensitivity of shape to central bonds
> >> means that you cannot hope to sample all the "right" conformation given
> >> fixed increment angle sampling, which is all you can afford to do. If
> >> you try to sample more finely, say 10 angles around a bond instead of 3,
> >> then you're stuck with 10^17 conformations. Even being clever and doing
> >> 10 points around central bonds decreasing to 3 points at the extremities
> >> would necessitate sampling an implausibly large number of conformations.
> >>
> >> 3. This molecule has terrible entropy problems. It is common practice to
> >> remove molecules from virtual screening libraries with more than 6
> >> methylene's in a row, for this reason. Large numbers of rotatable bonds
> >> tend to have bioavailability problems too (Veber, J Med Chem, 2002), in
> >> case you are still unconvinced.
> >>
> >> By the way, there are many drugs that break the rules I just laid
> >> outlined. I am not saying these molecules cannot be drugs. I am saying
> >> they are problematic candidates for molecular docking, and very likely,
> >> as *starting points* for ligand discovery.
> >>
> >> I hope this is clear and helpful.
> >>
> >> John
> >>
> >>
> >>
> >> Francesco Pietra wrote:
> >>     
> >>> Is your skepticism only about the precision of docking (with large,
> >>>       
> >> flexible
> >>     
> >>> molecules) or is any evidence that also the region of receptor where
> >>>       
> >> docking is
> >>     
> >>> found may be false? E.g. helix S5 instead of S6 in a pore?
> >>> Thanks
> >>> francesco pietra
> >>>
> >>> --- "John J. Irwin" <jji at cgl.ucsf.edu> wrote:
> >>>
> >>>   
> >>>       
> >>>> Hi Asdrubal
> >>>>
> >>>> That molecule has more rotatable bonds (13 in a row, 17 total, + limited
> >>>> sampling on the 2 amides) than I feel comfortable with. It also has
> >>>> molecular weight > 600. These are two reason why the ZINC upload server
> >>>> just won't take it. I have to draw the line somewhere, and I regret to
> >>>> say you have hit it.
> >>>>
> >>>> I would be skeptical of anyone who docks a molecule having 17 (or even
> >>>> 13) rotatable bonds and gets the crystallographic pose within 2A rmsd.
> >>>> Actually, my skepticism starts at around 8 rotatable bonds, but I keep
> >>>> it mostly to myself till we get past 12. ;-)
> >>>>
> >>>> Almost for sure, you are trying to dock into two distinct pockets, and
> >>>> the long aliphatic chain is a linker between them. My suggestion is
> >>>> therefore to dock each end separately. Shoot for something with 7
> >>>> rotatable bonds, even a bit less if you can. Then you can model in the
> >>>> rest of the linker between them.
> >>>>
> >>>> Good luck, and sorry to disappoint.
> >>>>
> >>>> John
> >>>>
> >>>>
> >>>> burgosgu at ualberta.ca wrote:
> >>>>     
> >>>>         
> >>>>> Hi everybody,
> >>>>>
> >>>>> I need to have a compound correctly protonated to dock it. I tried to  
> >>>>> use the resource of
> >>>>> "upload sets" of ZINC, but it seems that it does not have the required 
> 
> >>>>> charactersitics of
> >>>>> bioavailability and non-toxicity, because it gives me no output as it  
> >>>>> did with other
> >>>>> compounds.
> >>>>>
> >>>>> The smile for this compound is:
> >>>>>
> >>>>>           
> >> C1=C(C=CC2=C1C(=C[N]2)CC(=O)NCCCNCCCCNCCCNC(=O)CC3=C[N]C4=C3C=C(C=C4)Br)Br
> >>     
> >>>>> Any suggestions??
> >>>>>
> >>>>> THANKS,
> >>>>>
> >>>>> Asdrubal
> >>>>>
> >>>>> _______________________________________________
> >>>>> Dock-fans mailing list
> >>>>> Dock-fans at docking.org
> >>>>> http://blur.compbio.ucsf.edu/mailman/listinfo/dock-fans
> >>>>>   
> >>>>>       
> >>>>>           
> >>>> _______________________________________________
> >>>> Dock-fans mailing list
> >>>> Dock-fans at docking.org
> >>>> http://blur.compbio.ucsf.edu/mailman/listinfo/dock-fans
> >>>>
> >>>>     
> >>>>         
> >>> __________________________________________________
> >>> Do You Yahoo!?
> >>> Tired of spam?  Yahoo! Mail has the best spam protection around 
> >>> http://mail.yahoo.com 
> >>>   
> >>>       
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around 
> > http://mail.yahoo.com 
> >   
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

From jji at cgl.ucsf.edu  Fri Nov  2 09:49:55 2007
From: jji at cgl.ucsf.edu (John J. Irwin)
Date: Fri, 02 Nov 2007 09:49:55 -0700
Subject: [Dock-fans] Fixing protonation state
In-Reply-To: <404442.11141.qm@web57605.mail.re1.yahoo.com>
References: <404442.11141.qm@web57605.mail.re1.yahoo.com>
Message-ID: <472B5533.9040203@cgl.ucsf.edu>

Francesco
>   
>> But given the famously high false positive rate of docking, the odds are
>> against you.
>>     
>
> Is any criterion to detect, or suspect (on the basis of DOCK + Amber) false
> positives? 
>   
That would be very useful! I can see how to rule *out* compounds by
coding up the same rules of thumb we use when looking at top scoring
hits (good overall steric, hydrophobic and shape complementarity,
penalize stranded polarity, and missed opportunities in the
protein-ligand complex. But I see this more as "getting rid of junk"
rather than pretending to scrupulously eliminate false positives.

John


From sbrozell at scripps.edu  Fri Nov  2 19:14:17 2007
From: sbrozell at scripps.edu (Scott Brozell)
Date: Fri, 2 Nov 2007 18:14:17 -0800 (PST)
Subject: [Dock-fans] RMSD
In-Reply-To: <59840f5f0710311038j68bc4713r2f91967add6b9db5@mail.gmail.com>
Message-ID: <Pine.LNX.4.44.0711021720560.20140-100000@loyd.scripps.edu>

Hi,

On Wed, 31 Oct 2007, Imtiaz M. wrote:

> In my dock.in file i have selected the RMSD as yes. now in my
> dock_ranked.mol2 I am getting a value RMSD 0.98786
> 
> Can any body tell me what that RMSD actually mean? i.e This root mean
> square deviation is between what and what?

Heavy atom RMSD between the final molecule pose and its initial structure.
http://dock.compbio.ucsf.edu/DOCK_6/dock6_manual.htm#LigandFileInput

Scott



From burgosgu at ualberta.ca  Sat Nov  3 14:14:40 2007
From: burgosgu at ualberta.ca (burgosgu at ualberta.ca)
Date: Sat, 03 Nov 2007 15:14:40 -0600
Subject: [Dock-fans] Fixing protonation state
In-Reply-To: <472B5533.9040203@cgl.ucsf.edu>
References: <404442.11141.qm@web57605.mail.re1.yahoo.com>
	<472B5533.9040203@cgl.ucsf.edu>
Message-ID: <20071103151440.srt4xonp44og04kc@webmail.ualberta.ca>


Hi John and Francesco,

I guess it's time for me to write. Thanks a lot for your explanations.

Well, actually that compound has been found to be the most powerful in  
vitro inhibitor for the enzyme with which I'm working. I wanted to  
dock it as a validation for the parameters I chose for the docking  
program (AutoDock). If the score thrown by AutoDock for this compound  
was higher than for most of the ligands then I could assume that the  
predictive ability of AutoDock with those parameters is fairly good. I  
actually docked this compound with very good results (predicted energy  
of binding = -10.83 kcal/mol). The structure I used was one that I  
drew myself with Pymol builder based on the paper that mentioned that  
it was a powerful inhibitor. But, I realized that I couldn't compare  
this value with the  predicted energies of binding for my drug  
candidates because they were all ZINC structures. So, the ZINC  
compounds had a correct protonation state while my compound didn't.  
That's why I tried to use ZINC upload sets resource.

So, in my particular case it would be very helpful that ZINC gave back  
a structure with the correct protonation, probably with a note that  
the compound broke the rules.

Thanks again,

Asdrubal


Quoting "John J. Irwin" <jji at cgl.ucsf.edu>:

> Francesco
>>
>>> But given the famously high false positive rate of docking, the odds are
>>> against you.
>>>
>>
>> Is any criterion to detect, or suspect (on the basis of DOCK + Amber) false
>> positives?
>>
> That would be very useful! I can see how to rule *out* compounds by
> coding up the same rules of thumb we use when looking at top scoring
> hits (good overall steric, hydrophobic and shape complementarity,
> penalize stranded polarity, and missed opportunities in the
> protein-ligand complex. But I see this more as "getting rid of junk"
> rather than pretending to scrupulously eliminate false positives.
>
> John
>
>



From chiendarret at yahoo.com  Mon Nov  5 03:00:28 2007
From: chiendarret at yahoo.com (Francesco Pietra)
Date: Mon, 5 Nov 2007 03:00:28 -0800 (PST)
Subject: [Dock-fans] "Atom valence violated" from LEaP
Message-ID: <950069.9840.qm@web57604.mail.re1.yahoo.com>

I am using DOCK6.1 and Amber9 with a pore protein model.

>From the model deprived of the single (natural) residue HOH from the pore, I
could carry out the whole sequence grid scoring and amber rescoring. The only
way I found to get the whole sequence passing, was by removing all hydrogen
atoms from the model, placing TER records to get rid of long (50A) bonds, and
let LEaP build the prmtop and inpcrd files, which could be taken from Chimera
1.2422, 17 Oct07 build for DockPrep, etc. 

Now I wanted to repeat all the above sequence with the natural residue HOH in
place, separated by a TER record. Here is the last portion of the pdb file now
used for LEaP:

ATOM   3412  O   THR X 444     -15.798  15.199  24.830  0.00  0.00           O

TER    3413      THR X 444

HETATM 3414  O   HOH X 448      -0.036   0.094  -2.262  0.00  0.00           O

END

Now, LEaP did the job, though grid generation in Chimera complained (on loading
the mol2 file generated from these prmtop and inpcrd files) that 

WARNING: assign_vdw_labels: Atom valence violated for xxxx.inpcrd
*** WAT445 445 H1 6886
Error in reading receptor

Chimera was right. The internal water residue was now triangulated. The H-H
bond error was not in creating the mol2 file with DocPrep: loading the prmtop
and inpcrd files from LEaP to either Chimera or VMD shows that the water
molecule is triangulated, three bonds, O-H, O-H, and H-H. The error was in LEaP
(or, obviously and most likely, in the operator).


The last portion of the coordinate section of the mol2 reads:

 6884 OXT       -13.9375   14.3278   24.9443 O.co2   444 THR444     -0.8044

 6885 O          -0.0360    0.0940   -2.2620 O.t3p   445 WAT445     -0.8340

 6886 H1          0.9212    0.0940   -2.2620 H.t3p   445 WAT445      0.4170

 6887 H2         -0.2760    1.0206   -2.2620 H.t3p   445 WAT445      0.4170

and that mol2 ends with:

   443 GLU443   6857 RESIDUE           4 A     GLU     2

   444 THR444   6872 RESIDUE           4 A     THR     1

   445 WAT445   6886 RESIDUE           4 A     WAT     0 ROOT



Must add that the model before removing all hydrogen atoms showed the HOH
residue correctly, i.e. two bonds.

Perhaps the protocol to follow is different from the one I followed. Removing
all protein hydrogens and leaving res HOH intact? How? Or any better idea.

Thanks 

francesco pietra

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

From biobrain at gmail.com  Mon Nov  5 05:20:14 2007
From: biobrain at gmail.com (Imtiaz M.)
Date: Mon, 5 Nov 2007 13:20:14 +0000
Subject: [Dock-fans] ranked.mol2
Message-ID: <59840f5f0711050520v71f9675eye7b04cfd26c0ac16@mail.gmail.com>

Dear All,

I am using the following options

num_scored_conformers_written                        20
cluster_conformations                                        yes
cluster_rmsd_threshold                                      2.0
rank_ligands                                                       yes
max_ranked_ligands                                           500


Please tell me how I can get clusters of the different possible
solutions. How I can select Top 20 solution for my docking experiment.

From gajuguard-dock at yahoo.co.in  Mon Nov  5 13:29:41 2007
From: gajuguard-dock at yahoo.co.in (gajuguard-dock at yahoo.co.in)
Date: Mon, 5 Nov 2007 21:29:41 +0000 (GMT)
Subject: [Dock-fans] gajuguard-dock@yahoo.co.in
Message-ID: <866679.15618.qm@web7912.mail.in.yahoo.com>

gajuguard-dock at yahoo.co.in
       
---------------------------------
 Why delete messages? Unlimited storage is just a click away.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://blur.compbio.ucsf.edu/pipermail/dock-fans/attachments/20071105/3eb3fbad/attachment.html 

From snoze.pa at gmail.com  Tue Nov  6 08:04:02 2007
From: snoze.pa at gmail.com (snoze pa)
Date: Tue, 6 Nov 2007 10:04:02 -0600
Subject: [Dock-fans] HEM in DOCK 6
Message-ID: <10f848910711060804l62b8b422n54f08799e8a69619@mail.gmail.com>

Hi, I am new in this mailing list but found chimera more useful than any
other software. I was building a protein that contain HEME. When I was
calculating the charge using chimera interface, then it is asking for
HEM[FE] and HEM[nonFE] formal charge. I know chimera is using MMTK and AMBER
forcefield. If I will give the default value then it is assigning +2 charge
to Fe, which is not a match based on AMBER forcefield.  Meanwhile I try to
change the Formal charge manually, but still it gives the same +2 for Fe.
Anybody used chimera to prepare a protein having heme for dock or geometry
build.

 My another question is: Is it possible in chimera to merge non polar
hydrogen charges on the heavy atoms, the technique used in autodock.

I will highly appreciate your help and suggestions in this matter.
thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://blur.compbio.ucsf.edu/pipermail/dock-fans/attachments/20071106/8add845a/attachment.html 

From sudmukh at yahoo.com  Tue Nov  6 08:20:14 2007
From: sudmukh at yahoo.com (Sudipto Mukherjee)
Date: Tue, 6 Nov 2007 08:20:14 -0800 (PST)
Subject: [Dock-fans] ranked.mol2
Message-ID: <280991.81692.qm@web36715.mail.mud.yahoo.com>

Imtiaz,

You could run dock with 'num_scored_conformers_written' set to a high number (e.g. 500) with clustering turned on. Then you can select the top 20 or so clusterheads from the mol2 file using a script, or by running dock again and using max_ligands=20.
 
Regards
Sudipto Mukherjee
Graduate Student, Robert C. Rizzo Lab
Dept. of Applied Math & Statistics, Stony Brook University

----- Original Message ----
From: Imtiaz M. <biobrain at gmail.com>
To: dock-fans at docking.org
Sent: Monday, November 5, 2007 8:20:14 AM
Subject: [Dock-fans] ranked.mol2


Dear All,

I am using the following options

num_scored_conformers_written                        20
cluster_conformations                                        yes
cluster_rmsd_threshold                                      2.0
rank_ligands                                                       yes
max_ranked_ligands                                           500


Please tell me how I can get clusters of the different possible
solutions. How I can select Top 20 solution for my docking experiment.
_______________________________________________
Dock-fans mailing list
Dock-fans at docking.org
http://blur.compbio.ucsf.edu/mailman/listinfo/dock-fans





__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://blur.compbio.ucsf.edu/pipermail/dock-fans/attachments/20071106/29764d9b/attachment.html 

From lujing1999 at 126.com  Wed Nov  7 00:20:04 2007
From: lujing1999 at 126.com (=?gb2312?Q?=C2=B9=BE=A7jinger.Lu?=)
Date: Wed, 7 Nov 2007 16:20:04 +0800 (CST)
Subject: [Dock-fans] a problem about sphen
Message-ID: <47317534.00006A.04693@bj126app18.126.com>

 Hi, dcock-fans, I met a problem when a run sphgen, and I have no idea how it happened , I email here to ask for help, and the following is the output message :
[jfpei at sunway 2_site]$ ../../bin/sphgen 
forrtl: severe (64): input conversion error, unit 2, file /gdata2/jfpei/lujing/docknew/dock6_mpich/1G3J/2_site/temp2.sph
Image              PC        Routine            Line        Source             
sphgen             08095B98  Unknown               Unknown  Unknown
sphgen             08095690  Unknown               Unknown  Unknown
sphgen             08074AB1  Unknown               Unknown  Unknown
sphgen             08050740  Unknown               Unknown  Unknown
sphgen             08050BE3  Unknown               Unknown  Unknown
sphgen             08060F04  Unknown               Unknown  Unknown
sphgen             0805FEDD  Unknown               Unknown  Unknown
sphgen             0804CE42  Unknown               Unknown  Unknown
sphgen             0804A973  Unknown               Unknown  Unknown
sphgen             080555DD  Unknown               Unknown  Unknown
Unknown            42017499  Unknown               Unknown  Unknown
sphgen             0804A071  Unknown               Unknown  Unknown

   --
jinger.Lu
TEL:13488692141
QQ: 58187898
MSN:zhishang_feng at hotmail.com
email:lujing1999 at 126.com



? ? ? ?? ? ? ? 500 ? ? ? ? ? ? ? >> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://blur.compbio.ucsf.edu/pipermail/dock-fans/attachments/20071107/17e4868a/attachment-0001.html 

From chiendarret at yahoo.com  Wed Nov  7 07:30:41 2007
From: chiendarret at yahoo.com (Francesco Pietra)
Date: Wed, 7 Nov 2007 07:30:41 -0800 (PST)
Subject: [Dock-fans] Segmentation fault on running docking
Message-ID: <52335.6927.qm@web57614.mail.re1.yahoo.com>

Having solved empirically, whitout external help, the problem (posted on last
week-end) of running grid when residue HOH is present within the pore, I am now
faced by segfault in running rigid docking. That occurs both on parallel and
serial run. It also occurs with previous files for the protein without HOH,
where both rigid and flex run OK on mpirun -np 4. Thus, it seems that there is
now something wrong with dock6 and I don't understand what. 

Before these unsuccessful attempts, I had
(1) Unsuccessfully tried to recompile Antechamber with new respgen.c (on
Amber9), which did not affect previous compilation.
(2) Carried out "apt-get update" to Debian Linux amd64 etch (i.e., stable)
without taking notice of the little that was affected.
---------------

While running:

mpirun -np 4 -i rigid.in -o rigid.out

the process halted (rigid_scored.mol2 0 bytes) because

Initialing MPI routines ....
[deb64:03540] *** Process received signal ***
[deb64:03540] Signal: Segmentation fault (11)
[deb64:03540] Signal code: Address not mapped (1)
[deb64:03540] Failing at address: 0x2b9ef5691000
dock6.mpi[3540]: segfault at 00002b9ef56910000 rip 0000000000447b1b rsp
00007fff43c137b0 error 6
[deb64:03540] [0] /lib/libthread.so.0 [0x2b9e681bc410]
[deb64:03540] [1] dock6.mpi (_ZN60rient12match_ligandER7DOCKMol+0x40b)
[0x447b1b]
[deb64:03540] [2] dock6.mpi (main+0xaf5) [0x42cc75]
[deb64:03540] [3] dock6.mpi /lib/libc.so.6(__libc_start_main+0xda)
[0x2b9e682e14ca]
[deb64:03540] [4] dock6.mpi (__gxx_personality_v0+0xc2) [0x41b4ea]
[deb64:03540] *** End of error message ***
mpirun noticed that jpb rank 0 with PID 3537 on node deb64 exited on signal 15
(Terminated).
3 additional processes aborted (not shown)
---------------------------

I tried also flex with the protein endowed of HOH

mpirun -np 4 -i anchor_and_grow.in -o anchor_and_grow.out 2>&1 | tee errors.out

with an even more complex of libraries and mpi problems (see please attachment.
------------------

Parallel dock had so far run correctly. DOCK6.1 had been compiled with:

./configure gnu parallel
MPICH_HOME=/usr/local
export MPICH_HOME
make dock

I have now unsuccessfully deselected $AMBERHOME in my .bashrc, as expected
because it should be only relevant to running amber_score. I did not change
otherwise my .bashrc, where

DOCK_HOME=/usr/local/dock6
PATH=$PATH:$DOCK_HOME/bib; export DOCK_HOME PATH

MPI_HOME=/usr/local
export MPI_home

I have now tried the test

cd test/mpi
make 2>&1 | tee test_parallel.out
which passed OK.

Also:

which mpicxx
/usr/local/bin/mpicxx

Also:


updatedb
locate mpi.h
/usr/include/sc/util/group/memmtmpi.h
/usr/include/sc/util/group/messmpi.h
/usr/dock6/src/dock/base_mpi.h
/usr/local/include/mpi.h
/usr/local/openmpi-1.2.3/ompi/include/mpi.h
/usr/local/openmpi-1.2.3/ompi/include/mpi.h.in
/usr/local/openmpi-1.2.3/ompi/mpi/f77/prototypes_mpi.h

-----------------------
Also on serial trial, segfault:

dock6 -i rigid.in -o rigid out

dock6[3602]: segfault at 00002b4da6e0c000 rip 000000000043ffd1 rsp
00007fff86593bc0 error 6
Segmentation fault
---------------------------


Thanks
francesco pietra





__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: errors.out.tar.bz2
Type: application/x-bzip
Size: 767 bytes
Desc: pat110858221
Url : http://blur.compbio.ucsf.edu/pipermail/dock-fans/attachments/20071107/13b481a1/attachment.bin 

From sbrozell at scripps.edu  Wed Nov  7 09:05:05 2007
From: sbrozell at scripps.edu (Scott Brozell)
Date: Wed, 7 Nov 2007 09:05:05 -0800 (PST)
Subject: [Dock-fans] Segmentation fault on running docking
In-Reply-To: <52335.6927.qm@web57614.mail.re1.yahoo.com>
Message-ID: <Pine.LNX.4.44.0711070849460.20140-100000@loyd.scripps.edu>

Hi,

On Wed, 7 Nov 2007, Francesco Pietra wrote:

> Having solved empirically, whitout external help, the problem (posted on last
> week-end) of running grid when residue HOH is present within the pore, I am now


Please post a reply to that thread with the problem resolution.

> faced by segfault in running rigid docking. That occurs both on parallel and
> serial run. It also occurs with previous files for the protein without HOH,
> where both rigid and flex run OK on mpirun -np 4. Thus, it seems that there is
> now something wrong with dock6 and I don't understand what. 
> 
> Before these unsuccessful attempts, I had
> (1) Unsuccessfully tried to recompile Antechamber with new respgen.c (on
> Amber9), which did not affect previous compilation.
> (2) Carried out "apt-get update" to Debian Linux amd64 etch (i.e., stable)
> without taking notice of the little that was affected.
> ---------------
> 
> While running:
> 
> mpirun -np 4 -i rigid.in -o rigid.out
> 
> the process halted (rigid_scored.mol2 0 bytes) because
> 
> Initialing MPI routines ....
> [deb64:03540] *** Process received signal ***
> [deb64:03540] Signal: Segmentation fault (11)
> [deb64:03540] Signal code: Address not mapped (1)
> [deb64:03540] Failing at address: 0x2b9ef5691000
> dock6.mpi[3540]: segfault at 00002b9ef56910000 rip 0000000000447b1b rsp
> 00007fff43c137b0 error 6
> [deb64:03540] [0] /lib/libthread.so.0 [0x2b9e681bc410]
> [deb64:03540] [1] dock6.mpi (_ZN60rient12match_ligandER7DOCKMol+0x40b)
> [0x447b1b]
> [deb64:03540] [2] dock6.mpi (main+0xaf5) [0x42cc75]
> [deb64:03540] [3] dock6.mpi /lib/libc.so.6(__libc_start_main+0xda)
> [0x2b9e682e14ca]
> [deb64:03540] [4] dock6.mpi (__gxx_personality_v0+0xc2) [0x41b4ea]
> [deb64:03540] *** End of error message ***
> mpirun noticed that jpb rank 0 with PID 3537 on node deb64 exited on signal 15
> (Terminated).
> 3 additional processes aborted (not shown)
> ---------------------------
> 
> I tried also flex with the protein endowed of HOH
> 
> mpirun -np 4 -i anchor_and_grow.in -o anchor_and_grow.out 2>&1 | tee errors.out
> 
> with an even more complex of libraries and mpi problems (see please attachment.
> ------------------
> 
> Parallel dock had so far run correctly. DOCK6.1 had been compiled with:
> 
> ./configure gnu parallel
> MPICH_HOME=/usr/local
> export MPICH_HOME
> make dock
> 
> I have now unsuccessfully deselected $AMBERHOME in my .bashrc, as expected
> because it should be only relevant to running amber_score. I did not change
> otherwise my .bashrc, where
> 
> DOCK_HOME=/usr/local/dock6
> PATH=$PATH:$DOCK_HOME/bib; export DOCK_HOME PATH
> MPI_HOME=/usr/local
> export MPI_home
> 
> I have now tried the test
> cd test/mpi
> make 2>&1 | tee test_parallel.out
> which passed OK.
> 
> Also:
> which mpicxx
> /usr/local/bin/mpicxx
> 
> Also:
> updatedb
> locate mpi.h
> /usr/include/sc/util/group/memmtmpi.h
> /usr/include/sc/util/group/messmpi.h
> /usr/dock6/src/dock/base_mpi.h
> /usr/local/include/mpi.h
> /usr/local/openmpi-1.2.3/ompi/include/mpi.h
> /usr/local/openmpi-1.2.3/ompi/include/mpi.h.in
> /usr/local/openmpi-1.2.3/ompi/mpi/f77/prototypes_mpi.h
> 
> -----------------------
> Also on serial trial, segfault:
> 
> dock6 -i rigid.in -o rigid out
> 
> dock6[3602]: segfault at 00002b4da6e0c000 rip 000000000043ffd1 rsp
> 00007fff86593bc0 error 6
> Segmentation fault
> ---------------------------

It is curious that the dock mpi test is passing, but other dock runs
are failing.  However, the failures suggest a machine problem.
If you have updated the operating system then it is likely that
executables will at least have to be re-linked and maybe re-compiled.
If you are a miser then try re-linking.
Otherwise rebuild dock:
cd install
# save any special config.h's
make distclean
./configure ...
make install
# build parallel

Scott



From sbrozell at scripps.edu  Wed Nov  7 09:28:54 2007
From: sbrozell at scripps.edu (Scott Brozell)
Date: Wed, 7 Nov 2007 09:28:54 -0800 (PST)
Subject: [Dock-fans] a problem about sphen
In-Reply-To: <47317534.00006A.04693@bj126app18.126.com>
Message-ID: <Pine.LNX.4.44.0711070912510.20140-100000@loyd.scripps.edu>

Hi,

On Wed, 7 Nov 2007, [gb2312] ????jinger.Lu wrote:

>  Hi, dcock-fans, I met a problem when a run sphgen, and I have no idea how it happened , I email here to ask for help, and the following is the output message :
> [jfpei at sunway 2_site]$ ../../bin/sphgen 
> forrtl: severe (64): input conversion error, unit 2, file /gdata2/jfpei/lujing/docknew/dock6_mpich/1G3J/2_site/temp2.sph
> Image              PC        Routine            Line        Source             
> sphgen             08095B98  Unknown               Unknown  Unknown
...

This is likely due to generating more than 99999 spheres.
The solution recommended in the tutorial is to divide and conquer
the receptor:
see step 2 of
http://dock.compbio.ucsf.edu/DOCK_6/tutorials/sphere_generation/generating_spheres.htm
http://blur.compbio.ucsf.edu/pipermail/dock-fans/2006-December/000813.html
and for another option:
http://blur.compbio.ucsf.edu/pipermail/dock-fans/2007-October/001260.html

Scott




From sbrozell at scripps.edu  Wed Nov  7 09:37:10 2007
From: sbrozell at scripps.edu (Scott Brozell)
Date: Wed, 7 Nov 2007 09:37:10 -0800 (PST)
Subject: [Dock-fans] HEM in DOCK 6
In-Reply-To: <10f848910711060804l62b8b422n54f08799e8a69619@mail.gmail.com>
Message-ID: <Pine.LNX.4.44.0711070935430.20140-100000@loyd.scripps.edu>

Hi,

Asked and answered in Chimera-users; see this thread:
http://www.cgl.ucsf.edu/pipermail/chimera-users/2007-November/001961.html

Scott

On Tue, 6 Nov 2007, snoze pa wrote:

> Hi, I am new in this mailing list but found chimera more useful than any
> other software. I was building a protein that contain HEME. When I was
> calculating the charge using chimera interface, then it is asking for
> HEM[FE] and HEM[nonFE] formal charge. I know chimera is using MMTK and AMBER
> forcefield. If I will give the default value then it is assigning +2 charge
> to Fe, which is not a match based on AMBER forcefield.  Meanwhile I try to
> change the Formal charge manually, but still it gives the same +2 for Fe.
> Anybody used chimera to prepare a protein having heme for dock or geometry
> build.
> 
>  My another question is: Is it possible in chimera to merge non polar
> hydrogen charges on the heavy atoms, the technique used in autodock.
> 
> I will highly appreciate your help and suggestions in this matter.
> thanks in advance.


From lsayaved at lcg.unam.mx  Wed Nov  7 10:48:22 2007
From: lsayaved at lcg.unam.mx (lsayaved at lcg.unam.mx)
Date: Wed, 7 Nov 2007 12:48:22 -0600 (CST)
Subject: [Dock-fans] A big problem
Message-ID: <49530.132.248.220.53.1194461302.squirrel@www.lcg.unam.mx>

I have the following error:

localhost: Connection refused
All servers died!

Please if somebody had the same error and knew how to fix it, I would
appreciate the help. I have been checking the things that you wrote and I
notticed that some people had the same error, but all the ideas to fix the
problem didnt work for me, I dont know if it is because Im using MacOSX
system with a PowerPC


From chiendarret at yahoo.com  Wed Nov  7 14:50:26 2007
From: chiendarret at yahoo.com (Francesco Pietra)
Date: Wed, 7 Nov 2007 14:50:26 -0800 (PST)
Subject: [Dock-fans] Segmentation fault on running docking
In-Reply-To: <Pine.LNX.4.44.0711070849460.20140-100000@loyd.scripps.edu>
Message-ID: <117437.97751.qm@web57606.mail.re1.yahoo.com>

I have rebuilt the dock program as follows:

MPICH_HOME=/usr/local
export MPICH_HOME
cd install
(save copy config.h)
make distclean
./configure gnu parallel
make dock #


Then
cd test
make test 2>&1 | tee test7Nov.out


the out file (attached)


The last section of the out file (attached) shows that "mpirun" was looked for
in the wrong place if I correctly understand that it was looked for in
/usr/local/dock6/bin (actually it is in /usr/local/bin). Is it OK to copy
"mpirun" from /usr/local/bin to /usr/local/dock6/bin ?

Or rather adding

MPICH_HOME=/usr/local
export MPICH_HOME

to my .bashrc

(which only contains
MPI_HOME=/usr/local
export MPI_HOME)

Without doing anything than the above compilation and tests, 

mpirun -np 4 -i file.in -o file.out 2>&1 | errors.out

only runs to end for the protein without HOH residue. With the protein
embodying HOH, the problems set forth below (now attached error ..) arise.

Probably the docking for the HOH-containing protein should be rerun when mpi is
fixed, befor assuming that there are problems with the protein.

I am really sorry for presenting a much confused situation.

Thanks

francesco

Incidentally, I have carried out successfully test.parallel for Amber 9 (whose
parallel depends on OpenMPI, like DOCK).




--- Scott Brozell <sbrozell at scripps.edu> wrote:

> Hi,
> 
> On Wed, 7 Nov 2007, Francesco Pietra wrote:
> 
> > Having solved empirically, whitout external help, the problem (posted on
> last
> > week-end) of running grid when residue HOH is present within the pore, I am
> now
> 
> 
> Please post a reply to that thread with the problem resolution.
> 
> > faced by segfault in running rigid docking. That occurs both on parallel
> and
> > serial run. It also occurs with previous files for the protein without HOH,
> > where both rigid and flex run OK on mpirun -np 4. Thus, it seems that there
> is
> > now something wrong with dock6 and I don't understand what. 
> > 
> > Before these unsuccessful attempts, I had
> > (1) Unsuccessfully tried to recompile Antechamber with new respgen.c (on
> > Amber9), which did not affect previous compilation.
> > (2) Carried out "apt-get update" to Debian Linux amd64 etch (i.e., stable)
> > without taking notice of the little that was affected.
> > ---------------
> > 
> > While running:
> > 
> > mpirun -np 4 -i rigid.in -o rigid.out
> > 
> > the process halted (rigid_scored.mol2 0 bytes) because
> > 
> > Initialing MPI routines ....
> > [deb64:03540] *** Process received signal ***
> > [deb64:03540] Signal: Segmentation fault (11)
> > [deb64:03540] Signal code: Address not mapped (1)
> > [deb64:03540] Failing at address: 0x2b9ef5691000
> > dock6.mpi[3540]: segfault at 00002b9ef56910000 rip 0000000000447b1b rsp
> > 00007fff43c137b0 error 6
> > [deb64:03540] [0] /lib/libthread.so.0 [0x2b9e681bc410]
> > [deb64:03540] [1] dock6.mpi (_ZN60rient12match_ligandER7DOCKMol+0x40b)
> > [0x447b1b]
> > [deb64:03540] [2] dock6.mpi (main+0xaf5) [0x42cc75]
> > [deb64:03540] [3] dock6.mpi /lib/libc.so.6(__libc_start_main+0xda)
> > [0x2b9e682e14ca]
> > [deb64:03540] [4] dock6.mpi (__gxx_personality_v0+0xc2) [0x41b4ea]
> > [deb64:03540] *** End of error message ***
> > mpirun noticed that jpb rank 0 with PID 3537 on node deb64 exited on signal
> 15
> > (Terminated).
> > 3 additional processes aborted (not shown)
> > ---------------------------
> > 
> > I tried also flex with the protein endowed of HOH
> > 
> > mpirun -np 4 -i anchor_and_grow.in -o anchor_and_grow.out 2>&1 | tee
> errors.out
> > 
> > with an even more complex of libraries and mpi problems (see please
> attachment.
> > ------------------
> > 
> > Parallel dock had so far run correctly. DOCK6.1 had been compiled with:
> > 
> > ./configure gnu parallel
> > MPICH_HOME=/usr/local
> > export MPICH_HOME
> > make dock
> > 
> > I have now unsuccessfully deselected $AMBERHOME in my .bashrc, as expected
> > because it should be only relevant to running amber_score. I did not change
> > otherwise my .bashrc, where
> > 
> > DOCK_HOME=/usr/local/dock6
> > PATH=$PATH:$DOCK_HOME/bib; export DOCK_HOME PATH
> > MPI_HOME=/usr/local
> > export MPI_home
> > 
> > I have now tried the test
> > cd test/mpi
> > make 2>&1 | tee test_parallel.out
> > which passed OK.
> > 
> > Also:
> > which mpicxx
> > /usr/local/bin/mpicxx
> > 
> > Also:
> > updatedb
> > locate mpi.h
> > /usr/include/sc/util/group/memmtmpi.h
> > /usr/include/sc/util/group/messmpi.h
> > /usr/dock6/src/dock/base_mpi.h
> > /usr/local/include/mpi.h
> > /usr/local/openmpi-1.2.3/ompi/include/mpi.h
> > /usr/local/openmpi-1.2.3/ompi/include/mpi.h.in
> > /usr/local/openmpi-1.2.3/ompi/mpi/f77/prototypes_mpi.h
> > 
> > -----------------------
> > Also on serial trial, segfault:
> > 
> > dock6 -i rigid.in -o rigid out
> > 
> > dock6[3602]: segfault at 00002b4da6e0c000 rip 000000000043ffd1 rsp
> > 00007fff86593bc0 error 6
> > Segmentation fault
> > ---------------------------
> 
> It is curious that the dock mpi test is passing, but other dock runs
> are failing.  However, the failures suggest a machine problem.
> If you have updated the operating system then it is likely that
> executables will at least have to be re-linked and maybe re-compiled.
> If you are a miser then try re-linking.
> Otherwise rebuild dock:
> cd install
> # save any special config.h's
> make distclean
> ./configure ...
> make install
> # build parallel
> 
> Scott
> 
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test7Nov.out.tar.bz2
Type: application/x-bzip
Size: 3385 bytes
Desc: pat1498224542
Url : http://blur.compbio.ucsf.edu/pipermail/dock-fans/attachments/20071107/29fdde80/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: errors_rig_HOH.out.tar.bz2
Type: application/x-bzip
Size: 600 bytes
Desc: 987713176-errors_rig_HOH.out.tar.bz2
Url : http://blur.compbio.ucsf.edu/pipermail/dock-fans/attachments/20071107/29fdde80/attachment-0003.bin 

From chiendarret at yahoo.com  Thu Nov  8 01:09:08 2007
From: chiendarret at yahoo.com (Francesco Pietra)
Date: Thu, 8 Nov 2007 01:09:08 -0800 (PST)
Subject: [Dock-fans] Fwd: Re:  Segmentation fault on running docking
Message-ID: <278222.59384.qm@web57607.mail.re1.yahoo.com>

On the below re-installation of dock, I added to my .bashrc

MPICH_HOME=/usr/local
export MPICH_HOME

and make a copy of 'mpirun' from /usr/local/bin to /usr/local/dock6/bin

The test did no more complain about mpirun (attached test8NovC.out)

Rigid docking with the protein deprived of HOH run correctly (attached
errors_rig_noHOH8Nov.out). However, top -i showed only two nodes involved. A
test.parallel with Amber9 showed all four nodes involved with sander.

Under these conditions, rigid docking with the protein containing HOH failed
(attached errors_rig_HOH8Nov.out) because of segmentation fault.

Thanks
francesco


--- Francesco Pietra <chiendarret at yahoo.com> wrote:

> Date: Wed, 7 Nov 2007 14:50:26 -0800 (PST)
> From: Francesco Pietra <chiendarret at yahoo.com>
> Subject: Re: [Dock-fans] Segmentation fault on running docking
> To: Scott Brozell <sbrozell at scripps.edu>
> CC: dock-fans <dock-fans at docking.org>
> 
> I have rebuilt the dock program as follows:
> 
> MPICH_HOME=/usr/local
> export MPICH_HOME
> cd install
> (save copy config.h)
> make distclean
> ./configure gnu parallel
> make dock #
> 
> 
> Then
> cd test
> make test 2>&1 | tee test7Nov.out
> 
> 
> the out file (attached)
> 
> 
> The last section of the out file (attached) shows that "mpirun" was looked
> for
> in the wrong place if I correctly understand that it was looked for in
> /usr/local/dock6/bin (actually it is in /usr/local/bin). Is it OK to copy
> "mpirun" from /usr/local/bin to /usr/local/dock6/bin ?
> 
> Or rather adding
> 
> MPICH_HOME=/usr/local
> export MPICH_HOME
> 
> to my .bashrc
> 
> (which only contains
> MPI_HOME=/usr/local
> export MPI_HOME)
> 
> Without doing anything than the above compilation and tests, 
> 
> mpirun -np 4 -i file.in -o file.out 2>&1 | errors.out
> 
> only runs to end for the protein without HOH residue. With the protein
> embodying HOH, the problems set forth below (now attached error ..) arise.
> 
> Probably the docking for the HOH-containing protein should be rerun when mpi
> is
> fixed, befor assuming that there are problems with the protein.
> 
> I am really sorry for presenting a much confused situation.
> 
> Thanks
> 
> francesco
> 
> Incidentally, I have carried out successfully test.parallel for Amber 9
> (whose
> parallel depends on OpenMPI, like DOCK).
> 
> 
> 
> 
> --- Scott Brozell <sbrozell at scripps.edu> wrote:
> 
> > Hi,
> > 
> > On Wed, 7 Nov 2007, Francesco Pietra wrote:
> > 
> > > Having solved empirically, whitout external help, the problem (posted on
> > last
> > > week-end) of running grid when residue HOH is present within the pore, I
> am
> > now
> > 
> > 
> > Please post a reply to that thread with the problem resolution.
> > 
> > > faced by segfault in running rigid docking. That occurs both on parallel
> > and
> > > serial run. It also occurs with previous files for the protein without
> HOH,
> > > where both rigid and flex run OK on mpirun -np 4. Thus, it seems that
> there
> > is
> > > now something wrong with dock6 and I don't understand what. 
> > > 
> > > Before these unsuccessful attempts, I had
> > > (1) Unsuccessfully tried to recompile Antechamber with new respgen.c (on
> > > Amber9), which did not affect previous compilation.
> > > (2) Carried out "apt-get update" to Debian Linux amd64 etch (i.e.,
> stable)
> > > without taking notice of the little that was affected.
> > > ---------------
> > > 
> > > While running:
> > > 
> > > mpirun -np 4 -i rigid.in -o rigid.out
> > > 
> > > the process halted (rigid_scored.mol2 0 bytes) because
> > > 
> > > Initialing MPI routines ....
> > > [deb64:03540] *** Process received signal ***
> > > [deb64:03540] Signal: Segmentation fault (11)
> > > [deb64:03540] Signal code: Address not mapped (1)
> > > [deb64:03540] Failing at address: 0x2b9ef5691000
> > > dock6.mpi[3540]: segfault at 00002b9ef56910000 rip 0000000000447b1b rsp
> > > 00007fff43c137b0 error 6
> > > [deb64:03540] [0] /lib/libthread.so.0 [0x2b9e681bc410]
> > > [deb64:03540] [1] dock6.mpi (_ZN60rient12match_ligandER7DOCKMol+0x40b)
> > > [0x447b1b]
> > > [deb64:03540] [2] dock6.mpi (main+0xaf5) [0x42cc75]
> > > [deb64:03540] [3] dock6.mpi /lib/libc.so.6(__libc_start_main+0xda)
> > > [0x2b9e682e14ca]
> > > [deb64:03540] [4] dock6.mpi (__gxx_personality_v0+0xc2) [0x41b4ea]
> > > [deb64:03540] *** End of error message ***
> > > mpirun noticed that jpb rank 0 with PID 3537 on node deb64 exited on
> signal
> > 15
> > > (Terminated).
> > > 3 additional processes aborted (not shown)
> > > ---------------------------
> > > 
> > > I tried also flex with the protein endowed of HOH
> > > 
> > > mpirun -np 4 -i anchor_and_grow.in -o anchor_and_grow.out 2>&1 | tee
> > errors.out
> > > 
> > > with an even more complex of libraries and mpi problems (see please
> > attachment.
> > > ------------------
> > > 
> > > Parallel dock had so far run correctly. DOCK6.1 had been compiled with:
> > > 
> > > ./configure gnu parallel
> > > MPICH_HOME=/usr/local
> > > export MPICH_HOME
> > > make dock
> > > 
> > > I have now unsuccessfully deselected $AMBERHOME in my .bashrc, as
> expected
> > > because it should be only relevant to running amber_score. I did not
> change
> > > otherwise my .bashrc, where
> > > 
> > > DOCK_HOME=/usr/local/dock6
> > > PATH=$PATH:$DOCK_HOME/bib; export DOCK_HOME PATH
> > > MPI_HOME=/usr/local
> > > export MPI_home
> > > 
> > > I have now tried the test
> > > cd test/mpi
> > > make 2>&1 | tee test_parallel.out
> > > which passed OK.
> > > 
> > > Also:
> > > which mpicxx
> > > /usr/local/bin/mpicxx
> > > 
> > > Also:
> > > updatedb
> > > locate mpi.h
> > > /usr/include/sc/util/group/memmtmpi.h
> > > /usr/include/sc/util/group/messmpi.h
> > > /usr/dock6/src/dock/base_mpi.h
> > > /usr/local/include/mpi.h
> > > /usr/local/openmpi-1.2.3/ompi/include/mpi.h
> > > /usr/local/openmpi-1.2.3/ompi/include/mpi.h.in
> > > /usr/local/openmpi-1.2.3/ompi/mpi/f77/prototypes_mpi.h
> > > 
> > > -----------------------
> > > Also on serial trial, segfault:
> > > 
> > > dock6 -i rigid.in -o rigid out
> > > 
> > > dock6[3602]: segfault at 00002b4da6e0c000 rip 000000000043ffd1 rsp
> > > 00007fff86593bc0 error 6
> > > Segmentation fault
> > > ---------------------------
> > 
> > It is curious that the dock mpi test is passing, but other dock runs
> > are failing.  However, the failures suggest a machine problem.
> > If you have updated the operating system then it is likely that
> > executables will at least have to be re-linked and maybe re-compiled.
> > If you are a miser then try re-linking.
> > Otherwise rebuild dock:
> > cd install
> > # save any special config.h's
> > make distclean
> > ./configure ...
> > make install
> > # build parallel
> > 
> > Scott
> > 
> > 
> > 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test7Nov.out.tar.bz2
Type: application/x-bzip
Size: 3385 bytes
Desc: pat1570478544
Url : http://blur.compbio.ucsf.edu/pipermail/dock-fans/attachments/20071108/6ba6a18f/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: errors_rig_HOH.out.tar.bz2
Type: application/x-bzip
Size: 600 bytes
Desc: pat1045121320
Url : http://blur.compbio.ucsf.edu/pipermail/dock-fans/attachments/20071108/6ba6a18f/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test8NovC.out.tar.bz2
Type: application/x-bzip
Size: 3422 bytes
Desc: 2030788345-test8NovC.out.tar.bz2
Url : http://blur.compbio.ucsf.edu/pipermail/dock-fans/attachments/20071108/6ba6a18f/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: errors_rig_noHOH8Nov.out.tar.bz2
Type: application/x-bzip
Size: 191 bytes
Desc: 4038345679-errors_rig_noHOH8Nov.out.tar.bz2
Url : http://blur.compbio.ucsf.edu/pipermail/dock-fans/attachments/20071108/6ba6a18f/attachment-0003.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: errors_rig_HOH.out.tar.bz2
Type: application/x-bzip
Size: 600 bytes
Desc: 987713176-errors_rig_HOH.out.tar.bz2
Url : http://blur.compbio.ucsf.edu/pipermail/dock-fans/attachments/20071108/6ba6a18f/attachment-0004.bin 

From lsayaved at lcg.unam.mx  Thu Nov  8 06:55:31 2007
From: lsayaved at lcg.unam.mx (lsayaved at lcg.unam.mx)
Date: Thu, 8 Nov 2007 08:55:31 -0600 (CST)
Subject: [Dock-fans] in the installation of dock..
Message-ID: <50102.200.95.147.28.1194533731.squirrel@www.lcg.unam.mx>


When Im installing dock6 I have the following error, does any body have
the fearest idea of how to correct it??

$make all
Starting installation of
DOCK v6.1
at Thu Nov  8 08:47:02 CST 2007.

cd ../src && make install
cd dock && make install
g++ -c  -O2 -o amber_typer.o  amber_typer.cpp
amber_typer.cpp: In function 'char* white_line(char*)':
amber_typer.cpp:11: error: 'strlen' was not declared in this scope
amber_typer.cpp: In function 'int assign_node(ATOM_TYPE_NODE&, int)':
amber_typer.cpp:62: error: 'strtok' was not declared in this scope
amber_typer.cpp:62: error: 'strcpy' was not declared in this scope
amber_typer.cpp:83: error: 'strncmp' was not declared in this scope
amber_typer.cpp: In function 'int check_type(const char*, const char*)':
amber_typer.cpp:121: error: 'strstr' was not declared in this scope
amber_typer.cpp: In member function 'void
ATOM_TYPER::get_vdw_labels(std::string, bool)':
amber_typer.cpp:281: error: 'strncmp' was not declared in this scope
amber_typer.cpp:342: error: 'strtok' was not declared in this scope
amber_typer.cpp: In member function 'int
ATOM_TYPER::assign_vdw_labels(DOCKMol&, int)':
amber_typer.cpp:471: error: 'strcmp' was not declared in this scope
amber_typer.cpp: In member function 'void
BOND_TYPER::get_flex_labels(std::string)':
amber_typer.cpp:527: error: 'strncmp' was not declared in this scope
amber_typer.cpp:540: error: 'strlen' was not declared in this scope
amber_typer.cpp:557: error: 'strtok' was not declared in this scope
amber_typer.cpp: In member function 'void
BOND_TYPER::get_flex_search(std::string)':
amber_typer.cpp:594: error: 'strtok' was not declared in this scope
amber_typer.cpp:596: error: 'strcmp' was not declared in this scope
amber_typer.cpp: In member function 'void
CHEM_TYPER::get_chem_labels(std::string)':
amber_typer.cpp:749: error: 'strncmp' was not declared in this scope
amber_typer.cpp:758: error: 'strtok' was not declared in this scope
make[2]: *** [amber_typer.o] Error 1
make[1]: *** [dock6] Error 2
make: *** [install] Error 2


From chiendarret at yahoo.com  Thu Nov  8 08:42:40 2007
From: chiendarret at yahoo.com (Francesco Pietra)
Date: Thu, 8 Nov 2007 08:42:40 -0800 (PST)
Subject: [Dock-fans] Fwd: Re:  Segmentation fault on running docking
Message-ID: <191556.99460.qm@web57609.mail.re1.yahoo.com>

I forgot to mention that for both the naked protein and the protein embodying a
single HOH residue, I went on with all the spheres generated by sphgen_cpp. The
array of spheres generated for the HOH-containing protein (seen from
"showsphere < sphgen_cpp_cluster.in as pdb file, 74 KB) is huge and dense,
encompassing the whole protein. This results in  a grid.nrg of 149 MB.

For unclear reasons (because I operated the same way), the array of spheres is
not so dense for the naked protein, resulting in sphgen_cpp_cluster1.pdb 15KB
and grid.nrg 80MB.

I wonder whether a grid.nrg of 149MB may pose problems to the docking
procedure, resulting in the errors described below.

Thanks
francesco


--- Francesco Pietra <chiendarret at yahoo.com> wrote:

> Date: Thu, 8 Nov 2007 01:09:08 -0800 (PST)
> From: Francesco Pietra <chiendarret at yahoo.com>
> Subject: Fwd: Re: [Dock-fans] Segmentation fault on running docking
> To: Scott Brozell <sbrozell at scripps.edu>
> CC: dock-fans <dock-fans at docking.org>
> 
> On the below re-installation of dock, I added to my .bashrc
> 
> MPICH_HOME=/usr/local
> export MPICH_HOME
> 
> and make a copy of 'mpirun' from /usr/local/bin to /usr/local/dock6/bin
> 
> The test did no more complain about mpirun (attached test8NovC.out)
> 
> Rigid docking with the protein deprived of HOH run correctly (attached
> errors_rig_noHOH8Nov.out). However, top -i showed only two nodes involved. A
> test.parallel with Amber9 showed all four nodes involved with sander.
> 
> Under these conditions, rigid docking with the protein containing HOH failed
> (attached errors_rig_HOH8Nov.out) because of segmentation fault.
> 
> Thanks
> francesco
> 
> 
> --- Francesco Pietra <chiendarret at yahoo.com> wrote:
> 
> > Date: Wed, 7 Nov 2007 14:50:26 -0800 (PST)
> > From: Francesco Pietra <chiendarret at yahoo.com>
> > Subject: Re: [Dock-fans] Segmentation fault on running docking
> > To: Scott Brozell <sbrozell at scripps.edu>
> > CC: dock-fans <dock-fans at docking.org>
> > 
> > I have rebuilt the dock program as follows:
> > 
> > MPICH_HOME=/usr/local
> > export MPICH_HOME
> > cd install
> > (save copy config.h)
> > make distclean
> > ./configure gnu parallel
> > make dock #
> > 
> > 
> > Then
> > cd test
> > make test 2>&1 | tee test7Nov.out
> > 
> > 
> > the out file (attached)
> > 
> > 
> > The last section of the out file (attached) shows that "mpirun" was looked
> > for
> > in the wrong place if I correctly understand that it was looked for in
> > /usr/local/dock6/bin (actually it is in /usr/local/bin). Is it OK to copy
> > "mpirun" from /usr/local/bin to /usr/local/dock6/bin ?
> > 
> > Or rather adding
> > 
> > MPICH_HOME=/usr/local
> > export MPICH_HOME
> > 
> > to my .bashrc
> > 
> > (which only contains
> > MPI_HOME=/usr/local
> > export MPI_HOME)
> > 
> > Without doing anything than the above compilation and tests, 
> > 
> > mpirun -np 4 -i file.in -o file.out 2>&1 | errors.out
> > 
> > only runs to end for the protein without HOH residue. With the protein
> > embodying HOH, the problems set forth below (now attached error ..) arise.
> > 
> > Probably the docking for the HOH-containing protein should be rerun when
> mpi
> > is
> > fixed, befor assuming that there are problems with the protein.
> > 
> > I am really sorry for presenting a much confused situation.
> > 
> > Thanks
> > 
> > francesco
> > 
> > Incidentally, I have carried out successfully test.parallel for Amber 9
> > (whose
> > parallel depends on OpenMPI, like DOCK).
> > 
> > 
> > 
> > 
> > --- Scott Brozell <sbrozell at scripps.edu> wrote:
> > 
> > > Hi,
> > > 
> > > On Wed, 7 Nov 2007, Francesco Pietra wrote:
> > > 
> > > > Having solved empirically, whitout external help, the problem (posted
> on
> > > last
> > > > week-end) of running grid when residue HOH is present within the pore,
> I
> > am
> > > now
> > > 
> > > 
> > > Please post a reply to that thread with the problem resolution.
> > > 
> > > > faced by segfault in running rigid docking. That occurs both on
> parallel
> > > and
> > > > serial run. It also occurs with previous files for the protein without
> > HOH,
> > > > where both rigid and flex run OK on mpirun -np 4. Thus, it seems that
> > there
> > > is
> > > > now something wrong with dock6 and I don't understand what. 
> > > > 
> > > > Before these unsuccessful attempts, I had
> > > > (1) Unsuccessfully tried to recompile Antechamber with new respgen.c
> (on
> > > > Amber9), which did not affect previous compilation.
> > > > (2) Carried out "apt-get update" to Debian Linux amd64 etch (i.e.,
> > stable)
> > > > without taking notice of the little that was affected.
> > > > ---------------
> > > > 
> > > > While running:
> > > > 
> > > > mpirun -np 4 -i rigid.in -o rigid.out
> > > > 
> > > > the process halted (rigid_scored.mol2 0 bytes) because
> > > > 
> > > > Initialing MPI routines ....
> > > > [deb64:03540] *** Process received signal ***
> > > > [deb64:03540] Signal: Segmentation fault (11)
> > > > [deb64:03540] Signal code: Address not mapped (1)
> > > > [deb64:03540] Failing at address: 0x2b9ef5691000
> > > > dock6.mpi[3540]: segfault at 00002b9ef56910000 rip 0000000000447b1b rsp
> > > > 00007fff43c137b0 error 6
> > > > [deb64:03540] [0] /lib/libthread.so.0 [0x2b9e681bc410]
> > > > [deb64:03540] [1] dock6.mpi (_ZN60rient12match_ligandER7DOCKMol+0x40b)
> > > > [0x447b1b]
> > > > [deb64:03540] [2] dock6.mpi (main+0xaf5) [0x42cc75]
> > > > [deb64:03540] [3] dock6.mpi /lib/libc.so.6(__libc_start_main+0xda)
> > > > [0x2b9e682e14ca]
> > > > [deb64:03540] [4] dock6.mpi (__gxx_personality_v0+0xc2) [0x41b4ea]
> > > > [deb64:03540] *** End of error message ***
> > > > mpirun noticed that jpb rank 0 with PID 3537 on node deb64 exited on
> > signal
> > > 15
> > > > (Terminated).
> > > > 3 additional processes aborted (not shown)
> > > > ---------------------------
> > > > 
> > > > I tried also flex with the protein endowed of HOH
> > > > 
> > > > mpirun -np 4 -i anchor_and_grow.in -o anchor_and_grow.out 2>&1 | tee
> > > errors.out
> > > > 
> > > > with an even more complex of libraries and mpi problems (see please
> > > attachment.
> > > > ------------------
> > > > 
> > > > Parallel dock had so far run correctly. DOCK6.1 had been compiled with:
> > > > 
> > > > ./configure gnu parallel
> > > > MPICH_HOME=/usr/local
> > > > export MPICH_HOME
> > > > make dock
> > > > 
> > > > I have now unsuccessfully deselected $AMBERHOME in my .bashrc, as
> > expected
> > > > because it should be only relevant to running amber_score. I did not
> > change
> > > > otherwise my .bashrc, where
> > > > 
> > > > DOCK_HOME=/usr/local/dock6
> > > > PATH=$PATH:$DOCK_HOME/bib; export DOCK_HOME PATH
> > > > MPI_HOME=/usr/local
> > > > export MPI_home
> > > > 
> > > > I have now tried the test
> > > > cd test/mpi
> > > > make 2>&1 | tee test_parallel.out
> > > > which passed OK.
> > > > 
> > > > Also:
> > > > which mpicxx
> > > > /usr/local/bin/mpicxx
> > > > 
> > > > Also:
> > > > updatedb
> > > > locate mpi.h
> > > > /usr/include/sc/util/group/memmtmpi.h
> > > > /usr/include/sc/util/group/messmpi.h
> > > > /usr/dock6/src/dock/base_mpi.h
> > > > /usr/local/include/mpi.h
> > > > /usr/local/openmpi-1.2.3/ompi/include/mpi.h
> > > > /usr/local/openmpi-1.2.3/ompi/include/mpi.h.in
> > > > /usr/local/openmpi-1.2.3/ompi/mpi/f77/prototypes_mpi.h
> > > > 
> > > > -----------------------
> > > > Also on serial trial, segfault:
> > > > 
> > > > dock6 -i rigid.in -o rigid out
> > > > 
> > > > dock6[3602]: segfault at 00002b4da6e0c000 rip 000000000043ffd1 rsp
> > > > 00007fff86593bc0 error 6
> > > > Segmentation fault
> > > > ---------------------------
> > > 
> > > It is curious that the dock mpi test is passing, but other dock runs
> > > are failing.  However, the failures suggest a machine problem.
> > > If you have updated the operating system then it is likely that
> > > executables will at least have to be re-linked and maybe re-compiled.
> > > If you are a miser then try re-linking.
> > > Otherwise rebuild dock:
> > > cd install
> > > # save any special config.h's
> > > make distclean
> > > ./configure ...
> > > make install
> > > # build parallel
> > > 
> > > Scott
> > > 
> > > 
> > > 
> > 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around 
> > http://mail.yahoo.com 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test7Nov.out.tar.bz2
Type: application/x-bzip
Size: 3385 bytes
Desc: pat250645930
Url : http://blur.compbio.ucsf.edu/pipermail/dock-fans/attachments/20071108/d742b708/attachment-0005.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: errors_rig_HOH.out.tar.bz2
Type: application/x-bzip
Size: 600 bytes
Desc: pat740259797
Url : http://blur.compbio.ucsf.edu/pipermail/dock-fans/attachments/20071108/d742b708/attachment-0006.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test8NovC.out.tar.bz2
Type: application/x-bzip
Size: 3422 bytes
Desc: pat2094446940
Url : http://blur.compbio.ucsf.edu/pipermail/dock-fans/attachments/20071108/d742b708/attachment-0007.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: errors_rig_noHOH8Nov.out.tar.bz2
Type: application/x-bzip
Size: 191 bytes
Desc: pat1456698440
Url : http://blur.compbio.ucsf.edu/pipermail/dock-fans/attachments/20071108/d742b708/attachment-0008.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: errors_rig_HOH.out.tar.bz2
Type: application/x-bzip
Size: 600 bytes
Desc: pat1426967275
Url : http://blur.compbio.ucsf.edu/pipermail/dock-fans/attachments/20071108/d742b708/attachment-0009.bin 

From biobrain at gmail.com  Thu Nov  8 22:54:16 2007
From: biobrain at gmail.com (Muhammad Imtiaz Sha)
Date: Fri, 9 Nov 2007 06:54:16 +0000 (GMT)
Subject: [Dock-fans] Link to call me for free
Message-ID: <28382764.1960591194591256069.JavaMail.tomcat@media1.jaxtr.com>



I am using jaxtr, and if you also sign up, we can talk for free on the phone at any time.

-Muhammad Imtiaz

P.S. Here is the link to sign up: http://www.jaxtr.com/user/ticket?n=T1a8gu3oiu07t3&type=joininvite

---
Delivered by jaxtr, Inc., 855 Oak Grove Avenue, Suite 100, Menlo Park, California 94025. To stop receiving messages from this sender go to http://www.jaxtr.com/user/reportabuse.jsp?it=T1a8gu3oiu07t3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://blur.compbio.ucsf.edu/pipermail/dock-fans/attachments/20071109/8d9d6481/attachment.html 

From vijayarajr_rv at yahoo.co.in  Fri Nov  9 04:28:30 2007
From: vijayarajr_rv at yahoo.co.in (V I J A Y)
Date: Fri, 9 Nov 2007 12:28:30 +0000 (GMT)
Subject: [Dock-fans] regarding showspere
Message-ID: <561510.558.qm@web8407.mail.in.yahoo.com>

hello,
   
        I am new to dock 6.1 software and i am trying to run tutorials in the dock web site. i have problem with showsphere program. its giving error report like
   
  7 [sig] showsphere 2380 C:\cygwin\dock6\bin\showsphere.exe: *** fatal error - called with threadlist_ix -1
   
  how do i solve this problem. 
   
  vijay

       
---------------------------------
 Bollywood, fun, friendship, sports and more. You name it,  we have it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://blur.compbio.ucsf.edu/pipermail/dock-fans/attachments/20071109/86fac84b/attachment.html 

From sbrozell at scripps.edu  Fri Nov  9 12:14:52 2007
From: sbrozell at scripps.edu (Scott Brozell)
Date: Fri, 9 Nov 2007 12:14:52 -0800 (PST)
Subject: [Dock-fans] regarding showspere
In-Reply-To: <561510.558.qm@web8407.mail.in.yahoo.com>
Message-ID: <Pine.LNX.4.44.0711091212520.20140-100000@loyd.scripps.edu>

Hi,

On Fri, 9 Nov 2007, V I J A Y wrote:

>         I am new to dock 6.1 software and i am trying to run tutorials in the dock web site. i have problem with showsphere program. its giving error report like
>    
>   7 [sig] showsphere 2380 C:\cygwin\dock6\bin\showsphere.exe: *** fatal error - called with threadlist_ix -1

What happens when you run the sphere_generation test ?
cd dock6/install/test/sphere_generation
make clean
make
make check

This is not the first such report:
http://blur.compbio.ucsf.edu/pipermail/dock-fans/2007-August/001158.html

Scott



From sbrozell at scripps.edu  Fri Nov  9 12:31:26 2007
From: sbrozell at scripps.edu (Scott Brozell)
Date: Fri, 9 Nov 2007 12:31:26 -0800 (PST)
Subject: [Dock-fans] in the installation of dock..
In-Reply-To: <50102.200.95.147.28.1194533731.squirrel@www.lcg.unam.mx>
Message-ID: <Pine.LNX.4.44.0711091217060.20140-100000@loyd.scripps.edu>

Hi,

On Thu, 8 Nov 2007 lsayaved at lcg.unam.mx wrote:

> When Im installing dock6 I have the following error, does any body have
> the fearest idea of how to correct it??
> 
> $make all
> Starting installation of
> DOCK v6.1
> at Thu Nov  8 08:47:02 CST 2007.
> 
> cd ../src && make install
> cd dock && make install
> g++ -c  -O2 -o amber_typer.o  amber_typer.cpp
> amber_typer.cpp: In function 'char* white_line(char*)':
> amber_typer.cpp:11: error: 'strlen' was not declared in this scope
> amber_typer.cpp: In function 'int assign_node(ATOM_TYPE_NODE&, int)':
> amber_typer.cpp:62: error: 'strtok' was not declared in this scope
> amber_typer.cpp:62: error: 'strcpy' was not declared in this scope
> amber_typer.cpp:83: error: 'strncmp' was not declared in this scope
> amber_typer.cpp: In function 'int check_type(const char*, const char*)':
> amber_typer.cpp:121: error: 'strstr' was not declared in this scope
...

Something is amiss with header file inclusion.
This is probably an operating system issue or maybe a compiler
installation problem: maybe your OS is stale
or maybe too bleeding edge.
Google on
your_OS error: 'strlen' was not declared in this scope
and you may find help.

Scott



From sbrozell at scripps.edu  Fri Nov  9 18:50:58 2007
From: sbrozell at scripps.edu (Scott Brozell)
Date: Fri, 9 Nov 2007 18:50:58 -0800 (PST)
Subject: [Dock-fans] Segmentation fault on running docking
In-Reply-To: <117437.97751.qm@web57606.mail.re1.yahoo.com>
Message-ID: <Pine.LNX.4.44.0711071432390.20140-100000@loyd.scripps.edu>

Hi,

On Thu, 8 Nov 2007, Francesco Pietra wrote:

> On the below re-installation of dock, I added to my .bashrc
> MPICH_HOME=/usr/local
> export MPICH_HOME
> and make a copy of 'mpirun' from /usr/local/bin to /usr/local/dock6/bin
> The test did no more complain about mpirun (attached test8NovC.out)


Yes.   Your attached error was
Processing test mpi
/bin/mpirun -np 2 ../../../bin/dock6.mpi -i mpi.dockin -o mpi.dockmpiout
make[3]: /bin/mpirun: Command not found

MPICH_HOME needs to be defined; this is the command used in the tests:
$(MPICH_HOME)/bin/mpirun


> Rigid docking with the protein deprived of HOH run correctly (attached
> errors_rig_noHOH8Nov.out). However, top -i showed only two nodes involved. A
> test.parallel with Amber9 showed all four nodes involved with sander.
>
> Under these conditions, rigid docking with the protein containing HOH failed
> (attached errors_rig_HOH8Nov.out) because of segmentation fault.


errors_rig_noHOH8Nov.out
Initializing MPI Routines...
Initializing MPI Routines...
Initializing MPI Routines...
Initializing MPI Routines...

is just four lines !  Where are the docking results ?


errors_rig_HOH8Nov.out
Initializing MPI Routines...
Initializing MPI Routines...
Initializing MPI Routines...
Initializing MPI Routines...
[deb64:20728] *** Process received signal ***
[deb64:20728] Signal: Segmentation fault (11)
[deb64:20728] Signal code: Address not mapped (1)
[deb64:20728] Failing at address: 0x2acf65505000
[deb64:20728] [ 0] /lib/libpthread.so.0 [0x2aced8030410]
[deb64:20728] [ 1] dock6.mpi(_ZN6Orient12match_ligandER7DOCKMol+0x40b) [0x447b1b]
[deb64:20728] [ 2] dock6.mpi(main+0xaf5) [0x42cc75]
[deb64:20728] [ 3] /lib/libc.so.6(__libc_start_main+0xda) [0x2aced81554ca]
[deb64:20728] [ 4] dock6.mpi(__gxx_personality_v0+0xc2) [0x41b4ea]


This still looks like an mpi issue.
Is it true that you have run sander.MPI successfully ?


> I forgot to mention that for both the naked protein and the protein embodying a
> single HOH residue, I went on with all the spheres generated by sphgen_cpp. The
> array of spheres generated for the HOH-containing protein (seen from
> "showsphere < sphgen_cpp_cluster.in as pdb file, 74 KB) is huge and dense,
> encompassing the whole protein. This results in  a grid.nrg of 149 MB.
>
> For unclear reasons (because I operated the same way), the array of spheres is
> not so dense for the naked protein, resulting in sphgen_cpp_cluster1.pdb 15KB
> and grid.nrg 80MB.


So there is only one water molecule difference, but the sphere file size
increases by a factor of 5 and the grid by a factor of 2 ?
Something is fishy here.  What does visualization of the sphere files show ?

test8NovC.out  shows possible failures:
# Select spheres within 10 Ang of ligand
../../../bin/sphere_selector struct.sph lig.mol2 3.0
../dockdif -t 3 selected_spheres.sph.save selected_spheres.sph
diffing selected_spheres.sph.save with selected_spheres.sph
possible FAILURE:  check selected_spheres.sph.dif
==============================================================
# Convert selected spheres into pdb format for viewing
../../../bin/showsphere < select.in > /dev/null
../dockdif selected_cluster.pdb.save selected_cluster.pdb
diffing selected_cluster.pdb.save with selected_cluster.pdb
possible FAILURE:  check selected_cluster.pdb.dif
==============================================================
...
Processing test mpi
/usr/local/bin/mpirun -np 2 ../../../bin/dock6.mpi -i mpi.dockin -o mpi.dockmpiout
Initializing MPI Routines...
Initializing MPI Routines...
../dockdif -t 8 mpi.dockmpiout.save mpi.dockmpiout
diffing mpi.dockmpiout.save with mpi.dockmpiout
possible FAILURE:  check mpi.dockmpiout.dif


What are these dif's ?
(Please if the files are small then just cut and paste the contents into
the email rather than attaching them.)


> I wonder whether a grid.nrg of 149MB may pose problems to the docking
> procedure, resulting in the errors described below.


Perhaps, but the behavior as far as I can tell indicates a failure
before reading of the grid.


Scott

On Wed, 7 Nov 2007, Francesco Pietra wrote:

> I have rebuilt the dock program as follows:
> 
> MPICH_HOME=/usr/local
> export MPICH_HOME
> cd install
> (save copy config.h)
> make distclean
> ./configure gnu parallel
> make dock #
> cd test
> make test 2>&1 | tee test7Nov.out
> the out file (attached)
> 
> The last section of the out file (attached) shows that "mpirun" was looked for
> in the wrong place if I correctly understand that it was looked for in
> /usr/local/dock6/bin (actually it is in /usr/local/bin). Is it OK to copy
> "mpirun" from /usr/local/bin to /usr/local/dock6/bin ?
> 
> Or rather adding
> 
> MPICH_HOME=/usr/local
> export MPICH_HOME
> to my .bashrc
> 
> (which only contains
> MPI_HOME=/usr/local
> export MPI_HOME)
> 
> Without doing anything than the above compilation and tests, 
> 
> mpirun -np 4 -i file.in -o file.out 2>&1 | errors.out
> 
> only runs to end for the protein without HOH residue. With the protein
> embodying HOH, the problems set forth below (now attached error ..) arise.
> 
> Probably the docking for the HOH-containing protein should be rerun when mpi is
> fixed, befor assuming that there are problems with the protein.
> 
> I am really sorry for presenting a much confused situation.
> 
> Incidentally, I have carried out successfully test.parallel for Amber 9 (whose
> parallel depends on OpenMPI, like DOCK).
> 
> 
> --- Scott Brozell <sbrozell at scripps.edu> wrote:
> 
> > Hi,
> > 
> > On Wed, 7 Nov 2007, Francesco Pietra wrote:
> > 
> > > Having solved empirically, whitout external help, the problem (posted on
> > last
> > > week-end) of running grid when residue HOH is present within the pore, I am
> > now
> > 
> > 
> > Please post a reply to that thread with the problem resolution.
> > 
> > > faced by segfault in running rigid docking. That occurs both on parallel
> > and
> > > serial run. It also occurs with previous files for the protein without HOH,
> > > where both rigid and flex run OK on mpirun -np 4. Thus, it seems that there
> > is
> > > now something wrong with dock6 and I don't understand what. 
> > > 
> > > Before these unsuccessful attempts, I had
> > > (1) Unsuccessfully tried to recompile Antechamber with new respgen.c (on
> > > Amber9), which did not affect previous compilation.
> > > (2) Carried out "apt-get update" to Debian Linux amd64 etch (i.e., stable)
> > > without taking notice of the little that was affected.
> > > ---------------
> > > 
> > > While running:
> > > 
> > > mpirun -np 4 -i rigid.in -o rigid.out
> > > 
> > > the process halted (rigid_scored.mol2 0 bytes) because
> > > 
> > > Initialing MPI routines ....
> > > [deb64:03540] *** Process received signal ***
> > > [deb64:03540] Signal: Segmentation fault (11)
> > > [deb64:03540] Signal code: Address not mapped (1)
> > > [deb64:03540] Failing at address: 0x2b9ef5691000
> > > dock6.mpi[3540]: segfault at 00002b9ef56910000 rip 0000000000447b1b rsp
> > > 00007fff43c137b0 error 6
> > > [deb64:03540] [0] /lib/libthread.so.0 [0x2b9e681bc410]
> > > [deb64:03540] [1] dock6.mpi (_ZN60rient12match_ligandER7DOCKMol+0x40b)
> > > [0x447b1b]
> > > [deb64:03540] [2] dock6.mpi (main+0xaf5) [0x42cc75]
> > > [deb64:03540] [3] dock6.mpi /lib/libc.so.6(__libc_start_main+0xda)
> > > [0x2b9e682e14ca]
> > > [deb64:03540] [4] dock6.mpi (__gxx_personality_v0+0xc2) [0x41b4ea]
> > > [deb64:03540] *** End of error message ***
> > > mpirun noticed that jpb rank 0 with PID 3537 on node deb64 exited on signal
> > 15
> > > (Terminated).
> > > 3 additional processes aborted (not shown)
> > > ---------------------------
> > > 
> > > I tried also flex with the protein endowed of HOH
> > > 
> > > mpirun -np 4 -i anchor_and_grow.in -o anchor_and_grow.out 2>&1 | tee
> > errors.out
> > > 
> > > with an even more complex of libraries and mpi problems (see please
> > attachment.
> > > ------------------
> > > 
> > > Parallel dock had so far run correctly. DOCK6.1 had been compiled with:
> > > 
> > > ./configure gnu parallel
> > > MPICH_HOME=/usr/local
> > > export MPICH_HOME
> > > make dock
> > > 
> > > I have now unsuccessfully deselected $AMBERHOME in my .bashrc, as expected
> > > because it should be only relevant to running amber_score. I did not change
> > > otherwise my .bashrc, where
> > > 
> > > DOCK_HOME=/usr/local/dock6
> > > PATH=$PATH:$DOCK_HOME/bib; export DOCK_HOME PATH
> > > MPI_HOME=/usr/local
> > > export MPI_home
> > > 
> > > I have now tried the test
> > > cd test/mpi
> > > make 2>&1 | tee test_parallel.out
> > > which passed OK.
> > > 
> > > Also:
> > > which mpicxx
> > > /usr/local/bin/mpicxx
> > > 
> > > Also:
> > > updatedb
> > > locate mpi.h
> > > /usr/include/sc/util/group/memmtmpi.h
> > > /usr/include/sc/util/group/messmpi.h
> > > /usr/dock6/src/dock/base_mpi.h
> > > /usr/local/include/mpi.h
> > > /usr/local/openmpi-1.2.3/ompi/include/mpi.h
> > > /usr/local/openmpi-1.2.3/ompi/include/mpi.h.in
> > > /usr/local/openmpi-1.2.3/ompi/mpi/f77/prototypes_mpi.h
> > > 
> > > -----------------------
> > > Also on serial trial, segfault:
> > > 
> > > dock6 -i rigid.in -o rigid out
> > > 
> > > dock6[3602]: segfault at 00002b4da6e0c000 rip 000000000043ffd1 rsp
> > > 00007fff86593bc0 error 6
> > > Segmentation fault
> > > ---------------------------
> > 
> > It is curious that the dock mpi test is passing, but other dock runs
> > are failing.  However, the failures suggest a machine problem.
> > If you have updated the operating system then it is likely that
> > executables will at least have to be re-linked and maybe re-compiled.
> > If you are a miser then try re-linking.
> > Otherwise rebuild dock:
> > cd install
> > # save any special config.h's
> > make distclean
> > ./configure ...
> > make install
> > # build parallel
> > 





From lsayaved at lcg.unam.mx  Sat Nov 10 11:49:21 2007
From: lsayaved at lcg.unam.mx (lsayaved at lcg.unam.mx)
Date: Sat, 10 Nov 2007 13:49:21 -0600 (CST)
Subject: [Dock-fans] Another problem
Message-ID: <51040.132.248.113.229.1194724161.squirrel@www.lcg.unam.mx>

Hi:

I was able to fixed my last error in the installation, but it was because
the string.h library wasnt included in some of the *.cpp files... or maybe
it was something else, I dont know.
Now I could succesfully have  installed the dock part, but when I am
installing the utilities, I have the following error::

/usr/local/lib/gcc/powerpc-apple-darwin8.9.0/4.3.0/../../../../include/c++/4.3.0/backward/backward_warning.h:32:2:
warning: #warning This file includes at least one deprecated or antiquated
header. Please consider using one of the 32 headers found in section
17.4.1.2 of the C++ standard. Examples include substituting the <X> header
for the <X.h> header for C++ includes, or <iostream> instead of the
deprecated header <iostream.h>. To disable this warning use
-Wno-deprecated.
/usr/bin/ld: unknown flag: -macosx_version_min
collect2: ld returned 1 exit status
make[2]: *** [sphere_selector] Error 1
make[1]: *** [utils] Error 2
make: *** [utils] Error 2


I really cant understand the reason of this problem, but please, if some
body knows how to fix it, could you help me?? I would really appreciate
it.

Lizbeth Sayavedra


From chiendarret at yahoo.com  Sat Nov 10 13:29:44 2007
From: chiendarret at yahoo.com (Francesco Pietra)
Date: Sat, 10 Nov 2007 13:29:44 -0800 (PST)
Subject: [Dock-fans] Segmentation fault on docking and Prepare issues
	solved
In-Reply-To: <Pine.LNX.4.44.0711071432390.20140-100000@loyd.scripps.edu>
Message-ID: <539634.58711.qm@web57604.mail.re1.yahoo.com>

The house is now fully in order.

The errors below at "errors_rig_HOH8Nov.out" were not from mpi, rather from
faulty input files, though for elusive reasons. With my pore protein and
150-atoms ligand, starting from previous "Prepare" and without any further
modification to the system, I carried out from scratch all other steps as from
Dock tutorials. As final step, the best pose from flex_docking was subjected to
amber re-scoring with "everything" option.

As to the alleged issue "4 vs 2 nodes involved", I have now noticed from "top
-i" that with heavy calculations, such as amber score everything, all four
nodes are involved (100% cpus, 0.3% memory out of the 4GB per node) as
requested by "mpirun -np 4 dock6.mpi". At later stages of the calculation, only
two nodes are active according to "top -i".

For less heavy calculations, such as amber score ligand, the change from 4 to 2
nodes involved is quite rapid. For light calculations, I was not rapid enough
to see 4 nodes involved. 2 nodes at the for "top -i" check.

Don't know if this is intrinsic to the dock programs or something resulting
from MPICK pointing to OpenMPI as in my system. At any event, all procedures
finished OK.

I remind the problems encountered in the "Prepare" step when a single residue
HOH is present in the pore (as determined by X-ray diffraction of O). Chimera's
DockPrep was unable to deal correctly with the protein pdb file. 

It was only using LEaP that the problem could be solved. First, on the
knowledge that Chimera's DockPrep deals better with prmtop and inpcrd rather
than pdb file from Amber, I prepared such prmtop and inpcrd with Amber9's LEaP
(leaprc.ff99SB and leaprc.gaff). Chimera accepted these files, while DockPrep
complained about incorrect valency for one H. In fact, the HOH residue showed a
bond between the two hydrogens. Curiously, the shape was correct for the water
molecule (H-O-H angle 104.5, H-H distance 1.51). Against all previous
experience, I prepared a pdb file from these prmtop/inpcrd with ambpdb. This
pdb showed the HOH correctly (with same geometry as above) and DockPrep
finished without any complain.

Having presented the facts (sorry for being unable to theorize about) I finish
with a question. Is any best promising route to follow now for carrying out
Amber9 MD with the complex protein-ligand and from that back to DOCK?

Thanks
francesco

--- Scott Brozell <sbrozell at scripps.edu> wrote:

> Hi,
> 
> On Thu, 8 Nov 2007, Francesco Pietra wrote:
> 
> > On the below re-installation of dock, I added to my .bashrc
> > MPICH_HOME=/usr/local
> > export MPICH_HOME
> > and make a copy of 'mpirun' from /usr/local/bin to /usr/local/dock6/bin
> > The test did no more complain about mpirun (attached test8NovC.out)
> 
> 
> Yes.   Your attached error was
> Processing test mpi
> /bin/mpirun -np 2 ../../../bin/dock6.mpi -i mpi.dockin -o mpi.dockmpiout
> make[3]: /bin/mpirun: Command not found
> 
> MPICH_HOME needs to be defined; this is the command used in the tests:
> $(MPICH_HOME)/bin/mpirun
> 
> 
> > Rigid docking with the protein deprived of HOH run correctly (attached
> > errors_rig_noHOH8Nov.out). However, top -i showed only two nodes involved.
> A
> > test.parallel with Amber9 showed all four nodes involved with sander.
> >
> > Under these conditions, rigid docking with the protein containing HOH
> failed
> > (attached errors_rig_HOH8Nov.out) because of segmentation fault.
> 
> 
> errors_rig_noHOH8Nov.out
> Initializing MPI Routines...
> Initializing MPI Routines...
> Initializing MPI Routines...
> Initializing MPI Routines...
> 
> is just four lines !  Where are the docking results ?
> 
> 
> errors_rig_HOH8Nov.out
> Initializing MPI Routines...
> Initializing MPI Routines...
> Initializing MPI Routines...
> Initializing MPI Routines...
> [deb64:20728] *** Process received signal ***
> [deb64:20728] Signal: Segmentation fault (11)
> [deb64:20728] Signal code: Address not mapped (1)
> [deb64:20728] Failing at address: 0x2acf65505000
> [deb64:20728] [ 0] /lib/libpthread.so.0 [0x2aced8030410]
> [deb64:20728] [ 1] dock6.mpi(_ZN6Orient12match_ligandER7DOCKMol+0x40b)
> [0x447b1b]
> [deb64:20728] [ 2] dock6.mpi(main+0xaf5) [0x42cc75]
> [deb64:20728] [ 3] /lib/libc.so.6(__libc_start_main+0