Re: [COOT] symmetry operator generation on COOT
Hi Jennifer, Doebbler wrote: I am running Coot 0.5.2 on an intel Mac 10.5.6. I am trying to visualize the symmetry related molecules for a small inorganic molecule in spacegroup P 21/C. If I load the file into swiss PDB viewer or Mercury, the symmetry operators show that I have 4 molecules in my unit cell and a pretty orderly looking packing scheme. Coot, however, does not seem to like the P 21/C spacegroup. I changed the CRYST1 line to read CRYST1 25.0006.082 11.308 90.00 100.04 90.00 P 1 21/c 1 Indeed. That is what I would have done. The space group symbol in the PDB file should match the xHM symbol in syminfo.lib If I go to Draw->cell and symmetry-> master switch: show symmetry related atoms-> yes I get a very cramped unit cell with many more than just 4 molecules within. Well that is a surprise. You should definitely only see 4. "Cramped" as in crowded I presume you mean. I imagine that Coot at least got the cell correct. (I presume (because of your scripting competence) that it wasn't something trivial like inadvertently displaying the symmetry for other molecules also) I tried to ask coot what it thinks my spacegroup and symmetry operators were to reconcile this result with those of mercury and swiss viewer. It recognizes the spacegroup as P 1 21/c 1. coot> (show-spacegroup 0) "P 1 21/c 1" As it should be. If I then ask coot to show-symmetry I get the following coot> (show-symmetry 0) Backtrace: In current input: 8: 0* (show-symmetry 0) :8:1: In expression (show-symmetry 0): :8:1: Unbound variable: show-symmetry ABORT: (unbound-variable) :-( There is no command to output the symmetry operators. I'll make a note to add one. I'm stumped - I don't know what is going on. If you have a shelx .ins file for this molecule, I'd be curious to know if it was displayed correctly. Paul.
Re: [COOT] coot does not read sg info in cns files
Sebastiano Pasqualato wrote: Hi Paul, hi all. I have noticed that coot can't deal with spacegroup information of cns files. I have to substitute this: CRYST1 87.188 49.276 132.627 90.00 108.88 90.00 P 21 with this: CRYST1 87.188 49.276 132.627 90.00 108.88 90.00 P 1 21 1 to have the symmetry displayed properly. Could you make coot be able to read the cns format too, I'll think about it. or is there a script that handle this? ;; This will force "P 1 21 1" down the throat of all model molecules ;; whose space group is unknown. (map (lambda (n) (if (string=? (show-spacegroup n) "No spacegroup") (set-space-group n "P 1 21 1"))) (model-molecule-list)) Paul.
[COOT] symmetry operator generation on COOT
Hi all, I am running Coot 0.5.2 on an intel Mac 10.5.6. I am trying to visualize the symmetry related molecules for a small inorganic molecule in spacegroup P 21/C. If I load the file into swiss PDB viewer or Mercury, the symmetry operators show that I have 4 molecules in my unit cell and a pretty orderly looking packing scheme. Coot, however, does not seem to like the P 21/C spacegroup. I changed the CRYST1 line to read CRYST1 25.0006.082 11.308 90.00 100.04 90.00 P 1 21/c 1 If I go to Draw->cell and symmetry-> master switch: show symmetry related atoms-> yes I get a very cramped unit cell with many more than just 4 molecules within. I tried to ask coot what it thinks my spacegroup and symmetry operators were to reconcile this result with those of mercury and swiss viewer. It recognizes the spacegroup as P 1 21/c 1. coot> (show-spacegroup 0) "P 1 21/c 1" If I then ask coot to show-symmetry I get the following coot> (show-symmetry 0) Backtrace: In current input: 8: 0* (show-symmetry 0) :8:1: In expression (show-symmetry 0): :8:1: Unbound variable: show-symmetry ABORT: (unbound-variable) Am I doing something dumb here? Thank you in advance. -Jennifer
Re: [COOT] autobuilder fails (was: ELFCLASS64)
I am trying to stop being lazy and just build coot for my system (64-bit Ubuntu Jaunty). I tried autobuilder scripts, which seem to be quite awesome, but so far fail in my hands. First few things were relatively obvious: I had to install the *-dev packages to get the pkgconfig to work. I hit the wall with the GtkGLExt. Then something weird happened - I turned off compiz and it went past GtkGlExt issue, but I can't reproduce it - it works now even after I turned the compiz back on. Now it tells me that I "Must install goosh for guile". That I can't figure out how to do - can't find anything in repositories. This leads me to a fundamental question - why do I have to tweak my system and install additional packages (after I installed everything mentioned as pre-requisites for the autobuilder in the README)? My understanding of the autobuilding process was that the script downloads all the dependencies and configures them in autobuild folder. Take this goosh issue. I do have the "goosh-1.3" folder in the appropriate place, why does the script fail to find it? This is reminiscent of my earlier issue when coot binaries were looking for libraries in /usr/lib instead of just getting them from coot/lib. This again indicates that something may be wrong with system configuration. Any ideas? Ed. On Tue, 2009-05-12 at 13:22 -0400, Ed Pozharski wrote: > Didn't help. > > It must have something to do with my configuration. I have no problems > on other machines running Hardy. > > Which executable actually requires this library? I put "ldd $coot_real" > into the xxx/bin/coot script, and it does list many libraries in xxx/lib > properly. However, the one in question is not listed (in fact, coot > also complains about canberra-gtk-module, libgiogconf, libgvfsdbus, > libgioremote-volume-monitor, but these are perhaps not critical so it > does not crash). > > This may be irrelevant, but I made the following observations: > > - when coot crashes, it says "ERROR: In procedure dynamic-link:" > - when I look in the source, the only place which has these very words > (i.e. dynamic-link) is in scheme/my-readline.scm > - it says (dynamic-link "libguilereadline-v-12"))) > - libguilereadline-v-12 is in guile-1.6-libs, not 1.8 > - moreover, coot/lib has libguilereadline-v-17, not 12 > - there is /usr/lib32/libguilereadline-v-17, but not 12 > > I tried to remove/reinstall both guile-1.6-libs and guile-1.8-libs, and > it didn't help. > > Ed. > > > On Tue, 2009-05-12 at 00:34 +0100, Paul Emsley wrote: > > Ed Pozharski wrote: > > > After recent upgrade to Ubuntu 9.04, coot binaries that worked fine > > > before started reporting the "ELFCLASS64" error when loading a > > > particular library, namely /usr/lib/libguile-srfi-srfi-1-v-3.so.3. > > > > > > I understand that the real root of this problem is my bizarre obsession > > > with installing 64-bit Linux and then being too lazy to compile coot > > > from source and instead trying to use 32-bit coot binaries. To resolve > > > the ELFCLASS64 issue, I downloaded guile1.8 32-bit debian package from > > > ubuntu repositories and placed libraries into /usr/lib32. That, of > > > course, didn't help and I had to redirect the symbolic link in /usr/lib > > > to /usr/lib32. > > > > > > OK, try this: > > > > in your xxx/bin/coot script, > > > > after the line > > > > export LD_LIBRARYN32_PATH > > > > add: > > > > LTDL_LIBRARY_PATH=$COOT_PREFIX/lib > > export LTDL_LIBRARY_PATH > > > > > > Paul. --
