Re: [cclib-devel] g09 fragment guesses

[Adam T. <ate...@gm...>]

Hi Karol,

I do occasionally have (make?) time for cclib, although it's usually when a
friend has a problem and asks me to fix it. Lately most of my non-work time
lately has been spent with my wife, moving into a new apartment and finding
furniture and such. But that's almost over, so perhaps I'll get around to
working on cclib more.

1) Shall I run the Fe2S2 example (or something similar) as our regression
>> file? Sam's files are hundreds of MB, and I think a prototypical example
>> would be best. ORCA also handles these systems well, and while I think it
>> parses such calculations fine, we probably should also have a regression
>> file for this parser too.
>>
>
> I would stick with something small that reproduces the issue.
>

I wanted something smaller, but I couldn't think of anything better.
Ideally it would be an organic bi- or di-radical. Semi-quinones would be
good, except I don't know how to logically split that into two fragments. I
suppose a peroxide is another option (say two HO• or alkyl-O• fragments),
but I think have closed-shell singlet ground states.


>
>>  2) Do we want to parse the fragment wavefunction info as well? It would
>> make our parser that much more robust, although it adds layers of
>> complexities. If so:
>>
>
> I think it safe to assume we want to, but won't do it right now unless
> somebody asks for it.
>

I'm also not inclined to do this unless it's specifically requested. There
are just too many other more interesting things to do.


> 2a) Create new attributes as necessary (fmoenergies, fmocoeffs, fhomos,
>> etc.)? We'd also want something analogous to fooverlaps and fonames (ADF),
>> but here it'd have to be a lists instead of the normal items.
>>
>
> I feel we should keep with single attributes, changing them their shapes
> to accommodate the fragments.
>

Makes sense to me.


> 2b) Or append to the current fmoenergies, fmocoeffs, etc? Then [0]/[1]
>> corresponds to molecule alpha/beta, [2]/[3] corresponds to fragment 1
>> alpha/beta, [4]/[5] corresponds to fragment 2 alpha/beta, and so on. (I
>> don't see any reasons these calculations would have restricted fragments).
>>
>
> The other option would be use indexes [0..N-1] for alphas and the rest for
> betas. I don't have a preference.
>

My only concern with the [0..N-1]/[N-2N-1] indices are that we then have to
keep track of where the alpha ends, either with a variable or checking the
size of nbasis, and we can't simply append when a new wavefunction block is
reached. The [n]/[n+1] can be access with a loop that increments by 2 and
extending the mocoeffs is as simple as an append.

Adam