cclib-devel Mailing List for cclib

On Monday 30 April 2007 08:54, Noel O'Boyle wrote:
> Maybe someone has already suggested this, but here's an idea to handle
> updating the "self.updateprogress".
>
> Every time an attribute is set by __setattr__, it should change the
> updateprogress string to the name of the attribute rather than having
> to do this in the subclass.

Good idea. This doesn't cover the whole range of situations 
LogFile.updateprogress is used in, though.

> Just a note:
>
> Line 197 of logfileparser:
>             self.updateprogress(inputfile, "Unsupported information",
> cupdate)
>
> If inputfile and cupdate are attributes of logfileparser, then there's
> no need to pass them in to updateprogress.

Yup.

-Karol

-- 
written by Karol Langner
Mon Apr 30 12:16:37 CEST 2007

Maybe someone has already suggested this, but here's an idea to handle
updating the "self.updateprogress".

Every time an attribute is set by __setattr__, it should change the
updateprogress string to the name of the attribute rather than having
to do this in the subclass.

Just a note:

Line 197 of logfileparser:
            self.updateprogress(inputfile, "Unsupported information", cupdate)

If inputfile and cupdate are attributes of logfileparser, then there's
no need to pass them in to updateprogress.

Noel

I've added charge and mult (multiplicity) to cclib. Any ideas on
better names? Perhaps spin instead of mult, or would that just be
confusing?

Noel

Nice work!

On 28/04/07, Karol Langner <kar...@kn...> wrote:
> Sure. I'll just mention the more important changes in names:
>
> Numeric.matrixmultiply -> numpy.dot
> Numeric.outerproduct -> numpy.outer
> LinearAlgebra.inverse -> numpy.linalg.inv
> Numeric.typecode -> numpy.dtype
>
> The last was the problematic one, since Numeric.typecode is a function, while
> numpy.dtype is a type.
>
> On Friday 27 April 2007 15:47, Noel O'Boyle wrote:
> > Let's leave a few days "cooling off period" to look through the code
> > for anything that doesn't seem right.
> >
> > On 27/04/07, Karol Langner <kar...@kn...> wrote:
> > > I changed all references to NumPy, but left the Numeric imports (when
> > > importing numpy fails). Some method names had to be changed. All the
> > > tests and regressions go fine, although I'm worried we don't have tests
> > > for all the methods, since that's where the most Numeric functions are
> > > used.
> > >
> > > --
> > > written by Karol Langner
> > > Fri Apr 27 17:36:53 CEST 2007
>
> --
> written by Karol Langner
> Sat Apr 28 11:36:59 CEST 2007
>

Sure. I'll just mention the more important changes in names:

Numeric.matrixmultiply -> numpy.dot
Numeric.outerproduct -> numpy.outer
LinearAlgebra.inverse -> numpy.linalg.inv
Numeric.typecode -> numpy.dtype

The last was the problematic one, since Numeric.typecode is a function, while 
numpy.dtype is a type.

On Friday 27 April 2007 15:47, Noel O'Boyle wrote:
> Let's leave a few days "cooling off period" to look through the code
> for anything that doesn't seem right.
>
> On 27/04/07, Karol Langner <kar...@kn...> wrote:
> > I changed all references to NumPy, but left the Numeric imports (when
> > importing numpy fails). Some method names had to be changed. All the
> > tests and regressions go fine, although I'm worried we don't have tests
> > for all the methods, since that's where the most Numeric functions are
> > used.
> >
> > --
> > written by Karol Langner
> > Fri Apr 27 17:36:53 CEST 2007

-- 
written by Karol Langner
Sat Apr 28 11:36:59 CEST 2007

Let's leave a few days "cooling off period" to look through the code
for anything that doesn't seem right.

On 27/04/07, Karol Langner <kar...@kn...> wrote:
> I changed all references to NumPy, but left the Numeric imports (when
> importing numpy fails). Some method names had to be changed. All the tests
> and regressions go fine, although I'm worried we don't have tests for all the
> methods, since that's where the most Numeric functions are used.
>
> - Karol
>
> --
> written by Karol Langner
> Fri Apr 27 17:36:53 CEST 2007
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

