Hi Folmer,

Thank you for the clarification. I think we should not start a discussion (people have better things to do in the weekend, I think) about what is best to do. I was not aware that there this was the difference between the official and nightly builds.

yeah, that was the reason I waited 5+ minutes before hitting Send to convince myself it's not goining to sparkle an endless useless discussion about what is right -:) But... we can discuss it off-list, if you wish! All the best, Pavel

Hi Ed, that's all right. Both ways have clear pros and cons (I have a few pages long email that I wrote a year ago to someone that carefully lists them all), but are ok as long as a) things are self-consistent, and b) track about what was done is recorded. The only reason I made that remark is to point out that the previous behavior was not strictly speaking a bug, that's all. At some point Garib made a very nice comment about this (in ccp4bb list). All the best, Pavel On 4/6/13 8:13 AM, Ed Pozharski wrote:

Pavel,

On 04/06/2013 05:00 AM, Pavel Afonine wrote:

...

A quick comment on "B-factor problem" recently brought to attention: in fact it is not a bug at all, but a conflict of philosophies. It all boils down to whether you want to keep meaningless bulk overall B-factor in ATOM records in your PDB file (current phenix.refine behavior) or you say it is junk and keep it in overall scale factors (previous behavior that many of you called a bug). Personally I would prefer to keep in overall scale factors.

While my useless comment has a potential to start an endless and equally useless discussion, I'd like to nevertheless point out that from my understanding overall B-factor is not entirely meaningless. While some of it is due to overall static disorder which is truly of little interest, figuring out what part of it is contributed by true thermal motion (whether real at 100K or frozen out from 300K) is not exactly trivial. I appreciate your opinion that from mathematical standpoint it does not matter where this contribution goes, but having B=0 for some atoms because min(B) was subtracted and placed into a header comment line is at least equally meaningless. I do not see how B-min(B) is a better assessment of the "true atomic B-factor".

Cheers,

Ed.

On Wed, Apr 10, 2013 at 4:09 PM, jp d wrote:

is there a way to do base stacking in phenix ?

If you mean restraints on base stacking, no, we don't have anything like this right now. The only implementation of this anywhere, as far as I know, is the one from your (Noller) lab, but (aside from the lack of an explicit license) the fact that it's derived from CNS makes me very reluctant to even look at the code. However, if anyone has the derivation for the restraint energy function, we'd be happy to consider adding this to Phenix - we need to make a lot of changes to how we handle base-pairing anyway. -Nat

Dare I? - yes I do. CCP4 have recently put in place a very nice update system - which essentially does exactly what Ed is suggesting / asking for. What's also nice is that updates can be installed / uninstalled as a user wishes. Massively reduces the file sizes of downloads. I too would like something like this implemented in Phenix if at all possible. Especially as I sys-admin a small suite of multi-users computers. Antony. Sent from my iPhone On 6 Apr 2013, at 15:59, "Ed Pozharski" mailto:[email protected]> wrote: IIUC, current mechanism for "updating" phenix is to download and install the whole thing every time one wants to get a nightly build and/or latest official release. While it is not technically difficult, it is something that I am reluctant to do on a regular basis (maybe I can set up a daemon that would do that for me every night, but additional difficulty is that one has to get a password by email). I am not using 4kbps modem anymore, but still the whole thing is pretty big. Given Pavel's comment ("not goining to sparkle an endless useless discussion about what is right") I suspect that an unsolicited suggestion of the kind I am going to make below is not necessarily what phenix team is looking for. I thought discussion boards are established just for that - uncensored (to a degree) discussion where users are free to express their concerns and opinions without fear of being labeled useless by people who control the board itself. I however know everything I say is generally useless already, so here goes. Given that changes between nightly builds are likely limited to relatively small patches/additions, is there some mechanism to do updates "revision control style", i.e. by downloading and updating only the parts of code that changed? This way if I want to keep using bleeding edge version, I do not need to download ~650Mb on a daily basis. Cheers, Ed. On 04/06/2013 04:31 AM, Folmer Fredslund wrote: Hi phenixbb/developers, Recently, some people have experienced problems with B-factor refinement in the official releases of PHENIX. It seems to me that, generally speaking, the first suggestion is to use the nightly builds of phenix. So, my question is: How does the official releases work? Is it a snapshot of the development version, or are you doing some kind of stabilization during the development of the official releases? Are you updating the official releases after release (to fix bugs) or are the bugs only fixed in the nightly builds. With the current official releases, would I be better off using the nightly builds for refinement? (I have also seen some weird behavior with B-factor refinement). Best regards and thank you for developing phenix, Folmer -- Folmer Fredslund Post doc MAX IV Laboratory Lund Sweden _______________________________________________ phenixbb mailing list [email protected]mailto:[email protected] http://phenix-online.org/mailman/listinfo/phenixbb -- Oh, suddenly throwing a giraffe into a volcano to make water is crazy? Julian, King of Lemurs _______________________________________________ phenixbb mailing list [email protected]mailto:[email protected] http://phenix-online.org/mailman/listinfo/phenixbb

