Difference between revisions of "DUMM1"
m (32 revisions)
|(2 intermediate revisions by the same user not shown)|
|Line 41:||Line 41:|
''Michael:'' if one has to generate large amounts of database files, you can put the jobs on the cluster. Use
''Michael:'' if one has to generate large amounts of database files, you can put the jobs on the cluster. Use <tt>dbstart.csh </tt> on sgehead to start the jobs and <tt>dbend.csh</tt> to collect them when they are done.
==[[DOCK]] updates ==
==[[DOCK]] updates ==
|Line 78:||Line 78:|
back to [[
back to []
Latest revision as of 20:11, 8 October 2012
Attendees & Time
Sarah, Alessandro, Francesco, Hao, Michael, Pascal, Peter
Date: June 04, 2008
Next DUM on Wednesday, July 2, 2008
Pascal: 8×44 "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.
John: Michael's gzipped output helps. Also set restart_interval to big value (100000) to prevent heavy disk writes. As of now, the new machines seem to have been absorbed with no performance problems.
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.
Michael: use runAMSOL3.csh WAIT to use AMSOL when preparing database files, so you get the correct cavitation term.
Michael: file2file.py has been improved: uses SYBYL atom types; charged molecules are handled correctly.
Michael: more tools for database generation are available: dbgen.csh uses the most recent version of the procedure without using ZINC, ensuring the molecules are all generated from scratch. Commandline: dbgen.csh my.smi [optional protonation type]
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.
Michael: if one has to generate large amounts of database files, you can put the jobs on the cluster. Use dbstart.csh ./dbname.smi on sgehead to start the jobs and dbend.csh to collect them when they are done. If dbname.smi contains more than 1000 molecules, break it down to smaller subparts.
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.
Sarah: how to keep old ZINC versions and ensure that molecules are the same, especially in order to be able to reproduce calculations?
John answers: ZINC 5, 6, 7 are all still on line and available.
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.
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.
→ back to DUMM main page