cclib-devel Mailing List for cclib

> On an unrelated note, the geo-opt files don't seem to contain scf
> convergence info except at the very end of the file. I'm not sure
> whether I should parse this, or try to find out whether there's some
> keyword that will cause scf convergence info to be printed in the main
> body of the file.

So I looked into this a bit. As I understand it, ADF determines SCF  
convergence by comparing the Fock matrix and the density matrix (as  
determined from the Fock matrix). Ideally, the difference would be 0,  
but since that would take forever, it uses two threshold values:  
scfcnv and scfcnv2. These can be set, but default to 1e-6 and 1e-3,  
respectively. These are on lines 1761 in dvb_gopt.adfout. These two  
values are used depending on whether it is a geometry optimization or  
not. During the first and last geom cycle, it should use scfcnv;  
otherwise, scfcnv2. More info is at:

http://www.scm.com/Doc/Doc2005.01/ADF/ADFUsersGuide/page124.html

During the SCF cycle, it prints imax (maximum matrix element) and d- 
Pmat, which I think are the maximum element and norm of the matrix.  
Unfortunately, the rules for determining whether the value is scfcnv  
or scfcnv2 don't seem to be followed exactly in this calc. It looks  
ok in the single point calc.

Is your understanding after reading the above link similar?

Adam

On Mon, 2006-04-24 at 08:22 -0700, Adam Tenderholt wrote:
> > ADF seems to do things differently, so I guess we should too. I had  
> > the
> > same impression that ADF likes fragments. Since we really, in the end,
> > want to calculate Mulliken pops, etc. for fragments ourselves, you're
> > probably right that we should run with ADF on this. In terms of
> > standardising across different parsers, we may wish to move to a
> > different naming scheme, i.e. not 'ao', for the fragment-based  
> > orbitals
> > ('fo'?) that we are going to use in ADF, or it will be misleading to
> > users.
> 
> Calling them fonames makes sense to me. If the SFOs are actual atomic  
> orbitals (ie. no user-defined fragments and no symmetry), should we  
> try to make sure they are called aonames? Perhaps we can have set a  
> flag during parsing, and if it passes parsing everything, we can  
> simply set aonames equal to fonames. Or should there be no aonames in  
> ADF?

Sounds like a good idea. Will you write something along these lines
under aonames and fonames on the wiki, e.g. "ADF specific info"?

On an unrelated note, the geo-opt files don't seem to contain scf
convergence info except at the very end of the file. I'm not sure
whether I should parse this, or try to find out whether there's some
keyword that will cause scf convergence info to be printed in the main
body of the file.

> 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

> ADF seems to do things differently, so I guess we should too. I had  
> the
> same impression that ADF likes fragments. Since we really, in the end,
> want to calculate Mulliken pops, etc. for fragments ourselves, you're
> probably right that we should run with ADF on this. In terms of
> standardising across different parsers, we may wish to move to a
> different naming scheme, i.e. not 'ao', for the fragment-based  
> orbitals
> ('fo'?) that we are going to use in ADF, or it will be misleading to
> users.

Calling them fonames makes sense to me. If the SFOs are actual atomic  
orbitals (ie. no user-defined fragments and no symmetry), should we  
try to make sure they are called aonames? Perhaps we can have set a  
flag during parsing, and if it passes parsing everything, we can  
simply set aonames equal to fonames. Or should there be no aonames in  
ADF?

Adam