Well that's absolutely fair enough Nat. I do think a "quick patch" system would be certainly very useful for correcting minor things, as you suggest - if of course you can squeeze it in along with everything else(!). We can then download full updates, as and when they become available. I keep my personal version of Phenix fairly up to date with some of the nightly builds - but only implement full releases on my team's computers, to minimise my time spent on admin. Just to say a big thank you for all your current and future(!) hard work on Phenix. With regards, Antony. Sent from my iPhone On 6 Apr 2013, at 18:06, "Nathaniel Echols" mailto:[email protected]> wrote: On Sat, Apr 6, 2013 at 9:18 AM, Antony Oliver mailto:[email protected]> wrote: Dare I? - yes I do. CCP4 have recently put in place a very nice update system - which essentially does exactly what Ed is suggesting / asking for. What's also nice is that updates can be installed / uninstalled as a user wishes. Massively reduces the file sizes of downloads. I too would like something like this implemented in Phenix if at all possible. The fundamental problem is this: there is exactly one person (me!) responsible for building and maintaining installers and handling the release cycle. And I have another half-dozen projects which involve actual science. Before the nightly builds were automated, Paul (who certainly has much better things to do) had build each new installer manually. Unlike CCP4, our funding sources do not provide much if any support for this process. (And needless to say, most of this stuff isn't publishable either.) We have had internal discussions about adding an update mechanism, and I'm fairly confident I can implement something quickly that would at least address relatively simple patches like the B-factor issue. The reason I haven't done this is a) I have other things I also need to get done (some very time-sensitive), b) we are concerned about the added overhead of maintaining such a system, and c) because of the nightly builds we have slightly less motivation to rush something out. Keeping it running would require considerably modifications to our build system - the good news is that we need to change a lot of this anyway, so it may become slightly easier to manage in the future. However, the fundamental problem of too little manpower remains. One point that needs to be clarified: Given that changes between nightly builds are likely limited to relatively small patches/additions, is there some mechanism to do updates "revision control style", i.e. by downloading and updating only the parts of code that changed? This is only true for Python code, where there is no platform dependence. Compiled code (e.g. SOLVE, RESOLVE, nearly all of Phaser, Reduce, Probe, etc.) is considerably more difficult, because we would need to rebuild the shared libraries and/or executables on each platform, and distribute those in a system-dependent matter. (Which is especially difficult right now, because we have multiple 64-bit Linux builds made on different distributions.) One final point: if we add an update mechanism, it would definitely *not* replace the nightly builds for getting bleeding-edge features; it would only be used to add critical fixes for problems with the official releases. The nightly builds provide us with the essential ability to quickly push experimental new code out to power users, but these aren't changes we necessarily want to inflict on the rest of our users. (And yes, I realize this makes the use of nightly builds to provide bug fixes somewhat problematic.) -Nat _______________________________________________ phenixbb mailing list [email protected]mailto:[email protected] http://phenix-online.org/mailman/listinfo/phenixbb