-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear Paul,
my email was meant to be provocative but neither insulting nor offensive
(having provoked quite a few responses when I last used the word
'offense' this email does not suffer from a subtle misinterpretation of
mine while not using my mother
Tim,
I'm sure your email was tongue-in-check, but it's provocative nevertheless. I
suspect that Nat's point was that scientific software developers (who are
predominantly scientists of course) are helpful people who want to see their
field of research be successful. If it is possible to spend
On 8/7/13 8:27 PM, Ethan Merritt wrote:
That would be a bug. But it hasn't been true for any version of coot
that I have used. As you say, this is a common thing to do and I am
certain I would have noticed if it didn't work. I just checked that
it isn't true for 0.7.1-pre.
Thanks.
Turns out I
rritt
Verzonden: 8-8-2013 2:28
Aan: CCP4BB@JISCMAIL.AC.UK
Onderwerp: Re: [ccp4bb] mmCIF as working format?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/07/2013 11:54 PM, Nat Echols wrote:
> PLEASE tell the developers what you need to get your job done; we
> can't read minds.
>
> -Nat
>
Dear Nat,
I have a student working for me until the end of the month. I asked
her to calculate the mean
I hope that some [X]Emacs expert can rewrite Charlie Bond's wonderful pdb-mode
to work with mmCIF files (or at least the coordinate bits)
… for exactly the reasons Phil Jeffrey points out
Phil
On 8 Aug 2013, at 00:54, "Jeffrey, Philip D." wrote:
> Nat Echols wrote:
> > Personally, if I need
On Wednesday, August 07, 2013 04:54:39 pm Jeffrey, Philip D. wrote:
> Nat Echols wrote:
> > Personally, if I need to change a chain ID, I can use Coot or pdbset or
> > many other tools. Writing code for
> > this should only be necessary if you're processing large numbers of models,
> > or have
Quoting "Jeffrey, Philip D." :
Nat Echols wrote:
Personally, if I need to change a chain ID, I can use Coot or
pdbset or many other tools. Writing code for
this should only be necessary if you're processing large numbers of
models, or have a spectacularly
misformatted PDB file.
Problem.
Nat Echols wrote:
> Personally, if I need to change a chain ID, I can use Coot or pdbset or many
> other tools. Writing code for
> this should only be necessary if you're processing large numbers of models,
> or have a spectacularly
> misformatted PDB file.
Problem. Coot is bad at the chain l
> I.e. programs would look like this
>
> ---
> GRAB protein FROM FILE "best_model_ever.cif";
> SELECT CHAIN A FROM protein AS chA;
> SET chA BFACTORS TO 30.0;
> GRAB data FROM FILE "best_data_ever.cif";
> BIND protein TO data;
> REFINE protein USING BUSTER WITH TLS+ANISO;
> DROP protein INTO FILE "
On Wednesday, August 07, 2013 04:00:16 pm Ed Pozharski wrote:
> On 08/07/2013 05:54 PM, Nat Echols wrote:
> > Personally, if I need to change a chain ID, I can use Coot or pdbset
> > or many other tools. Writing code for this should only be necessary
> > if you're processing large numbers of mod
On 08/07/2013 05:54 PM, Nat Echols wrote:
Personally, if I need to change a chain ID, I can use Coot or pdbset
or many other tools. Writing code for this should only be necessary
if you're processing large numbers of models, or have a spectacularly
misformatted PDB file. Again, I'll repeat wh
James,
On 08/07/2013 05:36 PM, James Stroud wrote:
Anyone can learn Python in an hour and a half.
Isn't this a bit of an exaggeration? Python is designed to be easy to
learn, but we probably talking about different definitions of "learning"
and "anyone".
I.e. programs would look like thi
ames Stroud
> [xtald...@gmail.com]
> Sent: Wednesday, August 07, 2013 1:51 PM
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] mmCIF as working format?
>
> On Aug 5, 2013, at 4:33 AM, Eugene Krissinel wrote:
>> I just hope that one day we all will be discussing a sort
On Wed, Aug 7, 2013 at 2:36 PM, James Stroud wrote:
> Although it is likely the "best" library for working with structural data,
> CCTBX requires a loop just to change a specific chain ID (to the best of my
> knowledge):
>
> ...
>
> I don't intend to pick on CCTBX specifically (because the CCTBX
On Aug 7, 2013, at 2:35 PM, Ed Pozharski wrote:
> If I understand your proposal and reference to SQL correctly, you want some
> scripting language that sounds like simple English.
I didn't say anything about being English-like. English and other natural
languages are ill-adapted to describing th
Ed Pozharski wrote:
[snip]
If I understand your proposal and reference to SQL correctly, you want
some scripting language that sounds like simple English. Is the
advantage over existing APIs here that one does not need to learn
Python, C++, (or, heaven forbid, FORTRAN)? I.e. programs would lo
On 08/07/2013 03:54 PM, James Stroud wrote:
On Aug 7, 2013, at 1:06 PM, Ed Pozharski wrote:
On 08/07/2013 01:51 PM, James Stroud wrote:
In the long term, the MM structure community should perhaps get its inspiration
from SQL
For this to work, a particular interface must monopolize access to s
The flexibility of CIF is indeed infinite. Even the names of the
unit-cell dimsnsions are different in mmCIF and (small molecule) core CIF.
One of the main reasons why I had to bring out a new version of SHELXL
recently (SHELXL-2013 to replace SHELXL-97) was that in the
meantime COMCIFS committe
Nobody has addressed the fact that mmCIF is a format
that allows for many ways of presenting the same data. The
recent discussions seem to be based on the assumption that
all mmCIF files will look like those currently prepared by
the PDB.
Any code that reads an mmCIF file should be pre
On Wed, Aug 7, 2013 at 12:54 PM, James Stroud wrote:
> All that needs to happen is that the community agree on
>
> 1. What is the finite set of essential/useful attributes of macromolecular
> structural data.
> 2. What is the syntax of (a) accessing and (b) modifying those attributes.
> 3. What i
On Aug 7, 2013, at 1:06 PM, Ed Pozharski wrote:
> On 08/07/2013 01:51 PM, James Stroud wrote:
>> In the long term, the MM structure community should perhaps get its
>> inspiration from SQL
> For this to work, a particular interface must monopolize access to structural
> data.
Not necessarily, al
On 08/07/2013 01:51 PM, James Stroud wrote:
In the long term, the MM structure community should perhaps get its inspiration
from SQL
For this to work, a particular interface must monopolize access to
structural data. Then maintainers of that victorious interface could
change the underlying fo
ISCMAIL.AC.UK] on behalf of James Stroud
> [xtald...@gmail.com]
> Sent: Wednesday, August 07, 2013 1:51 PM
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] mmCIF as working format?
>
> On Aug 5, 2013, at 4:33 AM, Eugene Krissinel wrote:
>> I just hope that one day w
James Stroud
[xtald...@gmail.com]
Sent: Wednesday, August 07, 2013 1:51 PM
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] mmCIF as working format?
On Aug 5, 2013, at 4:33 AM, Eugene Krissinel wrote:
> I just hope that one day we all will be discussing a sort of universal API to
> read
On Aug 5, 2013, at 4:33 AM, Eugene Krissinel wrote:
> I just hope that one day we all will be discussing a sort of universal API to
> read/write structural information instead of referencing to raw formats, and
> routines to query MX data, which would be more appropriate than grep (would
> many
Dear David and Kaiser:
While the PDB format is (thankfully--to those used to it) around, it seems to
me it is certainly a rather poor deterrent to the enjoyment of AWK:
For fixed-field format input, the designers of AWK suggested a useful solution:
the function substr(s,p,n), i.e., "return subs
e:
>>
>>
>> /Boaz Shaanan, Ph.D.
>> Dept. of Life Sciences
>> Ben-Gurion University of the Negev
>> Beer-Sheva 84105
>> Israel
>>
>> E-mail: bshaa...@bgu.ac.il
>> Phone: 972-8-647-2220 Skype: boaz.shaanan
>> Fax: 972-8-647-2992 or 972-8-646-1710 /
>> //
>> //
>> /
>>
>>
On Mon, Aug 05, 2013, Boaz Shaanan wrote:
> I teach many such students and it's fairly easy to explain to them where
> to look in the PDB for particular pieces of information relevant to the
> structure. I can't imagine how they'll cope with the cryptic mmCIF format.
For many purposes, it's not a
2-8-647-2992 or 972-8-646-1710 /
//
//
/
/
*From:* Nat Echols [nathaniel.ech...@gmail.com]
*Sent:* Monday, August 05, 2013 10:45 PM
*To:* בעז שאנן
*Cc:* CCP4BB@JISCMAIL.AC.UK
*Subject:* Re: [ccp4bb] mmCIF as working format?
On Mon, Aug 5, 2013 at 12:37 PM, Boaz Shaanan <
, August 05, 2013 10:45 PM
To: בעז שאנן
Cc: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] mmCIF as working format?
On Mon, Aug 5, 2013 at 12:37 PM, Boaz Shaanan <bshaa...@bgu.ac.il> wrote:
There seems to be some kind of a gap between users and developers as far the eagerness to abandon PDB in
On Mon, Aug 5, 2013 at 12:37 PM, Boaz Shaanan wrote:
> There seems to be some kind of a gap between users and developers as far
> the eagerness to abandon PDB in favour of mmCIF. I myself fully agree with
> Jeffrey about the ease of manipulating PDB's during work, particularly when
> encounterin
From: CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] on behalf of Nat Echols [nathaniel.ech...@gmail.com]
Sent: Monday, August 05, 2013 10:10 PM
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] mmCIF as working format?
On Mon, Aug 5, 2013 at 11:11 AM, Phil Jeffrey <pjeff...@p
On Mon, Aug 5, 2013 at 11:11 AM, Phil Jeffrey wrote:
> While alternative programs exist to do almost everything I prefer
> something that works well, works quickly, and provides instant visual
> feedback. CCP4 and Phenix are stuck in a batch processing paradigm that I
> don't find useful for thes
Questionable practice is writing an interpretation program for
operations that can be handled simply at the command line. Programs
that use the API that Eugene implicitly refers to are no panacea, e.g.
Coot has strange restrictions on things like changing the chain label
that can be fixed in a
I always assumed there was a broad consensus that the PDB format was
ancient and by now profoundly rubbish.
Ho hum, live and learn.
On 05/08/2013 14:53, Pavel Afonine wrote:
Tim,
PDB file format is good because of its simplicity and that's perhaps
it. However, it cannot accommodate wealth o
Tim,
PDB file format is good because of its simplicity and that's perhaps it.
However, it cannot accommodate wealth of information that is available at
the end of refinement. Of course one can keep creating remarks for PDB file
etc but I guess mmCIF is just a better way of doing it rather than ugl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Ian,
yes, also as Andrew pointed at, I meant to refer to the ration of xml
vs. cif rather than cif vs. PDB.
My worry was that future versions of programs like refmac, phenix, or
buster-TNT would only write large files (in xml-format) and no more
P
On 05/08/13 09:03, Tim Gruene wrote:
having read Gerard Kleywegt's latest announcement on the wwPDB Workshop
(1st August) made me wonder whether it is planned to introduce mmCIF as
working format to users in addition to using it at e.g. the PDB, because
I think that would make life unnecessarily
Hi Tim,
I just downloaded GroEL entry 4KI8 in pdb format and cid format from
RSCB. The PDB format was 4.7Mb and the CIF format was 5.9Mb, doesn't seem such
a big difference to me ? Which example were you looking at ?
Andrew
On 5 Aug 2013, at 09:03, Tim Gruene wrote:
> -BEGIN
I just hope that one day we all will be discussing a sort of universal API to
read/write structural information instead of referencing to raw formats, and
routines to query MX data, which would be more appropriate than grep (would
many SB students/postdocs use grep these days? but many if them w
Tim,
Having not read Gerard Kleywegt's announcement, and not considering myself a
programmer, I have to disagree with the majority of your statement. Yes, using
grep on mmcif files is "awk"ward (but petfectly possible); awk on the other
hand works much better. It's actually more of a pain to u
42 matches
Mail list logo
