From: Karol L. <kar...@kn...> - 2007-08-04 23:17:28
|
I believe there was a consensus to drop support for Numeric, so I did that just now. So... you _need_ numpy in order to use the svn revision now. I guess this should make alot of math-related things clear. On a related note - while working on the Molpro parser today I ran into the situation where you have only partial data in the output to parse some attribute. For example, Molpro by default prints the SCF cycle only for the first/last point in a gopt, therefore scfvalues is not of the expected dimensions. I know that for tests we should always have proper output, but I wonder how we are to deal with this in general. I mean, we don't want the user to get an attribute with dimensions he doesn't understand, right? To me it seems reasonable to fill up the gaps - put something in place of the lacking elements. I see two possibilities: 1) always use None 2) use numpy.nan. What re your thoughts? Karol -- written by Karol Langner Sun Aug 5 01:04:17 EDT 2007 |
From: Noel O'B. <bao...@gm...> - 2007-08-07 15:34:30
|
On 05/08/07, Karol Langner <kar...@kn...> wrote: > I believe there was a consensus to drop support for Numeric, so I did that > just now. So... you _need_ numpy in order to use the svn revision now. I > guess this should make alot of math-related things clear. Sounds good.. > On a related note - while working on the Molpro parser today I ran into the > situation where you have only partial data in the output to parse some > attribute. For example, Molpro by default prints the SCF cycle only for the > first/last point in a gopt, therefore scfvalues is not of the expected > dimensions. I know that for tests we should always have proper output, but I > wonder how we are to deal with this in general. I mean, we don't want the > user to get an attribute with dimensions he doesn't understand, right? To me > it seems reasonable to fill up the gaps - put something in place of the > lacking elements. I see two possibilities: 1) always use None 2) use > numpy.nan. What re your thoughts? First of all, is it possible to create the correct test file? If so, I'd appreciate if you could do so. Secondly, IMO I wouldn't fill the gaps for the general case. Rather I would return an array of size 2 in that dimension. I won't argue this too much but if you fill the gap, you will probably cause a users program to fail (e.g. GaussSum will fail with this information), rather than plot something. Also there is the problem that we haven't taken this attitude with the other programs. I don't feel that this information is so important that we need to spend too much time getting this perfect. It's easy for user to construct a calculation where there are more SCF cycles than GeoOpts. For example, an IR calculation in some programs. cclib just extracts the SCF information wherever it is, and doesn't worry about the context. Noel > Karol > > -- > written by Karol Langner > Sun Aug 5 01:04:17 EDT 2007 > > ------------------------------------------------------------------------- > 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-08-17 16:27:18
|
On Tuesday 07 August 2007 11:34, Noel O'Boyle wrote: > > On a related note - while working on the Molpro parser today I ran into > > the situation where you have only partial data in the output to parse > > some attribute. For example, Molpro by default prints the SCF cycle only > > for the first/last point in a gopt, therefore scfvalues is not of the > > expected dimensions. I know that for tests we should always have proper > > output, but I wonder how we are to deal with this in general. I mean, we > > don't want the user to get an attribute with dimensions he doesn't > > understand, right? To me it seems reasonable to fill up the gaps - put > > something in place of the lacking elements. I see two possibilities: 1) > > always use None 2) use numpy.nan. What re your thoughts? > > First of all, is it possible to create the correct test file? If so, > I'd appreciate if you could do so. AFAIK it is not possible to get Molpro to print the SCF microiterations to the principal output file (*.out). Reading both that one and the *.log file gives the correct attribute. > Secondly, IMO I wouldn't fill the gaps for the general case. Rather I > would return an array of size 2 in that dimension. I won't argue this > too much but if you fill the gap, you will probably cause a users > program to fail (e.g. GaussSum will fail with this information), > rather than plot something. Also there is the problem that we haven't > taken this attitude with the other programs. I don't feel that this > information is so important that we need to spend too much time > getting this perfect. It's easy for user to construct a calculation > where there are more SCF cycles than GeoOpts. For example, an IR > calculation in some programs. cclib just extracts the SCF information > wherever it is, and doesn't worry about the context. OK -- written by Karol Langner Fri Aug 17 18:15:13 EDT 2007 |