cclib-devel — Developer's mailing list

[cclib-devel] Fwd: Point-Group Symmetry Codes

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

Geoff is interested in point group symmetry code...

---------- Forwarded message ----------
From: Geoffrey Hutchison <ge...@pi...>

Hi guys,

I've been toying around with the point group symmetry code that was
GPL'ed by Dr. Serguei Patchkovskii
http://www.cobalt.chem.ucalgary.ca/ps/symmetry/

I've found that while it looks like it has great capabilities (strange
higher-order symmetry like C7 and S7 rotations), it doesn't work very
well. For example, I drew benzene in Avogadro, ran an optimization and
saved it. The molecule is in the Z=0 plane, but slightly out of center
and not aligned to the X or Y axes. (In short, a typical aromatic
benzene with equal bond lengths.)

All it finds is the mirror plane along Z=0.

So I'm curious to ask you two: as part of the cclib work, whether
you've come across some *robust* point group symmetry recognition code?

Thanks,
-Geoff

-------------------------------------------
Geoff Hutchison
Assistant Professor
University of Pittsburgh, Department of Chemistry
219 Parkman Avenue
Pittsburgh, PA 15260

[cclib-devel] setuptools

[Karol L. <kar...@kn...>]

I've made setup.py more catious - it imports from setuptools only is 'egg' is 
on the command line. This is because I'm experiencing problems when using 
setuptools with Python2.5 (or I don't know how to use it yet). This is how I 
should have done it from the start, anyway.

- Karol

P.S. Also, the last commit fixes the installation path for data files when 
installing to a non-standard location (with the --prefix option).

-- 
written by Karol Langner
Mon Nov 19 22:32:14 CET 2007

Re: [cclib-devel] Further JSON support

[Karol L. <kar...@kn...>]

I removed all pickle/json functions and methods from data.py. It does seem 
healthier to leave the read/write layer outside of cclib.

I left arrayify, listify, getattributes and setatttributes as they are. So, if 
someone wants a dictionary of attributes for JSON, getattributes is the best 
function, after calling listify (also just added an optional 'tolists' 
argument that does this).

Karol

-- 
written by Karol Langner
Mon Nov 19 19:09:37 CET 2007

Re: [cclib-devel] Further JSON support

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

On 19/11/2007, Karol Langner <kar...@kn...> wrote:
> On Monday 19 November 2007 16:29, you wrote:
> > Good point. The user just needs to call listify() beforehand. In that
> > case, listify() should probably return a dictionary, rather than
> > altering the ccData object itself. The dictionary can be written with
> > whatever JSON library the user wants to use...
> >
> > Great! I think we have a winner :-)
>
> I recently added the "getattributes" method, which listifies and returns such
> a dictionary (and later arrayifies) - so that's all that needs to be called.

Well, my point was just that there's no need to call arrayify() if
listify just returns a dictionary. It's also a cleaner solution as it
means that the ccData object will not be perturbed. listify() is not
used by any other code, as far as I know.

> I'll go with anything here. So we are choosing not to provide any intrinsic
> JSON support?
I think so. If there are lots of different libraries that a user might
want to use, the best solution is to allow the user to choose
whichever they want.
> What about pickle?
pickle works already just like for any other Python object. See the
docs on the wiki at:
http://cclib.sourceforge.net/wiki/index.php/Using_cclib

 > Karol
>
> --
> written by Karol Langner
> Mon Nov 19 16:55:31 CET 2007
>

Re: [cclib-devel] Further JSON support

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

Good point. The user just needs to call listify() beforehand. In that
case, listify() should probably return a dictionary, rather than
altering the ccData object itself. The dictionary can be written with
whatever JSON library the user wants to use...

Great! I think we have a winner :-)

Noel

On 19/11/2007, Karol Langner <kar...@kn...> wrote:
> I have no definite opinion. If there is no actual JSON support in cclib
> (bundled or imported), then there's no point in having a 'writejson' method
> is there? Just an ambigious 'write' method, since you can pass a function
> that does _anything_.
>
> Karol
>
> --
> written by Karol Langner
> Mon Nov 19 16:22:20 CET 2007
>

Re: [cclib-devel] Further JSON support

[Karol L. <kar...@kn...>]

