Difference between revisions of "DUMM1"

From DISI
Jump to navigation Jump to search
Line 59: Line 59:
 
<br>
 
<br>
 
''Francesco:'' there is a script called <tt>rebuildit.pl</tt> which will schedule the molecules in question for rebuilding in [http://zinc.docking.org ZINC]. Commandline: <tt>rebuildit.pl list_of_zinc_ids</tt>.<br>
 
''Francesco:'' there is a script called <tt>rebuildit.pl</tt> which will schedule the molecules in question for rebuilding in [http://zinc.docking.org ZINC]. Commandline: <tt>rebuildit.pl list_of_zinc_ids</tt>.<br>
''Michael:'' the molecule files are located on <tt>/raid2</tt>.
+
''Michael:'' the molecule files are located on <tt>/raid2/db/XX/YY/PROTXXYY.*</tt>. Note this is the protomer id and not the zinc id.
  
 
'''Knowledge managment'''
 
'''Knowledge managment'''

Revision as of 05:35, 10 June 2008

Attendees

Sarah, Alessandro, Francesco, Hao, Michael, Pascal, Peter

Hardware updates

Pascal: 8x44 "Fight for Mike" machines will arrive shortly. Problem: how to coordinate the high number of machines to write to disk w/o affecting the other users ⇒ what gets written to disk during a DOCK run?
Michael: three big files: test.eel1, test.1 and OUTDOCK. test.1 should be optional. test.eel1 and OUTDOCK are gzipped in the most recent version of DOCK (part of dock67). Problem: DOCK writes test.* at the end of the run ⇒ maybe streamline the process?
Pascal: solution is probably to write to scratch and then cp files over at the end.

Software updates

dock67 | solvmap

Michael: dock67 has been released. It contains a new version of solvmap, which has a bugfix for the "blank lines bug" that caused the solvation penalties to be wrong. The output of the new version can be recognized by the fact that the last three numbers on the first line are floats.

runAMSOL3.csh

Michael: use runAMSOL3.csh WAIT to use AMSOL when preparing database files, so you get the correct cavitation term.

file2file.py

Michael: file2file.py has been improved: uses SYBYL atom types; charged molecules are handled correctly.

dbgen.csh

Michael: more tools for database generation are available: dbgen.csh uses the most recent version of the procedure without using ZINC, ensuring they are all generated from scratch. Commandline: dbgen.csh my.smi [optional protonation type]

decoys.py

Michael: decoys.py builds DUD-style set of decoys. Help accessible with decoys.py -h. Executable can be found at ~mysinger/code/dud/trunk/decoys.py.

database generation

Michael: if one has to generate large amounts of database files, you can put the jobs on the cluster. Use the script dbstart.csh on sgehead to start the jobs and dbend.csh to collect them when they are done.

DOCK updates

dock67

Michael: the most recent version of DOCK (part of dock67) gzips test.eel1 and OUTDOCK.

Requests/Improvements

Hao: it might be good to include an option in DOCK to be able to write out more than one pose per molecule.
Michael: this is part of my orals proposal.

Varia

ZINC history

Sarah: how to keep old ZINC versions and ensure that molecules are the same, especially in order to be able to reproduce calculations?
Pascal: is there a way to find out which tools were used to build a certain molecule?
Peter: how to rebuild molecules?
Francesco: there is a script called rebuildit.pl which will schedule the molecules in question for rebuilding in ZINC. Commandline: rebuildit.pl list_of_zinc_ids.
Michael: the molecule files are located on /raid2/db/XX/YY/PROTXXYY.*. Note this is the protomer id and not the zinc id.

Knowledge managment

Peter: how do we make software changes visible to the internal users?
Michael/Peter/Sarah: keep minutes and put them up on the wiki. Ideally include subpages and changelogs for the software items. Make sure that everyone has access to the latest versions of software/scripts/testcases for evaluation purposes.
Pascal/Michael: make more consistent use of the CVS to omit consecutive numbering of scripts.

--Kolb 16:08, 9 June 2008 (PDT)