Re: [ccp4bb] cluster Ta6Br12 in phaser
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Kevin, the phaser developers would probably give you a precise answer. In the meantime I would debug this by setting each of the three occurances of TX to UX (or anything else), one after the other, to check which of them is misinterpreted. It's a shame phaser does not read the sres-file directly ;-) Given that you are trying to phase on a Ta-cluster I assume that your resolution is too poor for phasing with shelxe? Did you try the autobuilding option (-a) with a large number of cycles? Although make sure you download the latest version of shelx c/d/e from the shelx web-site. sbgrid are not really the fastest with updating their distribution, at least not according to the versions listed on their web site. Best, Tim On 06/27/2013 12:15 AM, Kevin Jude wrote: We are trying to get SAD phases using a Ta6Br12 cluster using phaser. Sites were found with ShelxD and we have set the ha.pdb in the form: ATOM 1 TX HAT 1 24.569 195.940 54.912 1.00 20.00 TX and we define the scatterer in phaser.inp with: SCATTERING TYPE TX FP = -25.31 FDP = 11.7 FIX OFF but get the error: INPUT ERROR: Type T not element or cluster We've tried a few permutations of columns 14-15 and 78-79 of ha.pdb but phaser hasn't been able to successfully interpret the scattering type. I haven't been able to find detailed information about the format of the input pdb file with the HA sites to bypass this error. We're using phaser from ccp4-6.3.0 distributed by sbgrid. Any help will be much appreciated, Kevin Jude - -- - -- Dr Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFRy/pJUxlJ7aRr7hoRAkkqAKDWPHGgCn5mCjcDKscVzJMakSZdgACePp5c g7vro6+16JKuq5cwxrIXb4I= =ykhD -END PGP SIGNATURE-
[ccp4bb] PDBe Quips: transformer proteins - the science, not the fiction
PDBe Quips: transformer proteins - the science, not the fiction. The bacterial transcription factor RfaH has been shown to undergo extreme conformational transformation. It is able to switch between two completely different secondary and tertiary structures, each with a specific physiological function. You can explore this remarkable transformer protein in our latest interactive Quips article: http://pdbe.org/quips?story=Transformer If you have an interesting structure whose story you would like to tell (with our help) in the form of a Quips article, please contact us at p...@ebi.ac.uk mailto:p...@ebi.ac.uk?subject=Quips -- Gary Battle Protein Data Bank in Europe (PDBe) http://www.facebook.com/proteindatabank http://twitter.com/PDBeurope
Re: [ccp4bb] Supplier for X-ray sensitive paper
Hi Joe, What is known as 'green paper' and some of the 'burn paper' variants used to be 'Green Detex' from Sessions of York -- and this is to the best of my knowledge not produced anymore. Green Detex was paper with UV sensitive coating for calibrating UV lamps. It works to use other UV sensitive paper types like: 'UV FASTCHECK STRIPS' from UVPS http://www.uvprocess.com/product.asp?code=INTS+LBL+B If you have a surveillance camera at hand you can also use fluorescent screens for a non-permanent indication of the beam position. If you search for 'X-ray intensifying screens', then you will find fluorescent screens that are used in X-ray setups where still a X-ray sensitive film rather than a camera is used: http://www.laborversand.de/product_info.php?info=p574_Intensifying-screens.html http://www.kiranxray.com/xrc_screens.asp I think the X-rays that passed the film are turned via this intensifying screen in visible light that exposes the film, i.e., the film detection becomes more efficient. Anyway: It is a cheap fluorescent screen, with the advantage and disadvantage of non-permanent X-ray position marks. I hope this helps a bit, best regards Oliver -- Date:Wed, 26 Jun 2013 16:03:12 -0400 From:Matthew Franklin mfrank...@nysbc.org Subject: Re: Supplier for X-ray sensitive paper Hi Joe - This is what I've used in the past. It's film, not paper, but needs no developer and is instant-readout. I think the find a distributor link should help you obtain it. http://www.ashland.com/products/gafchromic-radiology-films - Matt On 6/26/13 3:51 PM, Patel, Joe wrote: Hi All, I have done a few searches of the archive and googled a few times but not found what I am looking for. Could someone point me in the direction of a supplier of the X-ray sensitive paper I have used in the past to confirm beam position on a home source. I am specifically after this type of paper rather than X-ray film so as not to have to go through any developing stage and quickly visualize the location of the beam at different points beyond the position of the goniometer towards the detector. A USA supplier would be great but any would do. Many thanks, Joe P -- Confidentiality Notice: This message is private and may contain confidential and proprietary information. If you have received this message in error, please notify us and remove it from your system and note that you must not copy, distribute or take any action in reliance on it. Any unauthorized use or disclosure of the contents of this message is not permitted and may be unlawful. -- Matthew Franklin, Ph. D. Senior Scientist New York Structural Biology Center 89 Convent Avenue, New York, NY 10027 (212) 939-0660 ext. 9374
[ccp4bb] Job Posting: Technical Key Account Managers (3 positions) at Microlytic
*Technical Key Account Managers - 3 positions currently available* To meet increasing customer demand Microlytic is hiring individuals with a strong scientific background for serving our growing base of large academic and industrial accounts in the USA. The technical key account managers will be traveling to customer sites to give seminars about Microlytic’s products, facilitate integration of products within customer workflow, and solve technical issues with customers. The candidate should reside in or be willing to relocate to one of the following three territories: (1) Greater San Francisco (1 position) (2) New York City/New Jersey (Philadelphia also considered) (1 position) (3) Maryland/DC/Virginia/North Carolina (1 position) *Job description* The primary focus of these positions is serving key accounts, specifically responding to customer requests, assisting customers with product integration, providing technical support and managing sales. Additionally, the candidates will be responsible for organizing trade shows, setting up workshops and promoting general sales within the assigned territory. Candidates should expect significant travel activity. *Qualifications* The ideal candidates will have some or all of the attributes listed below - PhD in biological, chemical or physical sciences – preferably in protein crystallography - Solid scientific understanding of protein crystallography - Very good communication and presentation skills - Willing to perform significant travel *Previous experience should include some of the following:* - Sales experience, from life science tools industry, serving large academic and industrial accounts - Technical support experience within the life science tools business - Working as protein crystallographer in a large lab or industrial group
[ccp4bb] Fwd: Job Posting: Technical Key Account Managers (3 positions) at Microlytic
*Technical Key Account Managers - 3 positions currently available* To meet increasing customer demand Microlytic is hiring individuals with a strong scientific background for serving our growing base of large academic and industrial accounts in the USA. The technical key account managers will be traveling to customer sites to give seminars about Microlytic’s products, facilitate integration of products within customer workflow, and solve technical issues with customers. The candidate should reside in or be willing to relocate to one of the following three territories: (1) Greater San Francisco (1 position) (2) New York City/New Jersey (Philadelphia also considered) (1 position) (3) Maryland/DC/Virginia/North Carolina (1 position) *Job description* The primary focus of these positions is serving key accounts, specifically responding to customer requests, assisting customers with product integration, providing technical support and managing sales. Additionally, the candidates will be responsible for organizing trade shows, setting up workshops and promoting general sales within the assigned territory. Candidates should expect significant travel activity. *Qualifications* The ideal candidates will have some or all of the attributes listed below - PhD in biological, chemical or physical sciences – preferably in protein crystallography - Solid scientific understanding of protein crystallography - Very good communication and presentation skills - Willing to perform significant travel *Previous experience should include some of the following:* - Sales experience, from life science tools industry, serving large academic and industrial accounts - Technical support experience within the life science tools business - Working as protein crystallographer in a large lab or industrial group Please submit a coverletter and resume to j...@microlytic.com or visit our careers page at https://www.microlytic.com/careers.
Re: [ccp4bb] Rfree is 20%,why still green and red density?
I disagree with Herman that 3 sigma features are nothing to worry about. Indeed, I think this is one of the deepest and most disturbing problems with macromolecular crystallography in general. Why can't we explain our data to within experimental error? If you think all the green and red stuff left over at the end of refinement is just noise, then I challenge you to re-collect your dataset and do the refinement again. You will find that the features wiggle a bit, but the difference peaks consistently pop up in the same place. Noise doesn't do that. But, if the only thing you are worried about is validation (aka is my structure worse than average?), then yes, once you get to the point when you can't find any way to build into the tallest difference feature you've got without making your R/Rfree worse, then you have reached the limits of current modelling technology and are basically done with building and refinement. Might as well deposit what you've got and wait for some future breakthrough to finally come up with an Fcalc that can explain your Fobs to within sigma(Fobs). -James Holton MAD Scientist On 6/26/2013 12:08 AM, herman.schreu...@sanofi.com wrote: Dear Jiang Yan, The Matthews function is based on an average protein crystal with 50% solvent. However, crystals do exist with as little as 25% solvent or as much as 75% solvent, so if your structure refines to an Rfree of 20%, your structure is solved and you have a crystal with a high percentage of solvent (which may explain your low Rfree). Maps are usually contoured at sigma levels, based on the variation in the electron density map. So with an Rfree of 20%, your difference map will be very flat with and the sigma will be very low. Also the 3 sigma level usually used for difference maps will be very low and statistically, there are always some peaks at plus or minus 3 sigma, but they are nothing to worry about. Best, Herman *Von:* CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] *Im Auftrag von *?? *Gesendet:* Mittwoch, 26. Juni 2013 06:05 *An:* CCP4BB@JISCMAIL.AC.UK *Betreff:* [ccp4bb] Rfree is 20%,why still green and red density? Hi everyone, I now meet some problems when trying to solve structure.Space group is P6422, and Mathews function shows there are 4 molecules in one asymmetry unit. However, Phenix-autobuild shows only 2 molecules in on one asymmetry unit, after refinement, Rfree=20%,(resolution is 2.8A). Although AA fit the map well, there are still some green and red density. I wonder if anyone met this problem before? Any suggestion is welcome. Best, Jiang Yan
Re: [ccp4bb] ctruncate bug?
On 22 June 2013 19:39, Douglas Theobald dtheob...@brandeis.edu wrote: So I'm no detector expert by any means, but I have been assured by those who are that there are non-Poissonian sources of noise --- I believe mostly in the readout, when photon counts get amplified. Of course this will depend on the exact type of detector, maybe the newest have only Poisson noise. Sorry for delay in responding, I've been thinking about it. It's indeed possible that the older detectors had non-Poissonian noise as you say, but AFAIK all detectors return _unsigned_ integers (unless possibly the number is to be interpreted as a flag to indicate some error condition, but then obviously you wouldn't interpret it as a count). So whatever the detector AFAIK it's physically impossible for it to return a negative number that is to be interpreted as a photon count (of course the integration program may interpret the count as a _signed_ integer but that's purely a technical software issue). I think we're all at least agreed that, whatever the true distribution of Ispot (and Iback) is, it's not in general Gaussian, except as an approximation in the limit of large Ispot and Iback (with the proviso that under this approximation Ispot Iback can never be negative). Certainly the assumption (again AFAIK) has always been that var(count) = count and I think I'm right in saying that only a Poisson distribution has that property? No, its just terminology. For you, Iobs is defined as Ispot-Iback, and that's fine. (As an aside, assuming the Poisson model, this Iobs will have a Skellam distribution, which can take negative values and asymptotically approaches a Gaussian.) The photons contributed to Ispot from Itrue will still be Poisson. Let's call them something besides Iobs, how about Ireal? Then, the Poisson model is Ispot = Ireal + Iback' where Ireal comes from a Poisson with mean Itrue, and Iback' comes from a Poisson with mean Iback_true. The same likelihood function follows, as well as the same points. You're correct that we can't directly estimate Iback', but I assume that Iback (the counts around the spot) come from the same Poisson with mean Iback_true (as usual). So I would say, sure, you have defined Iobs, and it has a Skellam distribution, but what, if anything, does that Iobs have to do with Itrue? My point still holds, that your Iobs is not a valid estimate of Itrue when IspotIback. Iobs as an estimate of Itrue requires unphysical assumptions, namely that photon counts can be negative. It is impossible to derive Ispot-Iback as an estimate for Itrue (when IspotIback) *unless* you make that unphysical assumption (like the Gaussian model). Please note that I have never claimed that Iobs = Ispot - Iback is to be interpreted as an estimate of Itrue, indeed quite the opposite: I agree completely that Iobs has little to do with Itrue when Iobs is negative. In fact I don't believe anyone else is claiming that Iobs is to be interpreted as an estimate of Itrue either, so maybe this is the source of the misunderstanding? Certainly for me Ispot - Iback is merely the difference between the two measurements, nothing more. Maybe if we called it something other than Iobs (say Idiff), or even avoided giving it a name altogether that would avoid any further confusion? Perhaps this whole discussion has been merely about terminology? I'm also puzzled as to your claim that Iback' is not Poisson. I don't think your QM argument is relevant, since we can imagine what we would have detected at the spot if we'd blocked the reflection, and that # of photon counts would be Poisson. That is precisely the conventional logic behind estimating Iback' with Iback (from around the spot), it's supposedly a reasonable control. It doesn't matter that in reality the photons are indistinguishable --- that's exactly what the probability model is for. I'm not clear how you would block the reflection? How could you do that without also blocking the background under it? A large part of the background comes from the TDS which is coming from the same place that the Bragg diffraction is coming from, i.e. the crystal. I know of no way of stopping the Bragg diffraction without also stopping the TDS (or vice versa). Indeed the theory shows that there is in reality no distinction between Bragg diffraction and TDS; they are just components of the total scattering that we find convenient to imagine as separate in the dynamical model of scattering (see http://people.cryst.bbk.ac.uk/~tickle/iucr99/s61.html for the relevant equations). Any given photon experiences the whole crystal on its way from the source to the detector (in fact it experiences more than that: it traverses all possible trajectories simultaneously, it's just that the vast majority cancel by destructive interference). The resulting wave function of the photon only collapses to a single point on hitting the detector, with a frequency proportional
[ccp4bb] REFMAC5 and read-only file systems
Howdy Y'all,
I have a lab where REFMAC jobs are blowing up trying to access the
monomers database. The logfile looks like this:
Open failed: Unit: 7, File:
/programs/x86_64-linux/ccp4/6.3.0/ccp4-6.3.0/lib/data/monomers/list/mon_lib_list.cif
(logical:
/programs/x86_64-linux/ccp4/6.3.0/ccp4-6.3.0/lib/data/monomers/list/mon_lib_list.cif)
BFONT COLOR=#FF!--SUMMARY_BEGIN--
Last system error message: Illegal seek
Refmac_5.7.0032: Open failed: File:
/programs/x86_64-linux/ccp4/6.3.0/ccp4-6.3.0/lib/data/monomers/list/mon_lib_list.cif
Refmac_5.7.0032: Open failed: File:
/programs/x86_64-linux/ccp4/6.3.0/ccp4-6.3.0/lib/data/monomers/list/mon_lib_list.cif
CCP4/REFMAC are being run from a read-only NFS volume. The NFS server
is RHEL 5 and the NFS client is RHEL 6. (I can get further details if
necessary.)
It looks like REFMAC is trying to open
$CLIBD_MON/list/mon_lib_list.cif read-write and then read-only, but
with the flag to create it, which is causing the system to return -1
for both open calls.
stat(/programs/x86_64-linux/ccp4/6.3.0/ccp4-6.3.0/lib/data/monomers/list/mon_lib_list.cif,
{st_mode=S_IFREG|0644, st_size=1078257, ...}) = 0
fstat(2, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
fstat(0, {st_mode=S_IFREG|0600, st_size=750, ...}) = 0
open(/programs/x86_64-linux/ccp4/6.3.0/ccp4-6.3.0/lib/data/monomers/list/mon_lib_list.cif,
O_RDWR|O_CREAT, 0666) = -1 EROFS (Read-only file system)
open(/programs/x86_64-linux/ccp4/6.3.0/ccp4-6.3.0/lib/data/monomers/list/mon_lib_list.cif,
O_RDONLY|O_CREAT, 0666) = -1 EROFS (Read-only file system)
lseek(1, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
lseek(1, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(1, Open failed: Unit: 7, File: /..., 212) = 212
lseek(1, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
lseek(1, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(1, BFONT COLOR=\#FF\!--SUM..., 46) = 46
dup(2) = 5
fcntl(5, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE)
fstat(5, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2b4842405000
lseek(5, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(5, Last system error message: Illeg..., 40) = 40
close(5)= 0
munmap(0x2b4842405000, 4096)= 0
write(2, Refmac_5.7.0032: Open failed:..., 147) = 147
What's confusing is that we have almost this exact same set up (RO NFS
sharing the software to many workstations) in _hundreds_ of labs and
none of them are having this problem.
I suppose I will go to the REFMAC/CCP4lib source next. Any other ideas
on how we can proceed?
Thanks.
-ben
--
| Ben Eisenbraun
| SBGrid Consortium | http://sbgrid.org |
| Harvard Medical School | http://hms.harvard.edu |
Re: [ccp4bb] AW: [ccp4bb] insertion code problem
Last time I checked pdbset doesn't renumber the LINK, CISPEP, SSBOND records at the same time (but maybe it was fixed). -- Ian On 26 June 2013 07:41, Francois Berenger beren...@riken.jp wrote: I think pdbset from CCP4 can renumber a PDB and hence get rid of the uggly insertion codes. On 06/26/2013 03:33 PM, herman.schreu...@sanofi.com wrote: Dear Rain, Insertion codes are still a sore point for many CCP4 programs and one of the reasons I prefer Buster over Refmac. Refmac5 does not remove insertion codes so I suspect the problem was with autoMR. The easiest is to superimpose your search model with insertion codes onto the pdb file which came out of the autoMR procedure. You could use lsqkab, but I think you can also do it in Coot. Then you continue refinement with this superimposed model. However, when I refined some structure with insertion codes in Refmac last week, Refmac created LINKR gap records for the inserted residues, cutting all peptide links. With an editor I had to change the gap to TRANS and then it worked. Good luck! Herman --**--** *Von:* CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] *Im Auftrag von *MAGGIE *Gesendet:* Mittwoch, 26. Juni 2013 04:07 *An:* CCP4BB@JISCMAIL.AC.UK *Betreff:* [ccp4bb] insertion code problem Dear group, I have a insertion code question. I used molecular replacement (CCP4, autoMR) to solve two structures: one is monomer, and another one is tetramer. The model I used is one chain of a dimer and the model has insertion code. After molecular replacement and refinement using refmac5 in CCP4, the new structures lost the insertion code, and the residues were numbered consecutively. Can anyone tell me how to keep the insertion code in the new structures? Thank you, Rain
Re: [ccp4bb] REFMAC5 and read-only file systems
On 06/27/2013 05:34 PM, Ben Eisenbraun wrote:
Howdy Y'all,
Howdy.
It looks like REFMAC is trying to open
$CLIBD_MON/list/mon_lib_list.cif read-write and then read-only,
Yes, it does... curious. In libcheck.f's WRT_LIB_LIST_NEW_STYLE, should
be OPENFR(), I imagine.
but
with the flag to create it, which is causing the system to return -1
for both open calls.
stat(/programs/x86_64-linux/ccp4/6.3.0/ccp4-6.3.0/lib/data/monomers/list/mon_lib_list.cif,
{st_mode=S_IFREG|0644, st_size=1078257, ...}) = 0
fstat(2, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
fstat(0, {st_mode=S_IFREG|0600, st_size=750, ...}) = 0
open(/programs/x86_64-linux/ccp4/6.3.0/ccp4-6.3.0/lib/data/monomers/list/mon_lib_list.cif,
O_RDWR|O_CREAT, 0666) = -1 EROFS (Read-only file system)
open(/programs/x86_64-linux/ccp4/6.3.0/ccp4-6.3.0/lib/data/monomers/list/mon_lib_list.cif,
O_RDONLY|O_CREAT, 0666) = -1 EROFS (Read-only file system)
lseek(1, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
lseek(1, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(1, Open failed: Unit: 7, File: /..., 212) = 212
lseek(1, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
lseek(1, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(1, BFONT COLOR=\#FF\!--SUM..., 46) = 46
dup(2) = 5
fcntl(5, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE)
fstat(5, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2b4842405000
lseek(5, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(5, Last system error message: Illeg..., 40) = 40
close(5)= 0
munmap(0x2b4842405000, 4096)= 0
write(2, Refmac_5.7.0032: Open failed:..., 147) = 147
What's confusing is that we have almost this exact same set up (RO NFS
sharing the software to many workstations) in _hundreds_ of labs and
none of them are having this problem.
I wonder if this is a (server-side?) SELinux issue.
I suppose I will go to the REFMAC/CCP4lib source next. Any other ideas
on how we can proceed?
restart the NFS? :-)
Other than that, fingers crossed for a one-letter fix (just tried it and
it didn't seem to damage anything (but then again the owner of the
process was the owner of mon_lib_list.cif...))
HTH,
Paul.
[ccp4bb] Postdoctoral Researcher, Membrane Structural and Functional Biology, Caffrey Lab, Trinity College Dublin, Ireland
Postdoctoral Research Fellow Membrane Structural and Functional Biology – Caffrey Lab Trinity College Dublin, Ireland Post Summary Applications for the post of Postdoctoral Research Fellow in the Membrane Structural and Functional Biology Research Group are invited. The major theme within the Group is structure and function of membrane proteins by crystallographic means. A project is underway to solve the high-resolution structure of membrane proteins that bind, signal through and metabolize lipids. Several are implicated in diabetes, obesity, cancer and pain and in communicable and other non-communicable diseases. The goal of the project is to use the structural information to understand how these membrane proteins function and interact at a molecular level and ultimately to assist in the development of new and improved therapeutics. An exciting postdoctoral research position is available in the Group to work on this project. We are looking for a highly motivated, creative and hardworking individual with experience in biochemistry and molecular biology to join our multidisciplinary team at Trinity in a lab that offers superb facilities. Individuals interested in moving into the membrane protein field are encouraged to apply. Person Specification The candidate must have a Ph.D. in biochemistry, biophysics, molecular biology or a related field. Demonstrated success in all aspects of molecular biology, recombinant protein production, purification, and functional characterization is required. Experience with membrane protein over-expression, crystallization, and structure-function studies is desirable. The candidate should be a highly motivated and creative individual who enjoys working as part of a collaborative, multidisciplinary team. Strong leadership, communication and teaching skills are decided assets. Salary €37,750 - €42,394 per annum depending on experience Closing Date 1 July 2013 Principal Investigator Prof. Martin Caffrey - mailto:martin.caff...@tcd.ie martin.caff...@tcd.ie http://www.tcd.ie/Biochemistry/research/m_caffrey.php http://www.tcd.ie/Biochemistry/research/m_caffrey.php Application Procedure Candidates are asked to submit a letter detailing education, training and laboratory experience. In the letter the candidate should outline why they feel they are suitable for the position in an interdisciplinary group that will involve extensive interaction with collaborators and data collection at facilites around the globe. The letter of application must be accompanied by a full CV to include the names and contact details of two referees (email addresses and phone numbers to be provided). At least one referee should be an individual the candidate has worked with and who has agreed to provide a letter of reference on the candidate’s behalf. Applications should be emailed to: Shuang Leng le...@tcd.ie Martin Caffrey Membrane Structural and Functional Biology Group School of Medicine and School of Biochemistry Immunology Trinity Biomedical Sciences Institute Trinity College Dublin 152-160 Pearse Street, Dublin 2, Ireland Email: mailto:martin.caff...@tcd.ie martin.caff...@tcd.ie Website: http://www.tcd.ie/Biochemistry/research/m_caffrey.php http://www.tcd.ie/Biochemistry/research/m_caffrey.php Phone: office + 353 (0)1 896 4253; mobile + 353 (0)86 818 7704
Re: [ccp4bb] AW: [ccp4bb] insertion code problem
Thank you, guys. My problem has been solved. AutoMR in CCP4 removed the insertion code. But I used it before, and it did not mess up with the insertion code at those times. Rain On Thu, Jun 27, 2013 at 12:56 PM, Ian Tickle ianj...@gmail.com wrote: Last time I checked pdbset doesn't renumber the LINK, CISPEP, SSBOND records at the same time (but maybe it was fixed). -- Ian On 26 June 2013 07:41, Francois Berenger beren...@riken.jp wrote: I think pdbset from CCP4 can renumber a PDB and hence get rid of the uggly insertion codes. On 06/26/2013 03:33 PM, herman.schreu...@sanofi.com wrote: Dear Rain, Insertion codes are still a sore point for many CCP4 programs and one of the reasons I prefer Buster over Refmac. Refmac5 does not remove insertion codes so I suspect the problem was with autoMR. The easiest is to superimpose your search model with insertion codes onto the pdb file which came out of the autoMR procedure. You could use lsqkab, but I think you can also do it in Coot. Then you continue refinement with this superimposed model. However, when I refined some structure with insertion codes in Refmac last week, Refmac created LINKR gap records for the inserted residues, cutting all peptide links. With an editor I had to change the gap to TRANS and then it worked. Good luck! Herman --**--** *Von:* CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] *Im Auftrag von *MAGGIE *Gesendet:* Mittwoch, 26. Juni 2013 04:07 *An:* CCP4BB@JISCMAIL.AC.UK *Betreff:* [ccp4bb] insertion code problem Dear group, I have a insertion code question. I used molecular replacement (CCP4, autoMR) to solve two structures: one is monomer, and another one is tetramer. The model I used is one chain of a dimer and the model has insertion code. After molecular replacement and refinement using refmac5 in CCP4, the new structures lost the insertion code, and the residues were numbered consecutively. Can anyone tell me how to keep the insertion code in the new structures? Thank you, Rain
Re: [ccp4bb] R too low?
Hello Everone, Thanks for all the help. The key to finding the problem was following up on Tim Gruene's suggestion to compare the data sets directly. It appears that an error occurred during conversion from I to F - until I find the log file for the conversion, I can't guess what was done. Longer version: When I compared the good and bad data sets, R was about 0.15, instead of the 0.07 I was expecting. Yesterday, I reintegrated the images using the same program that generated the bad data (CrystalClear - sorry to be opaque but I didn't want to inspire a lot of discussion about various integration programs when I was pretty sure the program wasn't at fault.), and ended up with a data set that agreed with the good data (XDS). (Yeah, I should've done this before sending a message to ccp4bb). The R for scaling the new CC dataset and the XDS dataset was 0.07 and refinement behaved as expected and agreed with that of XDS. I have been unable to find the log file for the conversion from integrated I to mtz F (it's on some computer somewhere, I'm sure), but I did find the original ScalAveraged.ref file for the bad data and reimported that using the import scaled data task in ccp4i. That data set is also good. So, I conclude that something was done wrong during import to ccp4. Tim suggested that perhaps the data was converted twice to amplitudes, perhaps that's it. Anyway, now I know where the problem arose. Several people suggested checking statistics using phenix polygon and other analysis tools in phenix. I agree that those are nice tools (and we had done that), however, they only tell you how your statistics are different from the median and often don't give any hints as to how any problems might have arisen. Again, thanks for all the help. Sue On Jun 26, 2013, at 8:54 AM, Tim Gruene wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Sue, if you made your rmsd (bonds) 20-30 times smaller I would agree they were not too loose. 0.14A is pretty high. So two suggestions: a) check the molprobity report of your PDB if its geometry is sane b) check the CC plot of one data set against the other one to check if the problem is due to two different data or due to the PDB file (xprep can do this plot conveniently). Did you check if you converted the data twice to amplitudes, or maybe not at all? Best, Tim On 06/26/2013 05:44 PM, Roberts, Sue A - (suer) wrote: Hello Everyone I have two data sets, from the same crystal form (space group P32) of the same protein, collected at 100 K at SSRL, about 2.2 A resolution, that refining to R = 0.14, Rf = 0.26 (refmac/TLS). This is a molecular replacement solution, from a model with about 40% homology (after MR density was apparent for some missing or misbuilt residues, so I don't think the structure is stuck in the wrong place. The Fo-Fc map is essentially featureless. The 2Fo-Fc map doesn't look as good as it should - for instance, there are very few water molecules to be found. The data reduction statistics look OK, the resolution cutoff is pretty conservative. There is one molecule in the asymmetric unit, so no NCS. There is no twinning either. It seemed to me that the R is too low, not Rf too high. More normally, R ends up about .18 - .20 for a data set at this resolution. I reprocessed the images with a different data processing program and redid the MR. The data reduction statistics look similar, the resolution is the same, but now the structure refines to R = 0.20, Rf = 0.24 (same free R set of reflections chosen, still refmac/TLS.) The maps look more normal. Further rebuilding took us to R = 0.18, Rf = 0.22 So, the question I have (and that I've been asked by the student and PI) is: What was the problem with the original data set? What should I be looking for in the data reduction log files, for instance, or in the refinement log? The large R - free R spread is characteristic of overfitting, but the geometry is not too loose (rmsd bonds = 0.14), there are plenty of reflections (both working and free). Can anyone point me toward a reason R would be low? Thanks Sue Dr. Sue A. Roberts Dept. of Chemistry and Biochemistry University of Arizona 1041 E. Lowell St., Tucson, AZ 85721 Phone: 520 621 8171 or 520 621 4168 s...@email.arizona.edu http://www.cbc.arizona.edu/xray or http://www.cbc.arizona.edu/facilities/x-ray_diffraction - -- - -- Dr Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFRyw6vUxlJ7aRr7hoRAq4HAKCJJf+FfRVT7u3UOrty0vTOFMN+mgCgtHz8 MYe+23hH+MKy/7E/h2w25+Q= =WAsD -END PGP SIGNATURE- Dr. Sue A. Roberts Dept. of Chemistry and Biochemistry University of Arizona 1041 E. Lowell St., Tucson, AZ 85721 Phone: 520 621