On Sat, 2006-04-22 at 11:20 -0700, Adam Tenderholt wrote:
> > Print Smat and EPrint SCF Eigvec looks useful, and I uploaded  
> > dvb_sp_b.adfout
> > as a test. Read the svn log for a description of challenges we face.
> 
> Awhile ago I added a simple Mo atom with BAS overlap and coeffs, but  
> only commented on it in the svn log. Unfortunately, the presence of  
> frozen core orbitals complicates the orbitals. For instance, look at  
> the BAS eigenvectors for anything. You can see that they are linear  
> combinations of orbitals that include the core basis functions. This  
> means, there isn't a 1 to 1 mapping between BAS functions and  
> aonames. Bummer. I don't think my understanding of BAS -> CFs -> SFOs  
> is good enough to figure out how to create a mapping between BAS and  
> real aonames right now. So...
> 
> We need to discuss how we'll parse aonames for ADF calculations. I  
> see three options:
> 
> 1) Don't parse aonames unless the molecule has nosymmetry (ie. MO  
> labels are are 1A, 2A, etc.)
> 
> 2) aonames become something like 1C_1S+4C_1S or 1C+4C_1S+1S for the  
> "positive" case and 1C_1Px-4C_1Px or 1C+4C_1Px-1Px for the negative  
> case.
> 
> 3) Take time and learn out how to map BAS to aonames. It ought to  
> just involve using the Core functions to linearize the valence  
> functions. This will be complicated with d and f functions because  
> one of the d cartesian function is an "s" orbital, and 3 of the 10 f  
> functions are "p" orbitals (says the ADF manual).
> 
> My preference is number 2. Since ADF allows "fragment" calculations,  
> it would be nice to keep track of the MOs in a basis of the fragment  
> MOs instead of atomic orbitals. I can come up with an example of how  
> this would be useful if you want. I'm pretty sure doing option 3  
> would get rid of this useful info. I'm against option 1 because the  
> symmetry labels are also useful information, although it's not quite  
> like info from the fragments.
> 
> What do you think?

ADF seems to do things differently, so I guess we should too. I had the
same impression that ADF likes fragments. Since we really, in the end,
want to calculate Mulliken pops, etc. for fragments ourselves, you're
probably right that we should run with ADF on this. In terms of
standardising across different parsers, we may wish to move to a
different naming scheme, i.e. not 'ao', for the fragment-based orbitals
('fo'?) that we are going to use in ADF, or it will be misleading to
users. 

> 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

> Print Smat and EPrint SCF Eigvec looks useful, and I uploaded  
> dvb_sp_b.adfout
> as a test. Read the svn log for a description of challenges we face.

Awhile ago I added a simple Mo atom with BAS overlap and coeffs, but  
only commented on it in the svn log. Unfortunately, the presence of  
frozen core orbitals complicates the orbitals. For instance, look at  
the BAS eigenvectors for anything. You can see that they are linear  
combinations of orbitals that include the core basis functions. This  
means, there isn't a 1 to 1 mapping between BAS functions and  
aonames. Bummer. I don't think my understanding of BAS -> CFs -> SFOs  
is good enough to figure out how to create a mapping between BAS and  
real aonames right now. So...

We need to discuss how we'll parse aonames for ADF calculations. I  
see three options:

1) Don't parse aonames unless the molecule has nosymmetry (ie. MO  
labels are are 1A, 2A, etc.)

2) aonames become something like 1C_1S+4C_1S or 1C+4C_1S+1S for the  
"positive" case and 1C_1Px-4C_1Px or 1C+4C_1Px-1Px for the negative  
case.

3) Take time and learn out how to map BAS to aonames. It ought to  
just involve using the Core functions to linearize the valence  
functions. This will be complicated with d and f functions because  
one of the d cartesian function is an "s" orbital, and 3 of the 10 f  
functions are "p" orbitals (says the ADF manual).

My preference is number 2. Since ADF allows "fragment" calculations,  
it would be nice to keep track of the MOs in a basis of the fragment  
MOs instead of atomic orbitals. I can come up with an example of how  
this would be useful if you want. I'm pretty sure doing option 3  
would get rid of this useful info. I'm against option 1 because the  
symmetry labels are also useful information, although it's not quite  
like info from the fragments.

What do you think?

Adam

Sounds reasonable.

Adam

On Apr 18, 2006, at 6:08 AM, Noel O'Boyle wrote:

> I've realised that scfvalues cannot be a Numeric array as the  
> number of
> dimensions varies (that is, different geo opt steps have different
> numbers of scf cycles). We could use a list of Numeric arrays instead.
> If you agree, I'll update the wiki (and the code).
>
> Regards,
>  Noel
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the  
> live webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel

I've realised that scfvalues cannot be a Numeric array as the number of
dimensions varies (that is, different geo opt steps have different
numbers of scf cycles). We could use a list of Numeric arrays instead.
If you agree, I'll update the wiki (and the code).

Regards,
 Noel

On Apr 14 2006, Adam Tenderholt wrote:

>> (2) It'd be good if you could run testall.py before uploading svn
>> changes as this guarantees that code doesn't break, and that we move in
>> the direction of passing increasing numbers of tests (a bug in the
>> latest revision means that all tests failed for adfparser). And I think
>> it's a pretty neat way of comparing the results from different programs
>> for some sort of parser validation.
>
>In the case of my most recent commit, I think you're right. It was a
>silly bug for the gopt case that I hadn't considered. However, I feel
>this isn't practical sometimes. What if I start work on a file, take a
>few days off before getting it to pass the tests, and then you begin
>working on something I had already started? We'd be duplicating our
>efforts. This may be a good thing because you might have the better
>solution, but may also be a waste of time. Also, what if we start work
>on one computer (work) and then finish it on another computer (home)?
>It's easy to hunt down the changed files and copy them as needed, but
>it's not as trivial as just updating your working copy.
>
>I know these two scenarios are rather unlikely and/or the "hard" fix
>outside of svn is actually quite easy, but I think they should at least
>be mentioned. If you think we should just ignore them, that's fine.
>Otherwise, I have two suggestions:
>
>1) Create unstable branches for those few times when we're going to
>start working on a file, but we can't get it to pass the unit tests
>before we take a few day break. This would be as simple as svn copy to
>create new branch, switch to that branch, and then make changes. After
>work is finished, it can be merged (hopefully automatically) back into
>the main branch.
>
>2) Run the tests before a commit, and if anything breaks, say which part
> in the commit log so it's not a complete surprise to other devs. We'll
>be able to review the changes that caused the break, and revert or fix
>them as necessary.
>
>What do you think?

In fact (and I've been thinking about this question and your response over 
the past few days, as well as reading the SVN book) I'd like to use a 
variation of 1. Since you usually don't know in advance that the tests will 
break just before it's time to leave work/go to bed, etc., it's not too 
difficult to create a new branch in-place and commit your changes to it.

a) Run the tests before commiting b) If tests that previously passed now no 
longer do (when we have a more complete and stable release, this will read 
"If any tests fail"), and you don't have time to fix things before 
commiting, commits your changes to a new branch as follows:
  1) svn copy https://svn.sourceforge.net/svnroot/cclib/trunk
               
https://svn/sourceforge/net/svnroot/cclib/branches/brokenadfparser
              -m "Informative log message about why you're branching"
  2) change directory into the 'top' of your working copy where setup.py is
  3) svn switch 
https://svn.sourceforge.net/svnroot/cclib/branches/brokenadfparser
     (note that this preserves the local modifications, only now these 
modifications are to the branch instead of the trunk)
  4) svn commit (commits the local modifications to the branch)

As soon as the tests that previously passed are passed again, merge the 
changes and remove the branch (should be within a revision or two of the 
branch).
  1) svn log --stop-on-copy (to find the revision when the branching took 
place)
  2) svn switch https://...../mytrunk
  3) svn merge --dry-run -r123:HEAD https://..../mybranch
  4) svn merge -r123:HEAD https://..../mybranch
  5) svn commit -m "Merging 123:HEAD of mybranch into trunk" 
  6) svn remove https://..../mybranch

(BTW, I've never tried these instructions, so I'll put them on the wiki and 
we can edit them into correctness when we actually try them out)

I'd really like to do this. Of course, it won't always be possible but I 
think it's good to have a policy like this. It means that our code is 
always improving, and means that test failures are real, and need to be 
addressed. Of course, it's a bit of overkill for two developers, but hey 
:-) Also, I used to be scared of branches with CVS, but with SVN it's a lot 
simpler, so it'd be good to have some experience messing around with them.

I should say that at the same time I wouldn't like to have long- or even 
medium-term branches for cclib. I think it'd be good to merge and remove a 
branch as soon as the code's not broken.

What do you think of all this? I don't want branching policies to get in 
the way of development.

Regards,
 Noel

> On some miscellaneous notes,
> (1) I've put information on the symmetry labels used by ADF and GAMESS
> on the mosyms page. Have you considered that we should extract all of
> the symmetry labels if we extract all of the evalues? The info on the
> wiki needs to be updated if we agree to go down this route.

I agree that we should extract all the symmetry labels if we extract all
the evalues. I'll update the wiki later.

> (2) It'd be good if you could run testall.py before uploading svn
> changes as this guarantees that code doesn't break, and that we move in
> the direction of passing increasing numbers of tests (a bug in the
> latest revision means that all tests failed for adfparser). And I think
> it's a pretty neat way of comparing the results from different programs
> for some sort of parser validation.

In the case of my most recent commit, I think you're right. It was a
silly bug for the gopt case that I hadn't considered. However, I feel
this isn't practical sometimes. What if I start work on a file, take a
few days off before getting it to pass the tests, and then you begin
working on something I had already started? We'd be duplicating our
efforts. This may be a good thing because you might have the better
solution, but may also be a waste of time. Also, what if we start work
on one computer (work) and then finish it on another computer (home)?
It's easy to hunt down the changed files and copy them as needed, but
it's not as trivial as just updating your working copy.

I know these two scenarios are rather unlikely and/or the "hard" fix
outside of svn is actually quite easy, but I think they should at least
be mentioned. If you think we should just ignore them, that's fine.
Otherwise, I have two suggestions:

1) Create unstable branches for those few times when we're going to
start working on a file, but we can't get it to pass the unit tests
before we take a few day break. This would be as simple as svn copy to
create new branch, switch to that branch, and then make changes. After
work is finished, it can be merged (hopefully automatically) back into
the main branch.

2) Run the tests before a commit, and if anything breaks, say which part
 in the commit log so it's not a complete surprise to other devs. We'll
be able to review the changes that caused the break, and revert or fix
them as necessary.

What do you think?

> (3) With regard to aonames (or anything else), upload any relevant test
> files although try to aim for as small a file as possible. If you could
> add a description to the metadata, it'll make it easier for me to do the
> same (if necessary) for some of the other codes. As you are taking the
> lead on aonames, it'd also be good if you put up some specs/examples on
> the wiki, and I'll make sure other parsers meet the specs.

Ok. It's basically because I'm not sure how frozen core basis functions
with ADF translate into an aoname yet. I figure single atoms will be
sufficient.

Happy Easter!

Adam

On some miscellaneous notes, 

(1) I've put information on the symmetry labels used by ADF and GAMESS on 
the mosyms page. Have you considered that we should extract all of the 
symmetry labels if we extract all of the evalues? The info on the wiki 
needs to be updated if we agree to go down this route.

(2) It'd be good if you could run testall.py before uploading svn changes 
as this guarantees that code doesn't break, and that we move in the 
direction of passing increasing numbers of tests (a bug in the latest 
revision means that all tests failed for adfparser). And I think it's a 
pretty neat way of comparing the results from different programs for some 
sort of parser validation.

(3) With regard to aonames (or anything else), upload any relevant test 
files although try to aim for as small a file as possible. If you could add 
a description to the metadata, it'll make it easier for me to do the same 
(if necessary) for some of the other codes. As you are taking the lead on 
aonames, it'd also be good if you put up some specs/examples on the wiki, 
and I'll make sure other parsers meet the specs.

Happy Easter,
   Noel

The test file for printing BAS info only includes single-zeta info, and only 
handles s/p orbitals right now. We'll have to look at it again once a higher 
quality basis set is added that includes multiple-zeta, polarization, and 
core functions is used.

I propose we test a few single point calculations of a d- and f- block metal 
(TZP basis set). What do you think?

Adam

-- 
Want a web browser that is fully customizable? 

Go to http://www.mozilla.org/products/firefox/

to download the newest version of Firefox and 
its available extentions.

> Maybe there's an easier solution. I've been looking at the ADF manual
> online. Try "Print Smat". It appears to print an overlap matrix of basis
> functions. If true, I think this may solve our problems.

Print Smat and EPrint SCF Eigvec looks useful, and I uploaded dvb_sp_b.adfout 
as a test. Read the svn log for a description of challenges we face.

Adam

On Mon, 2006-04-10 at 10:28 -0700, Adam Tenderholt wrote:
> > I propose http://cclib.sourceforge.net/wiki/index.php/Parsed_Data as the
> > home of the cclib specification (instead of logfileparser.py),
> > especially as we can put more specific information (for developers, in
> > particular) on hyperlinked 'subpages'.
> 
> Sounds reasonable. Are you going to take charge in setting up a couple example 
> pages so the rest of us can follow your lead?

Well, you know, just random stuff is fine. For example, we discussed
keeping track of the convergence criteria of different programs...we
should paste this in behind scftargets and geotargets.

> > One thing that we should clarify is how we handle geometry optimisation
> > files. When we extract MO symmetries and evalues, should we extract the
> > final MO symmetry and evalues, the first one, all of them? My parsers
> > extract the final one, by rewriting over the previous one every time it
> > comes to a new block, but this is something we need to agree on.
> 
> I think we should keep every evalue for a geometry optimization so that the 
> progress of optimization can be monitored if so desired. I'm not too sure 
> keeping track of symmetry would be useful, so we can add it later if 
> requested.
I'm not sure whether any of this is useful, but I think we need to do
the same for all of the affected attributes. If you think it's useful to
keep all evalues, then we should keep all everything. Otherwise the
interface will be pretty confusing. Users won't know which ones are kept
and which not, etc.

