NECI Re-write - Revision history

import>Jss43: /* Tasks */

2008-02-25T18:04:46Z

Tasks

← Older revision		Revision as of 18:04, 25 February 2008
Line 41:		Line 41:

	Now I understand better the murkier details of Fortran memory management, perhaps the excitation generator storage could be handled better. I'm still not quite sure whether Fortran is flexible enough. --[[User:ajwt3\|alex]] 23:17, 19 February 2008 (GMT)		Now I understand better the murkier details of Fortran memory management, perhaps the excitation generator storage could be handled better. I'm still not quite sure whether Fortran is flexible enough. --[[User:ajwt3\|alex]] 23:17, 19 February 2008 (GMT)


	* Combine sym.inc, sym.F and the symmetry work in UMatCache (and other places?) into a symmetry module.--[[User:jss43\|james]] 18:55, 18 February 2008 (GMT)		* Combine sym.inc, sym.F and the symmetry work in UMatCache (and other places?) into a symmetry module.--[[User:jss43\|james]] 18:55, 18 February 2008 (GMT)

import>Jss43 at 18:03, 25 February 2008

2008-02-25T18:03:31Z

← Older revision		Revision as of 18:03, 25 February 2008
Line 46:		Line 46:

	* Go through each of the input modules and clearly comment what each variable does.--[[User:jss43\|james]] 18:55, 18 February 2008 (GMT)		* Go through each of the input modules and clearly comment what each variable does.--[[User:jss43\|james]] 18:55, 18 February 2008 (GMT)

	* Improved memory bookkeeping scheme. The current one using IP addresses isn't particularly reliable it appears when combined with the allocate statement. I will investigate alternatives. Alston has kindly let me look at his memory management system, and I'll try to borrow from that.--[[User:jss43\|james]] 18:55, 18 February 2008 (GMT)

	This would be advisable to be done before the guts of the rewrite. --[[User:ajwt3\|alex]] 23:17, 19 February 2008 (GMT)

	= Completed =		= Completed =
Line 59:		Line 55:
	* Local modifications to CPMD also stored in modules.		* Local modifications to CPMD also stored in modules.
	* Sets of defaults that can be called via a date.		* Sets of defaults that can be called via a date.
			* New memory book-keeping scheme in place. Currently the old routines just call the new ones with some of the options set to a default value.

	= Problems =		= Problems =

import>Ajwt3: /* Proposals */

2008-02-19T23:18:22Z

Proposals

← Older revision		Revision as of 23:18, 19 February 2008
Line 12:		Line 12:
	* Use the only specifier when declaring modules (for me, this is non-negotiable). --[[User:jss43\|james]] 15:21, 6 December 2007 (GMT)		* Use the only specifier when declaring modules (for me, this is non-negotiable). --[[User:jss43\|james]] 15:21, 6 December 2007 (GMT)
	* Transfer include files to modules? How far do we want to go on this? --[[User:jss43\|james]] 15:21, 6 December 2007 (GMT)		* Transfer include files to modules? How far do we want to go on this? --[[User:jss43\|james]] 15:21, 6 December 2007 (GMT)

			All the way! Lets get rid of those include files altogether. --[[User:ajwt3\|alex]] 23:18, 19 February 2008 (GMT)

	= Tasks =		= Tasks =

import>Ajwt3: /* Tasks */

2008-02-19T23:17:02Z

Tasks

← Older revision		Revision as of 23:17, 19 February 2008
Line 26:		Line 26:

	Has this been covered by George's work on the input?--[[User:jss43\|james]] 18:55, 18 February 2008 (GMT)		Has this been covered by George's work on the input?--[[User:jss43\|james]] 18:55, 18 February 2008 (GMT)

			Yes and no. I was hoping it would end up a bit more modular. I'm taking some drastic renaming options.
			e.g. Gone is the sysread module and out comes a System module which will contain all the relevant System input data, as well as the NECI-generated runtime data. --[[User:ajwt3\|alex]] 23:17, 19 February 2008 (GMT)

	* Modularize the basis. Again this will include lists of basis functions, energies and symmetries. Probably also the interfaces to access the 1- and 2-electron integrals. --[[User:ajwt3\|alex]] 16:36, 11 December 2007 (GMT)		* Modularize the basis. Again this will include lists of basis functions, energies and symmetries. Probably also the interfaces to access the 1- and 2-electron integrals. --[[User:ajwt3\|alex]] 16:36, 11 December 2007 (GMT)