I changed all references to NumPy, but left the Numeric imports (when 
importing numpy fails). Some method names had to be changed. All the tests 
and regressions go fine, although I'm worried we don't have tests for all the 
methods, since that's where the most Numeric functions are used.

- Karol

-- 
written by Karol Langner
Fri Apr 27 17:36:53 CEST 2007

Hi,

With revision 614, I have basically completed the refactoring changes I 
planned. All tests still pass, two ADF regression tests fail, but this was 
true before my commits, if I remember correctly.

I'm probably not going to do anything else today, to let the changes "sink 
in". I might add a few more minor things tommorow related with the 
refactoring, though. This would be good moment to discuss the possibility of 
using a dictionary of functions instead of the extract() method, or other 
further ideas. My main worry is where all the functions would be defined.

- Karol

-- 
written by Karol Langner
Thu Apr 26 17:17:09 CEST 2007

I just made fupdate and cupdate attributes of the parser class. They can be 
set upon initializing the parser. The parse() method still takes them as 
optional arguments, because I don't know if this is used by your programs 
somewhere (GausSum, PyMOlyze, ...). If not, I guess that can be thrown out, 
too.

I'm still not too aware what the difference between these is, but I'll get to 
that eventually when I take a deeper look.

- Karol

-- 
written by Karol Langner
Thu Apr 26 15:40:36 CEST 2007

On 26/04/07, Karol Langner <kar...@kn...> wrote:
> On Thursday 26 April 2007 12:57, Noel O'Boyle wrote:
> > On 26/04/07, Karol Langner <kar...@kn...> wrote:
> > > On Thursday 26 April 2007 08:04, Noel wrote:
> > > > Do any of our parsers set the attribute, but then delattr it? Might be
> > > > worth checking. Also, it would be possible to check the types of
> > > > attributes at this point, using an assert statement. I can look into
> > > > this.
> > >
> > > langner@slim:~/tmp/python/cclib/trunk/src/cclib/parser$ grep "delattr" *
> > > logfileparser.py:                delattr(self, attr)
> > >
> > > The actual parsing no - the only place it is used is in LogFile.clean().
> > >
> > > What do you mean by "checking the types of attributes at this point"? Do
> > > you mean checking that the value is the correct type inside
> > > LogFile.__setattr()?
> >
> > E.g. verify that mocoeffs is a list of 1 or 2 numeric arrays of rank 2
> > or whatever. It wouldn't add much overhead to the program, and would
> > act as a sanity check.
>
> As you know, presently types are checked after parsing (I added the _attrtypes
> list today). This could be done additionally in __setattr__. Checking the
> contents of lists, though, is done only for lists that are supposed to
> contain arrays. The method __setattr__, however, is called only when a new
> value is assigned (using equivalence or whatever). So that would be a rather
> weak sanity check for list contents - if something is appended to the list,
> or one of the elements changed, the method is not called.
>
Sorry - I forget that it was already being checked after parsing.

> - Karol
>
> --
> written by Karol Langner
> Thu Apr 26 15:11:57 CEST 2007
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

On Thursday 26 April 2007 12:57, Noel O'Boyle wrote:
> On 26/04/07, Karol Langner <kar...@kn...> wrote:
> > On Thursday 26 April 2007 08:04, Noel wrote:
> > > Do any of our parsers set the attribute, but then delattr it? Might be
> > > worth checking. Also, it would be possible to check the types of
> > > attributes at this point, using an assert statement. I can look into
> > > this.
> >
> > langner@slim:~/tmp/python/cclib/trunk/src/cclib/parser$ grep "delattr" *
> > logfileparser.py:                delattr(self, attr)
> >
> > The actual parsing no - the only place it is used is in LogFile.clean().
> >
> > What do you mean by "checking the types of attributes at this point"? Do
> > you mean checking that the value is the correct type inside
> > LogFile.__setattr()?
>
> E.g. verify that mocoeffs is a list of 1 or 2 numeric arrays of rank 2
> or whatever. It wouldn't add much overhead to the program, and would
> act as a sanity check.