> > Don't despair though - we're getting there! Although, on another note, I
> > have just gotten a copy of GAMESS-UK from the computing officer, and it
> > appears to have completely different input and output compared to the
> > other GAMESSes. Yikes!
> 
> Sounds like fun.

I'll upload the data files as soon as I have them.

> > If we get ADF/GAMESS/Gaussian/Jaguar in a decent state, we can make the
> > first release of cclib, and get people using it (including ourselves
> > regarding GaussSum and PyMOlyze). Then onwards and upwards.
> 
> > BTW, there are some magic SVN commands that will allow you to include a
> > particular version of cclib from SVN (e.g. the tagged 0.1 release) into
> > your own PyMOlyze SVN repository. I think you will find this handy
> > rather than asking users to install cclib separately.
> 
> Are you thinking of svn copy? This is a really great idea, although I'm sure 
> it'll require some setup.py tweaking to make it work.

Um, I forget - looking quickly at the book, I think it's "Externals
definition" in Chap 7.

OK - gotta go...

Noel

On Mon, 2006-04-10 at 10:51 -0700, Adam Tenderholt wrote:
> > I guess my question is, is it possible to translate the mocoeffs matrix
> > from being based on the Symmetry Adapted Linear Combinations (or
> > whatever) to being based on the original atomic orbitals. Isn't this
> > what we need to do to make it possible to do our population analyses?
> > We're not interested in how much 1/sqrt(2) (C1s + C2s) contributes to a
> > particular molecular orbital, but in how much C1s contributes.
> 
> This should be possible since the coefficients of each atomic orbital in a 
> SALC orbital is printed. I see three challeges/problems:
> 
> First, there are only two significant figures printed for these aoname/SALC 
> coefficients, which I feel isn't enough since the mocoeffs often have 5 or 
> more sigfigs. I suppose for now, we can use the actual value 1/sqrt(2) when 
> we find 0.71 and address other possibilities as they come up.
> 
> Second, is splitting up the SALC overlap matrix trivial like for the mocoeffs? 
> My intuition says no, but I can't think of an example.
> 
> Third, I can't think of a trivial way to do all of this. We'd probably have to 
> read everything in, do some list/dictionary magic, and at the end, convert 
> the SALC matrices to aoname matrices.

Maybe there's an easier solution. I've been looking at the ADF manual
online. Try "Print Smat". It appears to print an overlap matrix of basis
functions. If true, I think this may solve our problems.

> Any thoughts?
> 
> Adam
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel

> I guess my question is, is it possible to translate the mocoeffs matrix
> from being based on the Symmetry Adapted Linear Combinations (or
> whatever) to being based on the original atomic orbitals. Isn't this
> what we need to do to make it possible to do our population analyses?
> We're not interested in how much 1/sqrt(2) (C1s + C2s) contributes to a
> particular molecular orbital, but in how much C1s contributes.

This should be possible since the coefficients of each atomic orbital in a 
SALC orbital is printed. I see three challeges/problems:

First, there are only two significant figures printed for these aoname/SALC 
coefficients, which I feel isn't enough since the mocoeffs often have 5 or 
more sigfigs. I suppose for now, we can use the actual value 1/sqrt(2) when 
we find 0.71 and address other possibilities as they come up.

Second, is splitting up the SALC overlap matrix trivial like for the mocoeffs? 
My intuition says no, but I can't think of an example.

Third, I can't think of a trivial way to do all of this. We'd probably have to 
read everything in, do some list/dictionary magic, and at the end, convert 
the SALC matrices to aoname matrices.

Any thoughts?

Adam

> I propose http://cclib.sourceforge.net/wiki/index.php/Parsed_Data as the
> home of the cclib specification (instead of logfileparser.py),
> especially as we can put more specific information (for developers, in
> particular) on hyperlinked 'subpages'.

Sounds reasonable. Are you going to take charge in setting up a couple example 
pages so the rest of us can follow your lead?

> One thing that we should clarify is how we handle geometry optimisation
> files. When we extract MO symmetries and evalues, should we extract the
> final MO symmetry and evalues, the first one, all of them? My parsers
> extract the final one, by rewriting over the previous one every time it
> comes to a new block, but this is something we need to agree on.

