Re: [Blueobelisk-discuss] [Fwd: Re: gperiodic: Some issues and improvements]
Le lundi 30 juillet 2007 à 09:04 +0300, Jonas Frantz a écrit : Hi, the problem here is that bodr is defining the vectors for each element, this is completely redundant as most of the crystal structures can be described as a function of lattice structure (hcp, fcc, bcc and so on), the length of the unit cell vectors a,b,c and the angles of these alfa, beta, gamma. This would allow full description of the more exotic crystal structures as well. Have a look at for instance http://www.webelements.com/webelements/elements/text/Si/xtal.html for a source of these parameters. You might notice that they also give the space group, not the Bravais lattice. The vectors for each crystalstructure can then be described as the vectors for each atom within the unit cell and the unitvectors. What this is practice means: - Reduce the crystalstructure.xml to only contain the separate crystalstructures with unitvectors in terms of the lattice constant. - Introduce a couple of new fields per element in elements.xml. Regarding introducing the new fields to elements.xml, I guess you would want to do it in this fashion (note that for fcc all vectors are equal): lattice abundance=1.0 label name=structure value=fcc / scalar name=lattice_a value=3.564 unit=angstrom / scalar name=lattice_b value=3.564 unit=angstrom / scalar name=lattice_c value=3.564 unit=angstrom / scalar name=lattice_alfa value=90 unit=degrees / scalar name=lattice_beta value=90 unit=degrees / scalar name=lattice_gamma value=90 unit=degrees / /lattice With those data, you need the position of the second Si atom. If you have the space group, you don't. Anyway, atomic position are needed at least for molecular crystals, as hydrogen, since the origin in that case is not at an atomic position and there is no translation (in the space group) from one atom to the other (in that case, probably one atom is enough, since they are related by a symmetry operation). Even some metals need atomic position, as Mn alpha. By using this structure, you could describe all of the existing structures for every element (the sum of the abundance parameters should of course be 1). - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Blueobelisk-discuss mailing list Blueobelisk-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss
Re: [Blueobelisk-discuss] [Fwd: Re: gperiodic: Some issues and improvements]
On Jul 30 2007, Jean Bréfort wrote: CML has two mechanisms for crystal structures. (a) lattice and latticeVectors (b) crystal and either scalar (6) or cellParameter(2) Either of these should be able to support the requirement. The example given below uses lattice and scalar. If these are CML thei is not the recommended combination. If they are not, what is the namespace, becuase otherwise there will be serious clashes. Also lattice does not have an abundance attribute in CML and I'm not sure what the role of this is here. P. Le lundi 30 juillet 2007 à 09:04 +0300, Jonas Frantz a écrit : Hi, the problem here is that bodr is defining the vectors for each element, this is completely redundant as most of the crystal structures can be described as a function of lattice structure (hcp, fcc, bcc and so on), the length of the unit cell vectors a,b,c and the angles of these alfa, beta, gamma. This would allow full description of the more exotic crystal structures as well. Have a look at for instance http://www.webelements.com/webelements/elements/text/Si/xtal.html for a source of these parameters. You might notice that they also give the space group, not the Bravais lattice. The vectors for each crystalstructure can then be described as the vectors for each atom within the unit cell and the unitvectors. What this is practice means: - Reduce the crystalstructure.xml to only contain the separate crystalstructures with unitvectors in terms of the lattice constant. - Introduce a couple of new fields per element in elements.xml. Regarding introducing the new fields to elements.xml, I guess you would want to do it in this fashion (note that for fcc all vectors are equal): lattice abundance=1.0 label name=structure value=fcc / scalar name=lattice_a value=3.564 unit=angstrom / scalar name=lattice_b value=3.564 unit=angstrom / scalar name=lattice_c value=3.564 unit=angstrom / scalar name=lattice_alfa value=90 unit=degrees / scalar name=lattice_beta value=90 unit=degrees / scalar name=lattice_gamma value=90 unit=degrees / /lattice -- Peter Murray-Rust Unilever Centre for Molecular Informatics Chemistry Department, Cambridge University Lensfield Road, CAMBRIDGE, CB2 1EW, UK Tel: +44-1223-763069 Fax: +44 1223 763076 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Blueobelisk-discuss mailing list Blueobelisk-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss
Re: [Blueobelisk-discuss] [Fwd: Re: gperiodic: Some issues and improvements]
On Jul 30 2007, Jonas Frantz wrote: Hi, let me give you a recap of this whole mess as I see it: I'll try to respond positively :-). We need to accept that whatever we do in this area needs a lot of work from committed people. We have to devise the systems, validate them, implement them as code and data, etc. A lot depends on enthusiasm, and - realistically - most of the wortk is done by the poeple who want something to happen. It can be a lonely road at the start 1. It all started of with me suggesting that we should add some information (Bravais lattice names and lattice constants) to bodr about the most common crystal structures of elements, because I'd be interested to use bodr to fetch element information to gperiodic. This information is required if I want to do the effort of importing bodr information into gperiodic because gperiodics users need it. I give an example of how I think this information _could_ be included (note! only a humble example). This is probably a larger task than it appears. There are - presumably - about 100 elements which are solid and several of those have allotropes (carbon, sulfur, etc.) So this involves ca 200 crystal strucures. These all have to be found from somewhere. We have already found that it is quite difficult to get hold of many crystal structures. Let's assume we have them somewhere. We have to agree on a representation. This representation should be the same throughout the data set. Obviously I would suggest CML (but you can use CIF or other systems). 2. This results in a heated discussion, most replies about how this is not going to work and how it's not the best way, and so on. No one seems to want to come to a conclusion. I try to mediate to achieve the result I'd like to see. This only results in even more bitching and moaning. I haven't followed the discussion, but this is a non-trivial task if you want to build your own system. If you want to use CML I can help you to get started. 3. As far as I see it this is where we stand: - I've given up on getting this information from bodr BODR depends on volunteers to fill it. If you badly want a resource of element crystal strucures then some people have to be prepared to fill it. It may be that some people are able to help convert existing data if it's in simple form. - I've lost my motivation for contributing to bodr That's a pity, but I am afraid there is no magic. If you look at the stuff that is present in BO you will see many people who have worked through the night to make software and data happen. Most of the frequent posters are fully occupioed with their own systems. So you will get advice, and if you are lucky find other people to help. But you cannot rely on it. - My view of bodr maintainers has hit rock bottom (I hope not all of you are as bad) Maintenance costs time and effort and is often done by paying people real money in the real world. If we want things that are Open it depends on volunteers, perhaps some funding, perhaps some liberation of existing resources - who knows. - bodr hasn't become any better (well, not any worse either) Many of these efforts tak time to get off the ground. Look at Jmol 7 years ago. It was very rudimentary. So was OpenBabel. Now these are wonderful examples of Open collaboration. Hope this helps to giove the perspective. There aren't many free lunches. P. -- Peter Murray-Rust Unilever Centre for Molecular Informatics Chemistry Department, Cambridge University Lensfield Road, CAMBRIDGE, CB2 1EW, UK Tel: +44-1223-763069 Fax: +44 1223 763076 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Blueobelisk-discuss mailing list Blueobelisk-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss
Re: [Blueobelisk-discuss] [Fwd: Re: gperiodic: Some issues and improvements]
Dear Jonas, I did not receive your email directly, but as the one who made the recent BODR releases, I do feel obliged to respond; if you are angry at the BODR development, I take that personally. That's fine, but I was not aware that I had let you down. On 30 Jul 2007 14:34:21 +0100, Dr P. Murray-Rust [EMAIL PROTECTED] wrote: On Jul 30 2007, Jonas Frantz wrote: let me give you a recap of this whole mess as I see it: I have apparently missed big blobs of the discussion, because the 'mess' I received before your reply consists 4 emails... 1. It all started of with me suggesting that we should add some information (Bravais lattice names and lattice constants) to bodr about the most common crystal structures of elements, because I'd be interested to use bodr to fetch element information to gperiodic. That's the whole point of BODR: to provide a common data base of chemical/physical properties. I would not call crystal structure elemental properties, but close enough. I do remember some discussion of putting in crystal structures in for elements, quite some months ago. At that moment I made the remark too that a crystal structure is not an elemental property; are you referring to that discussion when using the term 'mess'? BTW, I never wanted to imply that crystal structures of single element compounds cannot be in BODR; I might have said that the elements.xml is not the place to do it. This information is required if I want to do the effort of importing bodr information into gperiodic because gperiodics users need it. I give an example of how I think this information _could_ be included (note! only a humble example). It's important to get things right in BODR, but hate to see people get disappointed because of implementation details. 2. This results in a heated discussion, most replies about how this is not going to work and how it's not the best way, and so on. No one seems to want to come to a conclusion. I try to mediate to achieve the result I'd like to see. This only results in even more bitching and moaning. I am not sure what this is referring to. I do not remember a heated discussion with bitching and moaning... is this supposed to have happened on the BO mailing list? If so, I really need to check my SPAM filter. 3. As far as I see it this is where we stand: - I've given up on getting this information from bodr - I've lost my motivation for contributing to bodr I find this disturbing... I feel sorry that I have not made you feel welcome and appreciated. - bodr hasn't become any better (well, not any worse either) Say again? There are two open bug reports, one of which is technical in nature (implementation details), the other one resolved, but not closed. If you have bug reports, please file them at: http://sourceforge.net/tracker/?atid=928367group_id=189199func=browse I'll make sure to fix them, or get them fixed. Kind regards, Egon - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Blueobelisk-discuss mailing list Blueobelisk-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss
