Toric is the preferred code for ICRH heating simulation in Transp, but is maintained ( under subversion control ) at IPP Garching. Both Toric and the Transp interface routines are under active development, which can give rise to problems ensuring that Transp users with access to the pppl SVN repository, but not to IPP Garching, nevertheless obtain the latest approved version ( for Transp ). A related problem arises for users who maintain a version of Toric, obtained directly from IPP Garching, which they wish to use with Transp, for testing purposes - how can this be done with the minimum of overheads ?
The Toric code was copied to a standard Transp directory - source/toric5 - and linked to create a library lib/toric5.a, using the standard Transp procedures for generating makefiles. The source code was stored at pppl, using cvs. This required some changes to the Toric code -
- File extensions .F were changed to .for
- Toric used a non-standard argument list calling linpack, leading to incompatibility with the standard library linked with Transp
- Interface routines which used modules from Toric were added
This had the advantage that Toric could then be treated as a standard Transp component, but the disadvantage that the Transp version was a secondary copy, and could not be compared directly with the definitive source code at Garching. A csh script ( $SC/toric5_cmp ) was written, which compared a version checked out from IPP with the code in source/toric5, taking account of the file extension change. However, this is in effect a 3 stage operation - both the Toric and Transp directories must first be updated, to obtain an 'end-to-end' comparison of the different repositories.
To help keep track of the revision numbers, a module mSVNvn has been written; this stores the SVN status information for the Toric source directories, and is automatically updated ( by make ) provided that make is processing a directory checked out from Garching
Several additional changes have made, to enable less labour intensive code maintenance -
- The linpack name conflict has been resolved, by moving the non-standard Toric routines inside the module which calls them
- All the Transp interface code ( & some associated scripts ) have been added to the ( Toric ) src_transp directory
- The Toric makefile has a new target 'SlibtoricT' which includes the Transp interface routines in the standard library Ser/libtoric.a. ( This library may be still be used to create the standard serial Toric executable )
- The Transp makefile system has been upgraded, so that external libraries ( defined by environment variables ) are treated in the same way as the internal libraries under codesys/lib - in particular, 'make' implements dependencies in the same way for both classes of library. ( Tested at JET, but not yet committed to pppl - 24-Jan )
Consequently, Transp may now be linked directly with a standard Toric library, created either from the definitive 'trunk' code or any user branch.
Two systems are proposed - one for Transp production systems ( pshare ), and for sites without direct access to IPP, and another for developers working on Toric and Transp. Neither uses the existing lib/toric5 .
The Transp production code will use a version of Toric distributed as a .tgz file. This would be created from the main 'trunk ' version of Toric, & contain the source & makefile. It is unpacked ( to codesys/other/Toric ) & the Toric library is then built using the standard Toric makefile.
The distribution is stored in source/toric_IPP_vns/Toric_<nnn>.tgz, where <nnn> is the overall SVN revision number ( at IPP ) when the code was checked out. The Toric source contains a file SvnTable.Fincl which stores the SVN revision numbers for each Toric source file, so the code in use can be traced back to the original IPP sources ( see the mSVNvn writeup ). Since individual source files contained in the archive cannot easily be altered, the revision numbers in SvnTable are likely to be correct.
The script toric_setup.pl has been written to export, import and build Toric as described above - see the writeup for more information. The directory codesys/other/Toric/base/Linux/Ser must be included in $TRANSP_LIB_PATH so that uplink can find libtoric.a.
Developers of both Transp and Toric can link Transp with any version of Toric, by
- Executing ">make SlibtoricT" in /src, to add the Transp interface routines to the Toric library ( NB this assumes that the same compiler, external libraries etc are used for both codes )
- Adding the Toric library location to $TRANSP_LIB_PATH
Specifically for pppl development, the code under branches/TRANSP ( at IPP ) has been updated to the current trunk revision, and some additional routines from source/toric5 have been added. While the code is now the same, subversion does not preserve revision numbers when merging between branches ( the actual numbers are listed here ). Provided that the TRANSP branch code is merged back to the trunk, and then checked out to create an updated archive file, there is no reason for the production system to be concerned with the revision numbers of the TRANSP branch, so in practice this should not be a problem.
Since the pppl repository will no longer contain Toric source in separate files, the code management activities can all be performed on the Garching repository, using standard SVN utilities. In particular, svn diff will compare code on different branches, and svn merge will transfer files from one branch to ( a checked out copy of ) another. These operations will all be logged.
The 'production' copy, under codesys/other, can be compared ( using diff ) with any other checked out copy, since the file extensions are no longer different. Provided that the code is not altered after being unpacked from the .tgz file, the overall revision number is sufficient to label the version in use.
The proposed system uses the standard Toric makefile ( with a perl wrapper ) to build the Toric library, and standard SVN commands to maintain the code. The revision numbers of the Transp production code can be reliably maintained using the SvnTable mechanism, and the code itself can be compared directly with any other version checked out from Garching. This should reduce the effort needed to maintain the Transp version.
The tar archive mechanism might in the future be replaced by a mirror ( at pppl ) of the IPP Garching repository, should the Toric custodians agree. This could easily be accomodated, by checking out code from the mirror repository to codesys/other/Toric/.. and using the library definition symbols as proposed above.