[phenixbb] Mac 64-bit kernel
Joseph Noel
noel at salk.edu
Mon Apr 4 11:44:41 PDT 2011
Nope. I've set up to always run the 64-bit kernel. I am a bit of a Mac lover so go pretty in depth with the operating system. I think Nat fixed things. For the last many latest builds, I have always installed from the source files for linux/mac to ensure I am running at maximum memory capacity.
___________________________________________________________
Joseph P. Noel, Ph.D.
Investigator, Howard Hughes Medical Institute
Professor, The Jack H. Skirball Center for Chemical Biology and Proteomics
The Salk Institute for Biological Studies
10010 North Torrey Pines Road
La Jolla, CA 92037 USA
Phone: (858) 453-4100 extension 1442
Cell: (858) 349-4700
Fax: (858) 597-0855
E-mail: noel at salk.edu
Web Site (Salk): http://www.salk.edu/faculty/noel.html
Web Site (HHMI): http://hhmi.org/research/investigators/noel.html
___________________________________________________________
On Apr 4, 2011, at 11:27 AM, phenixbb-request at phenix-online.org wrote:
> Send phenixbb mailing list submissions to
> phenixbb at phenix-online.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://phenix-online.org/mailman/listinfo/phenixbb
> or, via email, send a message with subject or body 'help' to
> phenixbb-request at phenix-online.org
>
> You can reach the person managing the list at
> phenixbb-owner at phenix-online.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of phenixbb digest..."
>
>
> Today's Topics:
>
> 1. Re: nqh_flips (Pavel Afonine)
> 2. latest 64-bit command line build for Mac OSX 10.6.7? (Joseph Noel)
> 3. Re: latest 64-bit command line build for Mac OSX 10.6.7?
> (Engin ?zkan)
> 4. Re: latest 64-bit command line build for Mac OSX 10.6.7?
> (Nathaniel Echols)
> 5. Re: latest 64-bit command line build for Mac OSX 10.6.7?
> (Ben Eisenbraun)
> 6. Re: latest 64-bit command line build for Mac OSX 10.6.7?
> (Nathaniel Echols)
> 7. Minor map-definition bug in 1.7 GUI (Joe Krahn)
> 8. bug report- gui freezed (Kendall Nettles)
> 9. Re: bug report- gui freezed (Nathaniel Echols)
> 10. Re: Minor map-definition bug in 1.7 GUI (Nathaniel Echols)
> 11. Re: latest 64-bit command line build for Mac OSX 10.6.7?
> (Nathaniel Echols)
> 12. Re: latest 64-bit command line build for Mac OSX 10.6.7?
> (Ben Eisenbraun)
> 13. Re: latest 64-bit command line build for Mac OSX 10.6.7?
> (Ben Eisenbraun)
> 14. Modeling Disordered Domains (Damian Ekiert)
> 15. Re: latest 64-bit command line build for Mac OSX 10.6.7?
> (Nathaniel Echols)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 02 Apr 2011 19:27:24 -0700
> From: Pavel Afonine <pafonine at lbl.gov>
> To: PHENIX user mailing list <phenixbb at phenix-online.org>
> Subject: Re: [phenixbb] nqh_flips
> Message-ID: <4D97DB0C.9020706 at lbl.gov>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi Maia,
>
> is the affected residue(s) listed within warning message in .log file
> saying that both original and flipped version do not solve the clash? If
> so, you may need to have a closer look at that residue to see what's
> wrong. Otherwise, we would be interested to see the details...
>
> Pavel.
>
>
> On 4/2/11 6:08 PM, Maia Cherney wrote:
>> Hi,
>> I just noticed that the nqh flips did not happen, even though the .def
>> file has nqh_flips = True.
>>
>> Maia
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 3 Apr 2011 10:57:35 -0700
> From: Joseph Noel <noel at salk.edu>
> To: phenixbb at phenix-online.org
> Subject: [phenixbb] latest 64-bit command line build for Mac OSX
> 10.6.7?
> Message-ID: <D7EFB995-80A8-4995-973B-8FFFCC07DFB4 at salk.edu>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi,
>
> I was trying to install the latest nightly build but get error (shown after my salutation) when using the recommended procedure:
>
> ./install --prefix=/Applications/
>
> Previously, I always installed from source so I could run the 64-bit version on Mac since I have some structures that require as much memory as possible. Should I just go back to that? It does take about an hour to install on my laptop. I assume this latest 64-bit option would significantly reduce the time for installation since I wouldn't be compiling from the source.
>
> Cheers!
>
> Joe
>
> ==========================================================================
> PHENIX Installation
>
> version: dev
> release tag: 718
> machine type: mac-intel-osx-x86_64
> source machine type: mac-intel-osx
> OS version: osx-10.6.7
> user shell: /bin/bash
> destination: /Applications/
> =========================================================================
> No binary bundles found for mac-intel-osx
> bundles directory contents:
> bundle-dev-718-mac-intel-osx-x86_64.tar.gz
> expected one of the following:
> /Users/sandiegonoels/Downloads/2011-04-03/phenix-installer-dev-718/bundles/bundle-dev-718-mac-intel-osx.tar.gz
>
> =============================== ERROR ===================================
> No binary installer found for mac-intel-osx, installation aborted
> =============================== ERROR ===================================
> ___________________________________________________________
> Joseph P. Noel, Ph.D.
> Investigator, Howard Hughes Medical Institute
> Professor, The Jack H. Skirball Center for Chemical Biology and Proteomics
> The Salk Institute for Biological Studies
> 10010 North Torrey Pines Road
> La Jolla, CA 92037 USA
>
> Phone: (858) 453-4100 extension 1442
> Cell: (858) 349-4700
> Fax: (858) 597-0855
> E-mail: noel at salk.edu
>
> Web Site (Salk): http://www.salk.edu/faculty/noel.html
> Web Site (HHMI): http://hhmi.org/research/investigators/noel.html
> ___________________________________________________________
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://phenix-online.org/pipermail/phenixbb/attachments/20110403/1def9a83/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 03 Apr 2011 11:15:18 -0700
> From: Engin ?zkan <eozkan at stanford.edu>
> To: PHENIX user mailing list <phenixbb at phenix-online.org>
> Subject: Re: [phenixbb] latest 64-bit command line build for Mac OSX
> 10.6.7?
> Message-ID: <4D98B936.5070706 at stanford.edu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> I have a guess, but I may be way off. It's probably because you are not
> running the 64-bit kernel? I think Macs still don't come running by
> default with a 64-bit kernel (except for a few high-end machines), but
> you can reboot your Mac with the 64-bit kernel. Now, why Phenix needs a
> 64-bit kernel to run as a 64-bit application, that's above my pay grade,
> and the developers would probably answer that.
>
> Engin
>
> On 4/3/11 10:57 AM, Joseph Noel wrote:
>> Hi,
>>
>> I was trying to install the latest nightly build but get error (shown
>> after my salutation) when using the recommended procedure:
>>
>> ./install --prefix=/Applications/
>>
>> Previously, I always installed from source so I could run the 64-bit
>> version on Mac since I have some structures that require as much
>> memory as possible. Should I just go back to that? It does take about
>> an hour to install on my laptop. I assume this latest 64-bit option
>> would significantly reduce the time for installation since I wouldn't
>> be compiling from the source.
>>
>> Cheers!
>>
>> Joe
>>
>> ==========================================================================
>> PHENIX Installation
>>
>> version: dev
>> release tag: 718
>> machine type: mac-intel-osx-x86_64
>> source machine type: mac-intel-osx
>> OS version: osx-10.6.7
>> user shell: /bin/bash
>> destination: /Applications/
>> =========================================================================
>> No binary bundles found for mac-intel-osx
>> bundles directory contents:
>> bundle-dev-718-mac-intel-osx-x86_64.tar.gz
>> expected one of the following:
>> /Users/sandiegonoels/Downloads/2011-04-03/phenix-installer-dev-718/bundles/bundle-dev-718-mac-intel-osx.tar.gz
>>
>> =============================== ERROR ===================================
>> No binary installer found for mac-intel-osx, installation aborted
>> =============================== ERROR ===================================
>> ___________________________________________________________
>> Joseph P. Noel, Ph.D.
>> Investigator, Howard Hughes Medical Institute
>> Professor, The Jack H. Skirball Center for Chemical Biology and Proteomics
>> The Salk Institute for Biological Studies
>> 10010 North Torrey Pines Road
>> La Jolla, CA 92037 USA
>>
>> Phone: (858) 453-4100 extension 1442
>> Cell: (858) 349-4700
>> Fax: (858) 597-0855
>> E-mail: noel at salk.edu <mailto:noel at salk.edu>
>>
>> Web Site (Salk): http://www.salk.edu/faculty/noel.html
>> <http://www.salk.edu/faculty/faculty_details.php?id=37>
>> Web Site (HHMI): http://hhmi.org/research/investigators/noel.html
>> ___________________________________________________________
>>
>>
>> _______________________________________________
>> phenixbb mailing list
>> phenixbb at phenix-online.org
>> http://phenix-online.org/mailman/listinfo/phenixbb
>
>
> --
> Engin ?zkan
> Post-doctoral Scholar
> Howard Hughes Medical Institute
> Dept of Molecular and Cellular Physiology
> 279 Campus Drive, Beckman Center B173
> Stanford School of Medicine
> Stanford, CA 94305
> ph: (650)-498-7111
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 3 Apr 2011 14:26:02 -0700
> From: Nathaniel Echols <nechols at lbl.gov>
> To: PHENIX user mailing list <phenixbb at phenix-online.org>
> Cc: Joseph Noel <noel at salk.edu>
> Subject: Re: [phenixbb] latest 64-bit command line build for Mac OSX
> 10.6.7?
> Message-ID: <BANLkTikd4tGS0=-zrcSPXDjvsxWj21LUbA at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Sun, Apr 3, 2011 at 10:57 AM, Joseph Noel <noel at salk.edu> wrote:
>> I was trying to install the latest nightly build but get error (shown after
>> my salutation) when using the recommended procedure:
>> ./install --prefix=/Applications/
>> Previously, I always installed from source so I could run the 64-bit version
>> on Mac since I have some structures that require as much memory as possible.
>> Should I just go back to that? It does take about an hour to install on my
>> laptop. I assume this latest 64-bit option would significantly reduce the
>> time for installation since I wouldn't be compiling from the source.
>
> There were several bugs in the install script - the convoluted
> workaround for using the 32-bit binary installer on Snow Leopard was
> causing problems for the 64-bit binary installer. I've patched the
> installer to fix the problem, and a new version is now posted online.
> It may have the side effect of breaking the forwards compatibility of
> the 32-bit build, but I will test and fix this tomorrow. (This is the
> first time the 64-bit build has actually run; Apple's habit of
> overengineering seemingly simple things like Unix user accounts made
> it surprisingly difficult to get our automation working.)
>
> -Nat
>
> (PS. the choice of kernel is irrelevant - 10.6 will always be detected
> as x86_64, and the 64-bit build should work with either kernel.)
>
>
> ------------------------------
>
> Message: 5
> Date: Sun, 3 Apr 2011 20:29:27 -0400
> From: Ben Eisenbraun <bene at hkl.hms.harvard.edu>
> To: PHENIX user mailing list <phenixbb at phenix-online.org>
> Subject: Re: [phenixbb] latest 64-bit command line build for Mac OSX
> 10.6.7?
> Message-ID: <20110404002927.GC28532 at crystal.harvard.edu>
> Content-Type: text/plain; charset=us-ascii
>
> On Sun, Apr 03, 2011 at 02:26:02PM -0700, Nathaniel Echols wrote:
>> (PS. the choice of kernel is irrelevant - 10.6 will always be detected
>> as x86_64, and the 64-bit build should work with either kernel.)
>
> Unless you are running on one of the very first Intel Macs using an Intel
> Core Duo CPU, which is 32-bit only.
>
> This is a minority population, but since people are reluctant to
> decomission Macs, we have already had several tickets on. e.g. 64-bit only
> CNS.
>
> -ben
>
> --
> | Ben Eisenbraun
> | SBGrid Consortium | http://sbgrid.org |
> | Harvard Medical School | http://hms.harvard.edu |
>
>
> ------------------------------
>
> Message: 6
> Date: Sun, 3 Apr 2011 17:45:49 -0700
> From: Nathaniel Echols <nechols at lbl.gov>
> To: PHENIX user mailing list <phenixbb at phenix-online.org>
> Subject: Re: [phenixbb] latest 64-bit command line build for Mac OSX
> 10.6.7?
> Message-ID: <BANLkTinxheQ3HpMe8ynOu9K=BVshKwW6yg at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Sun, Apr 3, 2011 at 5:29 PM, Ben Eisenbraun <bene at hkl.hms.harvard.edu> wrote:
>>> (PS. the choice of kernel is irrelevant - 10.6 will always be detected
>>> as x86_64, and the 64-bit build should work with either kernel.)
>>
>> Unless you are running on one of the very first Intel Macs using an Intel
>> Core Duo CPU, which is 32-bit only.
>>
>> This is a minority population, but since people are reluctant to
>> decomission Macs, we have already had several tickets on. e.g. 64-bit only
>> CNS.
>
> Oh dear. Well, they're definitely going to have problems with Phenix
> as it stands right now. Could you please check with one of these
> users and find out what the output of "uname -a" is? I believe there
> is a smarter way to identify 64-bit systems than what I'm doing now
> (basically, just looking at the OS version), but I need to make sure
> it won't result in false positives.
>
> A more general issue with 32-bit vs. 64-bit Mac (especially relevant
> to SBGrid): currently, if you install either the 32-bit
> (mac-intel-osx) or 64-bit (mac-intel-osx-x86_64) installer on Snow
> Leopard, the binary build directory will be
> $PHENIX/build/mac-intel-osx-x86_64. So they can't co-exist in the
> same location, which is potentially a problem for GUI users since
> wxPython 2.9 still has a few serious bugs, as well as some
> incompatibilities which we haven't dealt with yet. (There isn't
> anything that I'm aware of that is likely to cause crashes, but some
> features don't behave properly, such as anything using OpenGL.) I
> have no bright ideas for this, other than tracking down and fixing the
> problems; given the number of memory overflow errors I've been
> receiving lately in bug reports, the 64-bit builds are pretty
> essential.
>
> Further information here: https://www.phenix-online.org/platforms/mac_notes.html
>
> thanks,
> Nat
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 4 Apr 2011 10:48:21 -0400
> From: Joe Krahn <krahn at niehs.nih.gov>
> To: PHENIX user mailing list <phenixbb at phenix-online.org>
> Subject: [phenixbb] Minor map-definition bug in 1.7 GUI
> Message-ID: <4D99DA35.10602 at niehs.nih.gov>
> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
>
> The new GUI has "---" in the list of map types for phenix.refine. Users
> expect this to mean "don't use map definition". I think there was
> previously a blank menu entry that worked this way. Instead, it is
> written to the .def file, and the job gives an error, but otherwise
> works OK.
>
> Thanks,
> Joe Krahn
>
>
> ------------------------------
>
> Message: 8
> Date: Mon, 4 Apr 2011 11:55:31 -0400
> From: Kendall Nettles <knettles at scripps.edu>
> To: PHENIX user mailing list <phenixbb at phenix-online.org>
> Subject: [phenixbb] bug report- gui freezed
> Message-ID: <C5254A57-F280-49E6-B989-ADD44C09A744 at scripps.edu>
> Content-Type: text/plain; charset="us-ascii"
>
> The GUI freezes when an add dialog box is open and a job ends, launching an announcement box (..coot is starting, ready set is done...etc). I can't close either box. Using phenix-1.7-650 on a mac
> Kendall
>
>
>
>
>
>
> ------------------------------
>
> Message: 9
> Date: Mon, 4 Apr 2011 09:59:34 -0700
> From: Nathaniel Echols <nechols at lbl.gov>
> To: PHENIX user mailing list <phenixbb at phenix-online.org>
> Subject: Re: [phenixbb] bug report- gui freezed
> Message-ID: <BANLkTim3JG5Bz=34Dx+Wauc3aGb8GX9N4g at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Mon, Apr 4, 2011 at 8:55 AM, Kendall Nettles <knettles at scripps.edu> wrote:
>> The GUI freezes when an add dialog box is open and a job ends, launching an announcement box (..coot is starting, ready set is done...etc). I can't close either box. Using phenix-1.7-650 on a mac
>
> I need more information to debug this. Which version of the OS are
> you using? Did you download the 32-bit binary installer, or compile
> from source? Does the cursor remain the same, or do you get the
> spinning beach ball of doom? Also, I'm unclear on what the "add
> dialog box" is - if you could send a screenshot (probably just to me -
> the list has a fairly strict size limit) that would be helpful.
>
> thanks,
> Nat
>
>
> ------------------------------
>
> Message: 10
> Date: Mon, 4 Apr 2011 10:13:06 -0700
> From: Nathaniel Echols <nechols at lbl.gov>
> To: PHENIX user mailing list <phenixbb at phenix-online.org>
> Subject: Re: [phenixbb] Minor map-definition bug in 1.7 GUI
> Message-ID: <BANLkTin7hp=nsvOde=zBsdzizvHmzyRGeg at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Mon, Apr 4, 2011 at 7:48 AM, Joe Krahn <krahn at niehs.nih.gov> wrote:
>> The new GUI has "---" in the list of map types for phenix.refine. Users
>> expect this to mean "don't use map definition". I think there was previously
>> a blank menu entry that worked this way. Instead, it is written to the .def
>> file, and the job gives an error, but otherwise works OK.
>
> The "---" replaced the blank to compensate for a bug in the 64-bit Mac
> version of wxPython 2.9, but the resulting output (.eff file) should
> be the same. There have been some changes to the way map parameters
> are validated, which may lead to slightly different behavior.
> However, as a general rule, changing the map type to null will not
> remove that parameter block unless all other parameters are set to
> their default - this is an inherent limitation of the internal
> parameter structure. If it would be more intuitive for the program to
> simply skip these maps instead of complaining, that isn't a difficult
> change to make, but it's Pavel's program, so I'll let him decide.
>
> -Nat
>
>
> ------------------------------
>
> Message: 11
> Date: Mon, 4 Apr 2011 10:26:08 -0700
> From: Nathaniel Echols <nechols at lbl.gov>
> To: PHENIX user mailing list <phenixbb at phenix-online.org>
> Subject: Re: [phenixbb] latest 64-bit command line build for Mac OSX
> 10.6.7?
> Message-ID: <BANLkTi=md1VyWn9D2Pu_9evkV3vGGvnEYw at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Sun, Apr 3, 2011 at 5:29 PM, Ben Eisenbraun <bene at hkl.hms.harvard.edu> wrote:
>> On Sun, Apr 03, 2011 at 02:26:02PM -0700, Nathaniel Echols wrote:
>>> (PS. the choice of kernel is irrelevant - 10.6 will always be detected
>>> as x86_64, and the 64-bit build should work with either kernel.)
>>
>> Unless you are running on one of the very first Intel Macs using an Intel
>> Core Duo CPU, which is 32-bit only.
>>
>> This is a minority population, but since people are reluctant to
>> decomission Macs, we have already had several tickets on. e.g. 64-bit only
>> CNS.
>
> Okay, Engin reminded me why I originally wrote it to always treat Snow
> Leopard as 64-bit: if you have a 64-bit processor, the 64-bit build
> will work regardless of kernel type. However, if you are running a
> 32-bit kernel, the architecture will always be reported as "i386". So
> we're left with these choices:
>
> 1) Make the 'mac-intel-osx-x86_64' platform dependent on the 64-bit
> kernel, so everyone who needs the 64-bit build has to change kernel
> version
> or
> 2) Keep the current behavior, and people running Snow Leopard on
> first-generation Intel Macs will need to use the 32-bit binary
> installer.
>
> Neither is ideal; the latter has additional problems for SBGrid, due
> to the way we 'alias' the architecture when the 32-bit installer is
> used. Ben, did you decide what to do about CNS?
>
> -Nat
>
>
> ------------------------------
>
> Message: 12
> Date: Mon, 4 Apr 2011 13:32:14 -0400
> From: Ben Eisenbraun <bene at hkl.hms.harvard.edu>
> To: PHENIX user mailing list <phenixbb at phenix-online.org>
> Subject: Re: [phenixbb] latest 64-bit command line build for Mac OSX
> 10.6.7?
> Message-ID: <20110404173214.GG4243 at crystal.harvard.edu>
> Content-Type: text/plain; charset=us-ascii
>
> On Sun, Apr 03, 2011 at 05:45:49PM -0700, Nathaniel Echols wrote:
>> Oh dear. Well, they're definitely going to have problems with Phenix
>> as it stands right now. Could you please check with one of these
>> users and find out what the output of "uname -a" is?
>
> It doesn't look particularly helpful to me, but here's a Core Duo iMac
> running 10.6.7:
>
> Darwin ps-common-imac.in.hwlab 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386
>
>> I believe there is a smarter way to identify 64-bit systems than what I'm
>> doing now (basically, just looking at the OS version), but I need to make
>> sure it won't result in false positives.
>
> I'm using `sysctl -n hw.optional.x86_64`, which will return 0 for
> non-64-bit capable hosts.
>
> -ben
>
> --
> | Ben Eisenbraun
> | SBGrid Consortium | http://sbgrid.org |
> | Harvard Medical School | http://hms.harvard.edu |
>
>
> ------------------------------
>
> Message: 13
> Date: Mon, 4 Apr 2011 14:10:39 -0400
> From: Ben Eisenbraun <bene at hkl.hms.harvard.edu>
> To: PHENIX user mailing list <phenixbb at phenix-online.org>
> Subject: Re: [phenixbb] latest 64-bit command line build for Mac OSX
> 10.6.7?
> Message-ID: <20110404181039.GH4243 at crystal.harvard.edu>
> Content-Type: text/plain; charset=us-ascii
>
> Hi Nat,
>
>> 1) Make the 'mac-intel-osx-x86_64' platform dependent on the 64-bit
>> kernel, so everyone who needs the 64-bit build has to change kernel
>> version
>> or
>> 2) Keep the current behavior, and people running Snow Leopard on
>> first-generation Intel Macs will need to use the 32-bit binary
>> installer.
>>
>> Neither is ideal; the latter has additional problems for SBGrid, due
>> to the way we 'alias' the architecture when the 32-bit installer is
>> used. Ben, did you decide what to do about CNS?
>
> For the time being, we're just checking for 32-bit only CPUs and then
> forcing them to use an older version of CNS. I tried building a 32-bit CNS
> and lipo'ing the 32 and 64-bit binaries into a two-way fat binary, but the
> default CNS optimizations seem to cause the 32-bit version to blow up.
> This might also be due to me using the latest version of the Intel
> compiler.
>
> You should be able to use the hw.optional.x86_64 sysctl to tweak the
> phenix_env scripts to allow for a dual branch 32/64 bit installation in the
> same directory, but it seems like you're not yet recommending the 64-bit
> PHENIX on OS X Intel for general consumption. You could also do something
> hackish like default to 32-bit but read $1 on the "source phenix_env"
> command line to enable the 64-bit version.
>
> Between the wxPython issues and the fact that about 1/3rd of our OS X users
> are still on 10.5, unless I get a specific request for the 64-bit version,
> I probably will not install it just yet. (That's the cue for emails from
> the SBGrid users requesting a 64-bit installation... :-)
>
> -ben
>
> --
> | Ben Eisenbraun
> | SBGrid Consortium | http://sbgrid.org |
> | Harvard Medical School | http://hms.harvard.edu |
>
>
> ------------------------------
>
> Message: 14
> Date: Mon, 4 Apr 2011 11:11:46 -0700
> From: Damian Ekiert <dcekiert at scripps.edu>
> To: PHENIX user mailing list <phenixbb at phenix-online.org>
> Subject: [phenixbb] Modeling Disordered Domains
> Message-ID: <6BF89471-13B0-4B21-AEE3-BE3AF1FE29A4 at scripps.edu>
> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed;
> delsp=yes
>
> Perhaps inspired by the fierce debate on this BB and elsewhere about
> how to model disordered side chains, I would like to present the
> following scenario (my current refinement project):
>
> The structure was solved by molecular replacement, is 3.25?
> resolution, and ~70% solvent. I have 6 copies of a large complex in
> the AU (~100kDa per protomer). Only one copy is fully ordered. In
> the other 5 copies, a entire domain (~25kDa) is largely disordered
> (some have patchy residual density, but not readily interpretable).
> Altogether, this means that I am missing ~20% of the total protein in
> the AU. It seems that how you model this much "missing" material
> could have a significant effect on the final refined model. This is
> something we have observed a number of times, so I am wondering if
> anyone can suggest ways to deal with this aside from just leaving the
> domains out entirely.
>
> In this case, the missing domain is connected by two short hinges that
> restrict the rotational degrees of freedom considerably (you can think
> of the missing domains as a door--it can only pivot about the hinge,
> can't be flipped upside-down or sideways, etc., and is anchored close
> to the door frame). Additionally, crystal packing and steric
> constraints restrict the "sweep" of the missing domains to further
> pinpoint their location.
>
> Is it worth trying to model this? My impression from some earlier
> posts was that most people were content for disordered regions to be
> modeled as bulk solvent (rather than fiddling with masks to also cover
> the expected location of protein, etc.), but I wonder if you may
> actually substantially improve the model when this much protein is
> disordered. I guess I am imagining something analogous to a rigid
> body fit to the mean position of the disordered domains and a TLS-like
> ADP description of the motion (with a very large magnitude to account
> for the large displacement), but I am open to suggestions.
>
> On a final note, regarding those pesky missing side chains: any
> thoughts on trying to employ a "Ringer"-like approach to model some of
> these (Fraser, et al., Nature 2009, 462(7273):669-673)? Is this
> practical (maybe this would add to many additional parameters)?
>
> Best,
>
> Damian Ekiert
>
> ------------------------------
>
> Message: 15
> Date: Mon, 4 Apr 2011 11:27:34 -0700
> From: Nathaniel Echols <nechols at lbl.gov>
> To: PHENIX user mailing list <phenixbb at phenix-online.org>
> Subject: Re: [phenixbb] latest 64-bit command line build for Mac OSX
> 10.6.7?
> Message-ID: <BANLkTinq0vV-Qyyn0QKmYLBNhkTmCjNA0g at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Mon, Apr 4, 2011 at 11:10 AM, Ben Eisenbraun
> <bene at hkl.hms.harvard.edu> wrote:
>> For the time being, we're just checking for 32-bit only CPUs and then
>> forcing them to use an older version of CNS. ?I tried building a 32-bit CNS
>> and lipo'ing the 32 and 64-bit binaries into a two-way fat binary, but the
>> default CNS optimizations seem to cause the 32-bit version to blow up.
>
> Unfortunately, this would be much more difficult with PHENIX, since it
> isn't a monolithic program like CNS.
>
>> You should be able to use the hw.optional.x86_64 sysctl to tweak the
>> phenix_env scripts to allow for a dual branch 32/64 bit installation in the
>> same directory, but it seems like you're not yet recommending the 64-bit
>> PHENIX on OS X Intel for general consumption. ?You could also do something
>> hackish like default to 32-bit but read $1 on the "source phenix_env"
>> command line to enable the 64-bit version.
>
> I think the sysctl command will at least let me distinguish between
> CPU types, so that takes care of the 64-bit detection problem. How to
> allow 32-bit and 64-bit versions to coexist is a separate issue;
> environment variables are another way, but neither of these options is
> intuitive. However, I think I figured out how to make them coexist in
> the same base directory, but only for the command-line installation;
> the graphical installers will still overlap.
>
> One clarification: for people who only use the command line, the
> 64-bit build is recommended - we haven't noticed any problems with
> program behavior so far and it will potentially save a lot of time and
> trouble to have access to all available memory. It's the GUI that's
> the problem, but I'm going to see if I can tackle that this week.
>
> -Nat
>
>
> ------------------------------
>
> _______________________________________________
> phenixbb mailing list
> phenixbb at phenix-online.org
> http://phenix-online.org/mailman/listinfo/phenixbb
>
>
> End of phenixbb Digest, Vol 65, Issue 2
> ***************************************
>
More information about the phenixbb
mailing list