As you know, presently types are checked after parsing (I added the _attrtypes 
list today). This could be done additionally in __setattr__. Checking the 
contents of lists, though, is done only for lists that are supposed to 
contain arrays. The method __setattr__, however, is called only when a new 
value is assigned (using equivalence or whatever). So that would be a rather 
weak sanity check for list contents - if something is appended to the list, 
or one of the elements changed, the method is not called.

- Karol

-- 
written by Karol Langner
Thu Apr 26 15:11:57 CEST 2007

On 26/04/07, Karol Langner <kar...@kn...> wrote:
> On Thursday 26 April 2007 08:04, Noel wrote:
> > Do any of our parsers set the attribute, but then delattr it? Might be
> > worth checking. Also, it would be possible to check the types of
> > attributes at this point, using an assert statement. I can look into
> > this.
>
> langner@slim:~/tmp/python/cclib/trunk/src/cclib/parser$ grep "delattr" *
> logfileparser.py:                delattr(self, attr)
>
> The actual parsing no - the only place it is used is in LogFile.clean().
>
> What do you mean by "checking the types of attributes at this point"? Do you
> mean checking that the value is the correct type inside LogFile.__setattr()?

E.g. verify that mocoeffs is a list of 1 or 2 numeric arrays of rank 2
or whatever. It wouldn't add much overhead to the program, and would
act as a sanity check.

> > > 5) Numeric->numpy transition. This isn't strictly related to the
> > > refactoring, but it might as well be done at once. The related changes
> > > seem to be trivial.
> >
> > Can we leave this until all current tests pass after the first refactoring.
>
> Of course. I added it, becuase hopefully the refactoring will not break any
> tests.
>
> - Karol
>
> --
> written by Karol Langner
> Thu Apr 26 14:26:08 CEST 2007
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

On Thursday 26 April 2007 08:04, Noel wrote:
> Do any of our parsers set the attribute, but then delattr it? Might be
> worth checking. Also, it would be possible to check the types of
> attributes at this point, using an assert statement. I can look into
> this.

langner@slim:~/tmp/python/cclib/trunk/src/cclib/parser$ grep "delattr" *
logfileparser.py:                delattr(self, attr)

The actual parsing no - the only place it is used is in LogFile.clean().

What do you mean by "checking the types of attributes at this point"? Do you
mean checking that the value is the correct type inside LogFile.__setattr()?

> > 5) Numeric->numpy transition. This isn't strictly related to the
> > refactoring, but it might as well be done at once. The related changes
> > seem to be trivial.
>
> Can we leave this until all current tests pass after the first refactoring.

Of course. I added it, becuase hopefully the refactoring will not break any
tests.

- Karol

-- 
written by Karol Langner
Thu Apr 26 14:26:08 CEST 2007

On 26/04/07, Chris Morley <c.m...@ga...> wrote:
> I also have had these compiling difficulties. My computer was down for a
> couple of weeks before the release of the source files and I wasn't able
> to check that they continued to compile. I have downloaded the released
> source and it needed a couple of minor changes. I also had to reinstall
> all my programs so that my wxWidgets version is 2.83.
Are you saying that I need wxWidgets 2.8.3 also? I think you are - I
saw that you updated the compile instructions on the wiki.

> In addition, Geoff
> seems to have removed some essential files from the distribution - like
> the libxml2 headers.
I'm posting to the list so Geoff can fill us in.

