Menu
▾
▴
cclib-devel
|
From: Noel O'B. <bao...@gm...> - 2007-07-31 14:15:07
|
Dear devs, In the next few weeks let's focus on getting cclib 0.8 out the door. That is, finalising parsers, getting our methods back on-line and bug fixes. As a provisional date, let's say release end of Sept. What do you think? Noel |
|
From: Adam T. <a-t...@st...> - 2007-07-31 18:06:10
|
I agree, but we need to discuss a few things: ccData: are we done with this, or are we going to change the way the various methods work? methods: are we going to try to add any new ones? parsers: what must be done before a parser is considered finished? for instance, the ORCA parser does everything i need for pymolyze, but it's missing the MP, TDDFT, and SCF things. Adam On Jul 31, 2007, at 7:15 AM, Noel O'Boyle wrote: > Dear devs, > > In the next few weeks let's focus on getting cclib 0.8 out the door. > That is, finalising parsers, getting our methods back on-line and bug > fixes. As a provisional date, let's say release end of Sept. > > What do you think? > > Noel > > ---------------------------------------------------------------------- > --- > 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/ > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel |
|
From: Nuno A. G. B. <nun...@is...> - 2007-07-31 18:22:39
|
Has the ADF parser been fixed yet ? Regards, -- Nuno A. G. Bandeira, AMRSC Graduate researcher and molecular sculptor Inorganic and Theoretical Chemistry Group, Faculty of Science University of Lisbon - C8 building, Campo Grande, 1749-016 Lisbon,Portugal http://cqb.fc.ul.pt/intheochem/nuno.html Doctoral student @ IST,Lisbon -- |
|
From: Karol L. <kar...@kn...> - 2007-07-31 21:06:57
|
On Tuesday 31 July 2007 14:21, Nuno A. G. Bandeira wrote: > Has the ADF parser been fixed yet ? If I remember correctly, there are still a few regressions failing for the ADF parser. I will be looking into these after getting some other things done, if no one else does before me. -- written by Karol Langner Tue Jul 31 23:02:29 EDT 2007 |
|
From: Noel O'B. <bao...@gm...> - 2007-07-31 18:35:40
|
On 31/07/07, Adam Tenderholt <a-t...@st...> wrote: > I agree, but we need to discuss a few things: > > ccData: are we done with this, or are we going to change the way the > various methods work? I think that we won't refactor any more at this stage. We'll just make sure it all currently works. The methods will have to be changed, but not that much right? If we fix/change one, we'll have an idea what the issues are. > methods: are we going to try to add any new ones? Well, this is the question. It depends on whether we have some already decent code around for some method. > parsers: what must be done before a parser is considered finished? > for instance, the ORCA parser does everything i need for pymolyze, > but it's missing the MP, TDDFT, and SCF things. Would it be possible for you to create some test files for MP and TDDFT? I have an incentive (i.e. GaussSum) to get TDDFT and SCF working... > Adam > > > On Jul 31, 2007, at 7:15 AM, Noel O'Boyle wrote: > > > Dear devs, > > > > In the next few weeks let's focus on getting cclib 0.8 out the door. > > That is, finalising parsers, getting our methods back on-line and bug > > fixes. As a provisional date, let's say release end of Sept. > > > > What do you think? > > > > Noel > > > > ---------------------------------------------------------------------- > > --- > > 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/ > > _______________________________________________ > > cclib-devel mailing list > > ccl...@li... > > https://lists.sourceforge.net/lists/listinfo/cclib-devel > > |
|
From: Karol L. <kar...@kn...> - 2007-07-31 21:05:15
|
On Tuesday 31 July 2007 14:35, Noel O'Boyle wrote: > On 31/07/07, Adam Tenderholt <a-t...@st...> wrote: > > I agree, but we need to discuss a few things: > > > > ccData: are we done with this, or are we going to change the way the > > various methods work? > > I think that we won't refactor any more at this stage. We'll just make > sure it all currently works. The methods will have to be changed, but > not that much right? If we fix/change one, we'll have an idea what the > issues are. I agree. Further refactoring can be done after the release, since it really won't affect the way cclib is used and is aimed at making developing easier in the future. If there is time, though, I would be happy to see this go a bit further. > > methods: are we going to try to add any new ones? > > Well, this is the question. It depends on whether we have some already > decent code around for some method. I have code ready for a few types of electrostatic multipole analyses (including Stone's DMA), but I might not want to include this in cclib before the release. > > On Jul 31, 2007, at 7:15 AM, Noel O'Boyle wrote: > > > Dear devs, > > > > > > In the next few weeks let's focus on getting cclib 0.8 out the door. > > > That is, finalising parsers, getting our methods back on-line and bug > > > fixes. As a provisional date, let's say release end of Sept. > > > > > > What do you think? I think the end of September is a good target, since the beginning of the academic year will mean less time for most of us. Karol -- written by Karol Langner Tue Jul 31 22:53:33 EDT 2007 |
|
From: Adam T. <a-t...@st...> - 2007-07-31 21:48:15
|
> I agree. Further refactoring can be done after the release, since > it really > won't affect the way cclib is used and is aimed at making > developing easier > in the future. If there is time, though, I would be happy to see > this go a > bit further. Ok, so we wait until after the release, unless Karol finds more time. As far as I know, there should only be minor changes for the methods. The things that come to mind are: 1. Pass ccData to constructor, instead of a parser 2. Remove any parser.parse() code. 3. ??? > I have code ready for a few types of electrostatic multipole analyses > (including Stone's DMA), but I might not want to include this in > cclib before > the release. Ok. I'll also upload some MP and TDDFT stuff for Orca in the next week or so. Adam |
|
From: Adam T. <a-t...@st...> - 2007-08-03 21:12:07
|
> Would it be possible for you to create some test files for MP and > TDDFT? I have an incentive (i.e. GaussSum) to get TDDFT and SCF > working... I have uploaded two new ORCA calculations: MP2 for water and TDDFT for dvb. I can't find anywhere in the ORCA manual how to do MP3/MP4 jobs. Adam |
|
From: Karol L. <kar...@kn...> - 2007-08-27 17:58:05
|
As far as the next release is concerned, I know Noel is getting a list prepared.... but here are some "issues" I haven't seen a clear answer to: 1) Is the Molpro parser staying in the trunk? 2) Is either the ORCA or Turbomole parser going to be trunked before the release? 3) Should any of the new attributes since 0.7 be excluded? charge and mult obviously not, but what about nocoeffs? The first unittests are there, and I'm planning on adding new ones. 4) Does anyone know how to deal with the current 2 failures in the ADF tests? -- written by Karol Langner Mon Aug 27 19:46:35 EDT 2007 |
|
From: Noel O'B. <bao...@gm...> - 2007-08-28 07:06:02
|
On 28/08/07, Karol Langner <kar...@kn...> wrote: > As far as the next release is concerned, I know Noel is getting a list > prepared.... but here are some "issues" I haven't seen a clear answer to: > > 1) Is the Molpro parser staying in the trunk? We moved it there because it was thought ready to release. Do you still think so? > 2) Is either the ORCA or Turbomole parser going to be trunked before the > release? Not at this stage. I want to get the next release out as soon as possible and neither of these have good coverage of the tests. > 3) Should any of the new attributes since 0.7 be excluded? charge and mult > obviously not, but what about nocoeffs? The first unittests are there, and > I'm planning on adding new ones. I'm happy leaving it in. I think that this is one of the smallest changes in the new release. > 4) Does anyone know how to deal with the current 2 failures in the ADF tests? We need to decide whether these are actually impossible to fix based on the log file. Noel > > -- > written by Karol Langner > Mon Aug 27 19:46:35 EDT 2007 > |
|
From: Adam T. <a-t...@st...> - 2007-08-29 05:07:09
|
>> 4) Does anyone know how to deal with the current 2 failures in the >> ADF tests? > We need to decide whether these are actually impossible to fix based > on the log file. I've looked at the Frags_NiCO4_orig file a bit tonight and noticed two things. First, our parser doesn't correctly detect the create run for the Ni atom because it is not formatted like we expect. Our parser looks for "INPUT FILE" >= 0 and then the next line starting with "Create". The regression file has a blank line after the INPUT FILE. This causes the parser to parse the O Create job, and thus, creates mosyms and symlist (I think), which screws up parsing mocoeffs in the main job. I'm not sure if this is related to ADF2006.01 (btw, ADF2007 was just released), the Ni create job, or both. Second, there are actually two calculations in this file: a CO fragment and the Ni(CO)4 molecule. I think it can get symmetry labels from the CO fragment and then tries to apply them to the Ni(CO)4 molecule when its mocoeffs are parsed. If all the cruft is deleted from this file so that just the calculation for the Ni(CO)4 molecule is left, it parses (although I haven't checked whether any of it is correct). We can try to fix the first issue by looking for "Create" or "create" in the next couple of lines after an INPUT FILE statement. I think the second issue should be addressed either by trying to catch the KeyError or looking for multiple jobs. Either way, we need to warn the user about the "problem" with their file. Comments? Adam P.S. I haven't looked at the Au2 file yet, but I vaguely remember Karol proposing a fix... |
|
From: Adam T. <a-t...@st...> - 2007-08-29 05:17:58
|
>> 2) Is either the ORCA or Turbomole parser going to be trunked >> before the >> release? > Not at this stage. I want to get the next release out as soon as > possible and neither of these have good coverage of the tests. What tests need to be covered for the ORCA parser? I've been using PyMOlyze with the ORCA trunk and haven't run into any problems yet. If you just want tests for determining whether arrays and lists have the right dimension, I can get on this right away as it *shouldn't* take long. If it's something more involved, then I agree it should wait until our next release. Adam |
|
From: Noel O'B. <bao...@gm...> - 2007-08-29 18:39:19
|
On 29/08/2007, Adam Tenderholt <a-t...@st...> wrote: > >> 2) Is either the ORCA or Turbomole parser going to be trunked > >> before the > >> release? > > Not at this stage. I want to get the next release out as soon as > > possible and neither of these have good coverage of the tests. > > What tests need to be covered for the ORCA parser? I've been using > PyMOlyze with the ORCA trunk and haven't run into any problems yet. > If you just want tests for determining whether arrays and lists have > the right dimension, I can get on this right away as it *shouldn't* > take long. If it's something more involved, then I agree it should > wait until our next release. Don't get me wrong - I trust the ORCA code. It's just that I don't want to spend the time now to increase the number of attributes parsed. Rather I would like us to focus on getting out a release. By using svnmerge.py we can keep the branches up to date with the trunk, so that PyMOlyze, for example, loses none of the capabilities of the trunk. However, I feel that releasing the ORCA parser now, and publicising it, without more coverage of attributes would not the best idea. I find myself short of time, and feel that the more we put in the trunk, the further away the release date will move. As ever, if you feel strongly now's the time to say it... Noel > Adam > > > > ------------------------------------------------------------------------- > 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/ > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel > |
|
From: Adam T. <a-t...@st...> - 2007-08-29 19:11:50
|
> Don't get me wrong - I trust the ORCA code. It's just that I don't > want to spend the time now to increase the number of attributes > parsed. Rather I would like us to focus on getting out a release. By > using svnmerge.py we can keep the branches up to date with the trunk, > so that PyMOlyze, for example, loses none of the capabilities of the > trunk. However, I feel that releasing the ORCA parser now, and > publicising it, without more coverage of attributes would not the best > idea. Ok, that's fine. I agree that we can get out a new release and merge those changes into the ORCA branch, which I can use if necessary. > I find myself short of time, and feel that the more we put in the > trunk, the further away the release date will move. I too am finding myself short on time, so I'm not likely to be pushing out a new version of PyMOlyze soon. Adam |
|
From: Noel O'B. <bao...@gm...> - 2007-09-03 18:26:34
|
Sorry for not replying on this earlier...I was just trying to get an overview. On 29/08/07, Adam Tenderholt <a-t...@st...> wrote: > >> 4) Does anyone know how to deal with the current 2 failures in the > >> ADF tests? > > We need to decide whether these are actually impossible to fix based > > on the log file. > > I've looked at the Frags_NiCO4_orig file a bit tonight and noticed > two things. > > First, our parser doesn't correctly detect the create run for the Ni > atom because it is not formatted like we expect. Our parser looks for > "INPUT FILE" >= 0 and then the next line starting with "Create". The > regression file has a blank line after the INPUT FILE. This causes > the parser to parse the O Create job, and thus, creates mosyms and > symlist (I think), which screws up parsing mocoeffs in the main job. > I'm not sure if this is related to ADF2006.01 (btw, ADF2007 was just > released), the Ni create job, or both. > > Second, there are actually two calculations in this file: a CO > fragment and the Ni(CO)4 molecule. I think it can get symmetry labels > from the CO fragment and then tries to apply them to the Ni(CO)4 > molecule when its mocoeffs are parsed. If all the cruft is deleted > from this file so that just the calculation for the Ni(CO)4 molecule > is left, it parses (although I haven't checked whether any of it is > correct). > > We can try to fix the first issue by looking for "Create" or "create" > in the next couple of lines after an INPUT FILE statement. Sounds fine. > I think the second issue should be addressed either by trying to > catch the KeyError or looking for multiple jobs. Either way, we need > to warn the user about the "problem" with their file. Comments? I don't think we should try to handle multiple jobs. All of our scripts assume one job per file, and it's quite easy for the user to ensure that the input is like this. I say log an error, and return None. > Adam > > P.S. I haven't looked at the Au2 file yet, but I vaguely remember > Karol proposing a fix... I'll dig up the date of the email... > > ------------------------------------------------------------------------- > 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/ > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel > |
|
From: Adam T. <a-t...@st...> - 2007-09-03 19:17:26
|
I've made a couple of changes to fix the Frags_NiCO4 errors >> We can try to fix the first issue by looking for "Create" or "create" >> in the next couple of lines after an INPUT FILE statement. > > Sounds fine. If there is a blank line after an INPUT FILE statement, it looks at the following line. It now checks for "create" in addition to "Create". >> I think the second issue should be addressed either by trying to >> catch the KeyError or looking for multiple jobs. Either way, we need >> to warn the user about the "problem" with their file. Comments? > > I don't think we should try to handle multiple jobs. All of our > scripts assume one job per file, and it's quite easy for the user to > ensure that the input is like this. I say log an error, and return > None. When "INPUT FILE" is found, it checks for scftargets as I figure all calculations, finished or not, should have scftargets set. If so, it logs a warning and skips to the end of the file. Sound reasonable? Adam |
|
From: Noel O'B. <bao...@gm...> - 2007-09-04 15:55:53
|
On 03/09/07, Adam Tenderholt <a-t...@st...> wrote: > I've made a couple of changes to fix the Frags_NiCO4 errors > > >> We can try to fix the first issue by looking for "Create" or "create" > >> in the next couple of lines after an INPUT FILE statement. > > > > Sounds fine. > > If there is a blank line after an INPUT FILE statement, it looks at > the following line. It now checks for "create" in addition to "Create". > > >> I think the second issue should be addressed either by trying to > >> catch the KeyError or looking for multiple jobs. Either way, we need > >> to warn the user about the "problem" with their file. Comments? > > > > I don't think we should try to handle multiple jobs. All of our > > scripts assume one job per file, and it's quite easy for the user to > > ensure that the input is like this. I say log an error, and return > > None. > > When "INPUT FILE" is found, it checks for scftargets as I figure all > calculations, finished or not, should have scftargets set. If so, it > logs a warning and skips to the end of the file. Sound reasonable? Maybe you should raise an Exception? I think our policy should be to not handle these files at all, and let the user know this. Otherwise, it will pass silently (except for the warning) through cclib...what do you think? > Adam > > |
|
From: Adam T. <a-t...@st...> - 2007-09-04 16:10:21
|
>> When "INPUT FILE" is found, it checks for scftargets as I figure all >> calculations, finished or not, should have scftargets set. If so, it >> logs a warning and skips to the end of the file. Sound reasonable? > > Maybe you should raise an Exception? I think our policy should be to > not handle these files at all, and let the user know this. Otherwise, > it will pass silently (except for the warning) through cclib...what do > you think? Won't this just cause the parser to fail? I think we should have it exit "sanely" by printing a warning/error message and skipping to the end of the file. cclib's default loglevel is INFO, so this information will be printed, and the results of the first calculation will still be available. Adam |
|
From: Noel O'B. <bao...@gm...> - 2007-09-04 18:28:19
|
On 04/09/07, Adam Tenderholt <a-t...@st...> wrote: > >> When "INPUT FILE" is found, it checks for scftargets as I figure all > >> calculations, finished or not, should have scftargets set. If so, it > >> logs a warning and skips to the end of the file. Sound reasonable? > > > > Maybe you should raise an Exception? I think our policy should be to > > not handle these files at all, and let the user know this. Otherwise, > > it will pass silently (except for the warning) through cclib...what do > > you think? > > Won't this just cause the parser to fail? > > I think we should have it > exit "sanely" by printing a warning/error message and skipping to the > end of the file. cclib's default loglevel is INFO, so this > information will be printed, and the results of the first calculation > will still be available. Maybe I was a little hasty...I guess you're right. > Adam > > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X