Re: [ccp4bb] Off-topic-Cleavage with TEV protease
Also keep in mind that many of the purchased TEVs are formulated with some reducing agent (e.g. AcTEV comes in a buffer with 5mM DTT, if I recall correctly). So unless the enzyme is buffer exchanged beforehand, there will be some reducing agent introduced alongside it, depending on the dilution. HTH, -Tim On Mon, Apr 16, 2012 at 4:32 PM, Jason Forse wrote: > I've run into the same problem, and found David Waugh's FAQ to be a great > resource: > http://mcl1.ncifcrf.gov/waugh_tech.html > They use a 3mM buffer of 10:1 reduced:oxidized glutathione. I've tried that > and it cleaves my protein without reducing reducing the disulfide bridges. > > I'll second someone else's suggestion to add more TEV. That's worked for me > as well, as long as the TEV's relatively fresh and there isn't too much > reducing agent introduced along with it. > > Jason
Re: [ccp4bb] Molprobity Clashscore
On Thu, Jan 12, 2012 at 8:11 AM, Pavel Afonine wrote: > >> Who needs hydrogens? > > > may be you need to read this (for example): > > http://www.phenix-online.org/papers/dz5209_reprint.pdf > While this reference is useful, it neglects the role of prior chemical forces (vdW and electrostatics, for example) in positioning hydrogen atoms. The X-ray/neutron data is often not sufficient to uniquely define an atomic position (hydrogen or otherwise), which can be especially problematic for atoms with several degrees of freedom, like water or a hydroxyl hydrogen. Force fields have come a long way in defining these forces with reasonable chemical accuracy in the past 10 years, and there is work to show this does benefit X-ray/neutron refinement (e.g. http://dx.doi.org/10.1016/j.str.2011.01.015) - suggesting its worthwhile to include this information in X-ray target functions. At the very least, it should not be left out of the discussion, especially when hydrogen atoms are concerned!!! Regards, Tim
Re: [ccp4bb] Babinet solvent correction [WAS: R-free flag problem]
On Thu, 28 Oct 2010 16:56:42 +0200 Dirk Kostrewa wrote: > > In the Babinet bulk solvent correction, no bulk solvent phases are > used, it is entirely based on amplitudes and strictly only valid if > the phases of the bulk solvent are opposite to the ones of the > protein. And as Sasha Urzhumtsev pointed out, this assumption is only > valid at very low resolution. > > The mask bulk solvent correction is a vector sum including the phases > of the bulk solvent mask, which makes a difference at medium > resolution (up to ~4.5 A, or so). > > As far as I can see, your formulas given below do not distinguish > between amplitude (modulus) and vector bulk solvent corrections. > Sorry - I didn't make that clear. The formulas all use complex structure factors, as in the paper. > Personally, I really don't see any physical sense in using both > corrections together, except for compensating any potential scaling > problems at low resolution. > We're not using "both corrections together" - the Babinet *method* is used to add in the bulk solvent contribution computed using the flat mask *model* (or the polynomial/Gaussian model in the paper). The protein structure factors (Fc) are not used in the bulk solvent correction - nor, in my opinion, should they be (as I attempted to point out in my previous email). Regards, Tim -- - Tim Fenn f...@stanford.edu Stanford University, School of Medicine James H. Clark Center 318 Campus Drive, Room E300 Stanford, CA 94305-5432 Phone: (650) 736-1714 FAX: (650) 736-1961 -
Re: [ccp4bb] Babinet solvent correction [WAS: R-free flag problem]
On Sat, 23 Oct 2010 10:05:15 -0700 Pavel Afonine wrote: > Hi Tim, > > ...but I hope this answers the question: > Babinet's vs. the flat model? Use them together! ;) > > > thanks a lot for your reply. > > Could you please explain the *physical* meaning of using both > models together? I can try! Typically, we model the bulk solvent using a real space mask that is set to 1 in the bulk solvent region and 0 in the protein. This gets Fourier transformed, symmetrized and added in to the scattering factors from the molecule (Equation 1 in the paper, page 6 in your presentation): Ftot = Fc + ks*Fs*exp(-Bs*s^2/4) which works great and is how things are usually coded in most macromolecular software, no problems or arguments there. However, we can come from the opposite - but equivalent! - direction of Babinet's principle, which tells us the bulk solvent can also be modeled by inverting everything: set the bulk solvent region to 0 and the protein region to 1 in the real space mask, apply a Fourier transform to that and then invert the phase: Ftot = Fc - ks*Fm*exp(-Bs*s^2/4) (I'm using Fm to distinguish it from Fs, due to the inversion of 0's and 1's in the real space mask) This is equation 2 in the paper. So we're still using the flat model to compute Fm, and we're using Babinet's principle to add it in to the structure factors - although its better described as adding the inverse (thus the minus sign in the second equation) of the complement (Fm rather than Fs). These two equations are exactly equivalent, without any loss of generality. So, I would argue the flat model and Babinet's are very much congruous. Also take a look at the description/discussion in the paper regarding Figure 2 (which helped me think about things at first). The big difference is that Babinet's is usually applied as: Ftot = Fc - ks*Fc*exp(-Bs*s^2/4) which, I would argue, isn't quite right - the bulk solvent doesn't scatter like protein, but it does get the shape right. Which I think is why Fokine and Urzhumtsev point out that at high resolution this form would start to show disagreement with the data. I haven't looked at this explicitly though, so we still haven't answered that question! We didn't want to spend much time on it in the paper, our main goal was to try out the differentiable models we describe. The Babinet trick was a convenient way to make coding easier. Anyway, I hope this helps explain it a bit more, and again: sorry for the long-windedness. Regards, Tim -- - Tim Fenn f...@stanford.edu Stanford University, School of Medicine James H. Clark Center 318 Campus Drive, Room E300 Stanford, CA 94305-5432 Phone: (650) 736-1714 FAX: (650) 736-1961 -
Re: [ccp4bb] Babinet solvent correction [WAS: R-free flag problem]
On Fri, 22 Oct 2010 13:38:07 -0700 Ethan Merritt wrote: > > Unfortunately for the current discussion, I do not find any practical > comparison to Babinet models in either paper. Both start with the > implicit assumption that a flat, masked model is better and then > proceed to explore how best to determine its parameters. The Fokine > and Urzhumtsev paper does state that "the [Babinet] exponential > scaling model is handicapped at higher resolution", but does not > present any examples or comparisons to document what effect this has > in practice. > > The same is true for the very recent paper by Fenn, Schneiders, and > Brunger Acta Cryst. (2010). D66, 1024-1031 > [ doi:10.1107/S0907444910031045 ] This paper presents the theoretical > basis for the Babinet treatment and for several recent hybrid mask > treatments that get away from describing the solvent region as > "flat". But the paper does not include a Babinet model in the tables > of comparative results. > > Do you know of any published or unpublished results that compare > the R factors achieved by Babinet treatment with those obtained from > the state-of-the-art mask models? > > I'll cc this to Tim Fenn in case he wants to chime in with additional > data that wasn't included in the recent paper. > Sorry for my late reply, and I'll try to explain a little more of our thinking in the paper you brought up. We don't have data to the effect you're asking about, but I feel the implementation outlined in the paper is the combination of the flat model *and* Babinet's principle. When we were initially thinking about how to go about things, we drew out a physical picture - which we liked so much we included in the paper as Figure 2. This made it clear to us that the phase of Fm - which is just one minus the realspace bulk solvent mask as it is usually generated, should be inverted, *not* Fc. And the definition of Babinet's, I think, backs this up: the diffraction of the bulk solvent that we want to add in is equivalent to adding the inverse of its complement, which is the inverse of the protein region as if it scattered as bulk solvent (NOT as protein). Some history that also explains how we got to this: when Mike and I first tinkered with bulk solvent methodology, we had an admittedly slow implementation - we would expand the model to P1, then generate the solvent mask. This got us to our primary motivation with the new mask definitions: they were differentiable, but we wanted to speed things up while avoiding the need to introduce asymmetric unit definitions in our code (yes, I'm that lazy) so we could apply symmetry in reciprocal space, which is must faster. So we started thinking of inverting the mask, or just using a protein mask (then we wouldn't care where the boundary of the asymmetric unit is - quiz question: why?), which naturally led us to discussions of Babinet's and the realization that it wasn't that crazy of an idea. So I think the implementation has a few advantages, since it combines the Babinet principle with the flat model (and the new models, which have some nice bonuses with respect to atomic gradients), makes coding easy and it runs fast (I have some timings to illustrate the latter, I'd be glad to show them to anyone thats interested). Sorry for the long-windedness, but I hope this answers the question: Babinet's vs. the flat model? Use them together! ;) Regards, Tim -- - Tim Fenn f...@stanford.edu Stanford University, School of Medicine James H. Clark Center 318 Campus Drive, Room E300 Stanford, CA 94305-5432 Phone: (650) 736-1714 FAX: (650) 736-1961 -
Re: [ccp4bb] Off-topic: Univ California boycott of Nature publishing group
On Tue, 8 Jun 2010 21:50:10 -0700 "William G. Scott" wrote: > > Sorry about the off-topic nature (so to speak) of this post, > especially given that it is not yet Friday, but I am interested what > our community thinks of this: > > http://library.ucsc.edu/sites/default/files/Nature_Faculty_Letter.pdf > There has been a rather extensive discussion on slashdot: http://science.slashdot.org/story/10/06/09/213256/Univ-of-California-Faculty-May-Boycott-Nature-Publisher Also take a gander at Donald Knuth's section "crisis in scientific publishing" on his webapge: http://www-cs-faculty.stanford.edu/~uno/news03.html with a link to an excellent letter he sent to Journal of Algorithms a few years ago: http://www-cs-faculty.stanford.edu/~uno/joalet.pdf -Tim -- ----- Tim Fenn f...@stanford.edu Stanford University, School of Medicine James H. Clark Center 318 Campus Drive, Room E300 Stanford, CA 94305-5432 Phone: (650) 736-1714 FAX: (650) 736-1961 -
Re: [ccp4bb] best linux for laptops?
On Fri, 4 Sep 2009 14:57:21 -0700 Bernhard Rupp wrote: > Dear All, > > the overwhelming consensus is ubuntu, largely for > wide variety of drivers incl. wireless and nvidia (which I can > confirm was a > *...@%! nightmare under RH) > Just to clarify, most drivers are available for fedora/RH, just not in the standard repositories, partly for legal reasons and primarily due to the hard-line FSF/OSI-stuff-only-please approach fedora takes to managing the distribution. rpmfusion.org has pretty much everything fedora won't or can't include, and takes one click to set up. ubuntu and fedora are pretty much identical otherwise. -Tim -- ----- Tim Fenn f...@stanford.edu Stanford University, School of Medicine James H. Clark Center 318 Campus Drive, Room E300 Stanford, CA 94305-5432 Phone: (650) 736-1714 FAX: (650) 736-1961 -
Re: [ccp4bb] LINKR in refmac
On Fri, 14 Aug 2009 13:24:16 -0700 Jan Abendroth wrote: > How can I tell refmac to maintain the peptide link? > Here is what I tried - the numbers above just for orientation > > 1 2 3 4 5 6 > 7 8 > 12345678901234567890123456789012345678901234567890123456789012345678901234567890 > LINKRC ASN B 729 N GLY B 741 ASN-GLY > > refmac comments in the log file ... however, still pulls the residues > apart. WARNING : description of link:ASN-GLY is not in the dictionary > link will be created with bond_lenth = 1.260 > > So, in my understanding it comes down to the question: > how is a peptide bond referenced to in the dictionary? > take a look at the data_link_list loop in mon_lib_list.cif (there may be an easier way to view this info): TRANS..peptide ..peptide default-peptide-link PTRANS ..peptide PRO .. default-peptide-link_pro NMTRANS ..peptide PRO .. default-peptide-link_cn CIS ..peptide ..peptide cis-peptide-link PCIS ..peptide PRO .. cis-peptide-link_pro NMCIS..peptide PRO .. cis-peptide-link_cn so you probably want TRANS. HTH, Tim -- --------- Tim Fenn f...@stanford.edu Stanford University, School of Medicine James H. Clark Center 318 Campus Drive, Room E300 Stanford, CA 94305-5432 Phone: (650) 736-1714 FAX: (650) 736-1961 -
Re: [ccp4bb] From oscillation photographs to seeing specific sections of reciprocal lattice.
On Thu, 25 Jun 2009 11:39:29 -0700 James Holton wrote: > A long time ago, I wrote a little program for turning spot picks into > a PDB file that you could load up and rotate around in a graphics > program (such as O, at the time): > http://bl831.als.lbl.gov/~jamesh/pickup/spt2xyz.com > this one works on the *.spt files that comes out of MOSFLM. You can > concatenate *.spt files for each of your images to get the full data > set represented. > I also wrote one that works on ADSC images if you have the DPS > program installed: > http://bl831.als.lbl.gov/~jamesh/pickup/adsc2pdb.com > but it only works for the "common" coordinate system convention we > use at ALS and SSRL. Not sure about other beamlines. > > The algorithm for converting spot positions into reciprocal space > is not exactly new, as it is at the core of any and every > autoindexing program. All you do is figure out the take-off angle of > the diffracted ray from the crystal and then calculate the coordinate > where this line intersects the Ewald sphere. Specifically, the > "distortion" is: distortion = lambda*sqrt((Xdet)^2+(Ydet)^2+(dist)^2) > where: > lambda - the x-ray wavelength in A > Xdet - X coordinate of the spot relative to the beam center (in > mm) Ydet - Y coordinate of the spot relative to the beam center > (in mm) dist- the crystal-to-film distance (from crystal to > direct-beam spot, in mm) > > You then use this "distortion" to compute the x-y-z coordinate of the > reciprocal-lattice point in reciprocal space: > x' = Xdet/distortion > y' = Ydet/distortion > z' = dist/distortion - 1/lambda > > Yes, there are x-y-z coordinates in reciprocal space. They all have > units of inverse Angstroms. Of course, these x',y',z' coordinates > are at the phi value of the image you picked spots on. To get the > coordinates at phi=0, you need to "un-roate" them: > x = x'*cos(phi)-z'*sin(phi) > y = y' > z = x'*sin(phi)+z'*cos(phi) > > where some people can probably tell that in this convention the phi > axis is right-handed and parallel to the "Ydet" axis of the detector. > > The last step is to multiply these x,y,z coordinates by some > reasonable scale factor and put them into a PDB file. Maybe put the > intensity in the B-factor column, so that you can color it. Then you > need to find a display program that can handle a million-atom PDB. > Does anyone have one of those? > > > Ideally, what one would like to do is make an electron density map > with pixel-to-pixel correspondence to the image. All you do is apply > the above formulas to each pixel, do a Lorentz-Polarization > correction, and then just render the data set as a map. > > Sounds like there are a couple of commercial programs that do this in > 2 dimensions. Problem with doing it in 3D is there are no programs > that can display an electron density map this big. In fact, I can't > even get CCP4 to write out map or mtz files bigger than 2 GB. I get > "filesize limit exceeded" errors (even though the filesystem can > handle large files). Is this a limitation of the 32-bit binaries? > Can anyone help me confirm that re-compiling CCP4 as 64-bit will fix > this? This error can be reproduced by trying to make a 2 A data set > for the largest unit cell in the PDB: > The limit on file sizes using fopen and the like for 32 bit systems is 2^31 bytes, unless you use fopen64 or use _FILE_OFFSET_BITS == 64 passed to the compiler (assuming you have LFS support, etc, etc): http://www.gnu.org/software/libc/manual/html_node/Opening-Streams.html#index-fopen64-931 on 64 bit machines, the file size limit is 2^63 bytes (this also depends on the file system type, just to make things even more complicated). Here's another easy way to test it: dd if=/dev/zero of=bigfile bs=1024 count=3145728 Hope this helps! -Tim -- - Tim Fenn f...@stanford.edu Stanford University, School of Medicine James H. Clark Center 318 Campus Drive, Room E300 Stanford, CA 94305-5432 Phone: (650) 736-1714 FAX: (650) 736-1961 -
Re: [ccp4bb] ANISOU
On Mon, 16 Mar 2009 11:01:34 +0800 Sheng Li wrote: > > Please read the coordinate file with alwyn's O, and then save it to > another file. The ANISOU lines will be removed. > only if you use s_a_i - pdb_read will preserve ANISOU. It might be easier to just grep them out: grep -v "^ANISOU" foo.pdb > bar.pdb -Tim
Re: [ccp4bb] COOT Problem
On Sat, 13 Dec 2008 09:33:11 + Paul Emsley wrote: > Ethan Lai wrote: > > Dear all, > > > > I have recently installed Coot version 0.5 on Fedora 9. However, > > when I tried to open a mtz file, the following error occurs. > > > >>> CCP4 library signal library_file:Bad mode (Error) > > raised in ccp4_file_readchar << > > > > Any advices? Thanks! > > > Something of a shot in the dark, but we have recently seen problems > (crashes) when using F8 binaries on a F9 machine. On switching to > the Ubuntu build things worked OK (this is IIUC). > > Ideally there should be a native F9 build of Coot. > Once coot gets through the review process: https://bugzilla.redhat.com/show_bug.cgi?id=472150 it will be available via yum for all "supported" fedora releases (F9 and F10 atm). -tim
Re: [ccp4bb] Crystallographic computing platform recommendations?
On Tue, 18 Nov 2008 18:04:11 + Kevin Cowtan <[EMAIL PROTECTED]> wrote: > From a system management point of view there is one very significant > benefit to Ubuntu: The LTS releases come out every 2 years and are > supported for 3 years. Compare this with Fedora: releases are only > supported for 18 months. > The comparable distribution to LTS is centos or the official rhel releases, which are on a 7 year support cycle. The standard ubuntu releases follow almost the same 18 month cycle as fedora. -Tim -- --------- Tim Fenn [EMAIL PROTECTED] Stanford University, School of Medicine James H. Clark Center 318 Campus Drive, Room E300 Stanford, CA 94305-5432 Phone: (650) 736-1714 FAX: (650) 736-1961 -
Re: [ccp4bb] Crystallographic computing platform recommendations?
On Tue, 18 Nov 2008 10:21:29 + Kevin Cowtan <[EMAIL PROTECTED]> wrote: > And I would give exactly the opposite advice, unless you are or have > a guru who can devote time to fixing all the little things which > still don't work under 64 bit OSs. > > (Does anyone else have any clues on why 64-bit compiled coot can't > calculate a map? I need to look into it, but have a huge backlog of > work at the moment.) > Try -fno-strict-aliasing, or dropping the optimization to -O0 or -O1. Fixed the exact same problem for me. I also noticed several of the m4 macros coot uses (mmdb/ssm/guile-gtk) are broken such that 32 and 64 bit libraries can get mixed up, so you may not be using a 64 bit binary. HTH, Tim -- --------- Tim Fenn [EMAIL PROTECTED] Stanford University, School of Medicine James H. Clark Center 318 Campus Drive, Room E300 Stanford, CA 94305-5432 Phone: (650) 736-1714 FAX: (650) 736-1961 -
Re: [ccp4bb] off-topic: Enzymology textbook recommendations?
On Thu, 11 Sep 2008 13:24:12 -0700 William Scott <[EMAIL PROTECTED]> wrote: > Hi Folks: > > I just found out that in a couple of weeks I am going to be teaching > a graduate student-level enzymology course. > > Can anyone recommend a good text, and possibly good websites > authored by people who are predisposed to consider plagiarism the > highest form of complement? > A few classics I wouldn't be caught without: "Catalysis in Chemistry and Enzymology" William P. Jencks "Enzymatic Reaction Mechanisms" Christopher Walsh -- ----- Tim Fenn [EMAIL PROTECTED] Stanford University, School of Medicine James H. Clark Center 318 Campus Drive, Room E300 Stanford, CA 94305-5432 Phone: (650) 736-1714 FAX: (650) 736-1961 -
Re: [ccp4bb] Hardware problem: "nVidia NV41 [Quadro FX 3450/4000 SDI]" on Redhat EL 5 (needed for stereo viewing)
On Mon, 18 Aug 2008 13:02:53 +0200 "Christian Rausch (Biol. Chemie)" <[EMAIL PROTECTED]> wrote: > > Thanks to everybody who helped with useful hints. > > The crucial point to solve this problem was actually to make sure > that exactly the same version of kernel binaries and sources are > installed. To make sure that the nvidia installer does not get > confused I removed all installed kernel binaries except those of the > running kernel. Then the source code of the driver could be compiled > without problem. > You can also use Axel Thimm's repositories, which include fedora/rhel rpms for nvidia drivers: http://atrpms.net -- ----- Tim Fenn [EMAIL PROTECTED] Stanford University, School of Medicine James H. Clark Center 318 Campus Drive, Room E300 Stanford, CA 94305-5432 Phone: (650) 736-1714 FAX: (650) 736-1961 -
Re: [ccp4bb] diffraction images images/jpeg2000
On Thu, 23 Aug 2007 10:46:51 -0700 James Holton <[EMAIL PROTECTED]> wrote: > > So would PNG be better? It does support 16 bit greyscale. Then > again, so does TIFF, and Mar already uses that. Why don't they use > the LZW compression feature of TIFF? Because of the patents on LZW (http://en.wikipedia.org/wiki/LZW#Patent_issues), I would guess. > > So, unless I am missing something, I think the best we are going to > get with lossless compression is about 2.5:1. At least, for > individual frames. Compressing a data set as a "video" sequence > might have substantial gains since only a few pixels change > significantly from frame-to-frame. Are there any lossless video > codecs out there? If so, can they handle 6144x6144 video? > Sure. CorePNG, for example, and it supports P-frame encoding. I still like netCDFv4 - its *designed* for this kind of thing, is an open standard and comes with many ready-to-go command line utilities and visualization programs. -Tim -- --------- Tim Fenn [EMAIL PROTECTED] Stanford University, School of Medicine James H. Clark Center 318 Campus Drive, Room E300 Stanford, CA 94305-5432 Phone: (650) 736-1714 FAX: (650) 736-1961 -
Re: [ccp4bb] possibility of other fabricated structures
On Thu, Aug 16, 2007 at 11:31:00PM -0400, Petr Leiman wrote: > A small, but very important excerpt from the original Randy Read's message > > "... Nature did not allow us to use the word "fabricated". Nor were we > allowed to discuss other structures from the same group, if they weren't > published in Nature." > > So, are there OTHER SUSPECT STRUCTURES from the same group or same authors > published elsewhere??? > Yes. I expect a similar letter, albeit to a different journal, soon. Regards, Tim -- --------- Tim Fenn [EMAIL PROTECTED] Stanford University, School of Medicine James H. Clark Center 318 Campus Drive, Room E300 Stanford, CA 94305-5432 Phone: (650) 736-1714 FAX: (650) 736-1961 -
Re: [ccp4bb] The CCP4 license is ambiguous
On Wed, 4 Jul 2007 23:21:33 -0700 Tim Fenn <[EMAIL PROTECTED]> wrote: > > I think the reason most folks have problems with the licensing on the > ccp4 *libraries* is that the ccp4 format for maps and reflection files > should be an *open* format - the way it stands now, without writing > your own library to access ccp4 files (and this is where ambiguity > sets in and I find the CCP4-type license completely lacking - can I > look at the source code from CCP4 and develop my own library based on > what I learn from the code? Does it also matter if I'm a commercial > versus academic user?), there is *no way* you can redistribute a > program that depends on CCP4 formatted files without simply including > said program in the CCP4 distribution. My apologies - this was overzealous and incorrect - although its still rather difficult to get the CCP4 libraries in a distributable form, since the license that covers the libraries aren't OSI/FSF approved. -Tim -- --------- Tim Fenn [EMAIL PROTECTED] Stanford University, School of Medicine James H. Clark Center 318 Campus Drive, Room E300 Stanford, CA 94305-5432 Phone: (650) 736-1714 FAX: (650) 736-1961 -
Re: [ccp4bb] The CCP4 license is ambiguous
On Wed, 4 Jul 2007 12:36:29 +0200 "George M. Sheldrick" <[EMAIL PROTECTED]> wrote: > The SHELX license agreement has had an 'indemnity clause' in it > for the last 30 years and no-one has complained about it yet! See: > http://shelx.uni-ac.gwdg.de/SHELX/applfrm.htm > I think the reason most folks have problems with the licensing on the ccp4 *libraries* is that the ccp4 format for maps and reflection files should be an *open* format - the way it stands now, without writing your own library to access ccp4 files (and this is where ambiguity sets in and I find the CCP4-type license completely lacking - can I look at the source code from CCP4 and develop my own library based on what I learn from the code? Does it also matter if I'm a commercial versus academic user?), there is *no way* you can redistribute a program that depends on CCP4 formatted files without simply including said program in the CCP4 distribution. The next best thing is to use the last redistributable verson of the library, which seems to be what the bulk of folks are doing these days. With shelx its a non-issue, since (most) of the files it produces are ascii. The fact that most crystallographic programs use an "academics-are-free, commercial-users-pay" style for all their licenses with all kinds of additional conditionals (please give us all your personal information and sign here, here and there!) also drives me up a wall, but thats another story. So yes, I strongly disagree with the SHELX license, but since its so frequently done amongst the crystallographic community, I've almost come to expect it. Regards, Tim -- ----- Tim Fenn [EMAIL PROTECTED] Stanford University, School of Medicine James H. Clark Center 318 Campus Drive, Room E300 Stanford, CA 94305-5432 Phone: (650) 736-1714 FAX: (650) 736-1961 -
Re: [ccp4bb] The CCP4 license is ambiguous
On Tue, 3 Jul 2007 14:55:22 +0100 Kevin Cowtan <[EMAIL PROTECTED]> wrote: > > The approach adopted by Coot, which is GPL'd, is to use the CCP4 > 5.0.2 libraries, which are LGPL, along with some patches currently > maintained by Ralph Grosse-Kunstleve to address the more serious > deficiencies of the older libraries. > Are the libraries with the patches available publicly? Regards, Tim -- --------- Tim Fenn [EMAIL PROTECTED] Stanford University, School of Medicine James H. Clark Center 318 Campus Drive, Room E300 Stanford, CA 94305-5432 Phone: (650) 736-1714 FAX: (650) 736-1961 -
Re: [ccp4bb] compiler question
On Thu, Mar 15, 2007 at 11:11:58AM +0800, yang li wrote: > When I installed a programm, it gave such information: > ./install.sh > /usr/bin/ld: cannot find -lstdc++ > collect2: ld returned 1 exit status > make: *** [Linux] Error 1 > > Is it because of absence of some compilers? How can I install it? > I am using the Fedora5 system. Thanks! > as root: yum install libstdc++ -- ----- Tim Fenn [EMAIL PROTECTED] Stanford University, School of Medicine James H. Clark Center 318 Campus Drive, Room E300 Stanford, CA 94305-5432 Phone: (650) 736-1714 FAX: (650) 736-1961 -
Re: [ccp4bb] MTZ to Shel-X?
On Mon, Mar 05, 2007 at 10:53:55AM +, Kevin Cowtan wrote: > You are absolutely right! The difficulty in getting from MTZ to any > other format or back is unacceptable. Expecting working > crystallographers to write Fortran format statements is ridiculous. I've > been trying to address this by adding support for other formats to > clipper, but my pace has been glacial, owing to the limited academic > rewards for such work. Even then, it needs someone to put together an > application and GUI to use it with. > I posit that if the CCP4 format was open (i.e. the CCP4C/F libraries were covered by an OSI/FSF approved license) and deposited in a reasonable code repository, then there exists the potential assistance of the entire public domain to standardize/extend/improve the library functions and ABIs (with, of course, oversight by the CCP4 folks). I know I would be far more inclined to help if such was the case. Regards, Tim
Re: ccp4bb on new site
On Sun, Jan 21, 2007 at 11:26:38PM -0800, Jan Abendroth wrote: > Hi all, > just realised that in the new ccp4bb setup (using various mail programs > such as thunderbird, mail, webpine), the actual sender does not appear > in the list of addressees, not even using "reply to all". This is an issue with the particular MUA. Email clients will use the "reply-to" header over the "from" header to decide who to respond to, and don't give you much else in terms of options (only a few of the MUA's, like mutt, seem to handle this reasonably well by offering a choice). The old ccp4bb setup did not set the "reply-to" header, the new one does. So, in most cases, you will *always* be sending an email to the bb. Again, I'm not familiar with jiscmail, but chances are this can be set depending on the admin's preferences. -Tim -- ----- Tim Fenn [EMAIL PROTECTED] Stanford University, School of Medicine James H. Clark Center 318 Campus Drive, Room E300 Stanford, CA 94305-5432 Phone: (650) 736-1714 FAX: (650) 736-1961 -
Re: ccp4bb on new site
On Fri, Jan 19, 2007 at 08:33:09PM +, Andy Purkiss wrote: > Quoting Juergen Bosch <[EMAIL PROTECTED]>: > > > Andy Purkiss-Trew wrote: > > > > >Dear Charles (and the rest of the bulletin board) > > > > > >I have a question regarding the new version of the software. > > > > > >Can the [ccp4bb] be put in front of the message subjects again? I use > > >this in my e-mail filtering, to get the ccp4 stuff out from under the > > >groaning weight of spam into its own folder. > > > > > >Andy > > > > > > > > > > > Just add an additional criteria to your filter e.g. to > > [EMAIL PROTECTED] > > > > That's easy to fix. > > > > I know that it is an easy fix :) > > However, nearly all of the lists that I am on use the [listname] notation and > this makes it a bit easier to sort out the lists from the personal mail. I'm > more likely to look at something with [ccp4bb] and not just skip over it. > > This is, however, only a personal preference and I just suggesting that the > marker be put back in, once the wrinkles of the software have been explored. > The "standard" method of filtering out list mails is to use one of Return-Path, List-Id, X-loop, X-BeenThere... headers. jiscmail seems to at least set the Return-Path. -Tim -- - Tim Fenn [EMAIL PROTECTED] Stanford University, School of Medicine James H. Clark Center 318 Campus Drive, Room E300 Stanford, CA 94305-5432 Phone: (650) 736-1714 FAX: (650) 736-1961 -
