Menu
▾
▴
Re: [cclib-devel] [cclib-users] Orca 2.9.0 error
|
From: Noel O'B. <bao...@gm...> - 2013-07-28 09:26:58
|
Sorry - I see that I said I'd do this but clearly never did.
Regarding (2) first, sure separate functions are fine and probably a
good idea in general.
Regarding (1), I have in mind that the next release will be based on
Python 3. So definitely make sure that your fixes go on the Py3
branch. My own feeling is maintaining two branches at the same time is
too much work - our resources are best spent on a single Python.
However, if one of you wants to merge fixes back to the Python2 branch
feel free to do it. (BTW, I still have to port GaussSum too and
similiarly it'll happen in the next few months.)
- Noel
On 27 July 2013 20:42, Adam Tenderholt <ate...@gm...> wrote:
> A user of QMForge just alerted me to this problem, and I didn't see an
> obvious fix in SVN. Before I started to work on it, I wanted to check-in and
> ask a few things.
>
> 1) Will there be a minor bug fix release for cclib 1.1 (python2), or are we
> only supporting fixes to the python3 branches now? If we make a change in
> one branch, how difficult is it to merge that to another branch given the
> python differences? Is it better to make two separate fixes? (QMForge is
> still on python2, but I plan on moving to python3 in the coming months.)
>
> 2) Any thoughts on the best approach? Right now, there is a large commented
> block detailing the format with the main parser code being if/elif
> statements inside a while loop. A second commented block can be added
> detailing the other format along with the associated parser code. Since this
> would likely lead to somewhat messier code, there could instead be two new
> functions (parse_scf_condensed_format and parse_scf_expanded_format) with
> format commented at the beginning of the function. I'm leaning towards the
> latter since our extract functions are becoming quite large (over 500 LOC
> for Orcaparser and 1000 LOC for Gaussian!!), and perhaps we should consider
> creating functions for individual attributes.
>
> Adam
>
>
>
> On Mon, Feb 25, 2013 at 3:24 PM, Karol M. Langner <kar...@gm...>
> wrote:
>>
>> I agree, and I'll leave this one to you guys. Have you checked if perhaps
>> this is caused by a change between ORCA versions? I'm not really up-to-date
>> on it's output.
>>
>> Karol
>>
>> On Feb 25 2013, Noel O'Boyle wrote:
>> > I'm all for parsing it. Since this is fairly GaussSum-specific I'm
>> > happy to do it if you can make sure these files are public domain. In
>> > the meanwhile, you can point out to the user that he can comment out
>> > the offending code.
>> >
>> > On 25 February 2013 17:31, Adam Tenderholt <ate...@gm...>
>> > wrote:
>> > > CC: dev list
>> > >
>> > > Any thoughts on this? Should we try to parse the alternate SCF
>> > > convergence
>> > > info, or just change the code so it doesn't raise an exception?
>> > >
>> > > Adam
>> > >
>> > > On Mon, Feb 25, 2013 at 3:14 AM, msmqbm <ms...@ci...> wrote:
>> > >>
>> > >> Dear Adam,
>> > >>
>> > >> Thanks for your message. The reason for that strange output is the
>> > >> NormalPrint keyword, it has nothing to do with the MRCI (you can
>> > >> delete that
>> > >> part). Here I attach an output with a DFT calculation and a
>> > >> normalPrint
>> > >> keyword, so that you can see the source of the problem.
>> > >> It's ok if you make this input or output public.
>> > >>
>> > >> It would be nice that, even if the parser cannot read the whole file,
>> > >> it
>> > >> didn't raise an exception, so that one could get at least the
>> > >> geometry, the
>> > >> number of atoms or the information it has read so far.
>> > >>
>> > >> Cheers,
>> > >>
>> > >>
>> > >> On 02/25/2013 01:24 AM, Adam Tenderholt wrote:
>> > >>
>> > >> Hi Melchor,
>> > >>
>> > >> Sorry for the delay. I've finally looked into your parse error. The
>> > >> problem is the output from the SCF convergence. For instance, it your
>> > >> file,
>> > >> it is:
>> > >>
>> > >> --------------
>> > >> SCF ITERATIONS
>> > >> --------------
>> > >> *** Starting incremental Fock matrix formation ***
>> > >>
>> > >> ----------------------------
>> > >> ! ITERATION 0 !
>> > >> ----------------------------
>> > >> Total Energy : -377.995940441385 Eh
>> > >> Energy Change : -377.995940441385 Eh
>> > >> MAX-DP : 0.104636203272
>> > >> RMS-DP : 0.004511416837
>> > >> Actual Damping : 0.7000
>> > >> Actual Level Shift : 0.2500 Eh
>> > >> Int. Num. El. : 43.99928165 (UP= 21.99964083 DN=
>> > >> 21.99964083)
>> > >> Exchange : -34.30375363
>> > >> Correlation : -2.02696332
>> > >>
>> > >>
>> > >> ----------------------------
>> > >> ! ITERATION 1 !
>> > >> ----------------------------
>> > >> Total Energy : -378.158637308210 Eh
>> > >> Energy Change : -0.162696866825 Eh
>> > >> MAX-DP : 0.056981704567
>> > >> RMS-DP : 0.002392614971
>> > >> Actual Damping : 0.7000
>> > >> Actual Level Shift : 0.2500 Eh
>> > >> Int. Num. El. : 43.99902992 (UP= 21.99951496 DN=
>> > >> 21.99951496)
>> > >> Exchange : -34.01830967
>> > >> Correlation : -2.01718102
>> > >>
>> > >> However, cclib is expecting the following:
>> > >>
>> > >> --------------
>> > >> SCF ITERATIONS
>> > >> --------------
>> > >> ITER Energy Delta-E Max-DP RMS-DP
>> > >> [F,P]
>> > >> Damp
>> > >> *** Starting incremental Fock matrix formation ***
>> > >> 0 -381.9867779344 0.000000000000 0.05707535 0.00425410
>> > >> 0.0807540
>> > >> 0.7000
>> > >> 1 -382.0079986969 -0.021220762511 0.02895905 0.00220039
>> > >> 0.0411442
>> > >> 0.7000
>> > >>
>> > >> I tried to make sense of your input file, but I don't have any
>> > >> experience
>> > >> with MRCI calculations with ORCA. Do you know if there was some
>> > >> option that
>> > >> caused the SCF convergence to be printed differently? Or is this how
>> > >> the
>> > >> convergence for all MRCI calculations is printed?
>> > >>
>> > >> Also, are you willing to place your logfile in the public domain? We
>> > >> would
>> > >> like to include it with our other regression files.
>> > >>
>> > >> Thanks,
>> > >>
>> > >> Adam
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> On Thu, Feb 21, 2013 at 1:48 AM, msmqbm <ms...@ci...> wrote:
>> > >>>
>> > >>> Dear cclib developers,
>> > >>> When trying to parse an Orca 2.9.0 output file I get the following
>> > >>> error:
>> > >>>
>> > >>> >>> import cclib
>> > >>> >>> f1= cclib.parser.ORCA("DAT6600.out")
>> > >>> >>> data1= f1.parse()
>> > >>> [ORCA DAT6600.out INFO] Creating attribute atomcoords[]
>> > >>> [ORCA DAT6600.out INFO] Creating attribute atomnos[]
>> > >>> [ORCA DAT6600.out INFO] Creating attribute natom: 9
>> > >>> [ORCA DAT6600.out INFO] Creating attribute nbasis: 90
>> > >>> [ORCA DAT6600.out INFO] Creating attribute charge: 0
>> > >>> [ORCA DAT6600.out INFO] Creating attribute mult: 1
>> > >>> [ORCA DAT6600.out INFO] Creating attribute scfvalues[]
>> > >>> Traceback (most recent call last):
>> > >>> File "<stdin>", line 1, in <module>
>> > >>> File
>> > >>> "/usr/lib/python2.7/dist-packages/cclib/parser/logfileparser.py",
>> > >>> line 221, in parse
>> > >>> self.extract(inputfile, line)
>> > >>> File
>> > >>> "/usr/lib/python2.7/dist-packages/cclib/parser/orcaparser.py",
>> > >>> line 90, in extract
>> > >>> assert line[1] == "Energy"
>> > >>> AssertionError
>> > >>>
>> > >>> I'm using cclib version 1.1 (the latest one). I attach the file
>> > >>> DAT6600.out.
>> > >>>
>> > >>> Is there a solution to this?
>> > >>>
>> > >>> Thanks in advance,
>> > >>>
>> > >>> --
>> > >>> Melchor Sánchez
>> > >>> PhD candidate
>> > >>> Institute of Advanced Chemistry of Catalonia
>> > >>> http://www.iqac.csic.es/qteor
>> > >>> IQAC - CSIC
>> > >>> Tel. +34 934006100 ext: 1307
>> > >>> Jordi Girona 18-26
>> > >>> 08034 Barcelona (Spain)
>> > >>>
>> > >>>
>> > >>>
>> > >>>
>> > >>> ------------------------------------------------------------------------------
>> > >>> Everyone hates slow websites. So do we.
>> > >>> Make your web apps faster with AppDynamics
>> > >>> Download AppDynamics Lite for free today:
>> > >>> http://p.sf.net/sfu/appdyn_d2d_feb
>> > >>> _______________________________________________
>> > >>> cclib-users mailing list
>> > >>> ccl...@li...
>> > >>> https://lists.sourceforge.net/lists/listinfo/cclib-users
>> > >>>
>> > >>
>> > >>
>> > >>
>> > >> --
>> > >> Melchor Sánchez
>> > >> PhD candidate
>> > >> Institute of Advanced Chemistry of Catalonia
>> > >> http://www.iqac.csic.es/qteor
>> > >> IQAC - CSIC
>> > >> Tel. +34 934006100 ext: 1307
>> > >> Jordi Girona 18-26
>> > >> 08034 Barcelona (Spain)
>> > >
>> > >
>> > >
>> > >
>> > > ------------------------------------------------------------------------------
>> > > Everyone hates slow websites. So do we.
>> > > Make your web apps faster with AppDynamics
>> > > Download AppDynamics Lite for free today:
>> > > http://p.sf.net/sfu/appdyn_d2d_feb
>> > > _______________________________________________
>> > > cclib-devel mailing list
>> > > ccl...@li...
>> > > https://lists.sourceforge.net/lists/listinfo/cclib-devel
>> > >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Everyone hates slow websites. So do we.
>> > Make your web apps faster with AppDynamics
>> > Download AppDynamics Lite for free today:
>> > http://p.sf.net/sfu/appdyn_d2d_feb
>> > _______________________________________________
>> > cclib-devel mailing list
>> > ccl...@li...
>> > https://lists.sourceforge.net/lists/listinfo/cclib-devel
>>
>> --
>> written by Karol M. Langner
>> Tue Feb 26 00:22:12 CET 2013
>
>
|
