Menu
▾
▴
cclib-devel
|
From: Nuno A. G. B. <nun...@is...> - 2007-03-18 21:33:45
|
Hi,
Some months ago I'd emailed the development team sending some sample ADF
outputs to improve cclib operability. Have they been used ? I don't see
them on the present cclib distribution.
Also I got this error message when running a simple ADF example file:
File "PyMOlyze", line 28, in ?
File "pymolyze\pymolyze.pyc", line 140, in open
File "cclib\parser\adfparser.pyc", line 728, in parse
IndexError: invalid index
The file is attached.
Also spin orbit runs give another error message:
Traceback (most recent call last):
File "PyMOlyze", line 28, in ?
File "pymolyze\pymolyze.pyc", line 140, in open
File "cclib\parser\adfparser.pyc", line 555, in parse
IndexError: list index out of range
Any help would be appreciated. If you'd like more input files I can
provide as many as you wish.
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: Noel O'B. <bao...@gm...> - 2007-03-18 22:31:38
|
On 18/03/07, Nuno A. G. Bandeira <nun...@is...> wrote: > Hi, > > Some months ago I'd emailed the development team sending some sample ADF > outputs to improve cclib operability. Have they been used ? I don't see > them on the present cclib distribution. As discussed at the time (around 18/8/06), using your files we solved several problems. However, the FeCl4.zip you sent (24/06/06) was parsed correctly by cclib, and so was not included in the distribution. Our policy is to only include those files that (at some time) break our parser. Note that in any case you won't find these files in the regular cclib-0.x download. Due to the size of the files, they are provided separately (since they are mainly for testing purposes) on the sourceforge download site (http://www.sf.net/projects/cclib). > Also I got this error message when running a simple ADF example file: > > > File "PyMOlyze", line 28, in ? > File "pymolyze\pymolyze.pyc", line 140, in open > File "cclib\parser\adfparser.pyc", line 728, in parse > IndexError: invalid index > > The file is attached. > > Also spin orbit runs give another error message: > > Traceback (most recent call last): > File "PyMOlyze", line 28, in ? > File "pymolyze\pymolyze.pyc", line 140, in open > File "cclib\parser\adfparser.pyc", line 555, in parse > IndexError: list index out of range We will look into these... > Any help would be appreciated. If you'd like more input files I can > provide as many as you wish. That's great - once we fix this bug, you could run 'ccget --list *.adfout' over all of your adf files to see whether they are all parsed without errors. > 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: Adam T. <a-t...@st...> - 2007-03-18 23:00:07
|
Nuno, From what I can tell, the errors for the first file is related to ADF 2006.01 (I have yet to switch from 2004.01). The symmetry labels are uppercase in your test files, but our parser only looks for the first letter being capitalized. I'd guess this is a simple fix, but I'm not positive that there aren't other issues we'd have to deal with. > Also spin orbit runs give another error message: > > Traceback (most recent call last): > File "PyMOlyze", line 28, in ? > File "pymolyze\pymolyze.pyc", line 140, in open > File "cclib\parser\adfparser.pyc", line 555, in parse > IndexError: list index out of range Spin orbit relativistic calculations print the info in a slightly different format than the non-relativistic and scalar relativistic calcs do. This may take a bit of time to write the extra parsing code. Sorry for the inconvenience and thanks for reporting the bugs. Adam |
|
From: Nuno A. G. B. <nun...@is...> - 2007-03-18 23:02:35
|
I just noticed, browsing through the ADF manual that SFO analysis is not produced with spin orbit runs so naturally there will be nothing for the parser to read in that case. -- 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: Noel O'B. <bao...@gm...> - 2007-03-19 09:41:16
|
On 18/03/07, Nuno A. G. Bandeira <nun...@is...> wrote: > I just noticed, browsing through the ADF manual that SFO analysis is not > produced with spin orbit runs so naturally there will be nothing for the > parser to read in that case. Even so, it's still a bug in cclib - the parser shouldn't exit with an error. > > > -- > 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-03-20 20:18:13
|
I'm not too well familiar with ADF, but also tried running Nuno's files
through the parser.
For "Au2.out", besides the code that parses mocoeffs failing (the new output
files don't have two lines of comment that were there before), there seems to
be a problem with the number of MOs. Adding some debugging code before the
mocoeffs section gives this:
>>from cclib.parser import ccopen
>>a = ccopen("Au2.out")
>>a.parse()
nbasis: 108
len(moenergies[0]) 170
len(mosyms[0]) 170
mosyms: [['SIGMAg', 'SIGMAu', 'SIGMAg', 'SIGMAu', 'PIu', 'PIu', 'PIu',
....... more lines .....
'SIGMAg', 'SIGMAu']]
[ADF Au2.out INFO] Creating attribute mocoeffs: array[]
Traceback (most recent call last):
File "./test", line 6, in <module>
a.parse()
File
"/home/langner/apps/python/lib/python2.5/site-packages/cclib/parser/logfileparser.py",
line 118, in parse
self.extract(inputfile, fupdate=fupdate, cupdate=cupdate)
File
"/home/langner/apps/python/lib/python2.5/site-packages/cclib/parser/adfparser.py",
line 696, in extract
self.mocoeffs[spin][aolist[i+base], row + symoffset] = float(cols[i + 1])
IndexError: invalid index
Notice that there are more MOs than basis functions (SFOs for ADF, I guess).
Is this norml? Now, since mocoeffs is created as Numeric.zeros((self.nbasis,
self.nbasis), "d") there will always be a problem with filling it in this
particular case.
Hope this helps somehow,
Karol
--
written by Karol Langner
Tue Mar 20 21:10:26 CET 2007
|
|
From: Adam T. <a-t...@st...> - 2007-03-20 20:58:01
|
> For "Au2.out", besides the code that parses mocoeffs failing (the
> new output
> files don't have two lines of comment that were there before),
> there seems to
> be a problem with the number of MOs. Adding some debugging code
> before the
> mocoeffs section gives this:
>
>>> from cclib.parser import ccopen
>>> a = ccopen("Au2.out")
>>> a.parse()
> nbasis: 108
> len(moenergies[0]) 170
> len(mosyms[0]) 170
> mosyms: [['SIGMAg', 'SIGMAu', 'SIGMAg', 'SIGMAu', 'PIu', 'PIu', 'PIu',
> ....... more lines .....
> 'SIGMAg', 'SIGMAu']]
I think it's not correctly adding up the degeneracies of orbitals for
SIGMA, PI, and DELTA symmetries. In the "all Irreps" section, where
moenergies and mosyms are set, you have to know that PI (x and y
"sub"-symmetries) and DELTA (xy and x2-y2 "sub"-symmetries) orbitals
are degenerate (occupations with 4 electrons are allowed) and I'm
guessing it's not adding this section up correctly. The mocoeffs
section (and nbasis section) already splits this up, so nbasis == 108
is correct and len(moenergies) == 170 is probably wrong.
> Hope this helps somehow,
It does. I didn't realize that the parser was this broken. I'll try
to get around running this file in ADF2004.01 and see if we have a
similar problem. My guess is we do because I don't work with linear
molecules and so this case wasn't expected.
Adam
|
|
From: Karol L. <kar...@kn...> - 2007-03-20 21:23:40
|
On Tuesday 20 of March 2007 21:57, Adam Tenderholt wrote:
> > For "Au2.out", besides the code that parses mocoeffs failing (the
> > new output
> > files don't have two lines of comment that were there before),
> > there seems to
> > be a problem with the number of MOs. Adding some debugging code
> > before the
> >
> > mocoeffs section gives this:
> >>> from cclib.parser import ccopen
> >>> a = ccopen("Au2.out")
> >>> a.parse()
> >
> > nbasis: 108
> > len(moenergies[0]) 170
> > len(mosyms[0]) 170
> > mosyms: [['SIGMAg', 'SIGMAu', 'SIGMAg', 'SIGMAu', 'PIu', 'PIu', 'PIu',
> > ....... more lines .....
> > 'SIGMAg', 'SIGMAu']]
>
> I think it's not correctly adding up the degeneracies of orbitals for
> SIGMA, PI, and DELTA symmetries. In the "all Irreps" section, where
> moenergies and mosyms are set, you have to know that PI (x and y
> "sub"-symmetries) and DELTA (xy and x2-y2 "sub"-symmetries) orbitals
> are degenerate (occupations with 4 electrons are allowed) and I'm
> guessing it's not adding this section up correctly. The mocoeffs
> section (and nbasis section) already splits this up, so nbasis == 108
> is correct and len(moenergies) == 170 is probably wrong.
OK, I see that now, but don't know how to fix it. I did just submit a little
fix for the code that parses mocoeff, although I'm not sure I relly fixed
anything (looks nicer, though).
> > Hope this helps somehow,
>
> It does. I didn't realize that the parser was this broken. I'll try
> to get around running this file in ADF2004.01 and see if we have a
> similar problem. My guess is we do because I don't work with linear
> molecules and so this case wasn't expected.
>
> Adam
--
written by Karol Langner
Tue Mar 20 22:18:34 CET 2007
|
|
From: Adam T. <a-t...@st...> - 2007-03-20 21:29:15
|
> OK, I see that now, but don't know how to fix it. I did just submit > a little > fix for the code that parses mocoeff, although I'm not sure I relly > fixed > anything (looks nicer, though). Nor do I. I'm a bit busy right now, but I'll keep it in the back of my mind and hopefully think of a fix soon. Adam |
|
From: Karol L. <kar...@kn...> - 2007-03-20 21:54:14
|
On Tuesday 20 of March 2007 22:29, Adam Tenderholt wrote: > > OK, I see that now, but don't know how to fix it. I did just submit > > a little > > fix for the code that parses mocoeff, although I'm not sure I relly > > fixed > > anything (looks nicer, though). > > Nor do I. I'm a bit busy right now, but I'll keep it in the back of > my mind and hopefully think of a fix soon. > > Adam I have an idea. There is a "SYMMETRY, ELECTRONS" section in the output, in two places - the second one is after building the fragments or something(?). Anyways, it looks like this the second time around for Nuno's "Au2.out": ===================================== S Y M M E T R Y , E L E C T R O N S ===================================== Symmetry: D(LIN) Irreducible Representations, including subspecies ------------------------------------------------- SIGMA.g SIGMA.u PI.g:x PI.g:y PI.u:x PI.u:y DELTA.g:x2-y2 DELTA.g:xy DELTA.u:x2-y2 DELTA.u:xy PHI.g:x3-3xy2 PHI.g:3x2y-y3 PHI.u:x3-3xy2 PHI.u:3x2y-y3 ...which should work nicely for counting the number of irreducible representations, I think. I don't think I understand where the mocoeffs are read in for ADF, though..... the attribute, together with mosyms, is parsed when "Orbital Energies, all Irreps" is found on some line - and this, again, happens twice. As it turns out, the second one is not parsed (there's an 'and not hasattr(self, "mosyms")' addition to the parsing condition. Is this correct? I wonder, because these energies are different, and the MO coefficients are printed only once, after the second MO energies output. This is all because I'm not oriented much with ADF. Karol -- written by Karol Langner Tue Mar 20 22:45:10 CET 2007 |
|
From: Karol L. <kar...@kn...> - 2007-03-23 12:52:17
|
On Tuesday 20 of March 2007 22:53, Karol Langner wrote: > On Tuesday 20 of March 2007 22:29, Adam Tenderholt wrote: > > > OK, I see that now, but don't know how to fix it. I did just submit > > > a little > > > fix for the code that parses mocoeff, although I'm not sure I relly > > > fixed > > > anything (looks nicer, though). > > > > Nor do I. I'm a bit busy right now, but I'll keep it in the back of > > my mind and hopefully think of a fix soon. > > > > Adam > > I have an idea. There is a "SYMMETRY, ELECTRONS" section in the output, in > two places - the second one is after building the fragments or > something(?). Anyways, it looks like this the second time around for Nuno's > "Au2.out": > > ===================================== > S Y M M E T R Y , E L E C T R O N S > ===================================== > > Symmetry: D(LIN) > > Irreducible Representations, including subspecies > ------------------------------------------------- > SIGMA.g > SIGMA.u > PI.g:x PI.g:y > PI.u:x PI.u:y > DELTA.g:x2-y2 DELTA.g:xy > DELTA.u:x2-y2 DELTA.u:xy > PHI.g:x3-3xy2 PHI.g:3x2y-y3 > PHI.u:x3-3xy2 PHI.u:3x2y-y3 > > ...which should work nicely for counting the number of irreducible > representations, I think. > > I don't think I understand where the mocoeffs are read in for ADF, > though..... the attribute, together with mosyms, is parsed when "Orbital > Energies, all Irreps" is found on some line - and this, again, happens > twice. As it turns out, the second one is not parsed (there's an 'and not > hasattr(self, "mosyms")' addition to the parsing condition. Is this > correct? I wonder, because these energies are different, and the MO > coefficients are printed only once, after the second MO energies output. > This is all because I'm not oriented much with ADF. > > Karol After looking through the parser code a bit, I understand now that the first print-out is from the reate job and therefore is'nt parsed. I commited a revision that parses the irrep subspecies from the output and stores them in a list called 'irreps' (each element one irrep). I also added a tweak for normalisedegenerates() and the part that parses mocoeffs and mosyms (only restricted variant now), so that any set of subspecies is used for repeating the parsed energies. A dict is created before that to add to mosyms, which is passed to normalisedegenerates() as a optional argument. All the tests still pass, but if I broke something don't hesitate to revert this, since I'm not into ADF too much yet. However, after these changes the jobs we have trouble with still don't get parsed. Notice that the number of SFOs in each irrep listed in the table with MO coefficients is not the same as that given in the section describing the SFOs (for example, 42 versus 16 for SIGMA.g in 'Au2.out'). I think this is the heart of the problem, at least in this case, and I don't understand it. Cheers, Karol -- written by Karol Langner Fri Mar 23 13:41:36 CET 2007 |
|
From: Adam T. <a-t...@st...> - 2007-03-28 00:13:01
|
> I commited a revision that parses the irrep subspecies from the > output and > stores them in a list called 'irreps' (each element one irrep). I > also added > a tweak for normalisedegenerates() and the part that parses > mocoeffs and > mosyms (only restricted variant now), so that any set of subspecies > is used > for repeating the parsed energies. A dict is created before that to > add to > mosyms, which is passed to normalisedegenerates() as a optional > argument. > All the tests still pass, but if I broke something don't hesitate > to revert > this, since I'm not into ADF too much yet. Do you know what the problem with parsing the Frags_NiCO4_orig.out file was before you made this commit? > However, after these changes the jobs we have trouble with still > don't get > parsed. Notice that the number of SFOs in each irrep listed in the > table with > MO coefficients is not the same as that given in the section > describing the > SFOs (for example, 42 versus 16 for SIGMA.g in 'Au2.out'). I think > this is > the heart of the problem, at least in this case, and I don't > understand it. From what I understand from the manual, ADF handles orthogonalization of valence orbitals with frozen core orbitals with a set of Core Functions (which are distinct from the core orbitals). If you look at the overlap matrix for the SIGMA symmetry basis function, you see that it only uses 27-42. Normally these aren't included in the output file, but there was a keyword specified to include them. I'm re-running the file without it to see if it fixes the parse error. Adam |
|
From: Karol L. <kar...@kn...> - 2007-03-28 08:12:48
|
On Wednesday 28 of March 2007 02:12, Adam Tenderholt wrote:
> > I commited a revision that parses the irrep subspecies from the
> > output and
> > stores them in a list called 'irreps' (each element one irrep). I
> > also added
> > a tweak for normalisedegenerates() and the part that parses
> > mocoeffs and
> > mosyms (only restricted variant now), so that any set of subspecies
> > is used
> > for repeating the parsed energies. A dict is created before that to
> > add to
> > mosyms, which is passed to normalisedegenerates() as a optional
> > argument.
> > All the tests still pass, but if I broke something don't hesitate
> > to revert
> > this, since I'm not into ADF too much yet.
>
> Do you know what the problem with parsing the Frags_NiCO4_orig.out
> file was before you made this commit?
No, I don't. Up to now, I've only looked at Au2.out. The error printed
suggests that it has something to do with symemtry labels?:
File
"/home/langner/apps/python/lib/python2.5/site-packages/cclib/parser/adfparser.py",
line 664, in extract
aolist = symlist[sym][spin]
KeyError: 'SIGMA'
> > However, after these changes the jobs we have trouble with still
> > don't get
> > parsed. Notice that the number of SFOs in each irrep listed in the
> > table with
> > MO coefficients is not the same as that given in the section
> > describing the
> > SFOs (for example, 42 versus 16 for SIGMA.g in 'Au2.out'). I think
> > this is
> > the heart of the problem, at least in this case, and I don't
> > understand it.
>
> From what I understand from the manual, ADF handles
> orthogonalization of valence orbitals with frozen core orbitals with
> a set of Core Functions (which are distinct from the core orbitals).
> If you look at the overlap matrix for the SIGMA symmetry basis
> function, you see that it only uses 27-42. Normally these aren't
> included in the output file, but there was a keyword specified to
> include them. I'm re-running the file without it to see if it fixes
> the parse error.
I had no idea about this.
--
written by Karol Langner
Wed Mar 28 11:09:06 CEST 2007
|
|
From: Adam T. <a-t...@st...> - 2007-03-28 00:51:22
|
> From what I understand from the manual, ADF handles > orthogonalization of valence orbitals with frozen core orbitals with > a set of Core Functions (which are distinct from the core orbitals). > If you look at the overlap matrix for the SIGMA symmetry basis > function, you see that it only uses 27-42. Normally these aren't > included in the output file, but there was a keyword specified to > include them. I'm re-running the file without it to see if it fixes > the parse error. I've uploaded a new Au2 logfile to the website, but I couldn't put it in the ADF2006.01 directory because I didn't have permissions (Noel, can you take care of this and regressionfiles.txt). I removed the keyword that prints the CF moceoffs and it now finishes correctly. A Mulliken analysis using PyMOlyze gives approximately the same LUMO composition as is printed in the logfile (there are always slight differences since ADF doesn't print every contribution), so everything should be ok. Adam |
|
From: Karol L. <kar...@kn...> - 2007-03-28 08:13:56
|
On Wednesday 28 of March 2007 02:51, Adam Tenderholt wrote: > I've uploaded a new Au2 logfile to the website, but I couldn't put it > in the ADF2006.01 directory because I didn't have permissions (Noel, > can you take care of this and regressionfiles.txt). I removed the > keyword that prints the CF moceoffs and it now finishes correctly. A > Mulliken analysis using PyMOlyze gives approximately the same LUMO > composition as is printed in the logfile (there are always slight > differences since ADF doesn't print every contribution), so > everything should be ok. So the question is how we should handle the core functions - just skip them? -- written by Karol Langner Wed Mar 28 11:12:09 CEST 2007 |
|
From: Noel O'B. <bao...@gm...> - 2007-03-28 08:23:49
|
On 28/03/07, Adam Tenderholt <a-t...@st...> wrote: > > From what I understand from the manual, ADF handles > > orthogonalization of valence orbitals with frozen core orbitals with > > a set of Core Functions (which are distinct from the core orbitals). > > If you look at the overlap matrix for the SIGMA symmetry basis > > function, you see that it only uses 27-42. Normally these aren't > > included in the output file, but there was a keyword specified to > > include them. I'm re-running the file without it to see if it fixes > > the parse error. > > I've uploaded a new Au2 logfile to the website, but I couldn't put it > in the ADF2006.01 directory because I didn't have permissions (Noel, > can you take care of this and regressionfiles.txt). Sorry about that - I've changed the directory permissions and moved the files into the correct location. Could you run "chmod a+r" on the output file? Does this mean that you have access to ADF2006.01 also? If so, it would be nice to get the output of a TD-DFT calculation on dvb at some stage. > I removed the > keyword that prints the CF moceoffs and it now finishes correctly. A > Mulliken analysis using PyMOlyze gives approximately the same LUMO > composition as is printed in the logfile (there are always slight > differences since ADF doesn't print every contribution), so > everything should be ok. Great. > Adam > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel > |
|
From: Adam T. <a-t...@st...> - 2007-03-28 15:30:30
|
> Does this mean that you have access to ADF2006.01 also? If so, it > would be nice to get the output of a TD-DFT calculation on dvb at some > stage. I just realized I used ADF2004.01 to run that file, so it should be moved into the 2004.01 directory. I can get ADF2006.01 for my lab's computers since we have a contract with SCM, but I haven't yet because ADF2004.01 works for me so why upgrade? ;o) Adam |
|
From: Noel O'B. <bao...@gm...> - 2007-09-03 18:51:24
|
This is the thread about Au2.out that died out in March of this year.
Karol seemed to have the last word, but I'm not sure what he is
referring to. The parsing error is:
File "c:\program files\python25\lib\site-packages\cclib-0.7-py2.5.egg\cclib\pa
rser\adfparser.py", line 702, in extract
self.mocoeffs[spin][moindices[i],aoindex] = coeffs[i]
IndexError: index (108) out of range (0<=index<108) in dimension 1
Noel
On 28/03/07, Karol Langner <kar...@kn...> wrote:
> On Wednesday 28 of March 2007 02:51, Adam Tenderholt wrote:
> > I've uploaded a new Au2 logfile to the website, but I couldn't put it
> > in the ADF2006.01 directory because I didn't have permissions (Noel,
> > can you take care of this and regressionfiles.txt). I removed the
> > keyword that prints the CF moceoffs and it now finishes correctly. A
> > Mulliken analysis using PyMOlyze gives approximately the same LUMO
> > composition as is printed in the logfile (there are always slight
> > differences since ADF doesn't print every contribution), so
> > everything should be ok.
>
> So the question is how we should handle the core functions - just skip them?
>
> --
> written by Karol Langner
> Wed Mar 28 11:12:09 CEST 2007
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>
|
|
From: Adam T. <a-t...@st...> - 2007-09-03 23:29:30
|
To summarize, the error arises because it prints the core function (CF) coefficients in the mocoeffs matrix. I have no idea why you'd ever turn on this print option since they don't have any physical meaning. As near as I can tell, we have two options: 1) Catch the IndexError and log which orbital is "broken", while allowing the parser to finish. This would just call into question the values of mocoeffs; the rest of the parser/ccData attributes *should* be fine. Obviously this is a less than perfect solution, but it is also the easiest option. We would simply not handle this extra info and would put something on the wiki saying which option(s) should NOT be used. 2) Modify the parser to ignore the CF coeffs. I believe this could be done by keeping the starting index of the orbitals. This information is present when we parse fonames. I'm hesitant to do this because we should first make the ADF unittests more robust, either by checking the validity of a number of mocoeffs or by making sure the MPA is reasonable, since it's could potentially be a pretty drastic change. What do y'all think? I should point out that I've already coded option 1 for debugging, but it prints several error messages during regression.py so it might need some modification. Adam On Sep 3, 2007, at 11:51 AM, Noel O'Boyle wrote: > This is the thread about Au2.out that died out in March of this year. > Karol seemed to have the last word, but I'm not sure what he is > referring to. The parsing error is: > > File "c:\program files\python25\lib\site-packages\cclib-0.7- > py2.5.egg\cclib\pa > rser\adfparser.py", line 702, in extract > self.mocoeffs[spin][moindices[i],aoindex] = coeffs[i] > IndexError: index (108) out of range (0<=index<108) in dimension 1 > > Noel > > On 28/03/07, Karol Langner <kar...@kn...> wrote: >> On Wednesday 28 of March 2007 02:51, Adam Tenderholt wrote: >>> I've uploaded a new Au2 logfile to the website, but I couldn't >>> put it >>> in the ADF2006.01 directory because I didn't have permissions (Noel, >>> can you take care of this and regressionfiles.txt). I removed the >>> keyword that prints the CF moceoffs and it now finishes correctly. A >>> Mulliken analysis using PyMOlyze gives approximately the same LUMO >>> composition as is printed in the logfile (there are always slight >>> differences since ADF doesn't print every contribution), so >>> everything should be ok. >> >> So the question is how we should handle the core functions - just >> skip them? >> >> -- >> written by Karol Langner >> Wed Mar 28 11:12:09 CEST 2007 >> >> --------------------------------------------------------------------- >> ---- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to >> share your >> opinions on IT & business topics through brief surveys-and earn cash >> http://www.techsay.com/default.php? >> page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> cclib-devel mailing list >> ccl...@li... >> https://lists.sourceforge.net/lists/listinfo/cclib-devel >> > > ---------------------------------------------------------------------- > --- > 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: Noel O'B. <bao...@gm...> - 2007-09-04 16:07:35
|
On 04/09/07, Adam Tenderholt <a-t...@st...> wrote: > To summarize, the error arises because it prints the core function > (CF) coefficients in the mocoeffs matrix. I have no idea why you'd > ever turn on this print option since they don't have any physical > meaning. As near as I can tell, we have two options: > > 1) Catch the IndexError and log which orbital is "broken", while > allowing the parser to finish. This would just call into question the > values of mocoeffs; the rest of the parser/ccData attributes *should* > be fine. Obviously this is a less than perfect solution, but it is > also the easiest option. We would simply not handle this extra info > and would put something on the wiki saying which option(s) should NOT > be used. This is equivalent to saying we don't handle log files with this option. I've no problem with this in principle as we need to draw the line somewhere. The downside is that this error might arise legitimately for some other type of logfile we have not yet seen, and could flag a bug in cclib. > 2) Modify the parser to ignore the CF coeffs. I believe this could be > done by keeping the starting index of the orbitals. This information > is present when we parse fonames. I'm hesitant to do this because we > should first make the ADF unittests more robust, either by checking > the validity of a number of mocoeffs or by making sure the MPA is > reasonable, since it's could potentially be a pretty drastic change. Well - this is probably the right thing to do to be honest. If you did a calculation with and without the CF coeffs, the results should be identical, right? So all we need is a stand-alone unit test which reads two output files, one with, and one without, this option, and compares all of the attributes. If you can create the additional "without this option" output file, I'll write the unittest and incorporate it into our framework. > What do y'all think? I should point out that I've already coded > option 1 for debugging, but it prints several error messages during > regression.py so it might need some modification. > > Adam > > On Sep 3, 2007, at 11:51 AM, Noel O'Boyle wrote: > > > This is the thread about Au2.out that died out in March of this year. > > Karol seemed to have the last word, but I'm not sure what he is > > referring to. The parsing error is: > > > > File "c:\program files\python25\lib\site-packages\cclib-0.7- > > py2.5.egg\cclib\pa > > rser\adfparser.py", line 702, in extract > > self.mocoeffs[spin][moindices[i],aoindex] = coeffs[i] > > IndexError: index (108) out of range (0<=index<108) in dimension 1 > > > > Noel > > > > On 28/03/07, Karol Langner <kar...@kn...> wrote: > >> On Wednesday 28 of March 2007 02:51, Adam Tenderholt wrote: > >>> I've uploaded a new Au2 logfile to the website, but I couldn't > >>> put it > >>> in the ADF2006.01 directory because I didn't have permissions (Noel, > >>> can you take care of this and regressionfiles.txt). I removed the > >>> keyword that prints the CF moceoffs and it now finishes correctly. A > >>> Mulliken analysis using PyMOlyze gives approximately the same LUMO > >>> composition as is printed in the logfile (there are always slight > >>> differences since ADF doesn't print every contribution), so > >>> everything should be ok. > >> > >> So the question is how we should handle the core functions - just > >> skip them? > >> > >> -- > >> written by Karol Langner > >> Wed Mar 28 11:12:09 CEST 2007 > >> > >> --------------------------------------------------------------------- > >> ---- > >> Take Surveys. Earn Cash. Influence the Future of IT > >> Join SourceForge.net's Techsay panel and you'll get the chance to > >> share your > >> opinions on IT & business topics through brief surveys-and earn cash > >> http://www.techsay.com/default.php? > >> page=join.php&p=sourceforge&CID=DEVDEV > >> _______________________________________________ > >> cclib-devel mailing list > >> ccl...@li... > >> https://lists.sourceforge.net/lists/listinfo/cclib-devel > >> > > > > ---------------------------------------------------------------------- > > --- > > 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-04 16:16:52
|
>> 2) Modify the parser to ignore the CF coeffs. I believe this could be >> done by keeping the starting index of the orbitals. This information >> is present when we parse fonames. I'm hesitant to do this because we >> should first make the ADF unittests more robust, either by checking >> the validity of a number of mocoeffs or by making sure the MPA is >> reasonable, since it's could potentially be a pretty drastic change. > > Well - this is probably the right thing to do to be honest. If you did > a calculation with and without the CF coeffs, the results should be > identical, right? So all we need is a stand-alone unit test which > reads two output files, one with, and one without, this option, and > compares all of the attributes. If you can create the additional > "without this option" output file, I'll write the unittest and > incorporate it into our framework. I agree that this is probably the right thing to do, it's just harder. ;-) And I still think we need to write unittests that make sure it doesn't break the "normal" cases without us knowing for sure. I'll try to get to it this afternoon, but as we all know, research takes priority... There is currently a file in the ADF2004.01 directory called Au2- fixed.adfout.gz which doesn't print the CF coeffs. It's a different version of ADF (2004 vs 2006), but as near as I can tell, everything is the same. Adam |
|
From: Karol L. <kar...@kn...> - 2007-09-04 19:22:15
|
On Tuesday 04 September 2007 12:16, Adam Tenderholt wrote: > >> 2) Modify the parser to ignore the CF coeffs. I believe this could be > >> done by keeping the starting index of the orbitals. This information > >> is present when we parse fonames. I'm hesitant to do this because we > >> should first make the ADF unittests more robust, either by checking > >> the validity of a number of mocoeffs or by making sure the MPA is > >> reasonable, since it's could potentially be a pretty drastic change. > > > > Well - this is probably the right thing to do to be honest. If you did > > a calculation with and without the CF coeffs, the results should be > > identical, right? So all we need is a stand-alone unit test which > > reads two output files, one with, and one without, this option, and > > compares all of the attributes. If you can create the additional > > "without this option" output file, I'll write the unittest and > > incorporate it into our framework. > > I agree that this is probably the right thing to do, it's just > harder. ;-) And I still think we need to write unittests that make > sure it doesn't break the "normal" cases without us knowing for sure. > I'll try to get to it this afternoon, but as we all know, research > takes priority... My two cents... even though the situation is esoteric, I also agree that this is the right choice. In March I started using ADF and got interested, but the project I needed it for died so finally I didn't get around to solving the problem. If no one finds the time/energy to make it happen before the release, be sure to file it with the bug or feature tracker for later. -- written by Karol Langner Tue Sep 4 21:08:12 EDT 2007 |
|
From: Adam T. <a-t...@st...> - 2007-09-05 00:43:09
|
> I agree that this is probably the right thing to do, it's just > harder. ;-) And I still think we need to write unittests that make > sure it doesn't break the "normal" cases without us knowing for sure. > I'll try to get to it this afternoon, but as we all know, research > takes priority... I've just committed a change that fixes the CF bug. It basically stores the starting index of non-CF functions (ie. the SFOs) for each symmetry. When parsing the mocoeffs, it makes sure the SFO index is greater than or equal to this starting index. The regression tests still parse, and it *shouldn't* screw up the values of mocoeffs for these tests, but I haven't looked into it. > There is currently a file in the ADF2004.01 directory called Au2- > fixed.adfout.gz which doesn't print the CF coeffs. It's a different > version of ADF (2004 vs 2006), but as near as I can tell, everything > is the same. I looked at these files a bit closer and it turns out that they have a different number of basis functions. I'll try to get comparable calculations up in the next day or so. 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