> At http://www.gaseq.co.uk/OB/openbabel-2.1.0.7z is a copy of the 2.1.0
> project which compiles for me. (I haven't tried OBPython recently.) We
> can get in a mess with versions and really will have to do it better
> next time.
I think it's fine so long as we use SVN and tag the release once it
compiles fine and has been tested. Then it is clear exactly what was
contained in the release. If we work locally, it will be more
difficult to untangle things.

> I suspect that the following data files should be included:
> SMARTS_InteLigand.txt
> logp.txt
> mr.txt
> psa.txt
> ghemical.prm
> It is difficult finding machine empty enough to be sure.
I have a pretty empty machine for testing once we get to this stage.

> If you would prefer to do this a different way, please say.
I'd really like to work from SVN, although it looks like we should be
working off the 2.1.x release branch rather than the trunk. If you
could get this to compile I think this is a better idea than working
off a download of the 2.1.0 release.

Geoff periodically merges from the release branch to the trunk (and
vice versa I guess in some cases), so any changes you/we make will be
incorporated into the trunk also.

Noel

I've been trying to upgrade GaussSum to use cclib 0.7 but I've run
into a difficulty of sorts. I realised that:
(1) some Jaguar files don't have aonames
(2) GaussSum was parsing the aonames to figure out which basis
functions were on which atoms

First of all, GaussSum shouldn't need to be parsing a text string to
figure out information which was available to cclib. This means we
need to add a new attribute which assigns basis functions to atoms,
e.g. a list of lists called atombasis where atombasis[0] is a list
containing the indices of the basis fns on the first atom.

Secondly, we need to tighten up our definitions of aonames. I note
here that some output files have more information than others. It is
not possible to standardise aonames across parsers but we should at
least provide some guidelines for how aonames should be constructed in
general.

Noel

On 26/04/07, Karol Langner <kar...@kn...> wrote:
> Hi,
>
>  I've already started, but I'd like to shortly summarize the changes I'm about
> to do in the trunk related to refactoring the parser, in the order they will
> proceed. Ideally, these changes won't break anything, but you never know, so
> be on the lookout! The goal is to get certain things working automatically
> and to move as many elements of the parsing process to the generic class
> LogFile, which in turn is supposed to make writing and modifying the child
> parsers easier in the future.
>
> 1) Move all calls to logger.infio() for newly created attributes to the method
> LogFile.__setattr__() - which is called automatically when an attibute is
> set. Prints the log message only if the attribute is new and present in
> LogFile.attrlist.
Do any of our parsers set the attribute, but then delattr it? Might be
worth checking. Also, it would be possible to check the types of
attributes at this point, using an assert statement. I can look into
this.

> 2) Up till now, we refrained from setting temporary attributes while parsing
> in order to keep things tidy. By utilizing an additional list attribute
> ("__nodelete"), these can be used (alot, if neede), and will be deleted after
> parsing (so the user does not see that they existed). Interestingly, this
> also requires that we keep LogFile.attrlist up-to-date :-)
>
> 3) THE MAJOR CHANGE - moving the "for line in inputfile" loop to
> LogFile.parse(). This may seem like just moving one line, but there are some
> extra things to change in order to keep things parsing (like using temporary
> attributes), and a number of things to consider. Note a paradigm shift in the
> way the parsers work: the method extract() will be now called many times
> instead of once. In my opinion, this is a natural step that makes the parsers
> more flexible and opens interesting possibilities for further enhacements,
>
> 4) Making fupdate and cupdate attributes of the class - this is reasonable, as
> then they won't have to be passed around to extract() in each call.
Sure.

> 5) Numeric->numpy transition. This isn't strictly related to the refactoring,
> but it might as well be done at once. The related changes seem to be trivial.

Can we leave this until all current tests pass after the first refactoring.

> 6) A few other minor changes I might not remember at the moment, but will
> comment on.
>
> Any further changes to the parser structure really need to be discussed
> thouroughly so as not to waste development time. For example, as mentioned by
> Noel, we could choose to use a dictionary of functions that parse separate
> blocks of output (best if the keys are regexps). I like the idea, and the
> present changes are a step in that direction. It would be pretty, optimal,
> and well-structured, which all makes writing new parses easier and more fun.
> Then main question is - where would all these functions be defined? If they
> are to be class methods, things can get messy, since there will be quite a
> lot of them. But first things first.

> Hope this clears up the up-coming commits,
> Karol
>
> --
> written by Karol Langner
> Thu Apr 26 01:24:12 CEST 2007
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

Hi,

 I've already started, but I'd like to shortly summarize the changes I'm about 
to do in the trunk related to refactoring the parser, in the order they will 
proceed. Ideally, these changes won't break anything, but you never know, so 
be on the lookout! The goal is to get certain things working automatically 
and to move as many elements of the parsing process to the generic class 
LogFile, which in turn is supposed to make writing and modifying the child 
parsers easier in the future.

1) Move all calls to logger.infio() for newly created attributes to the method 
LogFile.__setattr__() - which is called automatically when an attibute is 
set. Prints the log message only if the attribute is new and present in 
LogFile.attrlist.

2) Up till now, we refrained from setting temporary attributes while parsing 
in order to keep things tidy. By utilizing an additional list attribute 
("__nodelete"), these can be used (alot, if neede), and will be deleted after 
parsing (so the user does not see that they existed). Interestingly, this 
also requires that we keep LogFile.attrlist up-to-date :-)

3) THE MAJOR CHANGE - moving the "for line in inputfile" loop to 
LogFile.parse(). This may seem like just moving one line, but there are some 
extra things to change in order to keep things parsing (like using temporary 
attributes), and a number of things to consider. Note a paradigm shift in the 
way the parsers work: the method extract() will be now called many times 
instead of once. In my opinion, this is a natural step that makes the parsers 
more flexible and opens interesting possibilities for further enhacements,

4) Making fupdate and cupdate attributes of the class - this is reasonable, as 
then they won't have to be passed around to extract() in each call.

5) Numeric->numpy transition. This isn't strictly related to the refactoring, 
but it might as well be done at once. The related changes seem to be trivial.

6) A few other minor changes I might not remember at the moment, but will 
comment on.

Any further changes to the parser structure really need to be discussed 
thouroughly so as not to waste development time. For example, as mentioned by 
Noel, we could choose to use a dictionary of functions that parse separate 
blocks of output (best if the keys are regexps). I like the idea, and the 
present changes are a step in that direction. It would be pretty, optimal, 
and well-structured, which all makes writing new parses easier and more fun. 
Then main question is - where would all these functions be defined? If they 
are to be class methods, things can get messy, since there will be quite a 
lot of them. But first things first.

Hope this clears up the up-coming commits,
Karol

-- 
written by Karol Langner
Thu Apr 26 01:24:12 CEST 2007

The first of the changes in refactoring the parser. The __setattr__ method can 
nicel handle calling logger.info() when new attributes are created. All calls 
in extract() in all parsers are gone now. Maybe some other things could also 
be simplified this way - no ideas right now, though.

Cheers,
Karol

-- 
written by Karol Langner
Wed Apr 25 21:05:30 CEST 2007

First of all, I've added you to the "openbabel-python" package as an owner.

Next, once you log in, click on the "openbabel" package (*not*
openbabel-python) and then the "Remove this package completely"
button...

Note that the only problem is that the new higher version number will
replace the old release, and I don't yet have a new Windows release
available. So, if could you hold off making the new 1.2.0 release
until I get a Windows release together (which may take some time
depending on how things are compiling in Windows and how busy Chris
is) that'd be great.

Regards,
   Noel

On 25/04/07, Geoffrey Hutchison <ge...@ge...> wrote:
>
> On Apr 25, 2007, at 9:42 AM, Noel O'Boyle wrote:
>
> >    http://cheeseshop.python.org/pypi?:action=browse&amp;c=389
> >
> > I'm guessing that you didn't realise it was there already, as it would
> > be good to keep the Windows and Linux releases in sync.
>
>
> Yes, exactly. I didn't realize you uploaded the previous iteration.
> If you have a suggestion for what to do, let me know. There's
> probably some procedure to remove the one I uploaded, right?
>
> Thanks,
> -Geoff
>

