Menu
▾
▴
cclib-devel
|
From: Adam T. <a-t...@st...> - 2006-10-24 01:46:31
|
Some quantum chemistry programs (eg. Jaguar) don't always have the same number of alpha orbitals as beta orbitals. Therefore, I propose that we change nmo from an integer to a list of integers like mocoeffs currently is. This would also mean in these cases, mocoeffs should have dimension (1 or 2, nbasis, nbasis) as nmo should always be less than or equal to nbasis. Comments? If this change is agreed upon, then I say we implement this after the 0.6 release so as to keep merging bugfix changes easy; alternatively, we could create a 0.8 trunk where these changes can be made. (Speaking of which, is there a timeframe for the 0.6 release? The ADF errors have been fixed as near as I can tell so regression.py passes all of the tests and only errors on the one ADF file which is missing MO info.) Adam |
|
From: Noel O'B. <bao...@gm...> - 2006-10-24 15:39:56
|
On 24/10/06, Adam Tenderholt <a-t...@st...> wrote: > Some quantum chemistry programs (eg. Jaguar) don't always have the > same number of alpha orbitals as beta orbitals. Therefore, I propose > that we change nmo from an integer to a list of integers like > mocoeffs currently is. This would also mean in these cases, mocoeffs > should have dimension (1 or 2, nbasis, nbasis) as nmo should always > be less than or equal to nbasis. Comments? > If this change is agreed upon, then I say we implement this after the > 0.6 release so as to keep merging bugfix changes easy; alternatively, > we could create a 0.8 trunk where these changes can be made. I would be reluctant to change things so much. I have had similar issues with GAMESS-UK, and AFAIK there is a switch that can be passed to Jaguar to make it print out all of the alpha and beta orbitals. Let us come back to this a little later. > (Speaking of which, is there a timeframe for the 0.6 release? The ADF > errors have been fixed as near as I can tell so regression.py passes > all of the tests and only errors on the one ADF file which is missing > MO info.) Indeed, I have to say "well done", Adam. You've put a lot of work into squashing these bugs and I think we can count on fairly good coverage of 'log file space', now. The timeframe is as soon as we figure out what to do about the final error on the ADF file. Check out my email of 12th Oct reproduced here: """ There is now only a single error in regression.py, which is the problem 1 below. Can we avoid getting a parse error in this case by refusing to create moenergies, or by filling MOs 1-25 with moenergies of 9999 (i.e. to indicate a problem). I think that users should be able to get the energies of the homo and lumo even though there is a problem with the rest of them. What do you think? """ Once we sort this out (whatever way), I will make the final release. Noel |
|
From: Adam T. <a-t...@st...> - 2006-10-24 18:21:17
|
> I would be reluctant to change things so much. I have had similar > issues with GAMESS-UK, and AFAIK there is a switch that can be passed > to Jaguar to make it print out all of the alpha and beta orbitals. Let > us come back to this a little later. I agree with coming back to this a bit later. The reason I bring it up now is one of my colleagues often only prints 15 or so virtual orbitals because of space reasons---she claims it causes Jaguar to crash, but I don't entirely believe her. This creates a problem because she often deals with S=2 or S=5/2 systems, so there will be an unequal number of alpha and beta orbitals. Let's postpone thinking about this for now, but I do think it is a (hopefully minor) change we should think about. > Indeed, I have to say "well done", Adam. You've put a lot of work into > squashing these bugs and I think we can count on fairly good coverage > of 'log file space', now. The timeframe is as soon as we figure out > what to do about the final error on the ADF file. Check out my email > of 12th Oct reproduced here: I feel like I've just been catching up for the all the coding I didn't do during the summer while you were working on the GAMESS parsers. :o) > """ > There is now only a single error in regression.py, which is the > problem 1 below. Can we avoid getting a parse error in this case by > refusing to create moenergies, or by filling MOs 1-25 with moenergies > of 9999 (i.e. to indicate a problem). I think that users should be > able to get the energies of the homo and lumo even though there is a > problem with the rest of them. What do you think? > """ I've made the changes. If the file is missing any MO info, it fills moenergies with 99999 and mosyms with 'A'. It now passes the regression test, although I haven't fully checked whether mocoeffs are accurate. Let me know if there is anything else we should do. Adam |
|
From: Noel O'B. <bao...@gm...> - 2006-10-25 15:37:56
|
> I've made the changes. If the file is missing any MO info, it fills > moenergies with 99999 and mosyms with 'A'. It now passes the > regression test, although I haven't fully checked whether mocoeffs > are accurate. Let me know if there is anything else we should do. Great. I'll start the merge. Might be good to double check the user docs on the wiki to see whether there's anything that needs updating. I think the only API addition is the .clean() method. Also, you want want to add some names to THANKS. Just a note to say that I've been playing about with .zip, .bz2, .gz support for output files on a branch that I'll merge *after* the release. It seems to be working without any problems and all using standard Python libraries, but we can verify this later. Noel |
|
From: Noel O'B. <bao...@gm...> - 2006-10-31 15:55:35
|
OK Adam, let's do it. I suppose it is a bit of a hack to fill empty MOs with zeros. > Some quantum chemistry programs (eg. Jaguar) don't always have the > same number of alpha orbitals as beta orbitals. Therefore, I propose > that we change nmo from an integer to a list of integers like > mocoeffs currently is. This would also mean in these cases, mocoeffs > should have dimension (1 or 2, nbasis, nbasis) as nmo should always > be less than or equal to nbasis. Comments? Sounds good, except that mocoeffs is *not* currently a list of integers. It's a rank 3 array. So, how many attributes will we need to change?: (1) nmo (2) mocoeffs (3) moenergies (4) mosyms (maybe, it's fine as it is though) So we need to... (1) update the wiki (2) update the unit tests/regression tests (3) add any extra tests we need to make sure we're obeying the wiki (4) change the code (let's just work off the HEAD revision). And the best part is that I'll even do some of this myself, as I'll start to have a bit more free time after next Monday (yippee!). Noel |
|
From: Adam T. <a-t...@st...> - 2006-10-31 17:03:38
|
>> Some quantum chemistry programs (eg. Jaguar) don't always have the >> same number of alpha orbitals as beta orbitals. Therefore, I propose >> that we change nmo from an integer to a list of integers like >> mocoeffs currently is. This would also mean in these cases, mocoeffs >> should have dimension (1 or 2, nbasis, nbasis) as nmo should always >> be less than or equal to nbasis. Comments? > > Sounds good, except that mocoeffs is *not* currently a list of > integers. It's a rank 3 array. Right. Which is why the size of the mocoeffs array should have dimension (1 or 2, nbasis, nbasis). Anything not assigned would be zero, and it's up to the user of cclib to decide what elements are valid based on nmo and nbasis (and spin). I think it's a safe assumption that the orbitals we know about run from zero to nmo (even in the one ADF case, I think mocoeffs was correct). > So, how many attributes will we need to change?: > (1) nmo Change this to a list. In most cases we've seen, nmo[0] == nmo[1] but we're making this change to address the case when nmo[0] != nmo[1]. > (2) mocoeffs See above. > (3) moenergies This should probably be a rank two array with size (1 or 2, nbasis) with unassigned elements 99999 like we did with the one ADF file. > (4) mosyms (maybe, it's fine as it is though) My guess is for most cases this is fine, although we may want to consider size (1 or 2, nbasis) and unassigned elements get A symmetry. > So we need to... > (1) update the wiki > (2) update the unit tests/regression tests > (3) add any extra tests we need to make sure we're obeying the wiki > (4) change the code (let's just work off the HEAD revision). Sounds good. > And the best part is that I'll even do some of this myself, as I'll > start to have a bit more free time after next Monday (yippee!). :o) Adam |
|
From: Noel O'B. <bao...@gm...> - 2006-11-07 08:08:30
|
On 31/10/06, Adam Tenderholt <a-t...@st...> wrote: > >> Some quantum chemistry programs (eg. Jaguar) don't always have the > >> same number of alpha orbitals as beta orbitals. Therefore, I propose > >> that we change nmo from an integer to a list of integers like > >> mocoeffs currently is. This would also mean in these cases, mocoeffs > >> should have dimension (1 or 2, nbasis, nbasis) as nmo should always > >> be less than or equal to nbasis. Comments? > > > > Sounds good, except that mocoeffs is *not* currently a list of > > integers. It's a rank 3 array. > > Right. Which is why the size of the mocoeffs array should have > dimension (1 or 2, nbasis, nbasis). Anything not assigned would be > zero, and it's up to the user of cclib to decide what elements are > valid based on nmo and nbasis (and spin). I think it's a safe > assumption that the orbitals we know about run from zero to nmo (even > in the one ADF case, I think mocoeffs was correct). > > > So, how many attributes will we need to change?: > > (1) nmo > > Change this to a list. In most cases we've seen, nmo[0] == nmo[1] but > we're making this change to address the case when nmo[0] != nmo[1]. > > (2) mocoeffs > > See above. > > > (3) moenergies > > This should probably be a rank two array with size (1 or 2, nbasis) > with unassigned elements 99999 like we did with the one ADF file. > > > (4) mosyms (maybe, it's fine as it is though) > > My guess is for most cases this is fine, although we may want to > consider size (1 or 2, nbasis) and unassigned elements get A symmetry. > > > So we need to... > > (1) update the wiki > > (2) update the unit tests/regression tests > > (3) add any extra tests we need to make sure we're obeying the wiki > > (4) change the code (let's just work off the HEAD revision). > > Sounds good. > > > And the best part is that I'll even do some of this myself, as I'll > > start to have a bit more free time after next Monday (yippee!). OK - thanks for explaining this in depth - I actually had the wrong idea. I thought we were going to split everything into two separate arrays for alpha and beta, e.g. moenergies[0] and moenergies[1] which would be of lengths nmo[0] and nmo[1] respectively (and similarly for mocoeffs, mosyms and so on). I'm happy to make the changes you suggest; I'll start by making some changes to the wiki which you might doublecheck. I'll put the new information on the attribute pages under a subheading like "Development version" or "cclib 0.7" or something, to avoid confusing users. BTW, I've merged the zip branch to the HEAD and compressed the regression files on the web server. See r402. Regards, Noel |
|
From: Noel O'B. <bao...@gm...> - 2006-11-22 20:04:06
|
Adam, I've been thinking about this a bit more and I feel that we've moved too far from the original problem, especially now that it's becoming less and less clear what the value of nmo should be in particular cases. In your original email below, you say that Jaguar doesn't always have the same number of alpha orbitals as beta orbitals. I think you mean that it doesn't print information on the same number of alpha orbitals as beta orbitals. Just like GAMESS-UK, then, I think - they actually have the same number of alpha and beta orbitals, but just the information on them isn't there (this is speculation, but it is certainly true for other programs). If what I say is true, then I don't think it helps to redefine nmo as the orbitals for which there is information in the log file. Instead, we should just relax the constraint that len(moenergies)==nmo, and that len(mocoeffs)==nmo. Instead, len(moenergies) is the number of MOs on which we have M.O. energies, and len(mocoeffs) is the number of MOs for which we have mocoeffs. For unrestricted calcs, we should perhaps move to a list of rank 2 arrays for mocoeffs, which can be of different sizes depending on how orbitals are described in the log file: mocoeff = [ alphamocoeffs, betamocoeffs ]. Overall, what I'm trying to say, is that we are ending up redefining nmo to give a value which we can already find by looking at len(moenergies) or len(mocoeffs). And now that we realise that for GAMESS-UK these values are not always equal to each other, it makes less sense than ever. We've both done some work on this already, but I'm worried that we're following red herrings. I think we can solve the Jaguar problem without doing this. Would the modifications I suggest be sufficient to handle Jaguar files? Noel On 24/10/06, Adam Tenderholt <a-t...@st...> wrote: > Some quantum chemistry programs (eg. Jaguar) don't always have the > same number of alpha orbitals as beta orbitals. Therefore, I propose > that we change nmo from an integer to a list of integers like > mocoeffs currently is. This would also mean in these cases, mocoeffs > should have dimension (1 or 2, nbasis, nbasis) as nmo should always > be less than or equal to nbasis. Comments? > > If this change is agreed upon, then I say we implement this after the > 0.6 release so as to keep merging bugfix changes easy; alternatively, > we could create a 0.8 trunk where these changes can be made. > (Speaking of which, is there a timeframe for the 0.6 release? The ADF > errors have been fixed as near as I can tell so regression.py passes > all of the tests and only errors on the one ADF file which is missing > MO info.) > > Adam > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel > |
|
From: Adam T. <a-t...@st...> - 2006-11-22 20:44:21
|
> In your original email below, you say that Jaguar doesn't always have > the same number of alpha orbitals as beta orbitals. I think you mean > that it doesn't print information on the same number of alpha orbitals > as beta orbitals. Just like GAMESS-UK, then, I think - they actually > have the same number of alpha and beta orbitals, but just the > information on them isn't there (this is speculation, but it is > certainly true for other programs). You are correct: in Jaguar, there are always the same number of alpha orbitals as beta orbitals. However, it doesn't always print the same number, esp if the ipvert=X option is enabled. In this case, it only prints X virtual orbitals which means that if homos[0] != homos[1] we'll get a different amount of information for the alpha orbitals compared to the beta orbitals. > If what I say is true, then I don't think it helps to redefine nmo as > the orbitals for which there is information in the log file. Instead, > we should just relax the constraint that len(moenergies)==nmo, and > that len(mocoeffs)==nmo. Instead, len(moenergies) is the number of MOs > on which we have M.O. energies, and len(mocoeffs) is the number of MOs > for which we have mocoeffs. For unrestricted calcs, we should perhaps > move to a list of rank 2 arrays for mocoeffs, which can be of > different sizes depending on how orbitals are described in the log > file: mocoeff = [ alphamocoeffs, betamocoeffs ]. I would definitely support mocoeffs being a list of rank 2 arrays to address the fact that alphamocoeffs and betamocoeffs could be different sizes. I think it also means that we should change moenergies to reflect something similar (list of rank 1 arrays). > Overall, what I'm trying to say, is that we are ending up redefining > nmo to give a value which we can already find by looking at > len(moenergies) or len(mocoeffs). And now that we realise that for > GAMESS-UK these values are not always equal to each other, it makes > less sense than ever. I agree with you here. My original suggestion was made because alphamocoeffs and betamocoeffs would be different sizes, so i figured it was just easier to make the mocoeffs matrix as large as nbasis x nbasis, and adjust nmo so that we know which coefficients are "real". > We've both done some work on this already, but I'm worried that we're > following red herrings. I think we can solve the Jaguar problem > without doing this. Would the modifications I suggest be sufficient to > handle Jaguar files? In summary, yes, I think we can revert nmo back to it's original definition if we change the definition of mocoeffs and moenergies as outlined above. Since your the SVN guru, will you revert the nmo changes back? Adam P.S. I'm on holiday for the next few days without internet. |
|
From: Noel O'B. <bao...@gm...> - 2006-11-22 21:03:02
|
I hate reverting stuff, but it's not until you try something out that you know for sure whether it's a good idea or not. If I was a real SVN guru, I should be able to think 10 revisions ahead (like those chess masters). :-) Have a nice holiday. I'll try and get some of this stuff sorted out over the next while. Noel On 22/11/06, Adam Tenderholt <a-t...@st...> wrote: > > In your original email below, you say that Jaguar doesn't always have > > the same number of alpha orbitals as beta orbitals. I think you mean > > that it doesn't print information on the same number of alpha orbitals > > as beta orbitals. Just like GAMESS-UK, then, I think - they actually > > have the same number of alpha and beta orbitals, but just the > > information on them isn't there (this is speculation, but it is > > certainly true for other programs). > > You are correct: in Jaguar, there are always the same number of alpha > orbitals as beta orbitals. However, it doesn't always print the same > number, esp if the ipvert=X option is enabled. In this case, it only > prints X virtual orbitals which means that if homos[0] != homos[1] > we'll get a different amount of information for the alpha orbitals > compared to the beta orbitals. > > > If what I say is true, then I don't think it helps to redefine nmo as > > the orbitals for which there is information in the log file. Instead, > > we should just relax the constraint that len(moenergies)==nmo, and > > that len(mocoeffs)==nmo. Instead, len(moenergies) is the number of MOs > > on which we have M.O. energies, and len(mocoeffs) is the number of MOs > > for which we have mocoeffs. For unrestricted calcs, we should perhaps > > move to a list of rank 2 arrays for mocoeffs, which can be of > > different sizes depending on how orbitals are described in the log > > file: mocoeff = [ alphamocoeffs, betamocoeffs ]. > > I would definitely support mocoeffs being a list of rank 2 arrays to > address the fact that alphamocoeffs and betamocoeffs could be > different sizes. I think it also means that we should change > moenergies to reflect something similar (list of rank 1 arrays). > > > Overall, what I'm trying to say, is that we are ending up redefining > > nmo to give a value which we can already find by looking at > > len(moenergies) or len(mocoeffs). And now that we realise that for > > GAMESS-UK these values are not always equal to each other, it makes > > less sense than ever. > > I agree with you here. My original suggestion was made because > alphamocoeffs and betamocoeffs would be different sizes, so i figured > it was just easier to make the mocoeffs matrix as large as nbasis x > nbasis, and adjust nmo so that we know which coefficients are "real". > > > We've both done some work on this already, but I'm worried that we're > > following red herrings. I think we can solve the Jaguar problem > > without doing this. Would the modifications I suggest be sufficient to > > handle Jaguar files? > > In summary, yes, I think we can revert nmo back to it's original > definition if we change the definition of mocoeffs and moenergies as > outlined above. Since your the SVN guru, will you revert the nmo > changes back? > > Adam > > P.S. I'm on holiday for the next few days without internet. > > |
×
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