Line 34:		Line 37:

	* Many have heard horror stories of the infamous excitation generators, but only Alex has confronted the beast - is there a way that these can be improved and made accessible to mere mortals, or are the problems with interfacing with CPMD too hard? - I'm not sure of the quality of the commenting in these, or the generality of their use either, but might be worth thinking about...--[[User:ghb24\|ghb24]] 17:51, 12 December 2007 (GMT)		* Many have heard horror stories of the infamous excitation generators, but only Alex has confronted the beast - is there a way that these can be improved and made accessible to mere mortals, or are the problems with interfacing with CPMD too hard? - I'm not sure of the quality of the commenting in these, or the generality of their use either, but might be worth thinking about...--[[User:ghb24\|ghb24]] 17:51, 12 December 2007 (GMT)

			Now I understand better the murkier details of Fortran memory management, perhaps the excitation generator storage could be handled better. I'm still not quite sure whether Fortran is flexible enough. --[[User:ajwt3\|alex]] 23:17, 19 February 2008 (GMT)


	* Combine sym.inc, sym.F and the symmetry work in UMatCache (and other places?) into a symmetry module.--[[User:jss43\|james]] 18:55, 18 February 2008 (GMT)		* Combine sym.inc, sym.F and the symmetry work in UMatCache (and other places?) into a symmetry module.--[[User:jss43\|james]] 18:55, 18 February 2008 (GMT)
Line 40:		Line 46:

	* Improved memory bookkeeping scheme. The current one using IP addresses isn't particularly reliable it appears when combined with the allocate statement. I will investigate alternatives. Alston has kindly let me look at his memory management system, and I'll try to borrow from that.--[[User:jss43\|james]] 18:55, 18 February 2008 (GMT)		* Improved memory bookkeeping scheme. The current one using IP addresses isn't particularly reliable it appears when combined with the allocate statement. I will investigate alternatives. Alston has kindly let me look at his memory management system, and I'll try to borrow from that.--[[User:jss43\|james]] 18:55, 18 February 2008 (GMT)

			This would be advisable to be done before the guts of the rewrite. --[[User:ajwt3\|alex]] 23:17, 19 February 2008 (GMT)

	= Completed =		= Completed =

import>Jss43 at 18:55, 18 February 2008

2008-02-18T18:55:45Z

Show changes

import>Jss43: /* Problems */

2007-12-18T16:18:52Z

Problems

← Older revision		Revision as of 16:18, 18 December 2007
Line 86:		Line 86:
	A further thought on this: a good practice would be to comment at the beginning of each routine what its purpose is (I know that this is done in many places, but certainly not all!).--[[User:jss43\|james]] 18:01, 12 December 2007 (GMT)		A further thought on this: a good practice would be to comment at the beginning of each routine what its purpose is (I know that this is done in many places, but certainly not all!).--[[User:jss43\|james]] 18:01, 12 December 2007 (GMT)

	* Scalability: we are (well, I am) looking at larger and larger systems. There are various places in the code (eg uhfdet), where a maximum system size is hard-coded in and causes seg faults etc. Allocatable arrays are the way forward...		* Scalability: we are (well, I am) looking at larger and larger systems. There are various places in the code (eg uhfdet), where a maximum system size is hard-coded in and causes seg faults etc. Allocatable arrays are the way forward...--[[User:jss43\|james]] 16:18, 18 December 2007 (GMT)

import>Jss43: /* Problems */

2007-12-18T16:18:35Z

Problems

← Older revision		Revision as of 16:18, 18 December 2007
Line 85:		Line 85:

	A further thought on this: a good practice would be to comment at the beginning of each routine what its purpose is (I know that this is done in many places, but certainly not all!).--[[User:jss43\|james]] 18:01, 12 December 2007 (GMT)		A further thought on this: a good practice would be to comment at the beginning of each routine what its purpose is (I know that this is done in many places, but certainly not all!).--[[User:jss43\|james]] 18:01, 12 December 2007 (GMT)

			* Scalability: we are (well, I am) looking at larger and larger systems. There are various places in the code (eg uhfdet), where a maximum system size is hard-coded in and causes seg faults etc. Allocatable arrays are the way forward...

import>Jss43: /* Problems */

2007-12-12T18:01:05Z

Problems

← Older revision		Revision as of 18:01, 12 December 2007
Line 84:		Line 84:
	The beauty of generating a programmers' reference from the source is that it reduces duplicate effort: reading the source is easy because of the commenting, and the documentation is complete from the comments. It's a neat solution and one I'll investigate.--[[User:jss43\|james]] 17:58, 12 December 2007 (GMT)		The beauty of generating a programmers' reference from the source is that it reduces duplicate effort: reading the source is easy because of the commenting, and the documentation is complete from the comments. It's a neat solution and one I'll investigate.--[[User:jss43\|james]] 17:58, 12 December 2007 (GMT)

	A further thought on this: a good practice would be to comment at the beginning of each routine what its purpose is (I know that this is done in many places, but certainly not all!).		A further thought on this: a good practice would be to comment at the beginning of each routine what its purpose is (I know that this is done in many places, but certainly not all!).--[[User:jss43\|james]] 18:01, 12 December 2007 (GMT)

import>Jss43: /* Problems */

2007-12-12T18:00:53Z

Problems