I think we should keep every evalue for a geometry optimization so that the 
progress of optimization can be monitored if so desired. I'm not too sure 
keeping track of symmetry would be useful, so we can add it later if 
requested.

> Don't despair though - we're getting there! Although, on another note, I
> have just gotten a copy of GAMESS-UK from the computing officer, and it
> appears to have completely different input and output compared to the
> other GAMESSes. Yikes!

Sounds like fun.

> If we get ADF/GAMESS/Gaussian/Jaguar in a decent state, we can make the
> first release of cclib, and get people using it (including ourselves
> regarding GaussSum and PyMOlyze). Then onwards and upwards.

Glad to hear. I'll try to work on cclib a bit this week. We still need to 
address ADF aonames, but I think that is best discussed in the other thread.

> BTW, there are some magic SVN commands that will allow you to include a
> particular version of cclib from SVN (e.g. the tagged 0.1 release) into
> your own PyMOlyze SVN repository. I think you will find this handy
> rather than asking users to install cclib separately.

Are you thinking of svn copy? This is a really great idea, although I'm sure 
it'll require some setup.py tweaking to make it work.

Adam

I propose http://cclib.sourceforge.net/wiki/index.php/Parsed_Data as the
home of the cclib specification (instead of logfileparser.py),
especially as we can put more specific information (for developers, in
particular) on hyperlinked 'subpages'.

One thing that we should clarify is how we handle geometry optimisation
files. When we extract MO symmetries and evalues, should we extract the
final MO symmetry and evalues, the first one, all of them? My parsers
extract the final one, by rewriting over the previous one every time it
comes to a new block, but this is something we need to agree on.

Don't despair though - we're getting there! Although, on another note, I
have just gotten a copy of GAMESS-UK from the computing officer, and it
appears to have completely different input and output compared to the
other GAMESSes. Yikes!

If we get ADF/GAMESS/Gaussian/Jaguar in a decent state, we can make the
first release of cclib, and get people using it (including ourselves
regarding GaussSum and PyMOlyze). Then onwards and upwards.

BTW, there are some magic SVN commands that will allow you to include a
particular version of cclib from SVN (e.g. the tagged 0.1 release) into
your own PyMOlyze SVN repository. I think you will find this handy
rather than asking users to install cclib separately.

Regards,
 Noel

On Thu, 2006-04-06 at 09:06 -0700, Adam Tenderholt wrote:
> > I've been thinking some more about this and now I think that we should
> > avoid Classes altogether, as this has been our method until now (e.g.
> > for molecular orbitals we have symmetries and coefficients as separate
> > attributes, for vibrations, we have raman intensity, and symmetry as
> > separate items, etc.). We can uses atomcoords, atomnos, atomXXXX, etc.
> > Or reduce 'atom' to 'at', or just 'a'.
> 
> Sounds reasonable.
> 
> > For the moment, I propose atomcoords (as we already have atomnos). If
> > you agree, we can add this to our specification (in the docstring of
> > logfileparser.py).
> 
> So atomcoords will be a list of array[2] (with dimensions natom x 3)?
> The list will be length 1 for single point calcs, and however long for
> geometry optimizations?

Yes, it'll be as you say if I understand you correctly. Remember that we
will be using Numeric arrays, and that atomcoords.shape should give
(n,m,3) where n is 1 for an sp (>=1 for a geoopt), m is the number of
atoms. Since it's not efficient/easy to extend Numeric arrays when
reading through a file, I find it better to just convert it from lists
to an array at the end of the file (see the GAMESS/Gaussian parsers).

> Adam
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel

On Thu, 2006-04-06 at 08:58 -0700, Adam Tenderholt wrote:
> > It looks like there are three distinct types of orbitals now: atomic
> > orbitals, basis set orbitals, and molecular orbitals. Molecular orbitals
> > are composed of linear combinations of basis set orbitals, which are
> > composed of linear combinations of atomic orbitals (is this correct?).
> > For Gaussian, basis set orbitals are equal to the atomic orbitals.
> 
> Molecular orbitals are linear combinations of basis set orbitals.
> Gaussian uses atomic orbitals as the basis set orbitals. ADF uses either
> atomic orbitals (no symmetry) or symmetry adapted linear combinations
> (SALCs) of atomic orbitals for its basis set.
> 
> > Is there any need to store basis set orbitals in an attribute? So long
> > as the ADF parser creates a mocoeffs matrix which describes the MOs in
> > terms of the AOs (and not the basis set orbitals) I think we don't need
> > the basis set orbitals. 
> 
> The problem is that ADF stores mocoeffs in terms of the basis set
> orbitals (it calls them CFOs, or something like that). It then breaks up
> these orbitals by symmetry, and prints their corresponding mocoeffs matrix.

I guess my question is, is it possible to translate the mocoeffs matrix
from being based on the Symmetry Adapted Linear Combinations (or
whatever) to being based on the original atomic orbitals. Isn't this
what we need to do to make it possible to do our population analyses?
We're not interested in how much 1/sqrt(2) (C1s + C2s) contributes to a
particular molecular orbital, but in how much C1s contributes.

> > Regarding the aonames, to be honest, I forget why I wanted to extract
> > aonames in the first place. In short, I think we should forget about
> > aonames (I'll remove it from the relevant places if you agree), and
> > concentrate on getting mocoeff the same between different programs.
> 
> I'd like the aonames because it's key to how PyMOlyze works. It reads
> the list of aonames, and lets the user specify fragments in terms of
> those. For instance, I usually create the following fragments: Mo d, Mo
> s/p, S, O, C/H. Occasionally, I split up the sulfur orbitals into p and
> s/d fragments.

OK - that's fine. If they're useful we'll extract them. Regarding the
format of the name, "Mo 2p", etc. seems fine.

> Adam
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel

> I've been thinking some more about this and now I think that we should
> avoid Classes altogether, as this has been our method until now (e.g.
> for molecular orbitals we have symmetries and coefficients as separate
> attributes, for vibrations, we have raman intensity, and symmetry as
> separate items, etc.). We can uses atomcoords, atomnos, atomXXXX, etc.
> Or reduce 'atom' to 'at', or just 'a'.

Sounds reasonable.

> For the moment, I propose atomcoords (as we already have atomnos). If
> you agree, we can add this to our specification (in the docstring of
> logfileparser.py).

So atomcoords will be a list of array[2] (with dimensions natom x 3)?
The list will be length 1 for single point calcs, and however long for
geometry optimizations?

Adam

> I think this would be good. I assumed that there wasn't any symmetry
> present but now I see that there is. There's no need to delete the old
> file (the more the merrier), just call one _a and the other _b and make
> some comments in the svn log, or in the metadata.

Ok. My parents are visiting me this week, so I can't make any promises
about getting it this week. Early next week for sure.

> It looks like there are three distinct types of orbitals now: atomic
> orbitals, basis set orbitals, and molecular orbitals. Molecular orbitals
> are composed of linear combinations of basis set orbitals, which are
> composed of linear combinations of atomic orbitals (is this correct?).
> For Gaussian, basis set orbitals are equal to the atomic orbitals.

Molecular orbitals are linear combinations of basis set orbitals.
Gaussian uses atomic orbitals as the basis set orbitals. ADF uses either
atomic orbitals (no symmetry) or symmetry adapted linear combinations
(SALCs) of atomic orbitals for its basis set.

> Is there any need to store basis set orbitals in an attribute? So long
> as the ADF parser creates a mocoeffs matrix which describes the MOs in
> terms of the AOs (and not the basis set orbitals) I think we don't need
> the basis set orbitals. 

The problem is that ADF stores mocoeffs in terms of the basis set
orbitals (it calls them CFOs, or something like that). It then breaks up
these orbitals by symmetry, and prints their corresponding mocoeffs matrix.

> Regarding the aonames, to be honest, I forget why I wanted to extract
> aonames in the first place. In short, I think we should forget about
> aonames (I'll remove it from the relevant places if you agree), and
> concentrate on getting mocoeff the same between different programs.

I'd like the aonames because it's key to how PyMOlyze works. It reads
the list of aonames, and lets the user specify fragments in terms of
those. For instance, I usually create the following fragments: Mo d, Mo
s/p, S, O, C/H. Occasionally, I split up the sulfur orbitals into p and
s/d fragments.

Adam

On Thu, 2006-03-30 at 17:04 -0800, Adam Tenderholt wrote:

> 2) In looking at the Gaussian parser, I wasn't able to find a variable for 
> storing each structure found for a gaussian calculation. What do you think 
> about adding a class for Atoms (name or number, x, y, z in either angs or 
> bohr), a class for Molecules (either a list of Atoms, or more complicated 
> with dictionaries?), and geoms[ ] and geomcoords[ ] in the parser classes?

I've been thinking some more about this and now I think that we should
avoid Classes altogether, as this has been our method until now (e.g.
for molecular orbitals we have symmetries and coefficients as separate
attributes, for vibrations, we have raman intensity, and symmetry as
separate items, etc.). We can uses atomcoords, atomnos, atomXXXX, etc.
Or reduce 'atom' to 'at', or just 'a'.

For the moment, I propose atomcoords (as we already have atomnos). If
you agree, we can add this to our specification (in the docstring of
logfileparser.py).

Regards,
 Noel

On Wed, 2006-04-05 at 14:08 -0800, Adam Tenderholt wrote:
> > I think the lowercase u/g is a good idea, but I'm not convinced about
> > the period. How about "Bu", etc? Isn't this the standard notation?
> 
> I agree.

Okay - we'll do this. I'll put specifications like this on the wiki from
now on once we have agreed.

> > Remember that there are possibly two special cases that
> > our program should also handle without problems: no symmetry (all A, I
> > guess), and really high symmetry (e.g. Td). For the first case, the
> > unrestricted calculation should have no symmetry. Might be worthwhile
> > running an optimisation of methane for the second (if you also think it
> > might be a problem).
> 
> I think we should handle as much as possible like you say. Should I rerun the 
> dvb unrestricted calculation in ADF with nosymmetry? 

I think this would be good. I assumed that there wasn't any symmetry
present but now I see that there is. There's no need to delete the old
file (the more the merrier), just call one _a and the other _b and make
some comments in the svn log, or in the metadata.

> Also, have we decided what to do about aonames for high symmetry calculations 
> in ADF?

See other email.

> Adam
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel

On Thu, 2006-03-30 at 17:04 -0800, Adam Tenderholt wrote:
> 1) I've been working on the ADF parser, however I ran into a problem with 
> reading "aonames". Basically, if there is any symmetry (and nosymmetry isn't 
> specified for the ADF calc), it uses linear combinations of orbitals on 
> different atoms for the atomic basis. As an example, look for the SFOs 
> section on line 1371 of dvb_sp.adfout. SFO 1Ag is constant (C1_1S + C4_1S), 
> where constant is 1/sqrt(2). I can think of two solutions. First, parse it as 
> it is so aonames become something like 1/2 C1_1S + C4_1S. My problem with 
> this is handling more complicated cases with 3+ atoms might lead to more 
> difficult coefficients. Second, ignore it and make sure cclib users know that 
> if they want to do anything with aonames, they need to specify nosymmetry in 
> the ADF calc.

It looks like there are three distinct types of orbitals now: atomic
orbitals, basis set orbitals, and molecular orbitals. Molecular orbitals
are composed of linear combinations of basis set orbitals, which are
composed of linear combinations of atomic orbitals (is this correct?).
For Gaussian, basis set orbitals are equal to the atomic orbitals.

Is there any need to store basis set orbitals in an attribute? So long
as the ADF parser creates a mocoeffs matrix which describes the MOs in
terms of the AOs (and not the basis set orbitals) I think we don't need
the basis set orbitals. 

Regarding the aonames, to be honest, I forget why I wanted to extract
aonames in the first place. In short, I think we should forget about
aonames (I'll remove it from the relevant places if you agree), and
concentrate on getting mocoeff the same between different programs.

> 2) In looking at the Gaussian parser, I wasn't able to find a variable for 
> storing each structure found for a gaussian calculation. What do you think 
> about adding a class for Atoms (name or number, x, y, z in either angs or 
> bohr), a class for Molecules (either a list of Atoms, or more complicated 
> with dictionaries?), and geoms[ ] and geomcoords[ ] in the parser classes?
> 
> 3) What if certain calculations don't implement the same parameters for 
> geotargets/geovalues and scftargets/scfvalues? Look at the differences 
> between the ADF and Gaussian calculations. Is there going to be a variable to 
> keep track of the names for each parameter? Or maybe a set of pre-defined 
> dictionaries (e.g. MaxForce:[ ], RMS Force:[ ], Energy:[ ], dEnergy:[ ], 
> etc.) should be used instead to keep some consistency across each type of 
> calculation?
> 
> Adam
> 
> P.S. Noel, I hope you enjoyed your travels...
>