cclib-devel

[cclib-devel] yet another adf bug

[Adam T. <a-t...@st...>]

So I think there's another ADF bug. In the dvb_sp.adfout file, the  
atom number in fonames doesn't agree with the atom number in  
atomcoords. As near as I can tell, this is because ADF reorders the  
atoms. This is seen near the GEOMETRY section. The next section is  
FRAGMENTS, and there's not an obvious 1 to 1 mapping between the  
fragment names (also element names) and atoms in the fragment.

As I recall, ADF is the only program that does fragment orbitals  
involving combinations of atomic orbitals. If this is the case, I  
propose we create a dictionary (say 'fragments') to store information  
about which fragment contains which atoms. The value of the  
dictionary is simply a tuple of atomic numbers and atomic coords. I  
propose a dictionary simply because it would make accessing the info  
for a specific fragment easier.

What do you think?

Adam

Re: [cclib-devel] yet another adf bug

[Noel O'B. <bao...@gm...>]

Remember that a dictionary doesn't have an explicit ordering, so if
you need ordering a list of fragments is better than a dictionary of
fragments. Apart from that, it sounds fine. 'frags' sounds good also,
although it does remind me of Quake.

I wonder though whether, in the end, reading the equivalent of a
checkpoint file would be a more sensible solution. There is a limit to
how complicated the output file can be while still being parsable.
Since you are likely to be doing the coding, you may want to think
about this long and hard, but it's up to you.

Noel

On 28/11/06, Adam Tenderholt <a-t...@st...> wrote:
> So I think there's another ADF bug. In the dvb_sp.adfout file, the
> atom number in fonames doesn't agree with the atom number in
> atomcoords. As near as I can tell, this is because ADF reorders the
> atoms. This is seen near the GEOMETRY section. The next section is
> FRAGMENTS, and there's not an obvious 1 to 1 mapping between the
> fragment names (also element names) and atoms in the fragment.
>
> As I recall, ADF is the only program that does fragment orbitals
> involving combinations of atomic orbitals. If this is the case, I
> propose we create a dictionary (say 'fragments') to store information
> about which fragment contains which atoms. The value of the
> dictionary is simply a tuple of atomic numbers and atomic coords. I
> propose a dictionary simply because it would make accessing the info
> for a specific fragment easier.
>
> What do you think?
>
> 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
>

Re: [cclib-devel] yet another adf bug

[Adam T. <a-t...@st...>]

> Remember that a dictionary doesn't have an explicit ordering, so if
> you need ordering a list of fragments is better than a dictionary of
> fragments. Apart from that, it sounds fine. 'frags' sounds good also,
> although it does remind me of Quake.

I've added two attributes to the ADF parser: frags  and fragnames.  
Fragnames is simply a list of names, and frags is a list of lists  
that contain the numbers corresponding to the ordering in atomnos/ 
atomcoords.

> I wonder though whether, in the end, reading the equivalent of a
> checkpoint file would be a more sensible solution. There is a limit to
> how complicated the output file can be while still being parsable.
> Since you are likely to be doing the coding, you may want to think
> about this long and hard, but it's up to you.

I do think I'd like to support the ADF checkpoint files at some  
point, but as I don't use it extensively, it's not high on my list. ;o)

Adam