On Apr 25, 2007, at 9:42 AM, Noel O'Boyle wrote:

>    http://cheeseshop.python.org/pypi?:action=browse&c=389
>
> I'm guessing that you didn't realise it was there already, as it would
> be good to keep the Windows and Linux releases in sync.


Yes, exactly. I didn't realize you uploaded the previous iteration.  
If you have a suggestion for what to do, let me know. There's  
probably some procedure to remove the one I uploaded, right?

Thanks,
-Geoff

Hey Geoff,

I think users are going to be confused by two separate cheeseshop
entries for OpenBabel.
    http://cheeseshop.python.org/pypi?:action=browse&c=389

I'm guessing that you didn't realise it was there already, as it would
be good to keep the Windows and Linux releases in sync.

Noel

While I was away, a GaussSum bug report reached me where a user used
'pop=regular' instead of the default pop, or pop=full, which we can
handle.

"pop=regular" is described by the manual as:
"The five highest occupied and five lowest virtual orbitals are
printed, along with the density matrices and a full (orbital by
orbital and atom by atom) Mulliken population analysis. Since the size
of the output depends on the square of the size of the molecule, it
can become quite substantial for larger molecules."

An error occurs when reading in the mocoeffs. The overall problem is
that we assume that mocoeffs contains the MO coefficients of all of
the orbitals up to a particular orbital N, where N is less than or
equal to the total number of MOs.

I feel that adapting mocoeffs to handle the "pop=regular" situation is
one special case too many. Instead, I intend to make sure that cclib
doesn't fail to parse, but avoid setting the 'mocoeffs' attribute.
Users of GaussSum know that they need to use 'pop=full' if they want
to do a population analysis.

Regards,
   Noel

I won't force the issue either way, but I feel it might be a good idea
to push ahead with the refactoring and get it over with. This will
mean a 0.8 release rather than 0.7.1, but we can make this a quick
release if all it contains is the refactoring plus some bugfixes (ADF)
and enhancements (ccenergies, tightening up the TD-DFT, filling holes
in Jaguar).

I suppose what it boils down to is how long it will take to fix the
ADF bugs. I haven't looked at these but, due to the nature of ADF
output files, ADF bugs are typically more complex than your average
one

Noel

On 27/03/07, Karol Langner <kar...@kn...> wrote:
> On Monday 26 of March 2007 20:26, Adam Tenderholt wrote:
> > What are the plans for version 0.7.1? It obviously will contain the
> > bug fixes we make to the ADF parser and the new functionality being
> > added to the Jaguar parser, as well as some of the changes I'll be
> > making to the methods. Is it appropriate to include the refactoring
> > in this release, or should it wait until 0.8?
> >
> > The reason I bring up this issue is how we should handle the svn
> > tree. If the refactoring is going into the 0.7.1 release, then I see
> > no reason to not merge it with trunk whenever you're ready. If this
> > is the case, then I'd like the most recent changes in trunk to be
> > merged with the 0.7 branch first as I'm trying to get Jaguar support
> > working better in PyMOlyze. If the refactoring goes into the 0.8
> > release, then you could simple rename that branch to 0.8 and we'll
> > push patches from trunk into that branch as necessary.
> >
> > Adam
>
> Good point, it's more logical to wait until after 0.7.1. Still, perhaps some
> of the smaller changes that don't alter the parser strusture (like automated
> logger messages in __setitem__) could be included in the next subrelease.
>
> Karol
>
> --
> written by Karol Langner
> Tue Mar 27 08:22:02 CEST 2007
>
> -------------------------------------------------------------------------
> 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
>

I checked this out some time ago, but not very comprehensively. This
time, I've compared the speed of:

   regular expressions
   in line
   line.find() == x
   line.startswith( ,x)
   line[x:y]

and line[x:y] is at least twice as fast as the other contenders. The
order (from memory) is roughly that listed above.

Regards,
   Noel