← Older revision		Revision as of 18:00, 12 December 2007
Line 83:		Line 83:

	The beauty of generating a programmers' reference from the source is that it reduces duplicate effort: reading the source is easy because of the commenting, and the documentation is complete from the comments. It's a neat solution and one I'll investigate.--[[User:jss43\|james]] 17:58, 12 December 2007 (GMT)		The beauty of generating a programmers' reference from the source is that it reduces duplicate effort: reading the source is easy because of the commenting, and the documentation is complete from the comments. It's a neat solution and one I'll investigate.--[[User:jss43\|james]] 17:58, 12 December 2007 (GMT)

			A further thought on this: a good practice would be to comment at the beginning of each routine what its purpose is (I know that this is done in many places, but certainly not all!).

import>Jss43: /* Problems */

2007-12-12T17:58:59Z

Problems

← Older revision		Revision as of 17:58, 12 December 2007
Line 82:		Line 82:
	It might well be worth rewritting the INPUT_DOC into a .tex file as well as the code comments and expanding it, so that maths can easily be inserted into it, and references sorted easily. I can give that a go if people think its worthwhile. --[[User:ghb24\|ghb24]] 17:51, 12 December 2007 (GMT)		It might well be worth rewritting the INPUT_DOC into a .tex file as well as the code comments and expanding it, so that maths can easily be inserted into it, and references sorted easily. I can give that a go if people think its worthwhile. --[[User:ghb24\|ghb24]] 17:51, 12 December 2007 (GMT)

	The beauty of generating a programmers' reference from the source is that it reduces duplicate effort: reading the source is easy because of the commenting, and the documentation is complete from the comments. It's a neat solution and one I'll investigate.		The beauty of generating a programmers' reference from the source is that it reduces duplicate effort: reading the source is easy because of the commenting, and the documentation is complete from the comments. It's a neat solution and one I'll investigate.--[[User:jss43\|james]] 17:58, 12 December 2007 (GMT)

← Older revision		Revision as of 23:17, 19 February 2008
Line 26:		Line 26:

	Has this been covered by George's work on the input?--[[User:jss43\|james]] 18:55, 18 February 2008 (GMT)		Has this been covered by George's work on the input?--[[User:jss43\|james]] 18:55, 18 February 2008 (GMT)

			Yes and no. I was hoping it would end up a bit more modular. I'm taking some drastic renaming options.
			e.g. Gone is the sysread module and out comes a System module which will contain all the relevant System input data, as well as the NECI-generated runtime data. --[[User:ajwt3\|alex]] 23:17, 19 February 2008 (GMT)

	* Modularize the basis. Again this will include lists of basis functions, energies and symmetries. Probably also the interfaces to access the 1- and 2-electron integrals. --[[User:ajwt3\|alex]] 16:36, 11 December 2007 (GMT)		* Modularize the basis. Again this will include lists of basis functions, energies and symmetries. Probably also the interfaces to access the 1- and 2-electron integrals. --[[User:ajwt3\|alex]] 16:36, 11 December 2007 (GMT)
Line 34:		Line 37:

	* Many have heard horror stories of the infamous excitation generators, but only Alex has confronted the beast - is there a way that these can be improved and made accessible to mere mortals, or are the problems with interfacing with CPMD too hard? - I'm not sure of the quality of the commenting in these, or the generality of their use either, but might be worth thinking about...--[[User:ghb24\|ghb24]] 17:51, 12 December 2007 (GMT)		* Many have heard horror stories of the infamous excitation generators, but only Alex has confronted the beast - is there a way that these can be improved and made accessible to mere mortals, or are the problems with interfacing with CPMD too hard? - I'm not sure of the quality of the commenting in these, or the generality of their use either, but might be worth thinking about...--[[User:ghb24\|ghb24]] 17:51, 12 December 2007 (GMT)

			Now I understand better the murkier details of Fortran memory management, perhaps the excitation generator storage could be handled better. I'm still not quite sure whether Fortran is flexible enough. --[[User:ajwt3\|alex]] 23:17, 19 February 2008 (GMT)


	* Combine sym.inc, sym.F and the symmetry work in UMatCache (and other places?) into a symmetry module.--[[User:jss43\|james]] 18:55, 18 February 2008 (GMT)		* Combine sym.inc, sym.F and the symmetry work in UMatCache (and other places?) into a symmetry module.--[[User:jss43\|james]] 18:55, 18 February 2008 (GMT)
Line 40:		Line 46:

	* Improved memory bookkeeping scheme. The current one using IP addresses isn't particularly reliable it appears when combined with the allocate statement. I will investigate alternatives. Alston has kindly let me look at his memory management system, and I'll try to borrow from that.--[[User:jss43\|james]] 18:55, 18 February 2008 (GMT)		* Improved memory bookkeeping scheme. The current one using IP addresses isn't particularly reliable it appears when combined with the allocate statement. I will investigate alternatives. Alston has kindly let me look at his memory management system, and I'll try to borrow from that.--[[User:jss43\|james]] 18:55, 18 February 2008 (GMT)

			This would be advisable to be done before the guts of the rewrite. --[[User:ajwt3\|alex]] 23:17, 19 February 2008 (GMT)

	= Completed =		= Completed =