On Monday 19 November 2007 15:56, Noel O'Boyle wrote:
> > > How about
> > > changing so that rather than passing in a module, you just pass in the
> > > dump/load function? Then cclib wouldn't have to do any of this. The
> > > user would do "from simplejson import dumps", and then pass "dumps" as
> > > a parameter to write_json.
> >
> > I'm not sure I understand: you propose to bundle a pure python JSON
> > module for the default (simplejson or json), and add an optional
> > dumps/loads argument if the user wants an alternate function?
>
> Maybe - what do you think? Alternatively, we could forget about
> bundling or importing the module ourselves, and just leave it to the
> user to pass in the dumps/loads function. This would make our code
> much cleaner, and fits the "Only one good way to do it" philosophy of
> Python. I will go with this as my final proposal...

I have no definite opinion. If there is no actual JSON support in cclib 
(bundled or imported), then there's no point in having a 'writejson' method 
is there? Just an ambigious 'write' method, since you can pass a function 
that does _anything_.

Karol

-- 
written by Karol Langner
Mon Nov 19 16:22:20 CET 2007

Re: [cclib-devel] Further JSON support

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

On 19/11/2007, Karol Langner <kar...@kn...> wrote:
> On Monday 19 November 2007 15:21, Noel O'Boyle wrote:
> > On 19/11/2007, Karol Langner <kar...@kn...> wrote:
> > > On Monday 19 November 2007 14:38, Noel O'Boyle wrote:
> > > > Do we really need support for three JSON libraries? We can just bundle
> > > > simplejson (or one of the others if their licenses permit) with cclib.
> > >
> > > I don't like it either, but it seems to be the simplest fix for now if I
> > > want to use cjson. Bundling is probably the best final solution. I would
> > > opt for cjson in that case, although it is a C extension and would
> > > require compilation upon install, which cclib has avoided up to now.
> >
> > Yes - I wouldn't like to do this for the 'core' parsing.
>
> Does this mean you would consider C extensions appropriate for ex.
> cclib.methods if they made them ore efficient?

I think I've answered this on another thread a few weeks ago. The
short answer is yes.

> > How about
> > changing so that rather than passing in a module, you just pass in the
> > dump/load function? Then cclib wouldn't have to do any of this. The
> > user would do "from simplejson import dumps", and then pass "dumps" as
> > a parameter to write_json.
>
> I'm not sure I understand: you propose to bundle a pure python JSON module for
> the default (simplejson or json), and add an optional dumps/loads argument if
> the user wants an alternate function?
Maybe - what do you think? Alternatively, we could forget about
bundling or importing the module ourselves, and just leave it to the
user to pass in the dumps/loads function. This would make our code
much cleaner, and fits the "Only one good way to do it" philosophy of
Python. I will go with this as my final proposal...

> - Karol
>
> --
> written by Karol Langner
> Mon Nov 19 15:36:43 CET 2007
>

Re: [cclib-devel] Further JSON support

[Karol L. <kar...@kn...>]

On Monday 19 November 2007 15:21, Noel O'Boyle wrote:
> On 19/11/2007, Karol Langner <kar...@kn...> wrote:
> > On Monday 19 November 2007 14:38, Noel O'Boyle wrote:
> > > Do we really need support for three JSON libraries? We can just bundle
> > > simplejson (or one of the others if their licenses permit) with cclib.
> >
> > I don't like it either, but it seems to be the simplest fix for now if I
> > want to use cjson. Bundling is probably the best final solution. I would
> > opt for cjson in that case, although it is a C extension and would
> > require compilation upon install, which cclib has avoided up to now.
>
> Yes - I wouldn't like to do this for the 'core' parsing.

Does this mean you would consider C extensions appropriate for ex. 
cclib.methods if they made them ore efficient?

> How about 
> changing so that rather than passing in a module, you just pass in the
> dump/load function? Then cclib wouldn't have to do any of this. The
> user would do "from simplejson import dumps", and then pass "dumps" as
> a parameter to write_json.

I'm not sure I understand: you propose to bundle a pure python JSON module for 
the default (simplejson or json), and add an optional dumps/loads argument if 
the user wants an alternate function?

- Karol

-- 
written by Karol Langner
Mon Nov 19 15:36:43 CET 2007

Re: [cclib-devel] Further JSON support

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

On 19/11/2007, Karol Langner <kar...@kn...> wrote:
> On Monday 19 November 2007 14:38, Noel O'Boyle wrote:
> > Do we really need support for three JSON libraries? We can just bundle
> > simplejson (or one of the others if their licenses permit) with cclib.
>
> I don't like it either, but it seems to be the simplest fix for now if I want
> to use cjson. Bundling is probably the best final solution. I would opt for
> cjson in that case, although it is a C extension and would require
> compilation upon install, which cclib has avoided up to now.

Yes - I wouldn't like to do this for the 'core' parsing. How about
changing so that rather than passing in a module, you just pass in the
dump/load function? Then cclib wouldn't have to do any of this. The
user would do "from simplejson import dumps", and then pass "dumps" as
a parameter to write_json.

> - Karol
>
> --
> written by Karol Langner
> Mon Nov 19 15:02:50 CET 2007
>

Re: [cclib-devel] Further JSON support

[Karol L. <kar...@kn...>]

On Monday 19 November 2007 14:38, Noel O'Boyle wrote:
> Do we really need support for three JSON libraries? We can just bundle
> simplejson (or one of the others if their licenses permit) with cclib.

I don't like it either, but it seems to be the simplest fix for now if I want 
to use cjson. Bundling is probably the best final solution. I would opt for 
cjson in that case, although it is a C extension and would require 
compilation upon install, which cclib has avoided up to now.

- Karol

-- 
written by Karol Langner
Mon Nov 19 15:02:50 CET 2007

Re: [cclib-devel] Further JSON support

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

Do we really need support for three JSON libraries? We can just bundle
simplejson (or one of the others if their licenses permit) with cclib.

Noel

On 19/11/2007, Karol Langner <kar...@kn...> wrote:
> Hi,
>
>  A clarification on my latest commit. Since I started to use a different JSON
> encoder/decoder than simplejson, I decided to add support for them in cclib.
>
>  One of simplejson, cjson ot json is loaded dynamically when load_json() is
> called in data.py. It is only loaded once, unless an optional argument for
> the module name is passed (can be passed through read_json, etc.). An
> example:
>
> >>> import cclib
> >>> m = cclib.parser.ccopen("dvb_sp.out").parse()
> (...)
> >>> m.writejson(outfile="x.simplejson", module="simplejson")
> >>> m.writejson(outfile="x.json", module="json")
> >>> m.writejson(outfile="x.cjson", module="cjson")
>
> This writes three files using the three different modules. So,
>
> x.cjson is 63K
> x.json is 69K
> x.simplejson is 105K
>
> I don't know if any of these modules is better or faster or if it matters, but
> since simplejson was first it is the default (being the first to try to
> load).
>
> Cheers,
> Karol
>
> --
> written by Karol Langner
> Mon Nov 19 14:26:59 CET 2007
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

[cclib-devel] Further JSON support

[Karol L. <kar...@kn...>]

Hi,

 A clarification on my latest commit. Since I started to use a different JSON 
encoder/decoder than simplejson, I decided to add support for them in cclib.

 One of simplejson, cjson ot json is loaded dynamically when load_json() is 
called in data.py. It is only loaded once, unless an optional argument for 
the module name is passed (can be passed through read_json, etc.). An 
example:

>>> import cclib
>>> m = cclib.parser.ccopen("dvb_sp.out").parse()
(...)
>>> m.writejson(outfile="x.simplejson", module="simplejson")
>>> m.writejson(outfile="x.json", module="json")
>>> m.writejson(outfile="x.cjson", module="cjson")

This writes three files using the three different modules. So,

x.cjson is 63K
x.json is 69K
x.simplejson is 105K

I don't know if any of these modules is better or faster or if it matters, but 
since simplejson was first it is the default (being the first to try to 
load).

Cheers,
Karol

-- 
written by Karol Langner
Mon Nov 19 14:26:59 CET 2007

Re: [cclib-devel] CI and TDDFT

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

I've just done the equivalent calculation with PCGAMESS and checked it
in. It's not only an order of magnitude faster (or more), but the
squares of the triplet contributions add to around 1. Is this a bug in
GAMESS-US then? Who knows? (Just to be clear, the TD-DFT code in
PCGAMESS and GAMESSUS is completely different)

Noel

On 15/11/2007, Karol Langner <kar...@kn...> wrote:
> On Wednesday 14 November 2007 11:37, Noel O'Boyle wrote:
> > I'm wondering whether either of you know whether the etsecs from a
> > restricted calculation of triplet excited states is likely to add to 1
> > (after squaring). I'm getting:
> >
> >    ---------------------------------
> >      R-TDDFT CALCULATION CONVERGED
> >    ---------------------------------
> >  NUMBER OF USED VECTORS / MAX =  49 / 200
> >  NUMBER OF ITERATIONS   / MAX =   6 / 100
> >  NUMBER OF SINGLE EXCITATIONS =   875
> >  NUMBER OF ATOMIC ORBITALS    =  60
> >  NUMBER OF TOTAL ELECTRONS    =          70.0035208
> >
> >           -------------------
> >           TRIPLET EXCITATIONS
> >           -------------------
> >
> >  STATE #   1  ENERGY =    3.027228 EV
> >  OSCILLATOR STRENGTH =    0.000000
> >         DRF    COEF       OCC      VIR
> >         ---    ----       ---      ---
> >          35 -1.105383     35  ->   36
> >          69 -0.389181     34  ->   37
> >         103 -0.405078     33  ->   38
> >         137  0.252485     32  ->   39
> >         168 -0.158406     28  ->   40
> >
> > The squares add to 1.63 or so.
>
> I've never seen a coefficient larger than one - I don't know what that means.
> Notice the oscilator strength is zero (or really very small).
>
> Can you attach the entire output file (i think only the singlet version is in
> teh trunk)? Also, how does this compare to Gaussian output? From my
> experience, GAMESS is buggy in some places when it comes to excitations. I've
> had some problems using soem of the CIS options.
>
> > It's not a big deal for users of cclib as we just extract whatever
> > figure is given here. Still, if anyone has any insight it would be
> > good to know. For comparison, here is a similar transition for the
> > SINGLET EXCITATIONS:
>
> True, although it would be good to know what's happening and maybe warn the
> user. I routinely use scripts to check output files for errors/warnings and
> generally strange output. This might be a good thing to add to cclib n the
> future.
>
> > > The handling of the etsecs is likely to have changed for CI due to my
> > > latest checkin. I hope this is not a problem. I am currently trying to
> > > standardise the values of etsecs for all calculations (using tests),
> > > but am only halfway. I need to carry out some TD-DFT calculations on
> > > unrestricted calculations and sort these out at the same time as
> > > handling the CI calculations.
>
> I'll have closer look over the weekend.
>
> Karol
>
> --
> written by Karol Langner
> Thu Nov 15 14:38:10 EST 2007
>

Re: [cclib-devel] CI and TDDFT

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

On 15/11/2007, Karol Langner <kar...@kn...> wrote:
> On Wednesday 14 November 2007 11:37, Noel O'Boyle wrote:
> > I'm wondering whether either of you know whether the etsecs from a
> > restricted calculation of triplet excited states is likely to add to 1
> > (after squaring). I'm getting:
> >
> >    ---------------------------------
> >      R-TDDFT CALCULATION CONVERGED
> >    ---------------------------------
> >  NUMBER OF USED VECTORS / MAX =  49 / 200
> >  NUMBER OF ITERATIONS   / MAX =   6 / 100
> >  NUMBER OF SINGLE EXCITATIONS =   875
> >  NUMBER OF ATOMIC ORBITALS    =  60
> >  NUMBER OF TOTAL ELECTRONS    =          70.0035208
> >
> >           -------------------
> >           TRIPLET EXCITATIONS
> >           -------------------
> >
> >  STATE #   1  ENERGY =    3.027228 EV
> >  OSCILLATOR STRENGTH =    0.000000
> >         DRF    COEF       OCC      VIR
> >         ---    ----       ---      ---
> >          35 -1.105383     35  ->   36
> >          69 -0.389181     34  ->   37
> >         103 -0.405078     33  ->   38
> >         137  0.252485     32  ->   39
> >         168 -0.158406     28  ->   40
> >
> > The squares add to 1.63 or so.
>
> I've never seen a coefficient larger than one - I don't know what that means.
> Notice the oscilator strength is zero (or really very small).
>
> Can you attach the entire output file (i think only the singlet version is in
> teh trunk)? Also, how does this compare to Gaussian output?
I'll check in the triplet one.

> From my
> experience, GAMESS is buggy in some places when it comes to excitations. I've
> had some problems using soem of the CIS options.
>
> > It's not a big deal for users of cclib as we just extract whatever
> > figure is given here. Still, if anyone has any insight it would be
> > good to know. For comparison, here is a similar transition for the
> > SINGLET EXCITATIONS:
>
> True, although it would be good to know what's happening and maybe warn the
> user. I routinely use scripts to check output files for errors/warnings and
> generally strange output. This might be a good thing to add to cclib n the
> future.
>
> > > The handling of the etsecs is likely to have changed for CI due to my
> > > latest checkin. I hope this is not a problem. I am currently trying to
> > > standardise the values of etsecs for all calculations (using tests),
> > > but am only halfway. I need to carry out some TD-DFT calculations on
> > > unrestricted calculations and sort these out at the same time as
> > > handling the CI calculations.
>
> I'll have closer look over the weekend.
I'll try to sort it out by then, so you that you can doublecheck what
I've done...

> Karol
>
> --
> written by Karol Langner
> Thu Nov 15 14:38:10 EST 2007
>

Re: [cclib-devel] CI and TDDFT

[Karol L. <kar...@kn...>]

On Wednesday 14 November 2007 11:37, Noel O'Boyle wrote:
> I'm wondering whether either of you know whether the etsecs from a
> restricted calculation of triplet excited states is likely to add to 1
> (after squaring). I'm getting:
>
>    ---------------------------------
>      R-TDDFT CALCULATION CONVERGED
>    ---------------------------------
>  NUMBER OF USED VECTORS / MAX =  49 / 200
>  NUMBER OF ITERATIONS   / MAX =   6 / 100
>  NUMBER OF SINGLE EXCITATIONS =   875
>  NUMBER OF ATOMIC ORBITALS    =  60
>  NUMBER OF TOTAL ELECTRONS    =          70.0035208
>
>           -------------------
>           TRIPLET EXCITATIONS
>           -------------------
>
>  STATE #   1  ENERGY =    3.027228 EV
>  OSCILLATOR STRENGTH =    0.000000
>         DRF    COEF       OCC      VIR
>         ---    ----       ---      ---
>          35 -1.105383     35  ->   36
>          69 -0.389181     34  ->   37
>         103 -0.405078     33  ->   38
>         137  0.252485     32  ->   39
>         168 -0.158406     28  ->   40
>
> The squares add to 1.63 or so.

I've never seen a coefficient larger than one - I don't know what that means. 
Notice the oscilator strength is zero (or really very small).

Can you attach the entire output file (i think only the singlet version is in 
teh trunk)? Also, how does this compare to Gaussian output? From my 
experience, GAMESS is buggy in some places when it comes to excitations. I've 
had some problems using soem of the CIS options.

> It's not a big deal for users of cclib as we just extract whatever
> figure is given here. Still, if anyone has any insight it would be
> good to know. For comparison, here is a similar transition for the
> SINGLET EXCITATIONS:

True, although it would be good to know what's happening and maybe warn the 
user. I routinely use scripts to check output files for errors/warnings and 
generally strange output. This might be a good thing to add to cclib n the 
future.

> > The handling of the etsecs is likely to have changed for CI due to my
> > latest checkin. I hope this is not a problem. I am currently trying to
> > standardise the values of etsecs for all calculations (using tests),
> > but am only halfway. I need to carry out some TD-DFT calculations on
> > unrestricted calculations and sort these out at the same time as
> > handling the CI calculations.

I'll have closer look over the weekend.

Karol

-- 
written by Karol Langner
Thu Nov 15 14:38:10 EST 2007

Re: [cclib-devel] CI and TDDFT

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

I'm wondering whether either of you know whether the etsecs from a
restricted calculation of triplet excited states is likely to add to 1
(after squaring). I'm getting:

   ---------------------------------
     R-TDDFT CALCULATION CONVERGED
   ---------------------------------
 NUMBER OF USED VECTORS / MAX =  49 / 200
 NUMBER OF ITERATIONS   / MAX =   6 / 100
 NUMBER OF SINGLE EXCITATIONS =   875
 NUMBER OF ATOMIC ORBITALS    =  60
 NUMBER OF TOTAL ELECTRONS    =          70.0035208

          -------------------
          TRIPLET EXCITATIONS
          -------------------

 STATE #   1  ENERGY =    3.027228 EV
 OSCILLATOR STRENGTH =    0.000000
        DRF    COEF       OCC      VIR
        ---    ----       ---      ---
         35 -1.105383     35  ->   36
         69 -0.389181     34  ->   37
        103 -0.405078     33  ->   38
        137  0.252485     32  ->   39
        168 -0.158406     28  ->   40

The squares add to 1.63 or so.

It's not a big deal for users of cclib as we just extract whatever
figure is given here. Still, if anyone has any insight it would be
good to know. For comparison, here is a similar transition for the
SINGLET EXCITATIONS:

 STATE #   2  ENERGY =    4.928436 EV
 OSCILLATOR STRENGTH =    0.051448
 SYMMETRY OF STATE   =    BU
        DRF    COEF       OCC      VIR
        ---    ----       ---      ---
         34 -0.749876     34  ->   36
         35 -0.220121     35  ->   36
         67 -0.070269     32  ->   37
         70 -0.625220     35  ->   37
        139 -0.033687     34  ->   39

Noel

On 14/11/2007, Noel O'Boyle <bao...@gm...> wrote:
> Dear all,
>
> The handling of the etsecs is likely to have changed for CI due to my
> latest checkin. I hope this is not a problem. I am currently trying to
> standardise the values of etsecs for all calculations (using tests),
> but am only halfway. I need to carry out some TD-DFT calculations on
> unrestricted calculations and sort these out at the same time as
> handling the CI calculations.
>
> The policy I am following is that for every type of calculation, the
> sum of the squares of the etsecs values is close to 1...
>
> Noel
>

[cclib-devel] CI and TDDFT

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

Dear all,

The handling of the etsecs is likely to have changed for CI due to my
latest checkin. I hope this is not a problem. I am currently trying to
standardise the values of etsecs for all calculations (using tests),
but am only halfway. I need to carry out some TD-DFT calculations on
unrestricted calculations and sort these out at the same time as
handling the CI calculations.

The policy I am following is that for every type of calculation, the
sum of the squares of the etsecs values is close to 1...

Noel

[cclib-devel] Changes to read/write json

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

Commit by langner  ::  r792 /trunk/src/cclib/data.py: (link)
Spruced up (I hope) readjson/writejson functions and added analogous
readpickle/writepickle functions.

What do these changes do?

Noel

[cclib-devel] [ cclib-Bugs-1784327 ] Can't handle GAMESS TD-DFT

[SourceForge.net <no...@so...>]

Bugs item #1784327, was opened at 2007-08-29 19:23
Message generated for change (Comment added) made by baoilleach
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1784327&group_id=161285

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parsers
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Noel O\'Boyle (baoilleach)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can't handle GAMESS TD-DFT

Initial Comment:
Vitaliy Gorbenko contacted GaussSum. It seems that cclib can't handle GAMESS and PC GAMESS TD-DFT. I haven't verified the problem.

He provided an input and output file but I include here only the keywords for the input:

GAMESS:
 $CONTRL SCFTYP=RHF DFTTYP=B3LYP TDDFT=EXCITE $END
 $SYSTEM TIMLIM=3000 MWORDS=50 $END
 $BASIS  GBASIS=N21 ngauss=3 NDFUNC=1 $END
 $TDDFT NSTATE=10 $END
 $DAT

He also reported problems with PC GAMESS:

 $CONTRL SCFTYP=RHF CITYP=CIS COORD=CART MAXIT=1000 $END                      
 $SYSTEM TIMLIM=3000 MEMORY=10000000 $END                                       
 $BASIS  GBASIS=N21 ngauss=3 NDFUNC=1 $END                                      
 $SCF DIIS=.F. SHIFT=.T. SOSCF=.T. $END                                         
 $CIS NSTATE=80 ISTSYM=0 ISTATE=1 $END                                          
 $DAT

and also:

 $CONTRL SCFTYP=RHF DFTTYP=B3LYP CITYP=TDDFT COORD=CART MAXIT=1000 $END       
 $SYSTEM TIMLIM=3000 MEMORY=10000000 $END                                        
 $BASIS  GBASIS=STO ngauss=3 NDFUNC=1 $END                                      
 $SCF DIIS=.F. SHIFT=.T. SOSCF=.T. $END                                         
 $TDDFT NSTATE=80 ISTSYM=0 ISTATE=1 TDA=.t. $END                                
 $DAT


----------------------------------------------------------------------

>Comment By: Noel O\'Boyle (baoilleach)
Date: 2007-11-06 15:47

Message:
Logged In: YES 
user_id=850620
Originator: YES

The problem appears to be that etoscs is not parsed. I am looking into
this...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1784327&group_id=161285

[cclib-devel] Orca branch

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

Can I delete the ORCA branch now?

Noel

Re: [cclib-devel] unit consistency issue

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

On 06/11/2007, Karol Langner <kar...@kn...> wrote:
> On Tuesday 06 November 2007 04:28, Noel O'Boyle wrote:
> > On 06/11/2007, Karol Langner <kar...@kn...> wrote:
> > > I want to raise a consistency issue,
> > >
> > >  Most energy-related attributes are parsed in eV (scfenergies,
> > > mpenergies, etc.). The numbers in scftargets and scfvalues, however, are
> > > parsed without conversion. Is this intentional or unnoticed?
> >
> > For me, the only requirement is that the same units are used for
> > scftargets and scfvalues - in fact, the units are different for
> > different elements of scftargets. As far as I know, this attribute is
> > only useful for monitoring progress. Different programs have different
> > ways of measuring convergence; typically delta energy and delta
> > matrix. Although we can change the units of delta energy if you wish,
> > I don't know who is going to be accessing them apart from GaussSum.
>
> I was just thinking that if someone took the energy change criteria of
> scftargets to be in eV they could be very surprised. I have no reason to add
> the conversion.

OK - I'll look into it. I guess you're right.

> Karol
>
> --
> written by Karol Langner
> Tue Nov  6 10:21:47 EST 2007
>

Re: [cclib-devel] unit consistency issue

[Karol L. <kar...@kn...>]

On Tuesday 06 November 2007 04:28, Noel O'Boyle wrote:
> On 06/11/2007, Karol Langner <kar...@kn...> wrote:
> > I want to raise a consistency issue,
> >
> >  Most energy-related attributes are parsed in eV (scfenergies,
> > mpenergies, etc.). The numbers in scftargets and scfvalues, however, are
> > parsed without conversion. Is this intentional or unnoticed?
>
> For me, the only requirement is that the same units are used for
> scftargets and scfvalues - in fact, the units are different for
> different elements of scftargets. As far as I know, this attribute is
> only useful for monitoring progress. Different programs have different
> ways of measuring convergence; typically delta energy and delta
> matrix. Although we can change the units of delta energy if you wish,
> I don't know who is going to be accessing them apart from GaussSum.

I was just thinking that if someone took the energy change criteria of 
scftargets to be in eV they could be very surprised. I have no reason to add 
the conversion.

Karol

-- 
written by Karol Langner
Tue Nov  6 10:21:47 EST 2007

Re: [cclib-devel] unit consistency issue

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

On 06/11/2007, Karol Langner <kar...@kn...> wrote:
> I want to raise a consistency issue,
>
>  Most energy-related attributes are parsed in eV (scfenergies, mpenergies,
> etc.). The numbers in scftargets and scfvalues, however, are parsed without
> conversion. Is this intentional or unnoticed?

For me, the only requirement is that the same units are used for
scftargets and scfvalues - in fact, the units are different for
different elements of scftargets. As far as I know, this attribute is
only useful for monitoring progress. Different programs have different
ways of measuring convergence; typically delta energy and delta
matrix. Although we can change the units of delta energy if you wish,
I don't know who is going to be accessing them apart from GaussSum.

> Cheers,
> Karol
>
> --
> written by Karol Langner
> Mon Nov  5 23:21:14 EST 2007
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

[cclib-devel] unit consistency issue

[Karol L. <kar...@kn...>]

I want to raise a consistency issue,

 Most energy-related attributes are parsed in eV (scfenergies, mpenergies, 
etc.). The numbers in scftargets and scfvalues, however, are parsed without 
conversion. Is this intentional or unnoticed?

Cheers,
Karol

-- 
written by Karol Langner
Mon Nov  5 23:21:14 EST 2007

[cclib-devel] [ cclib-Bugs-1821996 ] Gaussian: can't parse if mult > 9

[SourceForge.net <no...@so...>]

Bugs item #1821996, was opened at 2007-10-29 09:55
Message generated for change (Comment added) made by baoilleach
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1821996&group_id=161285

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parsers
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Noel O\'Boyle (baoilleach)
Assigned to: Nobody/Anonymous (nobody)
Summary: Gaussian: can't parse if mult > 9

Initial Comment:
It's a trivial fix, but the parser fails if the multiplicity is 10 or greater. I've attached some test files.

----------------------------------------------------------------------

>Comment By: Noel O\'Boyle (baoilleach)
Date: 2007-10-31 13:13

Message:
Logged In: YES 
user_id=850620
Originator: YES

Fixed in r776.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1821996&group_id=161285