From: Noel O'B. <bao...@gm...> - 2012-10-08 16:16:19
|
I've been thinking that a shared Google spreadsheet would be a good way to go. If it's in there, I can write a script to generate the wiki text from that. - Noel On 8 October 2012 17:14, Karol M. Langner <kar...@gm...> wrote: > Sure, if you can spare the time, add them as a regression or replace the > current unit test. > > - Karol > > P.S. I also took a stab at updating the wiki for atomcharges/atomspins, > but in the end it would be good to generate some of the wiki (parsed data > tables) automatically. > > On Oct 08 2012, Adam Tenderholt wrote: >> Hi Karol, >> >> Thanks for working on these attributes. Looks like you covered the big five >> (Gaussian, ADF, ORCA, GAMESS, and GAMESS-UK). I think there's an iop for >> Gaussian that causes Lowdin charges to be printed. Want me to try this? >> >> Adam >> >> >> On Sat, Oct 6, 2012 at 11:33 AM, Karol M. Langner >> <kar...@gm...>wrote: >> >> > On Oct 06 2012, Karol M. Langner wrote: >> > > On Oct 05 2012, Noel O'Boyle wrote: >> > > > On 5 October 2012 18:53, Adam Tenderholt <ate...@gm...> >> > wrote: >> > > > > Copying to cclib-dev instead of cclib-users... >> > > > > >> > > > >> So, Noel, Adam... what do you think? We can't have na attribute for >> > > > >> every type of population analysis parsed. I see two options: >> > > > >> 1) use a dictionary, with keys like 'Mulliken', 'Loewdin' >> > > > >> 2) use a list of tuples consisting of a string and an array of >> > charges >> > > > > >> > > > > >> > > > > I agree that it's bad form to have to deal with all permutations of >> > > > > attributes like mulliken_charges, loewdin_charges, etc, so it's best >> > to have >> > > > > just have charges and densities attributes. >> > > > > >> > > > > I think dictionaries are more elegant than a list of tuples. For >> > example, >> > > > > getting the Mulliken charges is simply charges["Mulliken"] instead >> > of having >> > > > > to iterate over the elements in a charges list looking for >> > "Mulliken" in >> > > > > tuple[0]. >> > > > >> > > > +1 >> > > >> > > I just implemented this in recent commits, for several parsers and >> > > Mulliken/Lowdin charges where they are printed. In some cases (Molpro >> > > and Jaguar) I could not find them and I think some flag in the input >> > > would need to be turned on in order to print them. I don't think I will >> > > update the data files and parsers for that unless somebody asks, though. >> > > >> > > The attribute is called atomcharges and I added unit tests for their >> > > length (should equal natom) and sum (should be zero for the unit tests). >> > > >> > > As far as spin densities are concerned, this is also easily done -- >> > > should we call the corresponding attribute atomspins? >> > >> > I went ahead and implemented this for ORCA, too. If you guys think a >> > different attribute name will better, jsut change it. Implementing this >> > for other parsers will require updating output files to have spin >> > densities. I might do that for GAMESS and one more sometime in the >> > future, but I suppose the rest will be upon request. >> > >> > - Karol >> > >> > -- >> > written by Karol M. Langner >> > Sat Oct 6 20:32:38 CEST 2012 >> > > > -- > written by Karol M. Langner > Mon Oct 8 18:13:15 CEST 2012 > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel |