Index: /tags/asap-4.4.0+atnf2/CHANGELOG =================================================================== --- /tags/asap-4.4.0+atnf2/CHANGELOG (revision 3150) +++ /tags/asap-4.4.0+atnf2/CHANGELOG (revision 3150) @@ -0,0 +1,243 @@ +Changelog +========= + +Release 4.2.0 [2012-07-02] + +* #291: add set_sourcename +* #293: rework history to allow access to large history +* #293:method to drop_history +* #291: add some more info to freq_align log +* #289: added ability to set Tsys, both for scalar and vector values +* #288: implemented dropping of xpols as scantable.drop_xpol() +* optimisation of baselining functions for scantable. + +Release 4.1.0 [2012-10-10] + +* reworked build system to work as 'normal' python package +* Ticket #257 fixed bug in average_time introduced in 4.0 +* experimental merging of IFs +* speed ups +* work with to ipython>=0.11 +* Ticket #269 fixed regression of reference scan detection for Hobart data +* work under OS X 10.7/10.8 +* fixed logging control through rcParams +* fix for frequency_alignment +* Ticket #264 silence skydip. +* Ticket #265 fix summary for multiple IF chains +* Ticket #280 fix SDFITS frequency frame output + +Release 4.0.0 [2011-10-05] + +* Ticket #251 fixed scantable.scale broken behaviour when selection was set +* Ticket #250 fixed average_time's change in behaviour +* Ticket #249 fixed backwards compatibility with existing scantable +* speed up of scantable.summary which has changed the + output of the summary information +* various changes to MS export + +Release 3.1.0 [2011-08-10] + +* additional baseline fitting, e.g. sinusoid, cspline +* speed ups in various areas +* plotter metadata display +* interactive statistics +* improved packaging +* matplotlib >= 1.0 support +* better support for MeasurementSet data +* more statistics e.g. max/min abcissa +* row-based flagging +* apply fft to spectra +* improved mask handling + +Release 3.0.0 [2010-05-06] + +* BEWARE: added asap2to3 which converts '.asap' files from version 2 to + version 3 +* Ticket #183 Added scantable.get_weather +* Ticket #181 Added work-around for casacore bug in saving tables with + selection +* Ticket #178 Added opacity_model based on miriad's atmospheric model +* Ticket #177 Added function skydip to determine opacities. +* Ticket #172 Fixed non-working scantable.resample +* Ticket #155 Better output filenames. Ignore non-existsing + beams/pols/ifs/scans +* Ticket #157 numpy >= 1.1 support +* Ticket #158 fixed plotter.set_font +* Ticket #160 Aspect ratio of plotter is customisable now +* Ticket #163 fixed for scantable.set_sourcetype +* Ticket #164 Upgrade note in wiki FAQ +* Ticket #165 Handle non-parallactified polarimtery data (if supported in + rpfits) +* Ticket #167 Added running polynomial filter to scantable.smooth +* Ticket #168 Data exported via scantable.save now contains correct frequency + or velocity information +* Ticket #169 Simplified selection of data +* Ticket #46 Interactive lag flagging +* Ticket #170 Provided access to frequency coordinate information via + scantable.get_coordinate +* Added OS X 10.5 Disk image installer +* Added support for OS X 10.6 +* Interactive plotting annotations via optional argument interactive=True +* Interactive creation of masks on the plotter - plotter.create_mask +* Tidy up date range in asapplotter.plotazel/plotpointings +* support for gcc-4.4 + +Release 2.3.1 [2009-03-25] + +* Ticket #154 Flagged data wasn't hnoured in fitting +* Ticket #153 plotter.plot_lines fixed for matplotlib >= 0.98 +* Ticket #90 Support integer values for frequencies/errors/intensities + +Release 2.3.0 [2009-03-13] + +* Ticket #150 fix in casacore for frequency frame conversions +* Ticket #151 added rc parameter and function set_sourcetype to identify + on/off scans +* Ticket #78/#112 Resolved the issue with random errors occuring under linux + for large + data files, which corrupted the identifaction of off scans +* Ticket #149 Fixed the bug causing spectral line search to go into an + infinite loop in some rare circumstances +* Ticket #110 Added export to CLASS readable FITS files + scantable.save("myfile.fits", "CLASS") +* Ticket #142 Fix of the frequency alignment for long observations +* Ticket #133 allow supression of history in the scantable via rc parameters +* Ticket #109 source direction for Hobart data +* Ticket #115 added running median to scantable.(smooth(kernel='rmedian') +* Ticket #148 opacity correction wasn't applied to TSYS +* Ticket #135 quotient detection failure for specific source names +* Ticket #140 NaN values not handled - added scantable.flag_nans to ensure + that the NaN are flagged +* added python iterator access to scantable rows +* made functions available to directly manipulate spectra + scantable.get/set_spectrum +* upgrade to support ipython >= 0.8.1 +* support gcc-4.3 +* use scons >= 1.1.0 +* update to latest livedata I/O functions +* add WCS info to the exported text files + + +Release 2.2.0 [2007-05-02] + +* fix for losing flags in average_time +* changed asap_update_data to contact ATNF ftp server directly +* Documentation updates +* changed to use casacore instead of aips++ +* auto_quotient uses on/off pair detection by default, 'time' the old mode can also + be accessed +* Ticket #107 added function to shift reference pixel +* Ticket #106 added function to retrieve integration times +* Ticket #105 added Parkes K-band gain curve +* Ticket #102 fixed wrong polarisation type in case of 'circular' +* Ticket #104/94 fixed segmentation fault for time average if all channels are flagged +* Ticket #98 AIPSPATH is honoured if set +* Ticket #101 fixed set_restfreqs not working for IFs not starting at 0 +* Ticket #97 fixed error in opacity calculation + +Minor Release 2.1.1 [2006-11-09] + +* fix for Ticket #88 - numpy masks +* better TAB completion for ipython (handles quotes, don't list private members) +* Fix for Ticket #81 = scanatble.stats output as list +* ticket #64 - speed up of auto_poly_baseline +* fix for ticket #89 - export of IF sub-selections +* fix for Ticket #83 - export to ms2 crashed asap +* added file suffix support for name.rpf.1 etc. + +Release Version 2.1.0 [2006-09-11] + +* Processing of Multibeam MX data +* Line Catalogs for both plotting and setting rest frequencies +* median averaging +* support of circular polarisations +* binaries for fedora (core 3/5), debian, ubuntu, OSX (ppc,intel) +* text/arrow/line annonations for plotter +* export of fit parameters to text file +* disk based scantables for large data sets +* re-introduced custom quotients +* fixed major fitter bug +* fft flagging +* full support for MOPS data + +Release Version 2.0 [2006-04-28] + +* Major rework of internal data representation. Now supports IFs with + different number of spectral channels. This has minimal effect on the + user interface. +* Creation of a "selector" object used for data selection. Allow slicing of + data in beam, IF, polarisation as well as selection via header values + (e.g. Tsys). set_cursor is now invalid use set_selection instead. +* Scantables can be merged +* scantable.lines() has been removed. Set rest frequencies by value + (This will change in 2.1) +* Multiple data files (e.g. rpf) can be read into a single scantable +* Polarmetric infrastructure improved to support most observing styles + (linear feeds only) +* ability to convert to/store as Stokes +* Plotter can now only plot from a single scantable (use merge if necessary) +* ASCII (text) spectral output changed to be more usable +* Can change the source position coordinate frame +* Bug fixes +* auto_quotient is doing "closest in time reference" +* option auto-align in velocity when using average_time +* flagging on a per channel base + + +(Release 1.2.2) + +* channel based flagging +* Added get_elevation, azimuth and parangle +* Added swap_lineas & invert_phase +* added allaxes arg to poly_baseline +* Request: added pager throuput for history and summary +* Request: Log meesage on auto_quotient() +* Bug Fix: plotter -set_mode("s","i"). +* Bug fix: plotter -autoscale abcissa limits from all spectra for stacking. + +Release Version 1.2.1 [2005-12-06] + +* scantable.recalc_azel - recalcualte azimuth and elevation based on +* pointing Bug fix: plotter - set_layout got overwritten byt plot; row + cursor not honoured in _plot_time + + +Release Version 1.2 [2005-11-30] + +Code changes +------------ +* frequency switching: scantable.freq_switch() +* get a list of sourcenames: scantable.get_sourcename() +* build quotients from matched _S/_R pairs or 1*_R/n*_S automatically +* plotting control: plotter.set_colors(), plotter.set_linestyles(), + plotter.set_linewidth() all also via .asaprc parameters +* non-interactive (non-GUI) plotting +* ASAP Online (Mopra) Monitor web interface (mini pipeline) +* user control of multi-panel: plotter.set_layout() +* histogram plotting: part of linestyles +* plugins: via ~/.asap/userfuncs.py +* plotter panel control: rcParams['plotter.ganged'] +* usability: reworked the whole asap startup scripts, now all user adjustable + through ~/.asap/ + +Todos/pending +-------------- +* documentation update: should be finished by 2005-11-25 +* cookbook +* release 1.2: 2005-11-30 + +Major non-targets, resulting from requirements/targets +----------------------------------------------------- +* asap logging, which can be turned on and off through .asaprc/rcParams + (from asapmon) +* Data container v2 design study and document ( moved from cycle II ) + +Not Addressed +------------- + +(deferred to cycle II, as described in support document) + +* Flexible data selection +* "Merging of spectra" (concatenating scantables) + +* public defect tracking system Index: /tags/asap-4.4.0+atnf2/CMakeLists.txt =================================================================== --- /tags/asap-4.4.0+atnf2/CMakeLists.txt (revision 3150) +++ /tags/asap-4.4.0+atnf2/CMakeLists.txt (revision 3150) @@ -0,0 +1,805 @@ +### +# CMakeLists.txt for ASAP module +### + +# minimum requirement for cmake version +cmake_minimum_required( VERSION 2.8 ) + +add_definitions ("-DUseCasacoreNamespace") + +# options +option (CXX11 "Compile as C++11 if possible" YES) + +option( USE_LIBCASACORE + "set ON to use libcasacore.so instead of libcasa_*.so" + OFF ) +option( STANDALONE + "set ON to build standalone mode" + OFF ) +option( PKSMS + "set ON to diable to build PKSMS2reader/writer" + OFF ) +message( STATUS "CXX11 = " ${CXX11} ) +message( STATUS "USE_LIBCASACORE = " ${USE_LIBCASACORE} ) +message( STATUS "STANDALONE = " ${STANDALONE} ) +message( STATUS "PKSMS = " ${PKSMS} ) + +# Use casapy's fork of casacore +if ( NOT STANDALONE ) + add_definitions( -DUSE_CASAPY ) + option( PYTHON_SHARED_LINKER_FLAGS + "set extra LINK_FLAGS for python shared objects and libraries" + OFF ) +endif () + +# Define compiler paths on OSX 10.5. This must be done before invoking project() +if( APPLE ) + if( EXISTS /opt/casa/core2-apple-darwin8/3rd-party/bin/gfortran ) + set( CMAKE_Fortran_COMPILER /opt/casa/core2-apple-darwin8/3rd-party/bin/gfortran ) + set( CMAKE_CXX_COMPILER /opt/casa/core2-apple-darwin8/3rd-party/bin/g++ ) + elseif( EXISTS /opt/local/bin/gfortran ) + set( CMAKE_Fortran_COMPILER /opt/local/bin/gfortran ) + elseif( EXISTS /opt/local/bin/gfortran-mp-4.4 ) + set( CMAKE_Fortran_COMPILER /opt/local/bin/gfortran-mp-4.4 ) + if( EXISTS /opt/local/bin/g++-mp-4.4 ) + set( CMAKE_CXX_COMPILER /opt/local/bin/g++-mp-4.4 ) + endif() + endif() +endif() + + +# project name is ASAP +project( ASAP ) + + +# +# build type and their flags +# +# CMAKE_BUILD_TYPE (Release, Debug, RelWithDebInfo, MinSizeRel, Profile) +# default is RelWithDebInfo +# +if ( NOT CMAKE_BUILD_TYPE ) + set( CMAKE_BUILD_TYPE RelWithDebInfo ) +endif() +message( STATUS "CMAKE_BUILD_TYPE = " ${CMAKE_BUILD_TYPE} ) + +# flags for Debug build +if ( CMAKE_BUILD_TYPE STREQUAL Debug ) + add_definitions( -DAIPS_DEBUG ) +endif() +set( CMAKE_CXX_FLAGS_DEBUG " -O0" ) +if (NOT "${CMAKE_CXX_COMPILER_ID}" STREQUAL "Intel") + set( CMAKE_CXX_FLAGS_DEBUG "-ggdb3 -fno-omit-frame-pointer" ) +endif( ) + +# flags for Profile build +set( CMAKE_CXX_FLAGS_PROFILE "-g -O2 -pg -fprofile-arcs -fno-omit-frame-pointer" ) + + +# flags for Release and MinSizeRel build +if ( APPLE ) + # OS X + # On 10.8 (Darwin-12) with llvm clang, -s option for linker + # causes link error. This may be because that -s option is + # obsolete and is different behavior from Linux. + if ( CMAKE_SYSTEM MATCHES ^Darwin-11 AND NOT LLVMCOMPILER ) + set( CMAKE_SHARED_LINKER_FLAGS_RELEASE "-Wl,-s" ) + set( CMAKE_EXE_LINKER_FLAGS_RELEASE "-Wl,-s" ) + set( CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL "-Wl,-s" ) + set( CMAKE_EXE_LINKER_FLAGS_MINSIZEREL "-Wl,-s" ) + endif() +else() + # Linux + set( CMAKE_SHARED_LINKER_FLAGS_RELEASE "-Wl,-s" ) + set( CMAKE_EXE_LINKER_FLAGS_RELEASE "-Wl,-s" ) + set( CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL "-Wl,-s" ) + set( CMAKE_EXE_LINKER_FLAGS_MINSIZEREL "-Wl,-s" ) +endif() + +if ( DEFINED CXX_FLAGS_TAIL_END ) + set( CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} ${CXX_FLAGS_TAIL_END}" ) + set( CMAKE_CXX_FLAGS_RELWITHDEBINFO "${CMAKE_CXX_FLAGS_RELWITHDEBINFO} ${CXX_FLAGS_TAIL_END}" ) + set( CMAKE_CXX_FLAGS_MINSIZEREL "${CMAKE_CXX_FLAGS_MINSIZEREL} ${CXX_FLAGS_TAIL_END}" ) + set( CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} ${CXX_FLAGS_TAIL_END}" ) + set( CMAKE_CXX_FLAGS_PROFILE "${CMAKE_CXX_FLAGS_PROFILE} ${CXX_FLAGS_TAIL_END}" ) +endif() + +# default flags +if( APPLE ) + set( DEFAULT_CXX_FLAGS "-pipe -Wall -Wextra -Wno-comment" ) +else () + set( DEFAULT_CXX_FLAGS "-pipe -Wall -Wextra -Wno-comment" ) +endif() +if (NOT "${CMAKE_CXX_COMPILER_ID}" STREQUAL "Intel") + set( DEFAULT_CXX_FLAGS "${DEFAULT_CXX_FLAGS} -Wcast-align" ) + if (NOT APPLE) + set( DEFAULT_CXX_FLAGS "${DEFAULT_CXX_FLAGS} -Wno-non-template-friend" ) + endif( ) +endif( ) + +# additional flag for fortran complex div/mul rules. +include( CheckCXXCompilerFlag ) +include( CheckCCompilerFlag ) +check_cxx_compiler_flag( -fcx-fortran-rules HAS_GXX_FORTRAN_RULES ) +check_c_compiler_flag( -fcx-fortran-rules HAS_GCC_FORTRAN_RULES ) +if( HAS_GXX_FORTRAN_RULES ) + set( DEFAULT_CXX_FLAGS "-fcx-fortran-rules ${DEFAULT_CXX_FLAGS}") +endif() +if( HAS_GCC_FORTRAN_RULES ) + set( CMAKE_C_FLAGS "-fcx-fortran-rules ${CMAKE_C_FLAGS}" ) +endif() + +# Detect if the compiler supports C++11 if we want to use it. +if (CXX11) + if ((CMAKE_COMPILER_IS_GNUCXX AND NOT ${CMAKE_CXX_COMPILER_VERSION} VERSION_LESS 4.6) OR + (CMAKE_CXX_COMPILER_ID STREQUAL "Clang" AND NOT ${CMAKE_CXX_COMPILER_VERSION} VERSION_LESS 4.3)) + set(DEFAULT_CXX_FLAGS "${DEFAULT_CXX_FLAGS} -std=c++11 -DCXX11") + else() + option(CXX11 "" NO) + endif() +endif() + +if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Intel") + ## setting intel libraries with e.g. + ## + ## find_library( INTEL_IRNG irng HINTS ${INTEL_PATH} ) + ## + ## causes CMAKE to substitute fully qualified paths which makes + ## python shared object unrelocatable in the case of libirng.so + ## + get_filename_component(INTEL_PATH ${CMAKE_CXX_COMPILER} DIRECTORY) + set(INTEL_LIB_PATH ${INTEL_PATH}/../lib/intel64) + set(INTEL_LIBS -limf -lsvml -lirng -lintlc -lifport -lifcore -liomp5) + set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,-rpath,${INTEL_LIB_PATH}") + set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -Wl,-rpath,${INTEL_LIB_PATH}") +endif() + +find_package( OpenMP ) +if( OPENMP_FOUND ) + if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Intel") + set(DEFAULT_CXX_FLAGS "${DEFAULT_CXX_FLAGS} -qopenmp") + else( ) + set( DEFAULT_CXX_FLAGS "${DEFAULT_CXX_FLAGS} ${OpenMP_CXX_FLAGS}" ) + endif( ) +endif() + +# environment dependent settings +message( STATUS "CMAKE_SYSTEM = " ${CMAKE_SYSTEM} ) +message( STATUS "CMAKE_SYSTEM_PROCESSOR = " ${CMAKE_SYSTEM_PROCESSOR} ) +if( APPLE ) + set( SO dylib ) + if( CMAKE_SYSTEM MATCHES ^Darwin-10 OR + CMAKE_SYSTEM MATCHES ^Darwin-11 ) + if( NOT archflag ) + if( EXISTS /opt/casa/01 ) + set( archflag x86_64 ) + elseif( EXISTS /opt/casa/darwin11 ) + set( archflag x86_64 ) + elseif( EXISTS /opt/casa/darwin10-64b ) + set( archflag x86_64 ) + elseif( EXISTS /opt/casa/core2-apple-darwin10 ) + set( archflag i386 ) + else() + set( archflag x86_64 ) + endif() + endif() + if( archflag STREQUAL x86_64 ) + add_definitions( -DAIPS_64B ) + endif() + execute_process( COMMAND ${CMAKE_CXX_COMPILER} --version + COMMAND head -1 + COMMAND perl -pe "s|.*?(\\d+\\.\\d+)\\.\\d+$|$1|" + OUTPUT_VARIABLE _cxx_version + OUTPUT_STRIP_TRAILING_WHITESPACE ) + if( NOT _cxx_version STREQUAL "4.4" ) + set( DEFAULT_CXX_FLAGS "${DEFAULT_CXX_FLAGS} -arch ${archflag}" ) + endif() + endif() +elseif( CMAKE_SYSTEM_NAME STREQUAL Linux ) + set( SO so ) + add_definitions( -DAIPS_LINUX ) + if( CMAKE_SYSTEM_PROCESSOR STREQUAL x86_64 ) + add_definitions( -DAIPS_64B ) + set( DEFAULT_CXX_FLAGS "${DEFAULT_CXX_FLAGS} -Wno-deprecated" ) + else() + set( DEFAULT_CXX_FLAGS "${DEFAULT_CXX_FLAGS} -Wno-deprecated -Woverloaded-virtual" ) + endif() +endif() + +# set flags for cpp compiler +set( CMAKE_CXX_FLAGS ${DEFAULT_CXX_FLAGS} ) + + +# +# casacore definitions +# +set( CASACORE_DEFINITIONS ${CASACORE_DEFINITIONS} + -DCASA_USECASAPATH + -DCASACORE_NEEDS_RETHROW + -DAIPS_STDLIB + -DAIPS_AUTO_STL + -D_GNU_SOURCE ) + +if( CMAKE_SYSTEM_NAME STREQUAL Linux ) + set( CASACORE_DEFINITIONS ${CASACORE_DEFINITIONS} + -D_FILE_OFFSET_BITS=64 + -D_LARGEFILE_SOURCE + ) +endif() + +add_definitions( ${CASACORE_DEFINITIONS} ) + +# +# mode specific settings +# +# STANDALONE=ON standalone build +# STANDALONE=OFF build with casa +# +set( CMAKE_MODULE_PATH "${CMAKE_MODULE_PATH};${CMAKE_SOURCE_DIR}/cmake" ) +message( STATUS "CMAKE_MODULE_PATH = " ${CMAKE_MODULE_PATH} ) +if( STANDALONE ) + include( standalone ) +else() + include( withcasa ) +endif() + +message( STATUS "CMAKE_INSTALL_PREFIX = " ${CMAKE_INSTALL_PREFIX} ) + + +# +# casacore +# +unset( CASACORE_INCLUDE_DIR CACHE ) +unset( CASACORE_LIBRARIES CACHE ) +if( NOT USE_LIBCASACORE ) + # use casacore libraries + set( _includename casa/aipsdef.h ) + find_path( CASACORE_INCLUDE_DIR ${_includename} + PATHS ${CASACORE_PATHS} ${CMAKE_INSTALL_PREFIX} + PATH_SUFFIXES include include/casacore + NO_DEFAULT_PATH ) + find_path( CASACORE_INCLUDE_DIR ${_includename} ) + if( CASACORE_INCLUDE_DIR MATCHES "NOTFOUND$" ) + message( FATAL_ERROR "${_includename} could not be found. Please check!" ) + endif() + set( CASACORE_LIBS casa + coordinates + fits + images + lattices + measures + mirlib + ms + msfits + scimath + scimath_f + tables + python ) + set( _casacore_libs "" ) + foreach( _a ${CASACORE_LIBS} ) + set( _libname libcasa_${_a}.${SO} ) + unset( _casacore_lib CACHE ) + find_library( _casacore_lib ${_libname} + PATHS ${CASACORE_PATHS} + PATH_SUFFIXES lib64 lib ) + if( _casacore_lib MATCHES "NOTFOUND$" ) + message( FATAL_ERROR "${_libname} could not be found. Please check!" ) + else() + #list( APPEND _casacore_libs casa_${_a} ) + list( APPEND _casacore_libs ${_casacore_lib} ) + endif() + endforeach() + set ( _libname libcomponents.${SO} ) + unset( _casacore_lib CACHE ) + find_library( _casacore_lib ${_libname} + PATHS ${CASACORE_PATHS} + PATH_SUFFIXES lib64 lib ) + if( _casacore_lib MATCHES "NOTFOUND$" ) + message( FATAL_ERROR "${_libname} could not be found. Please check!" ) + else() + list( APPEND _casacore_libs ${_casacore_lib} ) + endif() + set( CASACORE_LIBRARIES ${_casacore_libs} ) +else() + # use libcasacore + set( _libname libcasacore.${SO} ) + find_library( CASACORE_LIBRARIES ${_libname} + PATHS ${CASACORE_PATHS} + PATH_SUFFIXES lib64 lib ) + if( CASACORE_LIBRARIES MATCHES "NOTFOUND$" ) + message( FATAL_ERROR "${_libname} could not be found. Please check!" ) + endif() + set( _includename casa/aipsdef.h ) + string( REGEX REPLACE /[^/]+/[^/]+/?$ "" _coreroot ${CASACORE_LIBRARIES} ) + find_path( CASACORE_INCLUDE_DIR ${_includename} + PATHS ${_coreroot} + PATH_SUFFIXES include include/casacore + NO_DEFAULT_PATH ) + find_path( CASACORE_INCLUDE_DIR ${_includename} + PATHS ${CASACORE_PATHS} + PATH_SUFFIXES include include/casacore + NO_DEFAULT_PATH ) + find_path( CASACORE_INCLUDE_DIR ${_includename} ) + if( CASACORE_INCLUDE_DIR MATCHES "NOTFOUND$" ) + message( FATAL_ERROR "${_includename} could not be found. Please check!" ) + endif() +endif() +message( STATUS "CASACORE_LIBRARIES = " ${CASACORE_LIBRARIES} ) +message( STATUS "CASACORE_INCLUDE_DIR = " ${CASACORE_INCLUDE_DIR} ) +unset( USE_LIBCASACORE CACHE ) + +# +# Python +# +if( STANDALONE ) + include( FindPythonLibs ) + if( NOT PYTHONLIBS_FOUND ) + message( FATAL_ERROR "Python could not be found. Please check!" ) + endif() + + # Define pyroot + string( REGEX REPLACE "/[^/]+/[^/]+/?$" "" pyroot ${PYTHON_INCLUDE_DIRS} ) + + # find numpy + string( REGEX MATCH [0-9].[0-9] PYTHONV ${PYTHON_INCLUDE_DIRS} ) + string( REPLACE "." "" PV ${PYTHONV} ) + find_path( NUMPY_INCLUDE_DIR numpy/npy_interrupt.h + PATHS + ${pyroot}/lib/python${PYTHONV}/site-packages/numpy/core + ${pyroot}/Library/Frameworks/Python.framework/Versions/${PYTHONV} + ${pyroot}/Library/Frameworks/Python.framework/Versions/${PYTHONV}/lib/python${PYTHONV}/site-packages/numpy/core + PATH_SUFFIXES include ) + if( NUMPY_INCLUDE_DIR MATCHES "NOTFOUND$" ) + message( FATAL_ERROR "numpy/npy_interrupt.h could not be found. Please check!" ) + endif() + list( APPEND PYTHON_INCLUDE_DIRS ${NUMPY_INCLUDE_DIR} ) + + set( PYTHON_DEFINITIONS ${PYTHON_DEFINITIONS} + -DPYTHONROOT=\"${pyroot}\" + -DPYTHONVER=\"${PYTHONV}\" + -DPYVERSION=${PV} ) +else() + # with CASA + if( NOT PYTHON_FOUND ) + if ( NOT PYTHON_LIBNAME ) + #set( _names 2.9 2.8 2.7 2.6 2.5.2 2.5 ) + set( _names 2.7 2.6 2.5.2 2.5 ) + # OSX 10.7 has Python2.7 by default. CASA has't yet supported python > 2.6 anyway. + # (The library named libpython.2.5.2.dylib seems to exist only in the CASA world.) + else() + set( _names ${PYTHON_LIBNAME} ) + endif() + + set( _found False ) + foreach( _v ${_names} ) + + casa_find( + PYTHON${_v} + PREFIX_HINTS ${PYTHON_ROOT_DIR} + LIBS python${_v} + NO_REQUIRE + ) + + if( PYTHON${_v}_FOUND ) + set( PYTHON_LIBNAME ${_v} ) + set( _found True ) + break() + endif() + + endforeach() + + if( NOT _found ) + message( FATAL_ERROR "Could not find any PYTHON library with version one of ${_names}. Please check!" ) + endif() + + endif() + + if( NOT PYTHON_LIBNAME ) + # Found Python, but PYTHON_LIBNAME is undefined, that is impossible. + message( FATAL_ERROR "The variable PYTHON_LIBNAME is undefined. Most likely, CMake's cache is out of date and you need to redetect your PYTHON installation (\"cmake -U PYTHON*\")") + endif() + + string( SUBSTRING ${PYTHON_LIBNAME} 0 3 PYTHONV ) + string( REPLACE "." "" PV ${PYTHONV} ) + set( python_library python${PYTHON_LIBNAME} ) + + # Form the Python install prefix by stripping away "lib/libpython2.5.2.dylib" (example) from + # the full python library path + string( REGEX MATCH "/lib(64)?/lib${python_library}" _match ${PYTHON${PYTHON_LIBNAME}_LIBRARIES} ) + if( _match ) + string( REGEX REPLACE "/lib(64)?/lib${python_library}.*" "" python_prefix ${PYTHON${PYTHON_LIBNAME}_LIBRARIES} ) + else() + # Python library was not in a lib(64) directory! + message( WARNING "Python library path \"${PYTHON${PYTHON_LIBNAME}_LIBRARIES}\" does not contain \"/lib(64)/lib${python_library}\"" ) + set( python_prefix ${casa_packages} ) + endif() + + # + # For some unknown reason cmake sets the /usr for Lion + # + if( APPLE ) + set( python_prefix ${casa_packages} ) + endif() + + # The python version and prefix is known, do the actual search + if( NOT PYTHON_FOUND ) + message( STATUS "Looking for PYTHON version ${PYTHONV}.x in ${python_prefix}" ) + endif() + + casa_find( PYTHON + VERSION 2.5 # minimum required + INCLUDES Python.h + numpy/npy_interrupt.h # for numpy + INCLUDES_SUFFIXES python${PYTHONV} + PREFIX_HINTS + ${PYTHON_ROOT_DIR} + ${NUMPY_ROOT_DIR} + ${python_prefix}/lib/python${PYTHONV}/site-packages/numpy/core + ${python_prefix}/Library/Frameworks/Python.framework/Versions/${PYTHONV} + ${python_prefix}/Library/Frameworks/Python.framework/Versions/${PYTHONV}/lib/python${PYTHONV}/site-packages/numpy/core + LIBS ${python_library} + CPP_VERSION PY_VERSION ) + + # Store PYTHON_LIBNAME in the cache + set( PYTHON_LIBNAME ${PYTHON_LIBNAME} CACHE STRING "Python major and minor version to use" FORCE ) + + # Define pyroot to two directory levels above Python.h. + string( REGEX REPLACE "/[^/]+/[^/]+/?$" "" pyroot ${PYTHON_Python.h} ) + + set( PYTHON_DEFINITIONS ${PYTHON_DEFINITIONS} + -DAIPSROOT=\"${CMAKE_SOURCE_DIR}\" + -DAIPSARCH=\"${arch}\" + -DAIPSSITE=\"garching\" + -DPYTHONROOT=\"${pyroot}\" + -DPYTHONVER=\"${PYTHONV}\" + -DPYVERSION=${PV} ) +endif() +message( STATUS "PYTHON_INCLUDE_DIRS = " ${PYTHON_INCLUDE_DIRS} ) +message( STATUS "PYTHON_LINRARIES = " ${PYTHON_LIBRARIES} ) +message( STATUS "PYTHONV = " ${PYTHONV} ) + + +# +# DL +# +set( DL_LIBRARIES ${CMAKE_DL_LIBS} CACHE STRING "dl libraries" FORCE ) +if( DL_LIBRARIES STREQUAL "dl" ) + set( DL_LIBRARIES "-ldl" CACHE STRING "dl libraries" FORCE ) +endif() +message( STATUS "DL_LIBRARIES = " ${DL_LIBRARIES} ) + + +# +# BLAS +# +find_library( BLAS_LIBRARIES libblas.${SO} ) +if ( BLAS_LIBRARIES MATCHES "NOTFOUND$" ) + message( FATAL_ERROR "blas could not be found. Please check!" ) +endif() +message( STATUS "BLAS_LIBRARIES = " ${BLAS_LIBRARIES} ) + + +# +# LAPACK +# +find_library( LAPACK_LIBRARIES liblapack.${SO} ) +if ( LAPACK_LIBRARIES MATCHES "NOTFOUND$" ) + message( FATAL_ERROR "lapack could not be found. Please check!" ) +endif() +message( STATUS "LAPACK_LIBRARIES = " ${LAPACK_LIBRARIES} ) + + +# +# Boost +# +set( boost_components python ) +if( NOT STANDALONE ) + set( boost_components ${boost_components} system ) +endif() +find_package( Boost REQUIRED ${boost_components} ) +if( NOT Boost_FOUND ) + message( FATAL_ERROR "Boost could not be found. Please check!" ) +endif() + +if(CMAKE_SYSTEM_NAME STREQUAL Linux AND Boost_LIBRARIES) + if(EXISTS "/usr/lib64/libicuuc.so") + set( Boost_LIBRARIES "${Boost_LIBRARIES};/usr/lib64/libicuuc.so" ) + endif( ) + if(EXISTS "/usr/lib64/libicudata.so") + set( Boost_LIBRARIES "${Boost_LIBRARIES};/usr/lib64/libicudata.so" ) + endif( ) + if(EXISTS "/usr/lib64/libicui18n.so") + set( Boost_LIBRARIES "${Boost_LIBRARIES};/usr/lib64/libicui18n.so" ) + endif( ) + message(STATUS "Boost_LIBRARIES=${Boost_LIBRARIES}") +endif( ) + + +message( STATUS "BOOST_INCLUDE_DIR = " ${Boost_INCLUDE_DIR} ) +message( STATUS "BOOST_LIBRARIES = " ${Boost_LIBRARIES} ) + + +# +# cfitsio +# +if( STANDALONE ) + find_path( CFITSIO_INCLUDE_DIRS fitsio.h + PATH_SUFFIXES cfitsio ) + if( CFITSIO_INCLUDE_DIRS MATCHES "NOTFOUND$" ) + message( FATAL_ERROR "fitsio.h could not be found. Please check!" ) + endif() + string( REGEX REPLACE "/[^/]+/?$" "" CFITSIO_ROOT ${CFITSIO_INCLUDE_DIRS} ) + message( STATUS "CFITSIO_ROOT=" ${CFITSIO_ROOT} ) + find_library( CFITSIO_LIBRARIES libcfitsio.${SO} + PATHS ${CFITSIO_ROOT} + PATH_SUFFIXES lib64 lib + NO_DEFAULT_PATH ) + if( CFITSIO_LIBRARIES MATCHES "NOTFOUND$" ) + find_library( CFITSIO_LIBRARIES libcfitsio.a + PATHS ${CFITSIO_ROOT} + PATH_SUFFIXES lib64 lib + NO_DEFAULT_PATH ) + endif() + find_library( CFITSIO_LIBRARIES libcfitsio.${SO} + PATHS /usr/local /usr + PATH_SUFFIXES lib64 lib ) + if( CFITSIO_LIBRARIES MATCHES "NOTFOUND$" ) + message( FATAL_ERROR "libcfitsio.so could not be found. Please check!" ) + endif() +else() + casa_find( CFITSIO + VERSION 3.006 + INCLUDES fitsio.h fitsio2.h + INCLUDES_SUFFIXES cfitsio + LIBS cfitsio + CPP_VERSION CFITSIO_VERSION + RUN_VERSION "(ffvers(&v), v)" ) +endif() +message( STATUS "CFITSIO_INCLUDE_DIRS = " ${CFITSIO_INCLUDE_DIRS} ) +message( STATUS "CFITSIO_LIBRARIES = " ${CFITSIO_LIBRARIES} ) + + +# +# Fortran +# +if( NOT FORTRAN_LIBRARIES ) + + message( STATUS "Looking for Fortran runtime libraries" ) + set( _try ${CMAKE_BINARY_DIR}/try_fortran.cc ) + file( WRITE ${_try} + "int main() { return 0; }\n" + ) + + execute_process( COMMAND ${CMAKE_Fortran_COMPILER} -print-search-dirs + COMMAND perl -e "$found = 0; while(<>) { s|\n||g; if( m|^libraries:\\s*=(.*?$)| ) { foreach $d (split(':',$1) ) { if ( -e \"$d/libgfortran${CMAKE_SHARED_LIBRARY_SUFFIX}\" ) { print \"$d/libgfortran${CMAKE_SHARED_LIBRARY_SUFFIX}\"; $found = 1; last; }} last if $found; } last if $found;}" +# COMMAND perl -e "$found = 0; while(<>) { s|\n||g; if( m|^libraries:\\s*=(.*?$)| ) { foreach $d (split(':',$1) ) { if ( -e \"$d/libgfortran${CMAKE_SHARED_LIBRARY_SUFFIX}\" ) { print \"$d/libgfortran${CMAKE_SHARED_LIBRARY_SUFFIX}\"; $found = 1; break; }} break if $found; } break if $found;}" + OUTPUT_VARIABLE _gfortran_lib_path + OUTPUT_STRIP_TRAILING_WHITESPACE ) + + if( _gfortran_lib_path ) + try_compile( _have_gfortran ${CMAKE_BINARY_DIR} ${_try} + CMAKE_FLAGS -Wdev "-DCMAKE_EXE_LINKER_FLAGS=${_gfortran_lib_path}" + ) + else() + try_compile( _have_gfortran ${CMAKE_BINARY_DIR} ${_try} + CMAKE_FLAGS -Wdev "-DCMAKE_EXE_LINKER_FLAGS=-lgfortran" + ) + endif() + try_compile( _have_g2c ${CMAKE_BINARY_DIR} ${_try} + CMAKE_FLAGS -Wdev "-DCMAKE_EXE_LINKER_FLAGS=-lg2c" + ) + + if( _have_gfortran ) + if( _gfortran_lib_path ) + set( FORTRAN_LIBRARIES ${_gfortran_lib_path} + CACHE STRING "Fortran library linker option" FORCE ) + else() + set( FORTRAN_LIBRARIES -lgfortran + CACHE STRING "Fortran library linker option" FORCE ) + endif() + message( STATUS "Looking for Fortran runtime libraries -- ${FORTRAN_LIBRARIES}" ) + elseif( _have_g2c ) + set( FORTRAN_LIBRARIES -lg2c + CACHE STRING "Fortran library linker option" FORCE ) + message( STATUS "Looking for Fortran runtime libraries -- ${FORTRAN_LIBRARIES}" ) + else() + set( FORTRAN_LIBRARIES "" + CACHE STRING "Fortran library linker option" FORCE ) + message( STATUS "Looking for Fortran runtime libraries -- " ) + # Not a fatal error because it might work, if all Fortran dependencies were + # already linked statically to the Fortran runtime... + endif() +endif() + +# X11. +if( NOT APPLE ) + find_package( X11 REQUIRED ) + # Rename + set( X11_INCLUDE_DIRS ${X11_INCLUDE_DIR} ) +endif() + +# PGPLOT (FORTRAN plotting package). +# depends on X11 +# not require in standalone mode +if( NOT STANDALONE ) + if( APPLE ) + set( _deps FORTRAN ) + else() + set( _deps X11 FORTRAN ) + endif() + if (CMAKE_SYSTEM MATCHES ^Darwin-11 AND NOT LLVMCOMPILER ) + set( CMAKE_SHARED_LINKER_FLAGS "-Wl,-undefined -Wl,error -framework AppKit -lgfortran" ) + else() + if (APPLE) + set( CMAKE_SHARED_LINKER_FLAGS "-Wl,-undefined -Wl,error -framework AppKit" ) + else() + set( CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -Wl,-undefined -Wl,error" ) + endif() + endif() + casa_find( PGPLOT + VERSION 5.3.1 + PREFIX_HINTS ${PGPLOT_ROOT_DIR} + INCLUDES cpgplot.h + LIBS pgplot${pgplot_ext} cpgplot${pgplot_ext} + DEPENDS ${_deps} ) + + add_definitions( -DENABLE_PLOTTER2 ) +endif() + +# +# RPFITS +# +if ( STANDALONE ) + find_path( RPFITS_INCLUDE_DIRS RPFITS.h + PATHS /usr/local /usr + PATH_SUFFIXES include ) + if( RPFITS_INCLUDE_DIRS MATCHES "NOTFOUND$" ) + message( FATAL_ERROR "RPFITS.h could not be found. Please check!" ) + endif() + find_library( RPFITS_LIBRARIES librpfits.so + PATHS /usr/local /usr + PATH_SUFFIXES lib64 lib ) + if( RPFITS_LIBRARIES MATCHES "NOTFOUND$" ) + message( FATAL_ERROR "librpfits.so could not be found. Please check!" ) + endif() + list( APPEND RPFITS_LIBRARIES ${FORTRAN_LIBRARIES} ) +else() + casa_find( RPFITS + VERSION 2.11 + INCLUDES RPFITS.h + LIBS rpfits + RUN_VERSION names_.rpfitsversion + DEPENDS FORTRAN ) +endif() +message( STATUS "RPFITS_INCLUDE_DIRS = " ${RPFITS_INCLUDE_DIRS} ) +message( STATUS "RPFITS_LIBRARIES = " ${RPFITS_LIBRARIES} ) + + +# +# wcslib +# +set( _wcslib libwcs.${SO} ) +set( _wcs_version 4.3 ) +find_library( WCSLIB ${_wcslib} + PATHS ${WCSLIB_ROOT_DIR} ${WCSLIB_PATHS} + PATH_SUFFIXES lib64 lib ) +if( WCSLIB MATCHES "NOTFOUND$" ) + message( STATUS "${_wcslib} could not be found." ) + unset( _wcslib CACHE ) + unset( WCSLIB CACHE ) + set( _wcslib libwcs.${_wcs_version}.${SO} ) + message( STATUS "Try to find ${_wcslib}..." ) + message( STATUS "looking in ${WCSLIB_PATHS}..." ) + find_library( WCSLIB ${_wcslib} + PATHS ${WCSLIB_ROOT_DIR} ${WCSLIB_PATHS} + PATH_SUFFIXES lib64 lib ) + if( WCSLIB MATCHES "NOTFOUND$" ) + message( FATAL_ERROR "${_wcslib} could not be found. Please check!" ) + endif() +endif() +message( STATUS "WCSLIB = " ${WCSLIB} ) +find_path( WCSLIB_INCLUDE_DIR wcslib/wcs.h + PATHS ${WCSLIB_ROOT_DIR} ${WCSLIB_PATHS} + PATH_SUFFIXES include ) +if( WCSLIB_INCLUDE_DIR MATCHES "NOTFOUND$" ) + message( FATAL_ERROR "wcs.h could not be found. Please check!" ) +endif() +message( STATUS "WCSLIB_INCLUDE_DIR = " ${WCSLIB_INCLUDE_DIR} ) + + +# +# common include path +# +include_directories( ${CASACORE_INCLUDE_DIR}/.. + ${CASACORE_INCLUDE_DIR} + ${Boost_INCLUDE_DIR} + ${X11_INCLUDE_DIRS} + ${PGPLOT_INCLUDE_DIRS} + ${PYTHON_INCLUDE_DIRS} + ${WCSLIB_INCLUDE_DIR} + ${CFITSIO_INCLUDE_DIRS} + ${RPFITS_INCLUDE_DIRS} ) + + +# +# install directory +# +set( EXEC_INSTALL_DIR bin ) +set( LIB_INSTALL_DIR lib ) +set( PYTHON_INSTALL_DIR python/${PYTHONV}/asap ) +set( SHARED_INSTALL_DIR share/asap ) +if( NOT STANDALONE ) + if( EXISTS ${CMAKE_INSTALL_PREFIX}/lib/python${PYTHONV} ) + message( STATUS "adjusting PYTHON_INSTALL_DIR to lib/python${PYTHONV}/asap" ) + set( PYTHON_INSTALL_DIR lib/python${PYTHONV}/asap ) + endif() +endif() + +# +# execute getsvnrev.sh to create/update svninfo.txt +# run chmod to make sure the script has executable +# +execute_process( COMMAND svn info + RESULT_VARIABLE SVNINFOSTATUS + WORKING_DIRECTORY ${CMAKE_SOURCE_DIR} +) +message("SVNINFOSTATUS: ${SVNINFOSTATUS}") + +if(${SVNINFOSTATUS} STREQUAL "0") + message("Running svn scripts.") + exec_program( chmod ARGS a+x ${ASAP_SOURCE_DIR}/getsvnrev.sh ) + exec_program( chmod ARGS a+x ${ASAP_SOURCE_DIR}/cmake/exec_getsvnrev.sh ) + exec_program( ${ASAP_SOURCE_DIR}/cmake/exec_getsvnrev.sh ARGS ${ASAP_SOURCE_DIR}) +else () + message("Couldn't get svn info. Running git scripts.") + exec_program( chmod ARGS a+x ${ASAP_SOURCE_DIR}/getgitrev.sh ) + exec_program( chmod ARGS a+x ${ASAP_SOURCE_DIR}/cmake/exec_getgitrev.sh ) + exec_program( ${ASAP_SOURCE_DIR}/cmake/exec_getgitrev.sh ARGS ${ASAP_SOURCE_DIR}) +endif () + +# Add the modules to be built. +# +# Choose to have correct RPATHs both in the build tree and +# in the install tree (at the cost of having to change the +# rpath when installing) +# +set( CMAKE_INSTALL_RPATH ${CMAKE_INSTALL_PREFIX}/lib ) +set( CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) +set( CMAKE_INSTALL_NAME_DIR ${CMAKE_INSTALL_PREFIX}/lib ) + +# +# PKSMS +# +if ( NOT PKSMS ) + add_definitions( -DNOPKSMS ) +endif() + +# +# libraries and executables +# +set( ASAPPYLIB _asap ) +set( ASAPLIB asap ) +#set( PYRAPLIB pyrap ) +#set( ATNFLIB atnf ) +set( ATNFLIB atnf_asap ) +set( ASAP2TO3 asap2to3 ) +#if ( NOT STANDALONE ) +# set( ASDM2ASAP_OLD oldasdm2ASAP ) +# set( ASDM2ASAP asdm2ASAP ) +#endif() + +# +# always install by default +# +add_custom_target( inst ALL ${CMAKE_BUILD_TOOL} install/fast ) + +# +# subdirectories +# +asap_add_subdirectory() + +if (NOT STANDALONE AND PYTHON_SHARED_LINKER_FLAGS) + set_target_properties(${ATNFLIB} PROPERTIES LINK_FLAGS ${PYTHON_SHARED_LINKER_FLAGS}) + set_target_properties(${ASAPLIB} PROPERTIES LINK_FLAGS ${PYTHON_SHARED_LINKER_FLAGS}) + set_target_properties(${ASAPPYLIB} PROPERTIES LINK_FLAGS ${PYTHON_SHARED_LINKER_FLAGS}) +endif (NOT STANDALONE AND PYTHON_SHARED_LINKER_FLAGS) Index: /tags/asap-4.4.0+atnf2/COPYING =================================================================== --- /tags/asap-4.4.0+atnf2/COPYING (revision 3150) +++ /tags/asap-4.4.0+atnf2/COPYING (revision 3150) @@ -0,0 +1,23 @@ +Copyright (C) 2004-2012 +CSIRO + +This program is free software; you can redistribute it and/or modify it +under the terms of the GNU General Public License as published by the Free +Software Foundation; either version 2 of the License, or (at your option) +any later version. + +This program is distributed in the hope that it will be useful, but +WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General +Public License for more details. + +You should have received a copy of the GNU General Public License along +with this program; if not, write to the Free Software Foundation, Inc., +675 Massachusetts Ave, Cambridge, MA 02139, USA. + +Correspondence concerning this software should be addressed as follows: + Internet email: asap@atnf.csiro.au + Postal address: Australia Telescope National Facility, + P.O. Box 76, + Epping, NSW, 2121, + AUSTRALIA Index: /tags/asap-4.4.0+atnf2/Doxyfile =================================================================== --- /tags/asap-4.4.0+atnf2/Doxyfile (revision 3150) +++ /tags/asap-4.4.0+atnf2/Doxyfile (revision 3150) @@ -0,0 +1,1252 @@ +# Doxyfile 1.5.1 + +# This file describes the settings to be used by the documentation system +# doxygen (www.doxygen.org) for a project +# +# All text after a hash (#) is considered a comment and will be ignored +# The format is: +# TAG = value [value, ...] +# For lists items can also be appended using: +# TAG += value [value, ...] +# Values that contain spaces should be placed between quotes (" ") + +#--------------------------------------------------------------------------- +# Project related configuration options +#--------------------------------------------------------------------------- + +# The PROJECT_NAME tag is a single word (or a sequence of words surrounded +# by quotes) that should identify the project. + +PROJECT_NAME = asap + +# The PROJECT_NUMBER tag can be used to enter a project or revision number. +# This could be handy for archiving the generated documentation or +# if some version control system is used. + +PROJECT_NUMBER = 2.2.0 + +# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) +# base path where the generated documentation will be put. +# If a relative path is entered, it will be relative to the location +# where doxygen was started. If left blank the current directory will be used. + +OUTPUT_DIRECTORY = doc/ + +# If the CREATE_SUBDIRS tag is set to YES, then doxygen will create +# 4096 sub-directories (in 2 levels) under the output directory of each output +# format and will distribute the generated files over these directories. +# Enabling this option can be useful when feeding doxygen a huge amount of +# source files, where putting all generated files in the same directory would +# otherwise cause performance problems for the file system. + +CREATE_SUBDIRS = NO + +# The OUTPUT_LANGUAGE tag is used to specify the language in which all +# documentation generated by doxygen is written. Doxygen will use this +# information to generate all constant output in the proper language. +# The default language is English, other supported languages are: +# Afrikaans, Arabic, Brazilian, Catalan, Chinese, Chinese-Traditional, +# Croatian, Czech, Danish, Dutch, Finnish, French, German, Greek, Hungarian, +# Italian, Japanese, Japanese-en (Japanese with English messages), Korean, +# Korean-en, Lithuanian, Norwegian, Polish, Portuguese, Romanian, Russian, +# Serbian, Slovak, Slovene, Spanish, Swedish, and Ukrainian. + +OUTPUT_LANGUAGE = English + +# This tag can be used to specify the encoding used in the generated output. +# The encoding is not always determined by the language that is chosen, +# but also whether or not the output is meant for Windows or non-Windows users. +# In case there is a difference, setting the USE_WINDOWS_ENCODING tag to YES +# forces the Windows encoding (this is the default for the Windows binary), +# whereas setting the tag to NO uses a Unix-style encoding (the default for +# all platforms other than Windows). + +USE_WINDOWS_ENCODING = NO + +# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will +# include brief member descriptions after the members that are listed in +# the file and class documentation (similar to JavaDoc). +# Set to NO to disable this. + +BRIEF_MEMBER_DESC = YES + +# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend +# the brief description of a member or function before the detailed description. +# Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the +# brief descriptions will be completely suppressed. + +REPEAT_BRIEF = YES + +# This tag implements a quasi-intelligent brief description abbreviator +# that is used to form the text in various listings. Each string +# in this list, if found as the leading text of the brief description, will be +# stripped from the text and the result after processing the whole list, is +# used as the annotated text. Otherwise, the brief description is used as-is. +# If left blank, the following values are used ("$name" is automatically +# replaced with the name of the entity): "The $name class" "The $name widget" +# "The $name file" "is" "provides" "specifies" "contains" +# "represents" "a" "an" "the" + +ABBREVIATE_BRIEF = + +# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then +# Doxygen will generate a detailed section even if there is only a brief +# description. + +ALWAYS_DETAILED_SEC = NO + +# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all +# inherited members of a class in the documentation of that class as if those +# members were ordinary class members. Constructors, destructors and assignment +# operators of the base classes will not be shown. + +INLINE_INHERITED_MEMB = NO + +# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full +# path before files name in the file list and in the header files. If set +# to NO the shortest path that makes the file name unique will be used. + +FULL_PATH_NAMES = NO + +# If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag +# can be used to strip a user-defined part of the path. Stripping is +# only done if one of the specified strings matches the left-hand part of +# the path. The tag can be used to show relative paths in the file list. +# If left blank the directory from which doxygen is run is used as the +# path to strip. + +STRIP_FROM_PATH = + +# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of +# the path mentioned in the documentation of a class, which tells +# the reader which header file to include in order to use a class. +# If left blank only the name of the header file containing the class +# definition is used. Otherwise one should specify the include paths that +# are normally passed to the compiler using the -I flag. + +STRIP_FROM_INC_PATH = + +# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter +# (but less readable) file names. This can be useful is your file systems +# doesn't support long names like on DOS, Mac, or CD-ROM. + +SHORT_NAMES = NO + +# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen +# will interpret the first line (until the first dot) of a JavaDoc-style +# comment as the brief description. If set to NO, the JavaDoc +# comments will behave just like the Qt-style comments (thus requiring an +# explicit @brief command for a brief description. + +JAVADOC_AUTOBRIEF = NO + +# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen +# treat a multi-line C++ special comment block (i.e. a block of //! or /// +# comments) as a brief description. This used to be the default behaviour. +# The new default is to treat a multi-line C++ comment block as a detailed +# description. Set this tag to YES if you prefer the old behaviour instead. + +MULTILINE_CPP_IS_BRIEF = NO + +# If the DETAILS_AT_TOP tag is set to YES then Doxygen +# will output the detailed description near the top, like JavaDoc. +# If set to NO, the detailed description appears after the member +# documentation. + +DETAILS_AT_TOP = NO + +# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented +# member inherits the documentation from any documented member that it +# re-implements. + +INHERIT_DOCS = YES + +# If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce +# a new page for each member. If set to NO, the documentation of a member will +# be part of the file/class/namespace that contains it. + +SEPARATE_MEMBER_PAGES = NO + +# The TAB_SIZE tag can be used to set the number of spaces in a tab. +# Doxygen uses this value to replace tabs by spaces in code fragments. + +TAB_SIZE = 8 + +# This tag can be used to specify a number of aliases that acts +# as commands in the documentation. An alias has the form "name=value". +# For example adding "sideeffect=\par Side Effects:\n" will allow you to +# put the command \sideeffect (or @sideeffect) in the documentation, which +# will result in a user-defined paragraph with heading "Side Effects:". +# You can put \n's in the value part of an alias to insert newlines. + +ALIASES = + +# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C +# sources only. Doxygen will then generate output that is more tailored for C. +# For instance, some of the names that are used will be different. The list +# of all members will be omitted, etc. + +OPTIMIZE_OUTPUT_FOR_C = NO + +# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java +# sources only. Doxygen will then generate output that is more tailored for Java. +# For instance, namespaces will be presented as packages, qualified scopes +# will look different, etc. + +OPTIMIZE_OUTPUT_JAVA = NO + +# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want to +# include (a tag file for) the STL sources as input, then you should +# set this tag to YES in order to let doxygen match functions declarations and +# definitions whose arguments contain STL classes (e.g. func(std::string); v.s. +# func(std::string) {}). This also make the inheritance and collaboration +# diagrams that involve STL classes more complete and accurate. + +BUILTIN_STL_SUPPORT = NO + +# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC +# tag is set to YES, then doxygen will reuse the documentation of the first +# member in the group (if any) for the other members of the group. By default +# all members of a group must be documented explicitly. + +DISTRIBUTE_GROUP_DOC = NO + +# Set the SUBGROUPING tag to YES (the default) to allow class member groups of +# the same type (for instance a group of public functions) to be put as a +# subgroup of that type (e.g. under the Public Functions section). Set it to +# NO to prevent subgrouping. Alternatively, this can be done per class using +# the \nosubgrouping command. + +SUBGROUPING = YES + +#--------------------------------------------------------------------------- +# Build related configuration options +#--------------------------------------------------------------------------- + +# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in +# documentation are documented, even if no documentation was available. +# Private class members and static file members will be hidden unless +# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES + +EXTRACT_ALL = NO + +# If the EXTRACT_PRIVATE tag is set to YES all private members of a class +# will be included in the documentation. + +EXTRACT_PRIVATE = NO + +# If the EXTRACT_STATIC tag is set to YES all static members of a file +# will be included in the documentation. + +EXTRACT_STATIC = NO + +# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs) +# defined locally in source files will be included in the documentation. +# If set to NO only classes defined in header files are included. + +EXTRACT_LOCAL_CLASSES = YES + +# This flag is only useful for Objective-C code. When set to YES local +# methods, which are defined in the implementation section but not in +# the interface are included in the documentation. +# If set to NO (the default) only methods in the interface are included. + +EXTRACT_LOCAL_METHODS = NO + +# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all +# undocumented members of documented classes, files or namespaces. +# If set to NO (the default) these members will be included in the +# various overviews, but no documentation section is generated. +# This option has no effect if EXTRACT_ALL is enabled. + +HIDE_UNDOC_MEMBERS = NO + +# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all +# undocumented classes that are normally visible in the class hierarchy. +# If set to NO (the default) these classes will be included in the various +# overviews. This option has no effect if EXTRACT_ALL is enabled. + +HIDE_UNDOC_CLASSES = NO + +# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all +# friend (class|struct|union) declarations. +# If set to NO (the default) these declarations will be included in the +# documentation. + +HIDE_FRIEND_COMPOUNDS = NO + +# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any +# documentation blocks found inside the body of a function. +# If set to NO (the default) these blocks will be appended to the +# function's detailed documentation block. + +HIDE_IN_BODY_DOCS = NO + +# The INTERNAL_DOCS tag determines if documentation +# that is typed after a \internal command is included. If the tag is set +# to NO (the default) then the documentation will be excluded. +# Set it to YES to include the internal documentation. + +INTERNAL_DOCS = NO + +# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate +# file names in lower-case letters. If set to YES upper-case letters are also +# allowed. This is useful if you have classes or files whose names only differ +# in case and if your file system supports case sensitive file names. Windows +# and Mac users are advised to set this option to NO. + +CASE_SENSE_NAMES = YES + +# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen +# will show members with their full class and namespace scopes in the +# documentation. If set to YES the scope will be hidden. + +HIDE_SCOPE_NAMES = YES + +# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen +# will put a list of the files that are included by a file in the documentation +# of that file. + +SHOW_INCLUDE_FILES = YES + +# If the INLINE_INFO tag is set to YES (the default) then a tag [inline] +# is inserted in the documentation for inline members. + +INLINE_INFO = YES + +# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen +# will sort the (detailed) documentation of file and class members +# alphabetically by member name. If set to NO the members will appear in +# declaration order. + +SORT_MEMBER_DOCS = YES + +# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the +# brief documentation of file, namespace and class members alphabetically +# by member name. If set to NO (the default) the members will appear in +# declaration order. + +SORT_BRIEF_DOCS = NO + +# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be +# sorted by fully-qualified names, including namespaces. If set to +# NO (the default), the class list will be sorted only by class name, +# not including the namespace part. +# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES. +# Note: This option applies only to the class list, not to the +# alphabetical list. + +SORT_BY_SCOPE_NAME = NO + +# The GENERATE_TODOLIST tag can be used to enable (YES) or +# disable (NO) the todo list. This list is created by putting \todo +# commands in the documentation. + +GENERATE_TODOLIST = YES + +# The GENERATE_TESTLIST tag can be used to enable (YES) or +# disable (NO) the test list. This list is created by putting \test +# commands in the documentation. + +GENERATE_TESTLIST = YES + +# The GENERATE_BUGLIST tag can be used to enable (YES) or +# disable (NO) the bug list. This list is created by putting \bug +# commands in the documentation. + +GENERATE_BUGLIST = YES + +# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or +# disable (NO) the deprecated list. This list is created by putting +# \deprecated commands in the documentation. + +GENERATE_DEPRECATEDLIST = YES + +# The ENABLED_SECTIONS tag can be used to enable conditional +# documentation sections, marked by \if sectionname ... \endif. + +ENABLED_SECTIONS = + +# The MAX_INITIALIZER_LINES tag determines the maximum number of lines +# the initial value of a variable or define consists of for it to appear in +# the documentation. If the initializer consists of more lines than specified +# here it will be hidden. Use a value of 0 to hide initializers completely. +# The appearance of the initializer of individual variables and defines in the +# documentation can be controlled using \showinitializer or \hideinitializer +# command in the documentation regardless of this setting. + +MAX_INITIALIZER_LINES = 30 + +# Set the SHOW_USED_FILES tag to NO to disable the list of files generated +# at the bottom of the documentation of classes and structs. If set to YES the +# list will mention the files that were used to generate the documentation. + +SHOW_USED_FILES = YES + +# If the sources in your project are distributed over multiple directories +# then setting the SHOW_DIRECTORIES tag to YES will show the directory hierarchy +# in the documentation. The default is NO. + +SHOW_DIRECTORIES = NO + +# The FILE_VERSION_FILTER tag can be used to specify a program or script that +# doxygen should invoke to get the current version for each file (typically from the +# version control system). Doxygen will invoke the program by executing (via +# popen()) the command , where is the value of +# the FILE_VERSION_FILTER tag, and is the name of an input file +# provided by doxygen. Whatever the program writes to standard output +# is used as the file version. See the manual for examples. + +FILE_VERSION_FILTER = + +#--------------------------------------------------------------------------- +# configuration options related to warning and progress messages +#--------------------------------------------------------------------------- + +# The QUIET tag can be used to turn on/off the messages that are generated +# by doxygen. Possible values are YES and NO. If left blank NO is used. + +QUIET = NO + +# The WARNINGS tag can be used to turn on/off the warning messages that are +# generated by doxygen. Possible values are YES and NO. If left blank +# NO is used. + +WARNINGS = YES + +# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings +# for undocumented members. If EXTRACT_ALL is set to YES then this flag will +# automatically be disabled. + +WARN_IF_UNDOCUMENTED = NO + +# If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for +# potential errors in the documentation, such as not documenting some +# parameters in a documented function, or documenting parameters that +# don't exist or using markup commands wrongly. + +WARN_IF_DOC_ERROR = YES + +# This WARN_NO_PARAMDOC option can be abled to get warnings for +# functions that are documented, but have no documentation for their parameters +# or return value. If set to NO (the default) doxygen will only warn about +# wrong or incomplete parameter documentation, but not about the absence of +# documentation. + +WARN_NO_PARAMDOC = NO + +# The WARN_FORMAT tag determines the format of the warning messages that +# doxygen can produce. The string should contain the $file, $line, and $text +# tags, which will be replaced by the file and line number from which the +# warning originated and the warning text. Optionally the format may contain +# $version, which will be replaced by the version of the file (if it could +# be obtained via FILE_VERSION_FILTER) + +WARN_FORMAT = "$file:$line: $text" + +# The WARN_LOGFILE tag can be used to specify a file to which warning +# and error messages should be written. If left blank the output is written +# to stderr. + +WARN_LOGFILE = + +#--------------------------------------------------------------------------- +# configuration options related to the input files +#--------------------------------------------------------------------------- + +# The INPUT tag can be used to specify the files and/or directories that contain +# documented source files. You may enter file names like "myfile.cpp" or +# directories like "/usr/src/myproject". Separate the files or directories +# with spaces. + +INPUT = src + +# If the value of the INPUT tag contains directories, you can use the +# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp +# and *.h) to filter out the source-files in the directories. If left +# blank the following patterns are tested: +# *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx +# *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.py + +FILE_PATTERNS = + +# The RECURSIVE tag can be used to turn specify whether or not subdirectories +# should be searched for input files as well. Possible values are YES and NO. +# If left blank NO is used. + +RECURSIVE = NO + +# The EXCLUDE tag can be used to specify files and/or directories that should +# excluded from the INPUT source files. This way you can easily exclude a +# subdirectory from a directory tree whose root is specified with the INPUT tag. + +EXCLUDE = + +# The EXCLUDE_SYMLINKS tag can be used select whether or not files or +# directories that are symbolic links (a Unix filesystem feature) are excluded +# from the input. + +EXCLUDE_SYMLINKS = NO + +# If the value of the INPUT tag contains directories, you can use the +# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude +# certain files from those directories. Note that the wildcards are matched +# against the file with absolute path, so to exclude all test directories +# for example use the pattern */test/* + +EXCLUDE_PATTERNS = + +# The EXAMPLE_PATH tag can be used to specify one or more files or +# directories that contain example code fragments that are included (see +# the \include command). + +EXAMPLE_PATH = + +# If the value of the EXAMPLE_PATH tag contains directories, you can use the +# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp +# and *.h) to filter out the source-files in the directories. If left +# blank all files are included. + +EXAMPLE_PATTERNS = + +# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be +# searched for input files to be used with the \include or \dontinclude +# commands irrespective of the value of the RECURSIVE tag. +# Possible values are YES and NO. If left blank NO is used. + +EXAMPLE_RECURSIVE = NO + +# The IMAGE_PATH tag can be used to specify one or more files or +# directories that contain image that are included in the documentation (see +# the \image command). + +IMAGE_PATH = + +# The INPUT_FILTER tag can be used to specify a program that doxygen should +# invoke to filter for each input file. Doxygen will invoke the filter program +# by executing (via popen()) the command , where +# is the value of the INPUT_FILTER tag, and is the name of an +# input file. Doxygen will then use the output that the filter program writes +# to standard output. If FILTER_PATTERNS is specified, this tag will be +# ignored. + +INPUT_FILTER = + +# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern +# basis. Doxygen will compare the file name with each pattern and apply the +# filter if there is a match. The filters are a list of the form: +# pattern=filter (like *.cpp=my_cpp_filter). See INPUT_FILTER for further +# info on how filters are used. If FILTER_PATTERNS is empty, INPUT_FILTER +# is applied to all files. + +FILTER_PATTERNS = + +# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using +# INPUT_FILTER) will be used to filter the input files when producing source +# files to browse (i.e. when SOURCE_BROWSER is set to YES). + +FILTER_SOURCE_FILES = NO + +#--------------------------------------------------------------------------- +# configuration options related to source browsing +#--------------------------------------------------------------------------- + +# If the SOURCE_BROWSER tag is set to YES then a list of source files will +# be generated. Documented entities will be cross-referenced with these sources. +# Note: To get rid of all source code in the generated output, make sure also +# VERBATIM_HEADERS is set to NO. + +SOURCE_BROWSER = NO + +# Setting the INLINE_SOURCES tag to YES will include the body +# of functions and classes directly in the documentation. + +INLINE_SOURCES = NO + +# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct +# doxygen to hide any special comment blocks from generated source code +# fragments. Normal C and C++ comments will always remain visible. + +STRIP_CODE_COMMENTS = YES + +# If the REFERENCED_BY_RELATION tag is set to YES (the default) +# then for each documented function all documented +# functions referencing it will be listed. + +REFERENCED_BY_RELATION = YES + +# If the REFERENCES_RELATION tag is set to YES (the default) +# then for each documented function all documented entities +# called/used by that function will be listed. + +REFERENCES_RELATION = YES + +# If the REFERENCES_LINK_SOURCE tag is set to YES (the default) +# and SOURCE_BROWSER tag is set to YES, then the hyperlinks from +# functions in REFERENCES_RELATION and REFERENCED_BY_RELATION lists will +# link to the source code. Otherwise they will link to the documentstion. + +REFERENCES_LINK_SOURCE = YES + +# If the USE_HTAGS tag is set to YES then the references to source code +# will point to the HTML generated by the htags(1) tool instead of doxygen +# built-in source browser. The htags tool is part of GNU's global source +# tagging system (see http://www.gnu.org/software/global/global.html). You +# will need version 4.8.6 or higher. + +USE_HTAGS = NO + +# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen +# will generate a verbatim copy of the header file for each class for +# which an include is specified. Set to NO to disable this. + +VERBATIM_HEADERS = YES + +#--------------------------------------------------------------------------- +# configuration options related to the alphabetical class index +#--------------------------------------------------------------------------- + +# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index +# of all compounds will be generated. Enable this if the project +# contains a lot of classes, structs, unions or interfaces. + +ALPHABETICAL_INDEX = NO + +# If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then +# the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns +# in which this list will be split (can be a number in the range [1..20]) + +COLS_IN_ALPHA_INDEX = 5 + +# In case all classes in a project start with a common prefix, all +# classes will be put under the same header in the alphabetical index. +# The IGNORE_PREFIX tag can be used to specify one or more prefixes that +# should be ignored while generating the index headers. + +IGNORE_PREFIX = + +#--------------------------------------------------------------------------- +# configuration options related to the HTML output +#--------------------------------------------------------------------------- + +# If the GENERATE_HTML tag is set to YES (the default) Doxygen will +# generate HTML output. + +GENERATE_HTML = YES + +# The HTML_OUTPUT tag is used to specify where the HTML docs will be put. +# If a relative path is entered the value of OUTPUT_DIRECTORY will be +# put in front of it. If left blank `html' will be used as the default path. + +HTML_OUTPUT = html + +# The HTML_FILE_EXTENSION tag can be used to specify the file extension for +# each generated HTML page (for example: .htm,.php,.asp). If it is left blank +# doxygen will generate files with .html extension. + +HTML_FILE_EXTENSION = .html + +# The HTML_HEADER tag can be used to specify a personal HTML header for +# each generated HTML page. If it is left blank doxygen will generate a +# standard header. + +HTML_HEADER = + +# The HTML_FOOTER tag can be used to specify a personal HTML footer for +# each generated HTML page. If it is left blank doxygen will generate a +# standard footer. + +HTML_FOOTER = + +# The HTML_STYLESHEET tag can be used to specify a user-defined cascading +# style sheet that is used by each HTML page. It can be used to +# fine-tune the look of the HTML output. If the tag is left blank doxygen +# will generate a default style sheet. Note that doxygen will try to copy +# the style sheet file to the HTML output directory, so don't put your own +# stylesheet in the HTML output directory as well, or it will be erased! + +HTML_STYLESHEET = + +# If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes, +# files or namespaces will be aligned in HTML using tables. If set to +# NO a bullet list will be used. + +HTML_ALIGN_MEMBERS = YES + +# If the GENERATE_HTMLHELP tag is set to YES, additional index files +# will be generated that can be used as input for tools like the +# Microsoft HTML help workshop to generate a compressed HTML help file (.chm) +# of the generated HTML documentation. + +GENERATE_HTMLHELP = NO + +# If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can +# be used to specify the file name of the resulting .chm file. You +# can add a path in front of the file if the result should not be +# written to the html output directory. + +CHM_FILE = + +# If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can +# be used to specify the location (absolute path including file name) of +# the HTML help compiler (hhc.exe). If non-empty doxygen will try to run +# the HTML help compiler on the generated index.hhp. + +HHC_LOCATION = + +# If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag +# controls if a separate .chi index file is generated (YES) or that +# it should be included in the master .chm file (NO). + +GENERATE_CHI = NO + +# If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag +# controls whether a binary table of contents is generated (YES) or a +# normal table of contents (NO) in the .chm file. + +BINARY_TOC = NO + +# The TOC_EXPAND flag can be set to YES to add extra items for group members +# to the contents of the HTML help documentation and to the tree view. + +TOC_EXPAND = NO + +# The DISABLE_INDEX tag can be used to turn on/off the condensed index at +# top of each HTML page. The value NO (the default) enables the index and +# the value YES disables it. + +DISABLE_INDEX = NO + +# This tag can be used to set the number of enum values (range [1..20]) +# that doxygen will group on one line in the generated HTML documentation. + +ENUM_VALUES_PER_LINE = 4 + +# If the GENERATE_TREEVIEW tag is set to YES, a side panel will be +# generated containing a tree-like index structure (just like the one that +# is generated for HTML Help). For this to work a browser that supports +# JavaScript, DHTML, CSS and frames is required (for instance Mozilla 1.0+, +# Netscape 6.0+, Internet explorer 5.0+, or Konqueror). Windows users are +# probably better off using the HTML help feature. + +GENERATE_TREEVIEW = NO + +# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be +# used to set the initial width (in pixels) of the frame in which the tree +# is shown. + +TREEVIEW_WIDTH = 250 + +#--------------------------------------------------------------------------- +# configuration options related to the LaTeX output +#--------------------------------------------------------------------------- + +# If the GENERATE_LATEX tag is set to YES (the default) Doxygen will +# generate Latex output. + +GENERATE_LATEX = YES + +# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put. +# If a relative path is entered the value of OUTPUT_DIRECTORY will be +# put in front of it. If left blank `latex' will be used as the default path. + +LATEX_OUTPUT = latex + +# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be +# invoked. If left blank `latex' will be used as the default command name. + +LATEX_CMD_NAME = latex + +# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to +# generate index for LaTeX. If left blank `makeindex' will be used as the +# default command name. + +MAKEINDEX_CMD_NAME = makeindex + +# If the COMPACT_LATEX tag is set to YES Doxygen generates more compact +# LaTeX documents. This may be useful for small projects and may help to +# save some trees in general. + +COMPACT_LATEX = NO + +# The PAPER_TYPE tag can be used to set the paper type that is used +# by the printer. Possible values are: a4, a4wide, letter, legal and +# executive. If left blank a4wide will be used. + +PAPER_TYPE = a4wide + +# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX +# packages that should be included in the LaTeX output. + +EXTRA_PACKAGES = + +# The LATEX_HEADER tag can be used to specify a personal LaTeX header for +# the generated latex document. The header should contain everything until +# the first chapter. If it is left blank doxygen will generate a +# standard header. Notice: only use this tag if you know what you are doing! + +LATEX_HEADER = + +# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated +# is prepared for conversion to pdf (using ps2pdf). The pdf file will +# contain links (just like the HTML output) instead of page references +# This makes the output suitable for online browsing using a pdf viewer. + +PDF_HYPERLINKS = NO + +# If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of +# plain latex in the generated Makefile. Set this option to YES to get a +# higher quality PDF documentation. + +USE_PDFLATEX = NO + +# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode. +# command to the generated LaTeX files. This will instruct LaTeX to keep +# running if errors occur, instead of asking the user for help. +# This option is also used when generating formulas in HTML. + +LATEX_BATCHMODE = NO + +# If LATEX_HIDE_INDICES is set to YES then doxygen will not +# include the index chapters (such as File Index, Compound Index, etc.) +# in the output. + +LATEX_HIDE_INDICES = NO + +#--------------------------------------------------------------------------- +# configuration options related to the RTF output +#--------------------------------------------------------------------------- + +# If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output +# The RTF output is optimized for Word 97 and may not look very pretty with +# other RTF readers or editors. + +GENERATE_RTF = NO + +# The RTF_OUTPUT tag is used to specify where the RTF docs will be put. +# If a relative path is entered the value of OUTPUT_DIRECTORY will be +# put in front of it. If left blank `rtf' will be used as the default path. + +RTF_OUTPUT = rtf + +# If the COMPACT_RTF tag is set to YES Doxygen generates more compact +# RTF documents. This may be useful for small projects and may help to +# save some trees in general. + +COMPACT_RTF = NO + +# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated +# will contain hyperlink fields. The RTF file will +# contain links (just like the HTML output) instead of page references. +# This makes the output suitable for online browsing using WORD or other +# programs which support those fields. +# Note: wordpad (write) and others do not support links. + +RTF_HYPERLINKS = NO + +# Load stylesheet definitions from file. Syntax is similar to doxygen's +# config file, i.e. a series of assignments. You only have to provide +# replacements, missing definitions are set to their default value. + +RTF_STYLESHEET_FILE = + +# Set optional variables used in the generation of an rtf document. +# Syntax is similar to doxygen's config file. + +RTF_EXTENSIONS_FILE = + +#--------------------------------------------------------------------------- +# configuration options related to the man page output +#--------------------------------------------------------------------------- + +# If the GENERATE_MAN tag is set to YES (the default) Doxygen will +# generate man pages + +GENERATE_MAN = NO + +# The MAN_OUTPUT tag is used to specify where the man pages will be put. +# If a relative path is entered the value of OUTPUT_DIRECTORY will be +# put in front of it. If left blank `man' will be used as the default path. + +MAN_OUTPUT = man + +# The MAN_EXTENSION tag determines the extension that is added to +# the generated man pages (default is the subroutine's section .3) + +MAN_EXTENSION = .3 + +# If the MAN_LINKS tag is set to YES and Doxygen generates man output, +# then it will generate one additional man file for each entity +# documented in the real man page(s). These additional files +# only source the real man page, but without them the man command +# would be unable to find the correct page. The default is NO. + +MAN_LINKS = NO + +#--------------------------------------------------------------------------- +# configuration options related to the XML output +#--------------------------------------------------------------------------- + +# If the GENERATE_XML tag is set to YES Doxygen will +# generate an XML file that captures the structure of +# the code including all documentation. + +GENERATE_XML = NO + +# The XML_OUTPUT tag is used to specify where the XML pages will be put. +# If a relative path is entered the value of OUTPUT_DIRECTORY will be +# put in front of it. If left blank `xml' will be used as the default path. + +XML_OUTPUT = xml + +# The XML_SCHEMA tag can be used to specify an XML schema, +# which can be used by a validating XML parser to check the +# syntax of the XML files. + +XML_SCHEMA = + +# The XML_DTD tag can be used to specify an XML DTD, +# which can be used by a validating XML parser to check the +# syntax of the XML files. + +XML_DTD = + +# If the XML_PROGRAMLISTING tag is set to YES Doxygen will +# dump the program listings (including syntax highlighting +# and cross-referencing information) to the XML output. Note that +# enabling this will significantly increase the size of the XML output. + +XML_PROGRAMLISTING = YES + +#--------------------------------------------------------------------------- +# configuration options for the AutoGen Definitions output +#--------------------------------------------------------------------------- + +# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will +# generate an AutoGen Definitions (see autogen.sf.net) file +# that captures the structure of the code including all +# documentation. Note that this feature is still experimental +# and incomplete at the moment. + +GENERATE_AUTOGEN_DEF = NO + +#--------------------------------------------------------------------------- +# configuration options related to the Perl module output +#--------------------------------------------------------------------------- + +# If the GENERATE_PERLMOD tag is set to YES Doxygen will +# generate a Perl module file that captures the structure of +# the code including all documentation. Note that this +# feature is still experimental and incomplete at the +# moment. + +GENERATE_PERLMOD = NO + +# If the PERLMOD_LATEX tag is set to YES Doxygen will generate +# the necessary Makefile rules, Perl scripts and LaTeX code to be able +# to generate PDF and DVI output from the Perl module output. + +PERLMOD_LATEX = NO + +# If the PERLMOD_PRETTY tag is set to YES the Perl module output will be +# nicely formatted so it can be parsed by a human reader. This is useful +# if you want to understand what is going on. On the other hand, if this +# tag is set to NO the size of the Perl module output will be much smaller +# and Perl will parse it just the same. + +PERLMOD_PRETTY = YES + +# The names of the make variables in the generated doxyrules.make file +# are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX. +# This is useful so different doxyrules.make files included by the same +# Makefile don't overwrite each other's variables. + +PERLMOD_MAKEVAR_PREFIX = + +#--------------------------------------------------------------------------- +# Configuration options related to the preprocessor +#--------------------------------------------------------------------------- + +# If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will +# evaluate all C-preprocessor directives found in the sources and include +# files. + +ENABLE_PREPROCESSING = YES + +# If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro +# names in the source code. If set to NO (the default) only conditional +# compilation will be performed. Macro expansion can be done in a controlled +# way by setting EXPAND_ONLY_PREDEF to YES. + +MACRO_EXPANSION = NO + +# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES +# then the macro expansion is limited to the macros specified with the +# PREDEFINED and EXPAND_AS_DEFINED tags. + +EXPAND_ONLY_PREDEF = NO + +# If the SEARCH_INCLUDES tag is set to YES (the default) the includes files +# in the INCLUDE_PATH (see below) will be search if a #include is found. + +SEARCH_INCLUDES = YES + +# The INCLUDE_PATH tag can be used to specify one or more directories that +# contain include files that are not input files but should be processed by +# the preprocessor. + +INCLUDE_PATH = + +# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard +# patterns (like *.h and *.hpp) to filter out the header-files in the +# directories. If left blank, the patterns specified with FILE_PATTERNS will +# be used. + +INCLUDE_FILE_PATTERNS = + +# The PREDEFINED tag can be used to specify one or more macro names that +# are defined before the preprocessor is started (similar to the -D option of +# gcc). The argument of the tag is a list of macros of the form: name +# or name=definition (no spaces). If the definition and the = are +# omitted =1 is assumed. To prevent a macro definition from being +# undefined via #undef or recursively expanded use the := operator +# instead of the = operator. + +PREDEFINED = + +# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then +# this tag can be used to specify a list of macro names that should be expanded. +# The macro definition that is found in the sources will be used. +# Use the PREDEFINED tag if you want to use a different macro definition. + +EXPAND_AS_DEFINED = + +# If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then +# doxygen's preprocessor will remove all function-like macros that are alone +# on a line, have an all uppercase name, and do not end with a semicolon. Such +# function macros are typically used for boiler-plate code, and will confuse +# the parser if not removed. + +SKIP_FUNCTION_MACROS = YES + +#--------------------------------------------------------------------------- +# Configuration::additions related to external references +#--------------------------------------------------------------------------- + +# The TAGFILES option can be used to specify one or more tagfiles. +# Optionally an initial location of the external documentation +# can be added for each tagfile. The format of a tag file without +# this location is as follows: +# TAGFILES = file1 file2 ... +# Adding location for the tag files is done as follows: +# TAGFILES = file1=loc1 "file2 = loc2" ... +# where "loc1" and "loc2" can be relative or absolute paths or +# URLs. If a location is present for each tag, the installdox tool +# does not have to be run to correct the links. +# Note that each tag file must have a unique name +# (where the name does NOT include the path) +# If a tag file is not located in the directory in which doxygen +# is run, you must also specify the path to the tagfile here. + +TAGFILES = + +# When a file name is specified after GENERATE_TAGFILE, doxygen will create +# a tag file that is based on the input files it reads. + +GENERATE_TAGFILE = + +# If the ALLEXTERNALS tag is set to YES all external classes will be listed +# in the class index. If set to NO only the inherited external classes +# will be listed. + +ALLEXTERNALS = NO + +# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed +# in the modules index. If set to NO, only the current project's groups will +# be listed. + +EXTERNAL_GROUPS = YES + +# The PERL_PATH should be the absolute path and name of the perl script +# interpreter (i.e. the result of `which perl'). + +PERL_PATH = /usr/bin/perl + +#--------------------------------------------------------------------------- +# Configuration options related to the dot tool +#--------------------------------------------------------------------------- + +# If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will +# generate a inheritance diagram (in HTML, RTF and LaTeX) for classes with base +# or super classes. Setting the tag to NO turns the diagrams off. Note that +# this option is superseded by the HAVE_DOT option below. This is only a +# fallback. It is recommended to install and use dot, since it yields more +# powerful graphs. + +CLASS_DIAGRAMS = YES + +# If set to YES, the inheritance and collaboration graphs will hide +# inheritance and usage relations if the target is undocumented +# or is not a class. + +HIDE_UNDOC_RELATIONS = YES + +# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is +# available from the path. This tool is part of Graphviz, a graph visualization +# toolkit from AT&T and Lucent Bell Labs. The other options in this section +# have no effect if this option is set to NO (the default) + +HAVE_DOT = NO + +# If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen +# will generate a graph for each documented class showing the direct and +# indirect inheritance relations. Setting this tag to YES will force the +# the CLASS_DIAGRAMS tag to NO. + +CLASS_GRAPH = YES + +# If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen +# will generate a graph for each documented class showing the direct and +# indirect implementation dependencies (inheritance, containment, and +# class references variables) of the class with other documented classes. + +COLLABORATION_GRAPH = YES + +# If the GROUP_GRAPHS and HAVE_DOT tags are set to YES then doxygen +# will generate a graph for groups, showing the direct groups dependencies + +GROUP_GRAPHS = YES + +# If the UML_LOOK tag is set to YES doxygen will generate inheritance and +# collaboration diagrams in a style similar to the OMG's Unified Modeling +# Language. + +UML_LOOK = NO + +# If set to YES, the inheritance and collaboration graphs will show the +# relations between templates and their instances. + +TEMPLATE_RELATIONS = NO + +# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT +# tags are set to YES then doxygen will generate a graph for each documented +# file showing the direct and indirect include dependencies of the file with +# other documented files. + +INCLUDE_GRAPH = YES + +# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and +# HAVE_DOT tags are set to YES then doxygen will generate a graph for each +# documented header file showing the documented files that directly or +# indirectly include this file. + +INCLUDED_BY_GRAPH = YES + +# If the CALL_GRAPH and HAVE_DOT tags are set to YES then doxygen will +# generate a call dependency graph for every global function or class method. +# Note that enabling this option will significantly increase the time of a run. +# So in most cases it will be better to enable call graphs for selected +# functions only using the \callgraph command. + +CALL_GRAPH = NO + +# If the CALLER_GRAPH and HAVE_DOT tags are set to YES then doxygen will +# generate a caller dependency graph for every global function or class method. +# Note that enabling this option will significantly increase the time of a run. +# So in most cases it will be better to enable caller graphs for selected +# functions only using the \callergraph command. + +CALLER_GRAPH = NO + +# If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen +# will graphical hierarchy of all classes instead of a textual one. + +GRAPHICAL_HIERARCHY = YES + +# If the DIRECTORY_GRAPH, SHOW_DIRECTORIES and HAVE_DOT tags are set to YES +# then doxygen will show the dependencies a directory has on other directories +# in a graphical way. The dependency relations are determined by the #include +# relations between the files in the directories. + +DIRECTORY_GRAPH = YES + +# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images +# generated by dot. Possible values are png, jpg, or gif +# If left blank png will be used. + +DOT_IMAGE_FORMAT = png + +# The tag DOT_PATH can be used to specify the path where the dot tool can be +# found. If left blank, it is assumed the dot tool can be found in the path. + +DOT_PATH = + +# The DOTFILE_DIRS tag can be used to specify one or more directories that +# contain dot files that are included in the documentation (see the +# \dotfile command). + +DOTFILE_DIRS = + +# The MAX_DOT_GRAPH_WIDTH tag can be used to set the maximum allowed width +# (in pixels) of the graphs generated by dot. If a graph becomes larger than +# this value, doxygen will try to truncate the graph, so that it fits within +# the specified constraint. Beware that most browsers cannot cope with very +# large images. + +MAX_DOT_GRAPH_WIDTH = 1024 + +# The MAX_DOT_GRAPH_HEIGHT tag can be used to set the maximum allows height +# (in pixels) of the graphs generated by dot. If a graph becomes larger than +# this value, doxygen will try to truncate the graph, so that it fits within +# the specified constraint. Beware that most browsers cannot cope with very +# large images. + +MAX_DOT_GRAPH_HEIGHT = 1024 + +# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the +# graphs generated by dot. A depth value of 3 means that only nodes reachable +# from the root by following a path via at most 3 edges will be shown. Nodes +# that lay further from the root node will be omitted. Note that setting this +# option to 1 or 2 may greatly reduce the computation time needed for large +# code bases. Also note that a graph may be further truncated if the graph's +# image dimensions are not sufficient to fit the graph (see MAX_DOT_GRAPH_WIDTH +# and MAX_DOT_GRAPH_HEIGHT). If 0 is used for the depth value (the default), +# the graph is not depth-constrained. + +MAX_DOT_GRAPH_DEPTH = 0 + +# Set the DOT_TRANSPARENT tag to YES to generate images with a transparent +# background. This is disabled by default, which results in a white background. +# Warning: Depending on the platform used, enabling this option may lead to +# badly anti-aliased labels on the edges of a graph (i.e. they become hard to +# read). + +DOT_TRANSPARENT = NO + +# Set the DOT_MULTI_TARGETS tag to YES allow dot to generate multiple output +# files in one run (i.e. multiple -o and -T options on the command line). This +# makes dot run faster, but since only newer versions of dot (>1.8.10) +# support this, this feature is disabled by default. + +DOT_MULTI_TARGETS = NO + +# If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will +# generate a legend page explaining the meaning of the various boxes and +# arrows in the dot generated graphs. + +GENERATE_LEGEND = YES + +# If the DOT_CLEANUP tag is set to YES (the default) Doxygen will +# remove the intermediate dot files that are used to generate +# the various graphs. + +DOT_CLEANUP = YES + +#--------------------------------------------------------------------------- +# Configuration::additions related to the search engine +#--------------------------------------------------------------------------- + +# The SEARCHENGINE tag specifies whether or not a search engine should be +# used. If set to NO the values of all tags below this one will be ignored. + +SEARCHENGINE = NO Index: /tags/asap-4.4.0+atnf2/Makefile =================================================================== --- /tags/asap-4.4.0+atnf2/Makefile (revision 3150) +++ /tags/asap-4.4.0+atnf2/Makefile (revision 3150) @@ -0,0 +1,86 @@ +### Notice: +### This Makefile assumes CASA+CASACore enviroment. +### For who wants to build ASAP with older CASA without CASACore +### environment, replace $(CASAPATH) with $(AIPSPATH). +#for mac +#PREFIX := /opt/casa/darwin +#for linux +PREFIX := $(word 1, $(CASAPATH))/$(word 2,$(CASAPATH)) +PYTHONVER := $(shell $(shell make -s -f $(PREFIX)/makedefs VARS=PYTHONVER eval_vars) && echo $$PYTHONVER) +PYDIR := $(PREFIX)/python/$(PYTHONVER) + +ifndef ASAPROOT + ASAPROOT := $(shell pwd) +endif +ATNFD := external-alma +PYRAPD := external/libpyrap + +#PY := $(wildcard python/*.py) +PY := $(wildcard python/*.py python/svninfo.txt) +LIBS := /tmp/_asap.so +BINS := bin/asap +APPS := apps/asap2to3 + +CASAROOT := $(word 1, $(CASAPATH)) +PLATFORM := $(word 2, $(CASAPATH)) +DISTDIR := asap_$(PLATFORM) + +all: module #doc + +module: + @if ( test -f getsvnrev.sh ) ; then /bin/bash getsvnrev.sh ; fi + @cd $(ASAPROOT)/$(PYRAPD); make + @cd $(ASAPROOT)/$(ATNFD); make + @cd $(ASAPROOT)/src; make + @cd $(ASAPROOT)/apps; make + +doc: + @cd $(ASAPROOT)/doc; make + + +install: + @if ( test -f getsvnrev.sh ) ; then /bin/bash getsvnrev.sh ; fi + @if ( test ! -d $(PYDIR)/asap ) ; then mkdir -p $(PYDIR)/asap ; fi + @if ( test ! -d $(PREFIX)/bin ) ; then mkdir -p $(PREFIX)/bin ; fi + @cd $(ASAPROOT)/$(ATNFD); make install + @cd $(ASAPROOT)/$(PYRAPD); make install + @for file in $(LIBS) ; do cp -f $$file $(PYDIR)/asap ; done + @for file in $(BINS) ; do cp -f $$file $(PREFIX)/bin ; done + @for file in $(PY) ; do cp -f $$file $(PYDIR)/asap ; done + @if ( test ! -d $(PREFIX)/share/asap ) ; then mkdir -p $(PREFIX)/share/asap ; fi + @cp -f share/ipythonrc-asap $(PREFIX)/share/asap/ + @for file in $(APPS) ; do cp -f $$file $(PREFIX)/bin ; done + @echo "Successfully installed asap module to" $(PYDIR) + +clean: + @cd $(ASAPROOT)/src; make clean +# @cd $(ASAPROOT)/doc; make clean + @cd $(ASAPROOT)/$(ATNFD); make realclean + @cd $(ASAPROOT)/apps; make clean + @cd $(ASAPROOT)/$(PYRAPD); make clean + +datadist: + @echo "Generating ASAP data archive from aips++ installation..." + @cd $(CASAROOT); tar cfj $(ASAPROOT)/$(DISTDIR)/share/data.tar.bz2 data/ephemerides data/geodetic + @echo "...done." + + +dist: module doc + @cd $(ASAPROOT) + @if ( test -d $(DISTDIR) ) ; then rm -rf $(DISTDIR) ; fi + @mkdir $(DISTDIR) + @mkdir $(DISTDIR)/build $(DISTDIR)/bin $(DISTDIR)/share + @for file in $(LIBS) ; do cp -f $$file $(DISTDIR)/build/ ; done + @for file in $(PY) ; do cp -f $$file $(DISTDIR)/build/ ; done + @for file in $(BINS) ; do cp -f $$file $(DISTDIR)/bin/ ; done + @cp -f share/ipythonrc-asap $(DISTDIR)/share/ + make datadist + @cp -f doc/README $(DISTDIR)/ + @cp -f doc/CHANGELOG $(DISTDIR)/ + @cp -f bin/install.sh $(DISTDIR)/bin/ + @echo "Creating compressed archive..." + @tar jcf $(DISTDIR).tar.bz2 $(DISTDIR) + @rm -rf $(DISTDIR)/ + @echo "Successfully created binary package" $(DISTDIR).tar.bz2 + +.PHONY: install clean Index: /tags/asap-4.4.0+atnf2/README =================================================================== --- /tags/asap-4.4.0+atnf2/README (revision 3150) +++ /tags/asap-4.4.0+atnf2/README (revision 3150) @@ -0,0 +1,51 @@ +Requirements +============ + +* scons >= 1.1 +* rpfits >= 2.19 +* cfitso >= 2 +* python >= 2.5 +* boost >= 1.40 +* casacore >= 1.5 +* wcslib >= 4.13 + +Installation +============ + +ASAP is based on c++ and python. It uses python's standard packaging tool +to build and install:: + + python setup.py install + +If the dependencies are in custom locations there are two ways to build +ASAP: + + * edit the file 'setup.cfg' then run 'python setup.py install' + * give command-line parameters; run 'python setup.py build_ext' with the + options and then 'python setup.py install' + (see python setup.py build_ext --help for the available options) + +Note: The installation must be done as 'root' or using 'sudo' + +Obtaining the data directory +============================ + +ASAP needs some meta-data which updates periodically. +The data repository can be obtained separately after installing ASAP. +Run as root (sudo):: + + asap_update_data + +This will install the data repository into the correct location. + +Creating a binary distribution +============================== + +You can make a binary distribution for you platform by running:: + + python setup.py bdist_egg + +This will create an 'egg' archive in the subdirectory 'dist'. +Send this to asap@atnf.csiro.au so other people can share it. + + Index: /tags/asap-4.4.0+atnf2/SConstruct =================================================================== --- /tags/asap-4.4.0+atnf2/SConstruct (revision 3150) +++ /tags/asap-4.4.0+atnf2/SConstruct (revision 3150) @@ -0,0 +1,203 @@ +import os +import sys +import distutils.sysconfig +import platform +import SCons + +# try to autodetect numpy +def get_numpy_incdir(): + try: + # try to find an egg + from pkg_resources import require + tmp = require("numpy") + import numpy + return numpy.__path__[0]+"/core/include" + except Exception: + # now try standard package + try: + import numpy + return numpy.__path__[0]+"/core/include" + except ImportError: + pass + return "" + +def get_libdir(): + return os.path.basename(distutils.sysconfig.get_config_var('LIBDIR')) + +LIBDIR = 'lib' #get_libdir() + +EnsureSConsVersion(1,0,0) + +opts = Variables("options.cache") +opts.AddVariables( + ("extraroot", "Addition tree to look for packages", None), + ("extraflags", "Additional build flags", None), + PathVariable("casacoreroot", "The location of casacore", + "/usr/local"), + BoolVariable("casacorestatic", + "Link statically against casacore", + False), + ("boostroot", "The root dir where boost is installed", None), + ("boostlib", "The name of the boost python library", + "boost_python"), + ("boostlibdir", "The boost library location", None), + ("boostincdir", "The boost header file location", None), + ("cfitsioroot", + "The root directory where cfistio is installed", None), + ("cfitsiolibdir", "The cfitsio library location", None), + ("cfitsiolib", "The cfitsio library name", "cfitsio"), + ("cfitsioincdir", "The cfitsio include location", None), + ("rpfitslib", "The rpfits library name", "rpfits"), + ("rpfitsroot", + "The root directory where rpfits is installed", None), + ("rpfitslibdir", "The rpfits library location", None), + + ("pyraproot", "The root directory where libpyrap is installed", + None), + ("numpyincdir", "numpy header file directory", + get_numpy_incdir()), + BoolVariable("enable_pyrap", + "Use pyrap conversion library from system", + False), + ("pyraplib", "The name of the pyrap library", "pyrap"), + ("pyraplibdir", "The directory where libpyrap is installed", + None), + ("pyrapincdir", "The pyrap include location", + None), + EnumVariable("mode", "The type of build.", "release", + ["release","debug"], ignorecase=1), + EnumVariable("makedoc", + "Build the userguide in specified format", + "none", + ["none", "pdf", "html"], ignorecase=1), + BoolVariable("apps", "Build cpp apps", True), + BoolVariable("alma", "Enable alma specific functionality", + False), + ) + +env = Environment( toolpath = ['./scons'], + tools = ["default", "utils", "casa"], + ENV = { 'PATH' : os.environ[ 'PATH' ], + 'HOME' : os.environ[ 'HOME' ] }, + options = opts) + +env.Help(opts.GenerateHelpText(env)) +env.SConsignFile() +if not ( env.GetOption('clean') or env.GetOption('help') ): + + conf = Configure(env) + if conf.env.get("extraroot", None): + conf.env.AddCustomPackage('extra') + conf.env.Append(CPPPATH=[distutils.sysconfig.get_python_inc()]) + if not conf.CheckHeader("Python.h", language='c'): + Exit(1) + pylib = 'python'+distutils.sysconfig.get_python_version() + if env['PLATFORM'] == "darwin": + conf.env.Append(FRAMEWORKS=["Python"]) + else: + if not conf.CheckLib(library=pylib, language='c'): Exit(1) + + conf.env.AddCustomPackage('boost') + libname = conf.env["boostlib"] + if libname.find(".") > -1 and os.path.exists(libname): + conf.env.AppendUnique(LIBS=[env.File(libname)]) + else: + if not conf.CheckLibWithHeader(libname, + 'boost/python.hpp', language='c++'): + Exit(1) + + if not conf.CheckLib("m"): + Exit(1) + # test for cfitsio + conf.env.AddCustomPackage('cfitsio') + libname = conf.env["cfitsiolib"] + if not conf.CheckHeader("fitsio.h"): + #SuSE is being special + conf.env.AppendUnique(CPPPATH=['/usr/include/libcfitsio0']) + if not conf.CheckHeader("fitsio.h"): + Exit(1) + if libname.find(".") > -1 and os.path.exists(libname): + conf.env.AppendUnique(LIBS=[env.File(libname)]) + else: + if not conf.CheckLib(libname, language='c'): + Exit(1) + + conf.env.AddCustomPackage('rpfits') + if not conf.CheckLibWithHeader(conf.env["rpfitslib"], "RPFITS.h", + language="c"): + Exit(1) + + libpath = "" + for p in [conf.env["casacoreroot"], conf.env.get("extraroot", "")]: + pth = os.path.join(p, "include", "casacore") + if os.path.exists(pth): + libpath = os.path.join(p, LIBDIR) + conf.env.AppendUnique(CPPPATH=[pth,pth+'/..']) + break + cclibs = ["casa_python", "casa_images", "casa_ms", + "casa_coordinates", "casa_lattices", + "casa_fits", "casa_measures", "casa_scimath", + "casa_scimath_f", "casa_tables", "casa_casa"] + if conf.env["casacorestatic"]: + libs = [ env.File(os.path.join(libpath, "lib"+lib+".a")) \ + for lib in cclibs ] + else: + conf.env.AppendUnique(LIBPATH=libpath) + if not conf.CheckLibWithHeader("casa_casa", "casa/aips.h", + language='c++', autoadd=0): + Exit(1) + libs = cclibs + conf.env.PrependUnique(LIBS=libs) + + if not conf.CheckLib('stdc++', language='c++'): Exit(1) + if conf.env["alma"]: + conf.env.Append(CPPFLAGS=['-DUSE_CASAPY']) + if conf.env.get("extraflags"): + flags = conf.env.ParseFlags(conf.env["extraflags"]) + conf.env.MergeFlags(flags) + env = conf.Finish() + +opts.Save('options.cache', env) + +env["version"] = "4.3.x" + +if env['mode'] == 'release': + if env["PLATFORM"] != "darwin": + env.Append(LINKFLAGS=['-Wl,-O1', '-s']) + env.Append(CCFLAGS=["-O2"]) + env.Append(CCFLAGS=["-std=c++11"]) +else: + env.Append(CCFLAGS=["-g", "-W", "-Wall"]) + +# Export for SConscript files +Export("env") + +# build externals +ext = env.SConscript("external-alma/SConscript") + +# build library +so = env.SConscript("src/SConscript", variant_dir="build", duplicate=0) + +apps = env.SConscript("apps/SConscript") + +# test module import, to see if there are unresolved symbols +def test_module(target,source,env): + pth = str(target[0]) + mod = os.path.splitext(pth)[0] + sys.path.insert(2, os.path.split(mod)[0]) + __import__(os.path.split(mod)[1]) + print "ok" + return 0 + +def test_str(target, source, env): + return "Testing module..." + +taction = Action(test_module, test_str) +env.AddPostAction(so, taction) + +if env.GetOption("clean"): + Execute(Delete(".sconf_temp")) + Execute(Delete("options.cache")) + Execute(Delete(".sconsign.dblite")) +if env["makedoc"].lower() != "none": + env.SConscript("doc/SConscript") Index: /tags/asap-4.4.0+atnf2/admin/generate_data.sh =================================================================== --- /tags/asap-4.4.0+atnf2/admin/generate_data.sh (revision 3150) +++ /tags/asap-4.4.0+atnf2/admin/generate_data.sh (revision 3150) @@ -0,0 +1,14 @@ +#!/bin/sh + +if [ "$AIPSPATH" != "" ]; then + a_root=`/bin/echo $AIPSPATH | awk '{print $1}'` +else + echo "No aips++ installation found" + exit 1 +fi + +target="`pwd`/data.tar.gz" +cd $a_root +echo "Generating ASAP data archive ${target} from aips++ installation." +tar cfz ${target} data/ephemerides data/geodetic +echo "Done." Index: /tags/asap-4.4.0+atnf2/admin/log2req.pl =================================================================== --- /tags/asap-4.4.0+atnf2/admin/log2req.pl (revision 3150) +++ /tags/asap-4.4.0+atnf2/admin/log2req.pl (revision 3150) @@ -0,0 +1,31 @@ +#!/usr/bin/perl -w + +use strict; + +use Getopt::Long; + +my $purge = 0; + +GetOptions('purge'=>\$purge); + +my @log = <>; +my $log = join '', @log; + +while ($log =~ /REQUIREMENT:\s*(R.*?):.?E.?N.?D.?R.?E.?Q/sg) { + $_ = $1; + s/\n//; + + if ($purge) { + next if (/& Deferred &/); + next if (/& Obsolete &/); + next if (/& Done.? &/); + next if (/& Removed &/); + } + + s/& Done1 & /& Completed &/; + s/& Done & /& Completed &/; + + s/(&[^&]*){2}$//; + + print "$_ \\\\\n"; +} Index: /tags/asap-4.4.0+atnf2/admin/newreq.sh =================================================================== --- /tags/asap-4.4.0+atnf2/admin/newreq.sh (revision 3150) +++ /tags/asap-4.4.0+atnf2/admin/newreq.sh (revision 3150) @@ -0,0 +1,7 @@ +#!/bin/sh -f + +touch reqsum.tex +latex requirements2 +\rm reqsum.tex +./log2req.pl -purge requirements2.log > reqsum.tex +latex requirements2 Index: /tags/asap-4.4.0+atnf2/admin/reqtable.tex =================================================================== --- /tags/asap-4.4.0+atnf2/admin/reqtable.tex (revision 3150) +++ /tags/asap-4.4.0+atnf2/admin/reqtable.tex (revision 3150) @@ -0,0 +1,29 @@ +\documentclass[11pt]{article} +\usepackage{a4} +\usepackage{longtable} + +% Adjust the page size +\addtolength{\oddsidemargin}{-0.4in} +\addtolength{\evensidemargin}{+0.4in} +\addtolength{\textwidth}{+0.8in} + +\setlength{\parindent}{0mm} +\setlength{\parskip}{1ex} + + +\begin{document} + +\begin{longtable}{|l|l|l|c|l|} + +\hline +\bf Requirement & & \bf Status & \bf Priority & \bf Effort \\ +\hline +\endhead +\hline +\endfoot +\input{reqsum.tex} + +\end{longtable} + + +\end{document} Index: /tags/asap-4.4.0+atnf2/admin/requirements1.tex =================================================================== --- /tags/asap-4.4.0+atnf2/admin/requirements1.tex (revision 3150) +++ /tags/asap-4.4.0+atnf2/admin/requirements1.tex (revision 3150) @@ -0,0 +1,1060 @@ +\documentclass[11pt]{article} +\usepackage{a4} +\usepackage{calc} +\usepackage{smartref} +\usepackage[dvips]{graphicx} + +% Adjust the page size +\addtolength{\oddsidemargin}{-0.4in} +\addtolength{\evensidemargin}{+0.4in} +\addtolength{\textwidth}{+0.8in} + +\setlength{\parindent}{0mm} +\setlength{\parskip}{1ex} + + +\title{ATNF Single Dish Spectral Line Software Requirements } +\author{Chris Phillips \& Malte Marquarding} + +\newcounter{requirement} +\addtoreflist{requirement} +\newcommand{\reqref}[1]{R\ref{#1}-\requirementref{#1}} + +\newcommand{\makenote}[1]{{\bf \tt \em#1}} + +\newcommand{\anitem}[2]{\smallskip \parbox[t]{2cm}{#1}\parbox[t]{\textwidth-2cm}{#2}} + +\newcommand{\showreqcounter}{{\stepcounter{requirement} + \bf R\arabic{section}.\arabic{subsection}-\arabic{requirement}}} + +\newcommand{\requirement}[2]{ + \hspace*{2mm}\begin{minipage}{\textwidth-2mm} + \setlength{\parindent}{-2mm} + \showreqcounter\ #1 \\ + \hspace*{1cm} {\em Priority #2} + \end{minipage} +} + +\newcommand{\extendedrequirement}[2]{ + \hspace*{2mm}\begin{minipage}{\textwidth-2mm} + \setlength{\parindent}{-2mm} + \showreqcounter\ #1 + \hspace*{1cm} {\em Priority #2} + \end{minipage} +} + +\newcommand{\reqeqn}[1]{\\\hspace*{1cm} $#1$} + +\let\oldsection\section +\renewcommand{\section}[1]{\setcounter{requirement}{0}\oldsection{#1}} + +\let\oldsubsection\subsection +\renewcommand{\subsection}[1]{\setcounter{requirement}{0}\oldsubsection{#1}} + +\begin{document} + +\maketitle + +\section{Introduction} + +The spectral line single-dish software {\tt spc} at the ATNF has +become increasingly difficult to maintain. There also have been many +requests for features which are not possible to implement without +major change to this package. The interface is based on outdated +operating systems and programming languages. The decision was made to +replace {\tt spc} with a new package which supports existing and +future ATNF single-dish instrumentation. A survey of users was taken +into account creating this requirements document. + +\section{Scope} + +The software should be able to process all spectral line single-dish +observations from ATNF telescopes (Parkes, Mopra \& Tidbinbilla). This +includes reading the data produced by the telescope, calibration and +reduction of the data and basic analysis of the data such as fitting +line profiles. + +It has been assumed that the following processing is out of the scope +of the new software. +\begin{itemize} +\item Raster or ``on-the-fly'' mapping (This is handled by +``livedata'' and gridzilla). +\item Very complex or specific data processing. (A route into + Class\footnote{Part of the GLIDAS software package, produced by + Institut de Radio Astronomie Millime\'trique http://www.iram.fr} + should be available for advanced processing). +%%TODO%% give example +\item Continuum data. +\item Pulsar timing observations. +\end{itemize} + +\section{Priorities} + +Requirements have been given a value of 0 to 3. The ``0'' priority +functions will be implemented in a demonstrator version of the +software (with no GUI interface). The other requirements will be +implemented mainly depending on priority, with ``1'' the +highest. Priority 3 and some priority 2 requirements will probably not +get implemented in the first released version of the software. + +\section{User Interface} + +The user interface (UI) is the most important part of a single dish +processing package, but probably the most difficult to get right. The +UI for this software will consist of three parts. +\begin{itemize} + \item A graphical user interface (GUI). + \item An interactive command line interface (CLI). + \item A scriptable interface for batch processing. +\end{itemize} + +The CLI and scriptable interface may essentially be the same. + +The software does not {\em need} to be able to run solely from a +``vt100'' style terminal. It can be assumed that the user is running +the software from within a windowed (i.e. X11) environment. This will +mean it will not necessarily be possible to run the software remotely +over a slow network connection (e.g. internationally or from home). +Where possible, operations on the data should be possible from all +three aspects of the user interface. + +The user interface needs to be implemented so that the user can easily +and transparently work on spectra either one at a time or by +processing multiple spectra in parallel. This means there must be an +easy way to select specific or multiple spectra to display or process. + +\subsection{Graphical User Interface} + +The GUI is intended to be the main interactive interface with the +software. + +\smallskip +\requirement{It should be simple, intuitive and +uncluttered. Specifically, use of many windows simultaneously should +be discouraged, as should hiding functionality behind layers of dialog +boxes.}{1} + +\requirement{The plotting window should be a major component of the GUI +control, not a separate isolated window.}{1} + +\requirement{The interface should use minimal ``always visible'' + controls, with use of pull down menus and maybe a toolbar for + frequency used functions. }{1} + +\requirement{Keyboard shortcuts should be available.}{2} + +\requirement{Most user preferences (i.e. keywords in the CLI) should +be presented in a popup, tabbed, dialog box.}{2} + +\requirement{When performing line profile fitting, a spreadsheet type +window should be viewable which shows the current parameter values +(amplitude, velocity etc) for each line fitted and allow the user to +change these parameters or set the current value as fixed. This gui +should stay synchronised with any CLI changes to these values.}{2} + +\subsection{Command Line Interface} + +\requirement{While the GUI should be the main interface for new users +and for basic manipulation, some tasks can be more efficiently +performed using a CLI. A virtual CLI could be integrated as part of +the GUI.}{1} + +\requirement{The CLI should have a keyword/argument form and never +prompt the user for specific values (the user should be able to change +values which are retained until they wants to change them again).}{1} + +\requirement{The CLI should be case insensitive and accept minimum +matching and short forms of keywords.}{2} + +\requirement{The user must be able to quickly and easily see from the +command line the available routines and keywords which affect it, so +they can see which parameters may need changing.}{1} + +\subsection{Scripting} + +\requirement{It must be possible to run the software in a scripting +mode. This would be to process large amounts of data in a routine +manner and also to automatically reproduce specific plots etc (So the +scripting must have full control of the plotter). Preferably the +scripting ``language'' and the CLI would be the same. }{1} + +\requirement{It would be worthwhile having a method to auto-generate +scripts (for reduction or plotting) from current spectra history, or +some similar method.}{3} + +\section{Plotter} + +The plotter should be fully interactive and be an integral part of the +GUI and software interface. + +\requirement{It must be able to produce plots of publishable +quality. This includes being able to specify line thickness, character +size, colours, position of axis ticks, axis titles etc and producing +hard copies in postscript and .png format.}{0} + +\requirement{It must be possible to flexibly select the data to plot + (e.g. Tsys vs time etc as well as plots such as amplitude vs channel + number or velocity). Preferably any of the header values for a + selection of scans could be plotted on a scatter plot (e.g. Tsys vs + elevation)}{2} + +\requirement{It must be possible to overlay multiple spectra on a + single plot using different colours and/or different line + styles. (Including multiple stokes data and multiple IFs).}{1} + +\requirement{It must be possible to plot either the individual + integrations (in either a stacked fashion, or using a new subplot + per integration) or some type of average of all the integrations in + a scan.}{2} + +\requirement{Multi-panelling of spectra in an n$\times$m size grid. If + more spectra than can fit on the plot matrix are to be plotted, then + it must be possible to step back and forth between the viewable + spectra (i.e. ``multi-page'' plots). It must be possible to quickly + and easily change the number of plots per page, and define the ``n'' + and ``m'' values.}{1} + +\requirement{When using multi-panelling, it should be possible to + easily change the display to flip between a single spectra display + and multi-panels display (i.e. zoom into a specific sub-window).}{3} + +\requirement{It must be possible to interactively zoom the plot + (channel range selection and amplitude of the spectra etc.) This + includes both GUI control of the zooming as well as command line + control of either the zoom factor or directly specifying the zoom + bounds. }{1} + +\requirement{On a single plot, it should be possible to plot the full + spectrum and a zoomed copy of the data (using a different lie style) + to see weak features. The user must be able to specify the zoom + factor.}{3} + +\requirement{Optionally when stacking multiple spectral plots in one + subwindow, a (user definable) offset in the ``y'' direction should + be added to each subsequent spectra.}{2} + +\requirement{The plotter should automatically update to reflect user +processing, either from the CLI or GUI. The user should have to option +to turn this feature off if they so wish.}{2} + +\requirement{It should be possible to plot individual integrations +(possibly from multiple scans) in a ``waterfall'' plot. This is an +image based display, where spectral channel is along the x-axis of the +plot, time (or integration number) along the y-axis and greyscale or +colour represent the amplitude of spectra. Interactive zooming and +panning of this image should be supported. }{3} + +\requirement{When plotting ``waterfall'' plots, it should be possible +to interactively select regions or points and mark them as invalid +(i.e. to remove RFI affected data). The plotter should also show the +time/velocity of the pixel beneath the cursor.}{3} + +\requirement{It should be possible to export the ``waterfall'' plot +images as a FITs file, for user specific analysis.}{3} + +\requirement{Line markers overlays, read from a catalogue should be + optionally available. This would include the full Lovas catalogue, + the JPL line catalogue, radio recombination lines and a simple user + definable catalogue. The lines would be Doppler corrected to the + line velocity. The user must be able to plot just a sub-section of + the lines in any specific catalogue (to avoid clutter).}{2} + +\requirement{Optionally plot fitted functions (e.g line profiles or + baseline fit). If multiple components (e.g. Gaussians) have been + fit, it should be possible to show the individual functions or the + sum of the components}{1} + +\requirement{It should be possible to plot the residual data with or + without subtraction of fit functions. This includes plotting the + spectra with or without baseline removal and the residual after + subtracting Gaussian fits. The default should be to plot the data + with baseline subtracted but profile fits not subtracted.}{2} + +\requirement{Basic header data (source name, molecule, observation + time etc) should be optionally shown, either on the plot or next to + it. This may either consist of a set of values, or only one or two + values the user specifically wants to see (source name and molecule, + for example). Preferably the user would be able to define where on + the plot the header info would appear.}{2} + +\requirement{Optionally, relevant data such as the current mouse + position should be displayed (maybe with a mode to display an + extended cross, horizontal or vertical line at the current cursor + position).}{2} + +\requirement{The user should be able to define simple + annotations. This would include text overlay and probably simple + graphics (lines, arrows etc).}{3} + +The user must be able to use the plotter window to interactively set +initial values and ranges used for fitting functions etc. The use of +keyboard ``shortcuts'' or other similar ``power user'' features should +be available to save the time of experienced users. + +The plotter should be used to set the following values: + +\requirement{Range of spectral points needed for specific tasks (See + requirement \reqref{ref:chansel})}{1} + +\requirement{Initial Gaussian parameters (velocity, width, amplitude) +for profile fitting.}{1} + +\requirement{Change the parameter values of existing line profile +fits, or channel ranges used for baseline fits.}{3} + +\section{Functionality} + +\subsection{Import/export} + +The software needs a set of import/export functions to deal with a +variety of data formats and to be able to exchange data with other +popular packages. These functions should be flexible enough to allow +the user to perform analysis functions in an different package and +re-import the data (or vice versa). The import function must be +modular enough to easily add new file formats when the need arises. +To properly import data, extra information may have to be read from +secondary calibration files (such as GTP, Gated Total Power, for 3~mm +wavelength data taken with Mopra). The import functions should be +flexible enough to gracefully handle data files with missing headers +etc. They should also be able to make telescope and date specific +corrections to the data (for ATNF observatories). + +The software must be able to read (import) the following file formats. + +\requirement{The rpfits file format produced by all current ATNF + correlators.}{0} + +\requirement{SDFITS (currently written by {\tt SPC}).}{1} + +\requirement{Simple ``image'' FITS (used by CLASS}{2} + +\requirement{Historic ATNF single dish formats (Spectra, SPC, +SLAP). Possibly a set of routines to translate these formats to SDFITs +would suffice.}{3} + +\requirement{PSRFIT for pulsar spectroscopy.} + +\requirement{For online analysis, the software should be able to read +an rpfits file which is is still currently open for writing by the +telescope backend processor.}{1} + +\requirement{Data which has been observed in either a fixed frequency +or Doppler tracked fashion needs to be handled transparently.}{1} + +The software should be able to export the data in the following formats. + +\requirement{Single Dish FITS.}{1} + +\requirement{Simple ``image'' FITS (used by CLASS. It must be possible +to to export multiple spectra simultaneously, using default file name +and postfix.}{2} + +\requirement{In a format which can be imported by other popular + packages such as Class. }{2} + +\requirement{Simple ascii format, suitable for use with programs such + as Perl, Python, SuperMongo etc.}{2} + +\requirement{The exported data should retain as much header data as +possible. It should also be possible to request specific data be +written in the desired form (B1950 coordinates, optical velocity +definition etc).}{2} + +\requirement{The import function should apply relevant corrections +(especially those which are time dependent) to specific +telescopes. See $\S$\ref{sec:issues} for a list of currently known +issues.}{1} + +\subsection{Sky subtraction} +\label{sec:skysubtraction} +To remove the effects of the passband filter shape and atmospheric +fluctuations across the band, sky subtraction must be performed on the +data. The software must be able to do sky subtraction using both +position switching (quotient spectra) and frequency switching +techniques. + +\requirement{\label{ref:skysub} Position switched sky subtraction +should be implemented using the algorithm \medskip\reqeqn{T_{ref} +\times \frac{S}{R} - T_{sig}} -- removes continuum\bigskip +\reqeqn{T_{ref} \times \frac{S}{R} - T_{ref}} -- preserves +continuum\medskip}{0} + +\requirement{The user should be able to specify an arbitrarily complex +reference/source order (which repeats), which can then be used to make +perform multiple sky subtractions in parallel.}{3} + +\requirement{Frequency switched sky subtraction should be + supported. (Ref. Liszt, 1997, A\&AS, 124, 183) }{2} + +%\requirement{For wideband multibit sampled data it may be desirable or +%even required to assume Tsys has a frequency dependency. Appropriate +%sky subtraction algorithms will need to be investigated.}{3} + +\requirement{For pulsar binned data, the (user specified) off pulse +bins can be used as the reference spectra. Due to potentially rapid +amplitude fluctuations, sky subtractions may need to be done on a per +integration basis.}{3} + +Multibeam systems can observe in a nodding fashion (called MX mode at +Parkes), where the telescope position is nodded between scans so that +the source is observed in turn by two beams and a reference spectra +for one beam is obtained while the other is observing the target source. + +\requirement{For multibeam systems, it must be possible to perform sky +subtraction with the source and reference in an alternate pair of +beams}{2} + +\subsection{Baseline removal} + +Baseline removal is needed to correct for imperfections in sky +subtraction. Depending on the stability of the system, the residual +spectral baseline errors can be small or quite large. Baseline removal +is usually done by fitting a function to the (user specified) line +free channels. + +\requirement{The software must be able to do baseline removal by + fitting a n'th order polynomials to the line free channels using a + least squares method.}{0} + +%\requirement{The baseline fitting should be reversible, i.e. the fit +%parameters must be retained.}{2} + +\requirement{Removal of standing wave ripples should be done by +fitting a Sine function to the line free channels.}{2} + +\requirement{``Robust'' fitting functions should be available, which are more + tolerant to RFI.}{1} + +\requirement{Automatic techniques for baselining should be + investigated.}{3} + +\subsection{Line Profile Fitting} + +The user will want to fit multicomponent line profiles to the data in +a simple manner and be able to manipulate the exact fitting +parameters. + +\requirement{The software must be able to do multi-component Gaussian + fitting of the spectra. The initial amplitude, width and velocity of + each component should be able to be set by the user and specific + values to be fit should be easily set.}{0} + +\requirement{The reduce Chi square (or similar statistic) of the fit +should given to the user, so that they can easily see if adding extra +components give a statistically significant improvement to the fit.}{1} + +%\requirement{The fit parameters should be stored with the data so that +%the user can work on multiple data sets simultaneously and experiment +%with different fitting values. These values should be saved to disk +%along with the data.}{1} + +\requirement{For multiple polarisation data, the individual stokes +parameters or polarisation products should be fit independently.}{1} + +\requirement{There should be an easy way of exporting the fit +parameter from multiple spectra, e.g. as an ASCII table.}{2} + +\requirement{It should be also possible to do constrained fitting of +multiple hyperfine components, e.g. the NH$_3$ hyperfine +components. (The constraints may be either the frequency separation of +the individual components or the amplitude ratio etc.)}{3} + +\requirement{It must be possible to alter the line profile fit +parameter values by hand at any stage.}{2} + +\requirement{It must be possible to ``fix'' particular values of the + line profile parameters, so that only subset of lines or (say) the + width of a line is fit.}{1} + +\requirement{The software should allow hooks for line profile shapes +other than Gaussian to be added in the future, possible user +specified.}{2} + +%\makenote{Should it be possible to attach multiple sets of fits to the +%data (similar to CL tables in classic AIPS), so the user can +%experiment with different ways of fitting the data?} + +%\makenote{Should calculations of rotational temperatures etc be +%handled when fitting hyperfine components, or should the user be doing +%this themselves?} + +\subsection{Calibration} + +The software should handle all basic system temperature (Tsys) and +gain calibration as well as opacity corrections where relevant. The +Tsys value should be contained in the rpfits files. The actual +application of the T$_{\mbox{sys}}$ factor will be applied as part of +the sky subtraction ($\S$\ref{sec:skysubtraction}). The units of Tsys +recorded in the data may be either in Jy or Kelvin, which will affect +how the data is calibrated. The rpfits file does {\em not} distinguish +if the flux units are Kelvin or Janskys. + +\requirement{Gain elevation corrections should be implemented using a +elevation dependent polynomial. The polynomial coefficients will be +telescope and frequency dependent. They will also have a (long term) +time dependence.}{1} + +\requirement{The user may wish to supply their own gain polynomial.}{2} + +\requirement{When required by the user, the spectral units must be +converted from Kelvin to Jansky. At higher (3mm) frequencies this +conversion is often not applied. The conversion factor is\medskip +\reqeqn{\mbox{Flux (Jy)} = \frac{T \times 2 k_b \times +10^{26}}{\eta A}},\medskip\\where $k_b$ is Boltzmann's constant, A is +the illuminated area of the telescope and $\eta$ is the efficiency of +the telescope (frequency, telescope and time dependent)}{1} +%%TODO%% Use planks formula here? + +\requirement{In some cases the recorded Tsys values will be +wrong. There needs to be a mechanism to scale the Tsys value and the +spectrum if the Tsys value has already been applied (i.e. a simple and +consistent rescaling factor).}{2} + +\requirement{The data may need to be corrected for opacity effects, +particularly at frequencies of 20~GHz and higher. The opacity factor +to apply is given by\medskip\reqeqn{C_o = e^{\tau/cos(z)}}\medskip\\ +where $\tau$ is the opacity and z is the zenith angle (90-El). These +corrections will generally be derived from periodic ``skydip'' +measurements. These values will not be contained in the rpfits files, +so there should be a simple way of the software obtaining them and +interpolating in time (the user should not {\em have} to type them in, +but may want to). Reading in an ascii file which contains the skydip +data along with a time-stamp would be one possibility.}{1} + +\requirement{For wideband, multibit observations, the software should +have the option to handle Tsys which varies across the band. The exact +implementation will have to be decided once experience is gained with +the new Mopra digital filterbank. This will affect the sky subtraction +algorithms (requirement \reqref{ref:skysub}).}{2} + +%\makenote{Is the dependence of gain on frequency weak enough for one +%set of coefficients for each receiver, or is a full frequency dependent +%set of values needed?} + +%\makenote{Should it be possible to read ``correct'' Tsys values from +%an external ascii file?} + +\subsection{Editing \& RFI robustness} + +In a data set with many observations, individual spectra may be +corrupted or the data may be affected by RFI and ``birdies''. The user +needs to be able to easily flag individual spectra or channels. This +may affect other routines such as sky-subtraction, as this will +disrupt the reference/source sequence. + +\requirement{The user must be able to set an entire spectra or part +thereof (individual polarisation, IF etc) as being invalid. The +effected channels should either be blanked or interpolated depending +on the user wishes. When blanked data is plotted, the plotting routine +should also either interpolate the data on the fly or show a blank in +the spectrum, depending on the users preferences.}{1} + +\requirement{The user must be able to indicate an individual spectral +point or range of spectral points are invalid. This should be applied +to an individual spectra, or set of spectra.}{1} + +\requirement{The user should be able to plot the average spectral flux +across the band, or part of the band, as a function of time and +interactively select sections of data which should be marked as +invalid (similar to IBLED in classic aips).}{3} + +\requirement{Where relevant, fitting routines etc should have the +option of selecting RFI tolerant (``robust'') algorithms. This will +require investigating alternate fitting routines other than the +least-squares approach.}{3} + +\requirement{A routine to automatically find birdies or RFI corrupted +data and indicate the data as invalid would be useful.}{3} + +\requirement{Other routines must be able to cope with portions of data +which are marked as invalid.}{1} + +\subsection{Spectra mathematics and manipulation} + +A flexible suite of mathematical operations on the spectra should be +possible. This should include options such as adding, subtracting, +averaging and scaling the data. For common operations such as +averaging and smoothing, it must be simple for the user to invoke the +function (i.e. not to have to start up a complex spectral +calculator). Where it makes sense, it should be possible to manipulate +multiple spectra simultaneously. + +The spectral manipulations which should be available are: + +\requirement{Add or subtract multiple spectra.}{1} + +\requirement{Averaging multiple spectra, with optional weighting based +on Tsys, integration or rms. If the velocity of the spectra to be +averaged is different, the data should be automatically aligned in +velocity.}{0} + +\requirement{Various robust averaging possibilities (e.g. median +averaging, clipped means etc) should be possible.}{2} + +\requirement{Re-sampling or re-binning of the data to a lower (or +higher) spectral resolution (i.e. change the number of spectral +points). The re-sampling factor may not necessarily be an integer.}{2} + +\requirement{It must be possible to shift the data in + ``frequency/velocity''. This should include channel, frequency and + velocity shifts of an arbitrary amount.}{1} + +\requirement{Spectral smoothing of the data. Hanning, Tukey, boxcar +and Gaussian smoothing of variable widths should be possible.}{1} + +\requirement{Scaling of the spectra.}{1} + +\requirement{Calculate basic statistical values (maximum, minimum, +rms, mean) on a range of spectral points. The range may not be +contiguous. The calculated rms value should be retained with the +spectra so it can be optionally used for weighted averaging of +spectra.}{1} + +\requirement{It must be possible to calculate the flux integral over a +range of channels. The units should be Jy.km/s (or Kelvin.km/s). The +channel range for the calculation should be specific via the GUI or +CLI.}{2} + +\requirement{It must be possible to calculate the numerical ``width'' +of a line (full width at half maximum type measurement). This should +be calculated by specifying a channel range and finding the maximum +value in this range and then finding the interpolated crossing point +of the data as a user defined fraction of the maximum (default +50\%). The profile width and velocity mid-point should then be +computed. If the profile shape is complex (e.g. double arch) with +multiple crossing points of the fraction value, the minimum and +maximum width values should be calculated. There should be the option +of using a user specified ``maximum value''.}{2} + +\requirement{The user must be able to easily change the rest-frequency +to which the velocity is referenced.}{1} + +\requirement{FFT filtering for high- and lowpass filtering and +tapering.}{3} + +\requirement{It should be possible to FFT the data to and from power + spectra to the autocorrelation function.}{2} + +\requirement{The user may wish to compute the cross correlation +function of two spectra. The result should be a standard ``spectra'', +which can be displayed and analysed using other functions (max, rms +etc).}{3} + +\requirement{Complex experiment specific processing can often be done +using a series of the simple of basic functions. A spectral calculator +options should be added to the CLI to perform a series of +manipulations on a set of spectra.}{3} + +The user may want to perform specific analysis on the data using the +functionality above, but wish to do the manipulation between two +polarisations or IFs. Allowing the functions to also, optionally, +specify specific polarisations or IF would be an implementation and +interface nightmare. The simplest solution is the allow the data to be +``split'' into separate spectra. + +\requirement{It must be possible to take multi IF, multibeam or +polarisation data and split out the individual spectral portions to +form self contained spectra.}{2} + +\subsection{Polarimetry} + +The software must fully support polarmetric analysis. This includes +calibration and basic conversions. Observations may be made with +linear or circular feed and the backend may or may not compute the +cross polarisation products. As such the software must cope with a +variety of conversions. The software should be able to calculate +stokes parameters with or without solving for leakage terms. + +%\makenote{It is debatable whether stokes I is the sum or average or +%two dual polarisation measurements.} + +\requirement{All functions on the data (calibration, sky subtraction +spectral mathematics) must support arbitrary, multiple, polarisation +(linear, circular \& stokes and single, dual \& cross +polarisations.}{1} + +\requirement{It must be possible to calculate stokes I from single or +dual polarisation observations.}{1} + +\requirement{Average a mixture of dual polarisation and single +polarisation data and form average stokes I (e.g. for a long +observation of a source, in which one polarisation is missing for some +time.}{3} + +\requirement{Full stokes parameters should be obtained from dual pol +(linear or circular) observations where the cross polarisation +products have been calculated.}{1} + +%\requirement{If the observations used linear polarisations and the +%cross polarisations were not computed, the source needs to be +%observed with the feeds set at least 3 different parallactic angles +%(note that if dual linear feeds are available, 2 orthogonal +%parallactic angles are obtained at once). The Stokes parameters can be +%solved using a least squares fit to the equation: +%\reqeqn{Iu/2 + Ip * cos^2 (PA + p)},\\ +%where PA is the linear feed position angle, p is the polarisation +%angle, Iu and Ip and the unpolarised and linearly polarised +%intensity. {\em Stolen from SPC. I need to write this in more useful +%language. Is this technique likely to be used anymore?.}}{3} + +\requirement{If dual circular polarisation measurements are taken, +without computing the cross products, the software should still be +able to compute stokes I and V.}{2} + +\requirement{The software should be able to calculate leakage terms +from a calibrator source and correct the data either before or after +conversion to Stokes. (ref. Johnston, 2002, PASA, 19, 277)}{3} + +\requirement{The software should be able to determine absolute +position angle from a calibrator source and correct the data either +before or after conversion to Stokes.}{3} + +\requirement{Zeeman splitting factors should be derived from +(previous) profile fitting and the left and right circular +polarisations. The velocity shift varies linearly with the magnetic +field, but the scaling factor depends on the molecule and +transition. Scaling factor for common transitions should be known by +the software and the user able to enter factors for less common +transitions. Correctly identifying Zeeman pairs is crucial in getting +the correct result. The software should attempt to make an initial +guess of pairs (based on component velocity and width) but make the +user confirm and override the pairing if required.}{3} + +\subsection{Data Selection} +While the software is running the user will usually have loaded +multiple (possibly many) spectra each of which may have multiple IFs, +data from multiple beams and multiple polarisations. The user will +want to be able to quickly flip from considering one spectra to +another and, where relevant, want to perform parallel processing on +multiple spectra at once (e.g. baselining a sequence of on/off +observations of the same source which will later be averaged +together). + +\requirement{The software needs an easy-to-use mechanism to select +either individual or multiple spectra for viewing, parallel processing +etc.}{1} + +\requirement{An easy-to-use mechanism to select individual IFs, beams +or polarisations is needed.}{1} + +\requirement{\label{ref:chansel} The range of spectral points to use +for baseline removal, statistical calculations, RFI editing, analysis +etc must be easily set by the user from both the CLI and GUI. From the +CLI there must be the option of setting the range using a variety of +units (channel number, velocity, frequency). The selection range will +probably not be a contiguous set of channels, but many sets of +disjoint channel ranges. For some tasks (such as baseline subtraction +and statistical values), the channel range should be retained and be +available as a plot overlay.}{1} + +\requirement{When performing baseline subtraction on many spectra +simultaneously, the software should have a mechanism for identifying +``on'' and ``off'' spectra and automatically selecting the signal and +quotient spectra. The algorithm needs to cope with on/off/on/off +sequences as well as off/on/on/off. If an individual quotient spectra +has been marked as invalid, an alternative should be found.}{3} + +\requirement{The software should be able to select sets of sources +based on simple regular expression type filtering (wild cards) on a +range of header values. Examples include G309$*$ or G309$*$w to select +on source name, or NH3$*$ to select on molecule name.}{3} + +\subsection{Plugins} + +\requirement{It would be desirable to support ``plugins'', user +definable functions for specific processing. The plugin code must have +full access (read/write) to the spectra data and headers. It should +also be possible to create new spectra which the software treats the +same as the original data. Preferably some (limited) access to the +plotter would also be possible and a number of the standard functions +accessible as ``library'' routines.}{3} + +\subsection{Pipelining} + +\requirement{Some sort of pipelining mode is required. This would +involve doing a quotient spectra, applying appropriate calibration and +possibly fitting a Gaussian to any lines present.}{3} + +\subsection{Methanol Multibeam Survey} + +The software may need to support reduction of data from the methanol +multibeam project. If so the pipelining will need to be flexible and +powerful enough to support this. + +\subsection{Miscellaneous functionality} + +\requirement{The software should be able to take a simple ``grid'' of +observations (normally a set of observations in a cross pattern on the +sky) and, for a subset of channels, fit the position of the +emission. The fit positions should be either plotted on the screen or +exported in a simple ascii form.}{3} + +\requirement{The kinematic distance of a source should be calculated +using basic Galactic rotation models. Multiple Galactic rotation +models must be supported and a mechanism for easily adding more.}{3} + +\requirement{For 1420 MHz observations of HI, the rms (Tsys) values +vary significantly across the band. The software should be able to +compute the rms as a function of frequency across the spectra from the +off-pulse data and then be able to plot n-sigma error bars on the +spectra.}{3} + +\requirement{It should be possible to take a selection of calibrated +spectra which are then passed to the ``Gridzilla'' program to produce +an image cube. Analysis of this cube would be done using external +programs (e.g. Miriad, aips++)}{3} + +\section{Help} + +\requirement{There should be built-in web-based documentation, which +can be easily kept up-to-date}{1} + +\requirement{A short and simple end-to-end cookbook for basic data +analysis should be available.}{1} + +\section{Data and meta-data} + +\requirement{The software must be capable of handling multi-IF + (potentially dozens of IFs) and multi-beam data with arbitrary + polarisation (e.g. single pol, dual pol, full stokes etc).}{1} + +\requirement{The software should handle pulsar binned data for pulsar +absorption experiments.}{3} + +\subsection{History} + +\requirement{A user viewable history of data processing steps should +be kept as part of the data. Where possible this should be retained +when data is imported from other packages.}{1} + +\requirement{It should be possible to use the history information to +create template pipeline scripts for batch processing.}{2} + +\subsection{Multiple IFs} + +\requirement{If multiple IFs are present (currently Tidbinbilla can +produce two IFs and the new wideband spectrometer for Mopra may have +dozens of IFs), the software should handle the data +transparently. Potentially each IF may have a significantly different +sky frequency and be observing a different molecule or transition with +a different rest frequency. From the users point of view, +simultaneously obtained IFs should be kept within the same +``container'' (not split into a myriad of separate ``container'').}{1} + +%\makenote{Does the case of multiple lines (so multiple +%rest frequencies) within a single IF need special attention?} + +\subsection{Multibeam} + +\requirement{Basic handling of multibeam data should be possible (ie +in general each beam will be treated as a separate observation, but +all within the same container. The user should be able to view or +process either individual beams or all beams in parallel.}{2} + +\requirement{The use of a single beam observing a source and the +rest of the beams as reference beams for sky-subtraction should be +investigated.}{2} + +\subsection{Robust fitting} + +\requirement{If robust fitting using median filtering is used, then +the individual integrations from the observations should {\em not} be +averaged when the data is imported, but retained within a single +container. Inspection of this data should be optionally of the averaged +or individual data.}{2} + +\subsection{Fit parameters} + +\requirement{The fitting parameters for functions which have been fit +to the data (e.g. for baseline removal or Gaussian fits) should be +retained as an integral part of the data and stored permantely on +disk.}{1} + +\requirement{It must be possible to export fitting values in an +appropriate form. (i.e. ascii text format)}{1} + +\requirement{It should be possible to ``undo'' functions which have +been subtracted from the data (e.g. baseline polynomials).}{3} + +\subsection{Coordinate frames and units} + +\requirement{Coordinate frames and unit selection and handling needs +to be flexible and relatively transparent to the user (i.e. if the +users preference is for LSRK velocities, they do not need to worry +about the reference frame in which the data was observed).}{1} + +\requirement{At a minimum the following reference frames and +conventions should be handled: \setlength{\parindent}{0pt} + +\smallskip +\anitem{Position}{(RA,Dec) in J2000 \& B1950 (as well as other + arbitrary epochs), Galactic, (Az,El).} + +\anitem{Frequency}{Velocity (Topocentric, Geocentric, Barycentric, + Heliocentric, kinematical LSR, dynamical LSR, Rest), Frequency + (MHz, GHz), channel number.} + +\anitem{Velocity}{ Optical, Radio, Relativistic.} + +\anitem{Flux}{ Jansky, Kelvin (mJy etc).}}{1} + +\requirement{All data should be internally labelled with the + appropriate coordinate frame and units. If this information is + ambiguous for some reason, it should be set when the data is imported + and the user should not have to worry about it again.}{1} + +\requirement{It should be clear to the user what coordinate frame +(velocity, position etc) the data is being presented as.}{1} + +\subsection{Meta-data} + +A comprehensive set of header data should be read from the input data +files. In general all meta-data available in the rpfits file should be +retained. The user may wish to enter some specific values by hand. + +\requirement{All header data should be viewable and editable by the +user. This includes changes such as scaling the given Tsys values.}{2} + +\requirement{Missing header data should be handled gracefully, +i.e. the software should fill the values with ``blanks'' and be able +to continue to process the data if possible.}{1} + +\requirement{The user must be able to add missing header data, which +is not present in the RPFITs file. It must be possible to add the same +header data to multiple scans simultaneously.}{2} + +\extendedrequirement{ +The following header data would be required per scan: +\begin{itemize} + \item Source name + \item Scan type (signal or reference) + \item Integration time + \item Scan length (actual time of observation, $\ge$ integration time) + \item Telescope + \item UT time and date of observation + \item Telescope elevation of observation + \item Parallactic angle + \item Beam size + \item Scan ID + \item Observer + \item Project + \item Polarisation + \item Receiver + \item Telescope coordinates + \item Weather info (temperature, pressure, humidity) + \item LO chain setup + \item User axis display preference (LSR velocity, frequency etc). +\end{itemize} +}{1} + +\extendedrequirement{ +\label{req:if} +The following header data is required for each IF, beam etc: +\begin{itemize} +\item Source coordinates and coordinate frame +\item Frequency/velocity axis definition and type +\item System Temperature +\item Antenna gain (if Tsys measured in Kelvin) +\item Beam number +\item Molecule rest frequency$^\dagger$ +\item Molecular name$^\dagger$ +\item Molecular transition$^\dagger$ +\item Molecular formula$^\dagger$ +\end{itemize} +}{1} + +\requirement{The molecular formula could be stored with embedded +superscripted and subscripted symbols for ``pretty'' printing on the +plotted, but printed in plain text on the CLI or in ascii output}{3} + +Some molecular line rest-frequencies are close enough that two or more +molecules or transitions may be observed in a single IF. Typical +examples include the 1665/1667~MHz OH maser pair, NH$_3$ transitions, +and many observations in the 3~mm band. + +\vspace{\parskip} +\requirement{The software should optionally support multiple lines per +IF, by storing a set of rest frequencies per IF, rather than a single +value. The header values in requirement \reqref{req:if} marked with a +$\dagger$ would all have to be stored as an array of values rather +than a scalar. A simple mechanism must be posible to change the +currently ``active'' rest-frequency.}{3} + +\section{Installation} + +\requirement{It must be possible for astronomers to install the +software at their own institute with either a moderate amount of OS +experience or some help from the local system administrators. This +includes installation on a central ``NFS'' server as well as local +desk-tops.}{1} + +\requirement{The software must run on Solaris and all major flavours +of Linux (Fedora/Redhat, Debian, etc). + }{1} + +\requirement{It must be possible for users to +install the software on their (unix) laptops and run with no network +connection. }{1} + +\requirement{It should be relatively easy to upgrade to the lastest +version of the software.}{2} + +\requirement{The software should run on MacOS/X}{3} + +\requirement{It would be desirable for the software to run on +Windows.}{3} + +\section{Known Issues} +\label{sec:issues} +The following issue are known problems with the data from ATNF +telescopes, which probably should be automatically corrected for if at +all possible. The best place to do this is while loading the data. + +\subsection{General} + +\begin{itemize} + \item All polarisations in the RPFITS files are labelled as + XX/YY. These need to be relabelled as LL/RR when appropriate. +\end{itemize} + +\subsection{Mopra} + +\begin{itemize} +\item Data obtained in 2002 \& 2003 (and probably before) have an + error in the frequency headers (this may be corrected by an external + program). \makenote{Nedd Ladd} + +\item The (RA,Dec) positions in the data file are in date coordinates + not J2000. This causes problems for packages like Class when + averaging the data. \makenote{Maria Hunt} + +\item It is possible Tsys calibration is inconsistent currently. + \makenote{Cormac Purcell??} + +\end{itemize} + +\subsection{Parkes} + +\begin{itemize} +\item For pulsar data the automatic gain control is disabled. This +means the nominal Tsys measurement does not change and Tsys per +integration is encoded in a non-standard way. \makenote{Simon +Johnston} +\end{itemize} + +\subsection{Tidbinbilla} + +\begin{itemize} +\item All 20-GHz data is calibrated in flux units of Kelvin. +\end{itemize} + +\section{Acknowledgements} + +We would like to thank the following people for input directly or from +previous documents: Maria Hunt, Paul Jones, Jim Caswell \& Dave +McConnell, Frank Briggs, Juergen Ott, Daniel Pisano, Jim Lovell, Ray +Norris, WIm Brouw, Maxim Voronkov, Vincent McIntyre, Jessica Chapman, +Simon Johnston, Nedd Ladd, Lister Staveley-Smith, Cormac Purcell \& +Rachel Deacon. + +\end{document} Index: /tags/asap-4.4.0+atnf2/admin/requirements2.tex =================================================================== --- /tags/asap-4.4.0+atnf2/admin/requirements2.tex (revision 3150) +++ /tags/asap-4.4.0+atnf2/admin/requirements2.tex (revision 3150) @@ -0,0 +1,1359 @@ +\documentclass[11pt]{article} +\usepackage{a4} +\usepackage{calc} +\usepackage{ifthen} +\usepackage{smartref} +\usepackage{longtable} + +\def\complete{no} + +% Adjust the page size +\addtolength{\oddsidemargin}{-0.4in} +\addtolength{\evensidemargin}{+0.4in} +\addtolength{\textwidth}{+0.8in} + +\setlength{\parindent}{0mm} +\setlength{\parskip}{1ex} + + +\title{ASAP - ATNF Spectral Analysis Package\\ + Software Requirements - Development Cycle 2 } + \author{Chris Phillips \& Malte Marquarding} + +\newcounter{requirement} +\newcounter{subrequirement} + +\addtoreflist{requirement} +\newcommand{\reqref}[1]{R\ref{#1}-\requirementref{#1}} + +\newcommand{\makenote}[1]{{\bf \tt \em#1}} + +\newcommand{\anitem}[2]{\smallskip \parbox[t]{2cm}{#1}% + \parbox[t]{\textwidth-2cm}{#2}} + +\newcommand{\showreqcounter}{ + R\arabic{section}.\arabic{subsection}-\arabic{requirement} +} + +\newcommand{\showsubreqcounter}{ + R\arabic{section}.\arabic{subsection}-\arabic{requirement}.\arabic{subrequirement} +} + +\newcommand{\status}[2]{ + \ifthenelse{\equal{#1}{Started}}{Started \hspace*{1cm} {\em Priority #2}} + {\ifthenelse{\equal{#1}{Not started}}{Not Started\hspace*{1cm} {\em Priority #2}} + {\ifthenelse{\equal{#1}{Done1}}{Completed} + { \ifthenelse{\equal{#1}{Duplicate}}{Duplicate?} + {#1} + }}} +} + +% Also Deferred, Obsolete + +% Requirement command +% Summary +% Status +% Priority +% Time estimate +% Percent complete +% Completion date +% Text + +%\newarray\Requirements + +%\newcounter{numreq} + +\newcommand{\requirement}[7]{ + \setcounter{subrequirement}{0} + \stepcounter{requirement} + + \ifthenelse{\equal{\complete}{yes}} + {\dorequirement{#1}{#2}{#3}{#4}{#5}{#6}{#7}} + {\ifthenelse{\equal{#2}{Done1} + \or \equal{#2}{Deferred} + \or \equal{#2}{Removed} + \or \equal{#2}{Obsolete}}{} + {\dorequirement{#1}{#2}{#3}{#4}{#5}{#6}{#7}}} +} + +\newcommand{\dorequirement}[7]{ + \hspace*{2mm}\begin{minipage}{\textwidth-2mm} + \setlength{\parindent}{-2mm} + {\bf \showreqcounter\ \bf #1} \\ + #7 \\ + \hspace*{1cm} \status{#2}{#3} + \end{minipage} + + \typeout{REQUIREMENT: \showreqcounter & #1 & #2 & #3 & #4 & #5 & #6 :ENDREQ} +} + +\newcommand{\subrequirement}[7]{ + \stepcounter{subrequirement} + + \ifthenelse{\equal{\complete}{yes}} + {\dosubrequirement{#1}{#2}{#3}{#4}{#5}{#6}{#7}} + {\ifthenelse{\equal{#2}{Done1} + \or \equal{#2}{Deferred} + \or \equal{#2}{Obsolete} + \or \equal{#2}{Removed}}{} + {\dosubrequirement{#1}{#2}{#3}{#4}{#5}{#6}{#7}}} +} + +\newcommand{\dosubrequirement}[7]{ + \hspace*{2mm}\begin{minipage}{\textwidth-2mm} + \setlength{\parindent}{-2mm} + {\bf \showsubreqcounter\ \bf #1} \\ + #7 \\ + \hspace*{1cm} \status{#2}{#3} + \end{minipage} + + \typeout{REQUIREMENT: \showsubreqcounter & #1 & #2 & #3 & #4 & #5 & #6 :ENDREQ} +} + + +\newcommand{\extendedrequirement}[7]{ + \setcounter{subrequirement}{0} + + \hspace*{2mm}\begin{minipage}{\textwidth-2mm} + \setlength{\parindent}{-2mm} + \stepcounter{requirement} + {\bf \showreqcounter\ #1} + #7 + \hspace*{1cm} \status{#2}{#3} + \end{minipage} + + \typeout{REQUIREMENT: \showreqcounter & #1 & #2 & #3 & #4 & #5 & #6 :ENDREQ} +} + + +\newcommand{\reqeqn}[1]{\\\hspace*{1cm} $#1$} + +\let\oldsection\section +\renewcommand{\section}[1]{\setcounter{requirement}{0}\oldsection{#1}} + +\let\oldsubsection\subsection +\renewcommand{\subsection}[1]{\setcounter{requirement}{0}\oldsubsection{#1}} + +\begin{document} + +\maketitle + + +%\tableofcontents +%\newpage + +\section{Introduction} + +ASAP has been written to replace the venerable single-dish software +{\tt spc} for processing of single dish spectral line data from all +ATNF observatories. Version 1.0 of ASAP was released in March +2005. This document reflects an update of the initial requirements +document. Some new requirements have been added and the requirement +priorities have been reassessed for the next development cycle. + +\section{Scope} + +ASAP should be able to process all spectral line single-dish +observations from ATNF telescopes (Parkes, Mopra \& Tidbinbilla). This +includes reading the data produced by the telescope, calibration and +reduction of the data and basic analysis of the data such as fitting +line profiles etc. + +It has been assumed that the following processing is out of the scope +of ASAP. +\begin{itemize} +\item Raster or ``on-the-fly'' mapping (This is handled by +``livedata'' and gridzilla). +\item Very complex or specific data processing. (A route into + Class\footnote{Part of the GLIDAS software package, produced by + Institut de Radio Astronomie Millime\'trique http://www.iram.fr} + should be available for advanced processing). +%%TODO%% give example +\item Continuum data. +\item Pulsar timing observations. +\end{itemize} + +\section{Priorities} + +Requirements have been given a value of 1 to 3. The other requirements +will be implemented mainly depending on priority, with ``1'' the +highest. Priority 3 and some priority 2 requirements will probably not +get implemented in the duration of the second development cycle. + +\section{User Interface} + +The user interface (UI) is the most important part of a single dish +processing package, but probably the most difficult to get right. Long +term the UI for this software will consist of three parts. +\begin{itemize} + \item A graphical user interface (GUI). + \item An interactive command line interface (CLI). + \item A scriptable interface for batch processing. +\end{itemize} + +The CLI and scriptable interface are essentially be the same. + +The software does not {\em need} to be able to run solely from a +``vt100'' style terminal. It can be assumed that the user is running +the software from within a windowed (i.e. X11) environment. This will +mean it will not necessarily be possible to run the software remotely +over a slow network connection (e.g. internationally or from home). +Where possible, operations on the data should be possible from all +three aspects of the user interface. + +The user interface needs to be implemented so that the user can easily +and transparently work on spectra either one at a time or by +processing multiple spectra in parallel. This means there must be an +easy way to select specific or multiple spectra to display or process. + +At this stage the development of a GUI has been deferred until the +basic package has stabilised and most features have been +implemented. At that stage a decision will be made on how to best +implement a GUI. On a shorter timescale specific purpose GUIs (such as +a simple Wizard for processing standard Mopra data) may be produced on +an as-needed basic. + +\subsection{Graphical User Interface} + +At this stage a general ASAP GUI has been deferred to a later date. + +\smallskip + +\requirement{Simple interface}{Deferred}{}{}{}{}{It should be simple, +intuitive and uncluttered. Specifically, use of many windows +simultaneously should be discouraged, as should hiding functionality +behind layers of dialog boxes.} + +\requirement{Integrated plotter}{Deferred}{}{}{}{}{The plotting window +should be a major component of the GUI control, not a separate +isolated window.} + +\requirement{Minimal controls}{Deferred}{}{}{}{}{The interface should use + minimal ``always visible'' controls, with use of pull down menus and + maybe a toolbar for frequency used functions. } + +\requirement{Keyboard shortcuts}{Deferred}{}{}{}{}{Keyboard shortcuts should +be available.} + +\requirement{GUI user preferences}{Deferred}{}{}{}{}{Most user preferences +(i.e. keywords in the CLI) should be presented in a popup, tabbed, +dialog box.} + +\requirement{GUI line fitting}{Deferred}{}{}{}{}{When performing line +profile fitting, a spreadsheet type window should be viewable which +shows the current parameter values (amplitude, velocity etc) for each +line fitted and allow the user to change these parameters or set the +current value as fixed. This GUI should stay synchronised with any CLI +changes to these values.} + +\requirement{Mopra online GUI}{Not started}{1}{}{}{} +{A simple GUI to do very basic online reduction of Mopra data should +be available. This should include averaging data, quotient } + +\subsection{Command Line Interface} + +The command line interface is the main user interface to ASAP. It is +implemented in ipython using a objected oriented command approach. + +\requirement{Virtual CLI}{Obsolete}{}{}{}{}{While the GUI should be the main +interface for new users and for basic manipulation, some tasks can be +more efficiently performed using a CLI. A virtual CLI could be +integrated as part of the GUI.} + +\requirement{CLI keyword/argument}{Obsolete}{}{}{}{}{The CLI should have a +keyword/argument form and never prompt the user for specific values +(the user should be able to change values which are retained until +they wants to change them again).} + +\requirement{CLI case insensitive}{Obsolete}{}{}{}{}{The CLI should be case +insensitive and accept minimum matching and short forms of +keywords.} + +\requirement{CLI available routines}{Done1}{}{}{}{}{The user must be able to +quickly and easily see from the command line the available routines +and keywords which affect it, so they can see which parameters may +need changing.} + +\subsection{Scripting} + +\requirement{Scripting}{Done1}{1}{}{}{}{It must be possible to run the +software in a scripting mode. This would be to process large amounts +of data in a routine manner and also to automatically reproduce +specific plots etc (So the scripting must have full control of the +plotter). Preferably the scripting ``language'' and the CLI would be +the same.} + +\requirement{Standard scripts}{Not started}{1}{}{}{} {ASAP should come +with sample scripts which users can use for standard observing modes +(e.g. standard Mopra observing, Parkes polarimetry etc)} + +%\requirement{Scripts from History}{Duplicate}{}{}{}{}{It would be worthwhile +%having a method to auto-generate scripts (for reduction or plotting) +%from current spectra history, or some similar method.} + +\section{Plotter} + +The plotter should be fully interactive and be an integral part of the +GUI and software interface. + +\requirement{High quality plots}{Done1}{}{}{}{}{It must be able to +produce plots of publishable quality.} + +\subrequirement{Histogram plots}{Not started}{1}{0.5d}{}{} {As well as line +plots, there needs to be an option to plot spectra in ``Histogram'' +mode} + + +The user must be able to specify: + +\subrequirement{Line Thickness}{Started}{1}{0.1d}{}{}{} + +\subrequirement{Character size}{Not started}{1}{0.1d}{}{}{} + +\subrequirement{Colours}{Started}{1}{0.75d}{}{}{} + +\subrequirement{Line styles}{Not started}{1}{0.5d}{}{}{} + +\subrequirement{Position of axis ticks}{Done1}{2}{}{}{}{} + +\subrequirement{Hard Copies}{Done1}{1}{}{}{}{Producing hard copies +in postscript and .png format. Other formats may be added on an as +need basic.} + +\subrequirement{Non-interactive hard copies}{Not started}{1}{2d}{}{} +{It must be possible to produce hard copiers without an interactive +(i.e X11) plotter starting}. + +\subrequirement{Scriptable plotting}{Done1}{1}{}{}{} {All aspects of +the plotter (zooming etc) must be setable from the command line for +scripting} + +\requirement{Arbitrary plots}{Not started}{3}{}{}{} +{It must be possible to flexibly select the data to plot (e.g. Tsys vs +time etc as well as plots such as amplitude vs channel number or +velocity). Preferably any of the header values for a selection of +scans could be plotted on a scatter plot (e.g. Tsys vs elevation)} + +\requirement{Overlay spectra}{Done1}{}{}{}{}{It must be possible to overlay + multiple spectra on a single plot using different colours and/or + different line styles. (Including multiple stokes data and multiple + IFs).[[CHECK]]} + +\requirement{Plot individual spectra}{Done1}{}{}{}{}{It must be possible to + plot either the individual integrations (in either a stacked + fashion, or using a new subplot per integration)} + +\subrequirement{Auto-average integrations for plotting}{Not started}{2}{}{}{} +{It should be possible to optionally auto-average integrations of a +scan for plotting (for data thats has not already been scan averaged)} + +\requirement{Plotter multi-panelling}{Done1}{1}{}{}{} +{It must be possible to multi-panel spectra in an n$\times$m size +grid. It must be possible to easily change the number of plots per +page, ie define the ``n'' and ``m'' values.} + +\subrequirement{Step between plots}{Not started}{2}{}{}{} +{If more spectra than can fit on the plot matrix are to be plotted, +then it must be possible to step back and forth between the viewable +spectra (i.e. ``multi-page'' plots). This includes stepping through a +single plot on the pages at a time.} + +\requirement{Multi-panel: change \# panels}{Not started}{2}{}{}{} +{When using multi-panelling, the plotter should automatically update +the plot when the plot matrix dimensions (``n'' and ``m'' are changed)} + +\requirement{Plotter interactive zooming}{Done1}{}{}{}{}{It must be possible + to interactively zoom the plot (channel range selection and + amplitude of the spectra etc.) This includes both GUI control of + the zooming as well as command line control of either the zoom + factor or directly specifying the zoom bounds. } + +\requirement{Zoomed subplot}{Not started}{2}{}{}{} +{On a single plot, it should be possible to plot the full spectrum and +a zoomed copy of the data (using a different lie style) to see weak +features. The user must be able to specify the zoom factor.} + +\requirement{Offset plots}{Not started}{2}{}{}{}{Optionally when stacking + multiple spectral plots in one subwindow, a (user definable) offset + in the ``y'' direction should be added to each subsequent + spectra.} + +\requirement{Plotter auto-update}{Not started}{3}{}{}{} +{The plotter should automatically update to reflect user processing, +either from the CLI or GUI. The user should have to option to turn +this feature off if they so wish.} + +\requirement{Waterfall plot}{Not started}{3}{}{}{} +{It should be possible to plot individual integrations (possibly from +multiple scans) in a ``waterfall'' plot. This is an image based +display, where spectral channel is along the x-axis of the plot, time +(or integration number) along the y-axis and greyscale or colour +represent the amplitude of spectra. Interactive zooming and panning of +this image should be supported. } + +\requirement{Waterfall editing}{Not started}{3}{}{}{} +{When plotting ``waterfall'' plots, it should be possible to +interactively select regions or points and mark them as invalid +(i.e. to remove RFI affected data). The plotter should also show the +time/velocity of the pixel beneath the cursor.} + +\requirement{Export waterfall to FITS}{Not started}{3}{}{}{} +{It should be possible to export the ``waterfall'' plot images as a +FITs file, for user specific analysis.} + +\requirement{Plot line catalog overlays}{Not started}{1}{3d}{}{} {Line markers overlays, +read from a catalogue should be optionally available. This would +include the full Lovas catalogue, the JPL line catalogue and radio +recombination lines. The lines would be Doppler corrected to a +specified velocity. The user must be able to plot just a sub-section +of the lines in any specific catalogue (to avoid clutter).} + +\subrequirement{Plot user catalog overlays}{Not started}{2}{}{}{} +{Simple user definable catalogue should be definable for plot overlays} + +\requirement{Plot fitted functions}{Done1}{}{}{}{} +{Optionally plot fitted functions (e.g line profiles or baseline +fit). If multiple components (e.g. Gaussian) have been fit, it should +be possible to show the individual functions or the sum of the +components} + +\requirement{Plot residual data}{Started}{1}{0.5d}{}{} +{It should be possible to plot the residual data with or without +subtraction of fit functions. This includes plotting the spectra with +or without baseline removal and the residual after subtracting +Gaussian fits. The default should be to plot the data with baseline +subtracted but profile fits not subtracted.} + +\requirement{Plot header data}{Not started}{2}{}{}{} {Basic header data +(source name, molecule, observation time, Tsys, elevation, parallactic +angle etc) should be optionally shown, either on the plot or next to +it. This may either consist of a set of values, or only one or two +values the user specifically wants to see (source name and molecule, +for example).} + +\subrequirement{User define header plot positions}{Not started}{3}{}{}{} +{The user should be able to define where on the plot the header info +would appear.} + +\requirement{Realtime cursor position}{Done1}{}{}{}{} +{Optionally, relevant data such as the current mouse position should +be displayed (maybe with a mode to display an extended cross, +horizontal or vertical line at the current cursor position).} + +\requirement{Plot annotations}{Not started}{2}{}{}{}{The user should be able + to define simple annotations. This would include text overlay and + probably simple graphics (lines, arrows etc).} + +The user must be able to use the plotter window to interactively set +initial values and ranges used for fitting functions etc. The use of +keyboard ``shortcuts'' or other similar ``power user'' features should +be available to save the time of experienced users. + +{\em The following requirements are deferred as they require a version +of Matplotlib not yet available.} + +The plotter should be used to set the following values: + +\requirement{Interactive channel selection}{Deferred}{1}{}{}{}{Range of + spectral channels needed for specific tasks (ie the channel mask) + (See requirement \reqref{ref:chansel})} + +\requirement{Interactive line fitting}{Deferred}{1}{}{}{}{Initial +Gaussian parameters (velocity, width, amplitude) for profile +fitting.} + +\requirement{Plotter change fit values}{Deferred}{1}{}{}{} +{Change the parameter values of existing line profile +fits, or channel ranges used for baseline fits.} + +\section{Functionality} + +\subsection{Import/export} + +The software needs a set of import/export functions to deal with a +variety of data formats and to be able to exchange data with other +popular packages. These functions should be flexible enough to allow +the user to perform analysis functions in an different package and +re-import the data (or vice versa). The import function must be +modular enough to easily add new file formats when the need arises. +To properly import data, extra information may have to be read from +secondary calibration files (such as GTP, Gated Total Power, for 3~mm +wavelength data taken with Mopra). The import functions should be +flexible enough to gracefully handle data files with missing headers +etc. They should also be able to make telescope and date specific +corrections to the data (for ATNF observatories). + +The software must be able to read (import) the following file formats. + +\requirement{Read rpfits}{Done1}{}{}{}{}{The rpfits file format produced by + all current ATNF correlators.} + +\requirement{Read sdfits}{Done1}{}{}{}{}{SDFITS (currently written by {\tt SPC}).} + +\requirement{Read simple FITS}{Not started}{2}{}{}{}{Simple ``image'' FITS +(used by CLASS} + +\requirement{Read historic formats}{Not started}{3}{}{}{} +{Historic ATNF single dish formats (Spectra, SPC, SLAP). Possibly a +set of routines to translate these formats to SDFITs would suffice.} + +\requirement{Read PSRFITS}{Deferred}{}{}{}{}{PSRFIT for pulsar spectroscopy.} + +\requirement{Read online data}{Not started}{1}{0.1d}{}{} +{For online analysis, the software should be able to read an rpfits +file which is is still currently open for writing by the telescope +backend processor.} + +\requirement{Handle Doppler data}{Done1}{1}{}{}{}{Data which has been +observed in either a fixed frequency or Doppler tracked fashion needs +to be handled.} + +The software should be able to export the data in the following formats. + +\requirement{Write SDFITS}{Done1}{}{}{}{}{Single Dish FITS.} + +\requirement{Write simple FITS}{Done1}{}{}{}{} +{Simple ``image'' FITS (as used by CLASS). It must be possible to to +export multiple spectra simultaneously, using default file name and +postfix.} + +\requirement{}{Removed}{}{}{}{}{}{In a format which can be imported by other popular + packages such as Class. + +\requirement{Write ASCIIs}{Done1}{}{}{}{} +{Simple ASCIIs format, suitable for use with programs such as Perl, +Python, SuperMongo etc.} + +\requirement{Header writing}{Started}{1}{0d}{}{} +{The exported data should retain as much header data as possible. It +should also be possible to request specific data be written in the +desired form (B1950 coordinates, optical velocity definition etc).} + +\requirement{Import corrections}{Done1}{}{}{}{} +{The import function should apply relevant corrections (especially +those which are time dependent) to specific telescopes. See +$\S$\ref{sec:issues} for a list of currently known issues.} + +\requirement{Append output files}{Not started}{1}{3d}{}{} {It must be possible +to append spectra to existing output files, specifically sdfits and +asap output files.} + +\subsection{Sky subtraction} +\label{sec:skysubtraction} +To remove the effects of the passband filter shape and atmospheric +fluctuations across the band, sky subtraction must be performed on the +data. The software must be able to do sky subtraction using both +position switching (quotient spectra) and frequency switching +techniques. + +\requirement{Quotient Spectra}{Done1}{}{}{}{} +{\label{ref:skysub} Position switched sky subtraction should be +implemented using the algorithm \medskip\reqeqn{T_{ref} \times +\frac{S}{R} - T_{sig}} -- removes continuum\bigskip \reqeqn{T_{ref} +\times \frac{S}{R} - T_{ref}} -- preserves continuum\medskip} + +\requirement{Arbitrary reference}{Not started}{2}{}{}{} +{The user should be able to specify an arbitrarily complex +reference/source order (which repeats), which can then be used to make +perform multiple sky subtractions in parallel.} + +\requirement{Frequency switching}{Not started}{2}{}{}{} +{Frequency switched sky subtraction should be supported. (Ref. Liszt, +1997, A\&AS, 124, 183) } + +%\requirement{For wideband multibit sampled data it may be desirable or +%even required to assume Tsys has a frequency dependency. Appropriate +%sky subtraction algorithms will need to be investigated.}{3} + +\requirement{Pulsar off pulse quotient}{}{}{}{Deferred}{3} +{For pulsar binned data, the (user specified) off pulse bins can be +used as the reference spectra. Due to potentially rapid amplitude +fluctuations, sky subtractions may need to be done on a +integration basis.} + +Multibeam systems can observe in a nodding fashion (called MX mode at +Parkes), where the telescope position is nodded between scans so that +the source is observed in turn by two beams and a reference spectra +for one beam is obtained while the other is observing the target source. + +\requirement{Multibeam MX mode}{Not started}{2}{}{}{} +{For multibeam systems, it must be possible to perform sky subtraction +with the source and reference in an alternate pair of beams} + +\subsection{Baseline removal} + +Baseline removal is needed to correct for imperfections in sky +subtraction. Depending on the stability of the system, the residual +spectral baseline errors can be small or quite large. Baseline removal +is usually done by fitting a function to the (user specified) line +free channels. + +\requirement{Baseline removal}{Done1}{}{}{}{} +{The software must be able to do baseline removal by fitting a n'th +order polynomials to the line free channels using a least squares +method.} + +\requirement{Standing wave ripples}{Not started}{3}{}{}{} +{Removal of standing wave ripples should be done by fitting a Sine +function to the line free channels.} + +\requirement{Robust fitting}{Not started}{3}{}{}{} +{``Robust'' fitting functions should be available, which are more +tolerant to RFI.} + +\requirement{Auto-baseline}{Done1}{}{}{}{} +{Automatic techniques for baselining should be investigated.} + +\subsection{Line Profile Fitting} + +The user will want to fit multicomponent line profiles to the data in +a simple manner and be able to manipulate the exact fitting +parameters. + +\requirement{Gaussian fitting}{Done1}{}{}{}{} +{The software must be able to do multi-component Gaussian fitting of +the spectra. The initial amplitude, width and velocity of each +component should be able to be set by the user and specific values to +be fit should be easily set.} + +\requirement{Chi squared}{Done1}{}{}{}{} +{The reduce Chi squared (or similar statistic) of the fit should given +to the user, so that they can easily see if adding extra components +give a statistically significant improvement to the fit.} + +%\requirement{The fit parameters should be stored with the data so that +%the user can work on multiple data sets simultaneously and experiment +%with different fitting values. These values should be saved to disk +%along with the data.}{1} + +\requirement{Fit multipol data}{}{}{}{Done1}{} +{For multiple polarisation data, the individual stokes parameters or +polarisation products should be fit independently.} + +\requirement{Export fit parameters}{Not started}{1}{1d}{}{} +{There should be an easy way of exporting the fit parameter from +multiple spectra, e.g. as an ASCII table.} + +\requirement{Constrained fitting}{Not started}{2}{}{}{} +{It should be also possible to do constrained fitting of multiple +hyperfine components, e.g. the NH$_3$ hyperfine components. (The +constraints may be either the frequency separation of the individual +components or the amplitude ratio etc.)} + +\subrequirement{Specific constrained fitting}{Not started}{1}{4d}{}{} +{Before arbitrary constrained fitting is available, support for +specific cases, such as the NH$_3$ hyperfine transition, should e +added on a case-by-case basis.} + +\requirement{Edit fits parameters}{Done1}{}{}{}{} +{It must be possible to alter the line profile fit parameter values by +hand at any stage.} + +\requirement{Fix fit parameters}{Done1}{}{}{}{} +{It must be possible to ``fix'' particular values of the line profile +parameters, so that only subset of lines or (say) the width of a line +is fit.} + +\requirement{Arbitrary line fitting}{Done1}{}{}{}{} +{The software should allow hooks for line profile shapes other than +Gaussian to be added in the future, possible user specified.} + +\requirement{Save fit parameters}{Done1}{}{}{}{} +{The fitting parameters for functions which have been fit to the data +(e.g. for baseline removal or Gaussian fits) should be retained as an +integral part of the data and stored permanently on disk.} + +\requirement{Undo subtracted fits}{Not started}{3}{}{}{} +{It should be possible to ``undo'' functions which have been +subtracted from the data (e.g. baseline polynomials).} + +\requirement{Gaussian line area}{Not started}{1}{0.2d}{}{} +{Optionally the area under a fitted Gaussian should be calculated for +the user.} + +%\makenote{Should it be possible to attach multiple sets of fits to the +%data (similar to CL tables in classic AIPS), so the user can +%experiment with different ways of fitting the data?} + +%\makenote{Should calculations of rotational temperatures etc be +%handled when fitting hyperfine components, or should the user be doing +%this themselves?} + +\subsection{Calibration} + +The software should handle all basic system temperature (Tsys) and +gain calibration as well as opacity corrections where relevant. The +Tsys value should be contained in the rpfits files. The actual +application of the T$_{\mbox{sys}}$ factor will be applied as part of +the sky subtraction ($\S$\ref{sec:skysubtraction}). The units of Tsys +recorded in the data may be either in Jy or Kelvin, which will affect +how the data is calibrated. The rpfits file does {\em not} distinguish +if the flux units are Kelvin or Janskys. + +\requirement{Gain-elevation}{Done1}{}{}{}{} +{Gain elevation corrections should be implemented using a elevation +dependent polynomial. The polynomial coefficients will be telescope +and frequency dependent. They will also have a (long term) time +dependence.} + +\requirement{User gain polynomial}{Done1}{}{}{}{} +{The user may wish to supply their own gain polynomial.} + +\requirement{K-Jy conversion}{Done1}{}{}{}{} +{When required by the user, the spectral units must be converted from +Kelvin to Jansky. At higher (3mm) frequencies this conversion is often +not applied. The conversion factor is\medskip \reqeqn{\mbox{Flux (Jy)} += \frac{T \times 2 k_b \times 10^{26}}{\eta A}},\medskip\\where $k_b$ +is Boltzmann's constant, A is the illuminated area of the telescope +and $\eta$ is the efficiency of the telescope (frequency, telescope +and time dependent)} + +\requirement{Scale Tsys}{Done1}{}{}{}{} +{In some cases the recorded Tsys values will be wrong. There needs to +be a mechanism to scale the Tsys value and the spectrum if the Tsys +value has already been applied (i.e. a simple and consistent rescaling +factor).} + +\requirement{Opacity}{Done1}{}{}{}{} +{The data may need to be corrected for opacity effects, particularly +at frequencies of 20~GHz and higher. The opacity factor to apply is +given by\medskip\reqeqn{C_o = e^{\tau/cos(z)}}\medskip\\ where $\tau$ +is the opacity and z is the zenith angle (90-El). These corrections +will generally be derived from periodic ``skydip'' measurements. These +values will not be contained in the rpfits files, so there should be a +simple way of the software obtaining them and interpolating in time +(the user should not {\em have} to type them in, but may want +to). Reading in an ASCIIs file which contains the skydip data along +with a time-stamp would be one possibility.} + +\requirement{Tsys variation with freq}{Not started}{3}{}{}{} +{For wideband, multibit observations, the software should have the +option to handle Tsys which varies across the band. The exact +implementation will have to be decided once experience is gained with +the new Mopra digital filterbank. This will affect the sky subtraction +algorithms (requirement \reqref{ref:skysub}).} + +%\makenote{Is the dependence of gain on frequency weak enough for one +%set of coefficients for each receiver, or is a full frequency dependent +%set of values needed?} + +%\makenote{Should it be possible to read ``correct'' Tsys values from +%an external ascii file?} + +\subsection{Editing \& RFI robustness} + +In a data set with many observations, individual spectra may be +corrupted or the data may be affected by RFI and ``birdies''. The user +needs to be able to easily flag individual spectra or channels. This +may affect other routines such as sky-subtraction, as this will +disrupt the reference/source sequence. + +\requirement{Spectra flagging}{Started}{1}{1d}{}{} +{The user must be able to set an entire spectra or part thereof +(individual polarisation, IF etc) as being invalid.} + +\requirement{Channel flagging}{Started}{1}{0.5d}{}{} +{The user must be able to indicate an individual spectral point or +range of spectral points are invalid. This should be applied to an +individual spectra, or set of spectra.} + +\subrequirement{Flagged channel plotting}{Done1}{1}{}{}{} {When plotting data +with flagged spectral channels, the plotting should left a gap (blank) +in the plotted data|}. + +\subrequirement{Flagged channel interpolation}{Not started}{2}{}{}{} +{When plotting or processing data (e.g. quotient spectra), the users +should be able to request that the values for flagged data are +obtained by interpolation from good data either side of the flagged +points.} + +\requirement{Plot average flux vs time}{Not started}{3}{}{}{} +{The user should be able to plot the average spectral flux across the +band, or part of the band, as a function of time and interactively +select sections of data which should be marked as invalid (similar to +IBLED in classic aips).} + +\requirement{Robust Fitting}{Duplicate}{2}{}{}{} +{Where relevant, fitting routines etc should have the option of +selecting RFI tolerant (``robust'') algorithms. This will require +investigating alternate fitting routines other than the least-squares +approach.} + +\requirement{Birdie finder}{Not started}{2}{}{}{} +{A routine to automatically find birdies or RFI corrupted data and +indicate the data as invalid would be useful.} + +\requirement{Handle flagged data}{Done1}{}{}{}{} +{Other routines must be able to cope with portions of data which are +marked as invalid.} + +\subsection{Spectra mathematics and manipulation} + +A flexible suite of mathematical operations on the spectra should be +possible. This should include options such as adding, subtracting, +averaging and scaling the data. For common operations such as +averaging and smoothing, it must be simple for the user to invoke the +function (i.e. not to have to start up a complex spectral +calculator). Where it makes sense, it should be possible to manipulate +multiple spectra simultaneously. + +The spectral manipulations which should be available are: + +\requirement{Add spectra}{Done1}{}{}{}{}{Add or subtract multiple spectra.} + +\requirement{Average spectra}{Done1}{1}{}{}{} +{Averaging multiple spectra, with optional weighting based on Tsys, +integration or rms.} + +\subrequirement{Average spectra with velocity shift}{Not started}{1}{0.2d}{}{} +{If the velocity of the spectra to be averaged is different, the data +should be aligned in velocity. The user should be able to turn this +feature on or off.} + +\requirement{Robust averaging}{Not started}{2}{}{}{} +{Various robust averaging possibilities (e.g. median averaging, +clipped means etc) should be possible.} + +\requirement{Data re-binning}{Done1}{}{}{}{} +{Re-sampling or re-binning of the data to a lower (or higher) spectral +resolution (i.e. change the number of spectral points). The +re-sampling factor may not necessarily be an integer.} + +\requirement{Velocity shift}{Done1}{}{}{}{} +{It must be possible to shift the data in ``frequency/velocity''. This +should include channel, frequency and velocity shifts of an arbitrary +amount.} + +\requirement{Spectra smoothing}{Done1}{}{}{}{} +{Spectral smoothing of the data. Hanning, Tukey, boxcar and Gaussian +smoothing of variable widths should be possible.} + +\requirement{Spectra scaling}{Done1}{}{}{}{}{Scaling of the spectra.} + +\requirement{Spectra statistics}{Done1}{}{}{}{} +{Calculate basic statistical values (maximum, minimum, rms, mean) on a +range of spectral points. The range may not be contiguous. The +calculated rms value should be retained with the spectra so it can be +optionally used for weighted averaging of spectra.} + +\requirement{Line flux}{Not started}{2}{}{}{} +{It must be possible to calculate the flux integral over a range of +channels. The units should be Jy.km/s (or Kelvin.km/s). The channel +range for the calculation should be specific via the GUI or CLI.} + +\requirement{Line width}{Not started}{2}{}{}{} +{It must be possible to calculate the numerical ``width'' of a line +(full width at half maximum type measurement). This should be +calculated by specifying a channel range and finding the maximum value +in this range and then finding the interpolated crossing point of the +data as a user defined fraction of the maximum (default 50\%). The +profile width and velocity mid-point should then be computed. If the +profile shape is complex (e.g. double arch) with multiple crossing +points of the fraction value, the minimum and maximum width values +should be calculated. There should be the option of using a user +specified ``maximum value''.} + +\requirement{Change rest frequency}{Done1}{}{}{}{} +{The user must be able to easily change the rest-frequency to which +the velocity is referenced.} + +\requirement{FFT filtering}{Not started}{3}{}{}{} +{FFT filtering for high- and lowpass filtering and tapering.} + +\requirement{FFT to/from autocorrelation function}{Not started}{3}{}{}{} +{It should be possible to FFT the data to and from power spectra to +the autocorrelation function.} + +\requirement{Cross correlation}{Not started}{3}{}{}{} +{The user may wish to compute the cross correlation function of two +spectra. The result should be a standard ``spectra'', which can be +displayed and analysed using other functions (max, rms etc).} + +\requirement{Spectral calculator}{Started}{1}{?}{}{} +{Complex experiment specific processing can often be done using a +series of the simple of basic functions. A spectral calculator options +should be added to the CLI to perform a series of manipulations on a +set of spectra.} + +The user may want to perform specific analysis on the data using the +functionality above, but wish to do the manipulation between two +polarisations or IFs. Allowing the functions to also, optionally, +specify specific polarisations or IF would be an implementation and +interface nightmare. The simplest solution is to allow the data to be +``split'' into separate spectra. + +\requirement{Slice data}{Not started}{1}{10d}{}{} {It must be possible to +take multi IF, multibeam or polarisation data and split out the a +splice of individual spectral portions to form self contained +spectra.} + +\requirement{Slice spectral channels}{Not started}{1}{0d}{}{} {It must be +possible to select a range of spectral channels to form self contained +spectra. The channel selection may be different for different IFs.} + +\requirement{Merge scantables}{Not started}{1}{5d}{}{} +{It must be possible to append rows from one scantable onto another} + +\subsection{Polarimetry} + +The software must fully support polarmetric analysis. This includes +calibration and basic conversions. Observations may be made with +linear or circular feed and the backend may or may not compute the +cross polarisation products. As such the software must cope with a +variety of conversions. The software should be able to calculate +stokes parameters with or without solving for leakage terms. + +%\makenote{It is debatable whether stokes I is the sum or average or +%two dual polarisation measurements.} + +\requirement{Support polarimetry}{Started}{1}{?}{}{} +{All functions on the data (calibration, sky subtraction spectral +mathematics) must support arbitrary, multiple polarisation (linear, +circular \& stokes and single, dual \& cross polarisations.} + +\requirement{Calculate stokes I}{Done1}{}{}{}{} +{It must be possible to calculate stokes I from single or dual +polarisation observations.} + +\requirement{Average mixed pol data}{Not started}{2}{}{}{} +{Average a mixture of dual polarisation and single polarisation data +and form average stokes I (e.g. for a long observation of a source, in +which one polarisation is missing for some time.} + +\requirement{Calculate stokes}{Done1}{}{}{}{} +{Full stokes parameters should be obtained from dual pol (linear or +circular) observations where the cross polarisation products have been +calculated.} + +%\requirement{If the observations used linear polarisations and the +%cross polarisations were not computed, the source needs to be +%observed with the feeds set at least 3 different parallactic angles +%(note that if dual linear feeds are available, 2 orthogonal +%parallactic angles are obtained at once). The Stokes parameters can be +%solved using a least squares fit to the equation: +%\reqeqn{Iu/2 + Ip * cos^2 (PA + p)},\\ +%where PA is the linear feed position angle, p is the polarisation +%angle, Iu and Ip and the unpolarised and linearly polarised +%intensity. {\em Stolen from SPC. I need to write this in more useful +%language. Is this technique likely to be used anymore?.}}{}{}{}{3} + +\requirement{Compute stokes V without crosspol}{Not started}{2}{}{}{} +{If dual circular polarisation measurements are taken, without +computing the cross products, the software should still be able to +compute stokes I and V.} + +\requirement{Polarisation leakages}{Not started}{3}{}{}{} +{The software should be able to calculate leakage terms from a +calibrator source and correct the data either before or after +conversion to Stokes. (ref. Johnston, 2002, PASA, 19, 277)} + +\requirement{Calibrate position angle}{Not started}{3}{}{}{} +{The software should be able to determine absolute position angle from +a calibrator source and correct the data either before or after +conversion to Stokes.} + +\requirement{Zeeman splitting}{Not started}{3}{}{}{} +{Zeeman splitting factors should be derived from (previous) profile +fitting and the left and right circular polarisations. The velocity +shift varies linearly with the magnetic field, but the scaling factor +depends on the molecule and transition. Scaling factor for common +transitions should be known by the software and the user able to enter +factors for less common transitions. Correctly identifying Zeeman +pairs is crucial in getting the correct result. The software should +attempt to make an initial guess of pairs (based on component velocity +and width) but make the user confirm and override the pairing if +required.} + +\subsection{Data Selection} +While the software is running the user will usually have loaded +multiple (possibly many) spectra each of which may have multiple IFs, +data from multiple beams and multiple polarisations. The user will +want to be able to quickly flip from considering one spectra to +another and, where relevant, want to perform parallel processing on +multiple spectra at once (e.g. baselining a sequence of on/off +observations of the same source which will later be averaged +together). + +\requirement{Spectra selection}{Started}{1}{0d}{}{} +{The software needs an easy-to-use mechanism to select either +individual or multiple spectra for viewing, parallel processing +etc.} + +\requirement{Beam/IF selection}{Started}{1}{0d}{}{} +{An easy-to-use mechanism to select individual IFs, beams or +polarisations is needed.} + +\requirement{Interactive channel selection}{Started}{1}{}{}{} +{\label{ref:chansel} The range of spectral points to use for baseline +removal, statistical calculations, RFI editing, analysis etc must be +easily set by the user from both the CLI and GUI. From the CLI there +must be the option of setting the range using a variety of units +(channel number, velocity, frequency). The selection range will +probably not be a contiguous set of channels, but many sets of +disjoint channel ranges. For some tasks (such as baseline subtraction +and statistical values), the channel range should be retained and be +available as a plot overlay.} + +\requirement{Auto-identify reference spectra}{Not started}{1}{5d+}{}{} +{When performing sky subtraction on many spectra simultaneously, the +software should have a mechanism for identifying ``on'' and ``off'' +spectra and automatically selecting the signal and quotient +spectra. The algorithm needs to cope with on/off/on/off sequences as +well as off/on/on/off. If an individual quotient spectra has been +marked as invalid, an alternative should be found. User specified +preference such as ``closest in time'' to ``first reference before +source'' should be accommodated.} + +\requirement{Select source via header values}{Started}{1}{}{}{} +{The software should be able to select sets of sources based on simple +regular expression type filtering (wild cards) on a range of header +values. } + +\subrequirement{Select on source name}{Done1}{1}{}{}{} +{The use should be able to select dana on source name, e.g G309$*$ or +G309$*$w} + +\subrequirement{Select on molecule}{Done1}{2}{}{}{} +{The use should be able to select data on molecule name, e.g. NH3$*$.} + +\subsection{Plugins} + +\requirement{Plugins}{Started}{1}{?}{}{} +{The package should support ``plugins'', user definable +functions for specific processing. The plugin code must have full +access (read/write) to the spectra data and headers.} + +\requirement{Plugins can reduce dimensions}{Not started}{2}{}{}{} +{Plugins need to be able to create ``derived'' spectra with reduced + dimensions (i.e. less beams, IFs, polarisations or spectral + channels)} + +\requirement{Simulated data}{Not stated}{3}{}{}{} +{The user should be able to create new spectra which the software +treats the same as the original data. This includes full specification +of the header items.} + +\subsection{Pipelining} + +\requirement{Pipelining}{Done1}{}{}{}{} +{Some sort of pipelining mode is required. This would involve doing a +quotient spectra, applying appropriate calibration and possibly +fitting a Gaussian to any lines present.} + +\subsection{Methanol Multibeam Survey} + +The software may need to support reduction of data from the methanol +multibeam project. If so the pipelining will need to be flexible and +powerful enough to support this. + +\subsection{Miscellaneous functionality} + +\requirement{Position fitting}{Not started}{2}{}{}{} +{The software should be able to take a simple ``grid'' of observations +(normally a set of observations in a cross pattern on the sky) and, +for a subset of channels, fit the position of the emission. The fit +positions should be either plotted on the screen or exported in a +simple ASCIIs form.} + +\requirement{Kinematic distance}{Not started}{3}{}{}{} +{The kinematic distance of a source should be calculated using basic +Galactic rotation models. Multiple Galactic rotation models must be +supported and a mechanism for easily adding more.} + +\requirement{Plot sigma errors on spectra}{Not started}{3}{}{}{} +{For 1420 MHz observations of HI, the rms (Tsys) values vary +significantly across the band. The software should be able to compute +the rms as a function of frequency across the spectra from the +off-pulse data and then be able to plot n-sigma error bars on the +spectra.} + +\requirement{Simple Mapping}{Not started}{3}{}{}{} +{It should be possible to take a selection of calibrated spectra which +are then passed to the ``Gridzilla'' program to produce an image +cube. Analysis of this cube would be done using external programs +(e.g. Miriad, aips++)} + +\section{Help} + +\requirement{Built in help}{Done1}{}{}{}{} +{There should be built-in and web-based documentation, which can be +easily kept up-to-date} + +\requirement{Cookbook}{Done1}{}{}{}{} +{A short and simple end-to-end cookbook for basic data analysis should +be available.} + +\requirement{Programmers Documentation}{Not started}{2}{}{}{} +{There should be documentation aimed at astronomers wishing to write +there own scripts, detailing the methods needed and how to get low +level access to the data.} + +\section{Data and meta-data} + +\requirement{Handle multi dimensional data}{Done1}{}{}{}{} +{The software must be capable of handling multi-IF (potentially dozens +of IFs) and multi-beam data with arbitrary polarisation (e.g. single +pol, dual pol, full stokes etc).} + +\requirement{Handle pulsar data}{Deferred}{}{}{}{} +{The software should handle pulsar binned data for pulsar absorption +experiments.} + +\subsection{History} + +\requirement{History}{Done1}{}{}{}{} +{A user viewable history of data processing steps should be kept as +part of the data. Where possible this should be retained when data is +imported from other packages.}{ + +\requirement{Convert history to script}{Not started}{2}{}{}{} +{It should be possible to use the history information to create +template pipeline scripts for batch processing.} + +\subsection{Multiple IFs} + +\requirement{Transparently handle multi-IF data}{Done1}{}{}{}{} +{If multiple IFs are present (currently Tidbinbilla can produce two +IFs and the new wideband spectrometer for Mopra may have dozens of +IFs) the software should handle the data transparently. Potentially +each IF may have a significantly different sky frequency and be +observing a different molecule or transition with a different rest +frequency. From the users point of view, simultaneously obtained IFs +should be kept within the same ``container'' (not split into a myriad +of separate ``container'').} + +\requirement{IFs with different number of spectral channels}{Not started}{1}{}{}{} +{Separate IFs may have a different number of spectral channels.} + +\subsection{Multibeam} + +\requirement{Handle multibeam data}{Done1}{}{}{}{} +{Basic handling of multibeam data should be possible (ie in general +each beam will be treated as a separate observation, but all within +the same container). The user should be able to view or process either +individual beams or all beams in parallel.} + +\requirement{Multibeam simultaneous reference/signal}{Not started}{3}{}{}{} +{The use of a single beam observing a source and the rest of the beams +as reference beams for sky-subtraction should be investigated.} + +\subsection{Robust fitting} + +\requirement{Retain raw correlator integrations}{Done1}{}{}{}{} +{If robust fitting using median filtering is used, then the individual +integrations from the observations should {\em not} be averaged when +the data is imported, but retained within a single +container. Inspection of this data should be optionally of the +averaged or individual data.} + +\subsection{Coordinate frames and units} + +\requirement{Flexible coordinate frames}{Done1}{}{}{}{} +{Coordinate frames and unit selection and handling needs to be +flexible and relatively transparent to the user (i.e. if the users +preference is for LSRK velocities, they do not need to worry about the +reference frame in which the data was observed).} + +\requirement{Specific reference frames}{Done1}{}{}{}{} +{At a minimum the following reference frames and conventions should be +handled: \setlength{\parindent}{0pt} + +\smallskip +\anitem{Position}{(RA,Dec) in J2000 \& B1950 (as well as other + arbitrary epochs), Galactic, (Az,El).} + +\anitem{Frequency}{Velocity (Topocentric, Geocentric, Barycentric, + Heliocentric, kinematical LSR, dynamical LSR, Rest), Frequency + (MHz, GHz), channel number.} + +\anitem{Velocity}{ Optical, Radio, Relativistic.} + +\anitem{Flux}{ Jansky, Kelvin (mJy etc).}} + +\requirement{Data units and frames properly labelled}{Done1}{}{}{}{} +{All data should be internally labelled with the appropriate + coordinate frame and units. If this information is ambiguous for some + reason, it should be set when the data is imported and the user + should not have to worry about it again.} + +\requirement{Current reference frames clear to user}{Done1}{}{}{}{} +{It should be clear to the user what coordinate frame (velocity, +position etc) the data is being presented as.} + +\requirement{Positional Reference Frame}{Not started}{1}{0.2d}{}{} {The user +should be able to specify the reference frame (Epoch,Equinox etc) for +which is used for exporting data, simple mapping output etc. J2000, +B1950 and Galactic should be supported. The default should be the frame +in what the data was recorded.} + +\requirement{Non-conformist Positional Reference Frame}{Not started}{2}{}{}{} +{Non-confirmist positional frames such as Az-El should be supported.} + +\subsection{Meta-data} + +A comprehensive set of header data should be read from the input data +files. In general all meta-data available in the rpfits file should be +retained. The user may wish to enter some specific values by hand. + +\requirement{View and edit header data}{Started}{1}{?}{}{} +{All header data should be viewable and editable by the user. This +includes changes such as scaling the given Tsys values.} + +\requirement{Missing header data}{Done1}{}{}{}{} +{Missing header data should be handled gracefully, i.e. the software +should fill the values with ``blanks'' and be able to continue to +process the data if possible.} + +\requirement{User add missing header data}{Not started}{2}{}{}{} +{The user must be able to add missing header data, which is not +present in the RPFITs file. It must be possible to add the same header +data to multiple scans simultaneously.} + +\extendedrequirement{Itemised header items}{Started}{1}{}{}{} +{The following header data would be required per scan: +\begin{itemize} + \item Source name + \item Scan type (signal or reference) + \item Integration time + \item Scan length (actual time of observation, $\ge$ integration time) + \item Telescope + \item UT time and date of observation + \item Telescope elevation of observation + \item Parallactic angle + \item Beam size + \item Scan ID + \item Observer + \item Project + \item Polarisation + \item Receiver + \item Telescope coordinates + \item Weather info (temperature, pressure, humidity) + \item User axis display preference (LSR velocity, frequency etc). +\end{itemize} +} + +\extendedrequirement{IF header items}{Started}{1}{}{}{} +{\label{req:if} +The following header data is required for each IF, beam etc: +\begin{itemize} +\item Source coordinates and coordinate frame +\item Frequency/velocity axis definition and type +\item System Temperature +\item Beam number +\item Molecule rest frequency$^\dagger$ +\item Molecular name$^\dagger$ +\item Molecular transition$^\dagger$ +\item Molecular formula$^\dagger$ +\end{itemize} +} + +\requirement{Pretty print formula}{Not started}{3}{}{}{} +{The molecular formula could be stored with embedded superscripted and +subscripted symbols for ``pretty'' printing on the plotted, but +printed in plain text on the CLI or in ASCIIs output} + +Some molecular line rest-frequencies are close enough that two or more +molecules or transitions may be observed in a single IF. Typical +examples include the 1665/1667~MHz OH maser pair, NH$_3$ transitions, +and many observations in the 3~mm band. +\vspace{\parskip} + +\requirement{Multiple rest frequencies per IF}{Not started}{2}{}{}{} +{The software should optionally support multiple lines per IF, by +storing a set of rest frequencies per IF, rather than a single +value. The header values in requirement \reqref{req:if} marked with a +$\dagger$ would all have to be stored as an array of values rather +than a scalar. A simple mechanism must be possible to change the +currently ``active'' rest-frequency.} + +\section{Installation} + +\requirement{Easy installation}{Started}{1}{?}{}{} +{It must be possible for astronomers to install the software at their +own institute with either a moderate amount of OS experience or some +help from the local system administrators. This includes installation +on a central ``NFS'' server as well as local desktops.} + +\requirement{Linux Support}{Started}{1}{3d}{}{} +{The software must run on major flavours of Linux +(Fedora/Redhat, Debian, etc).} + +\subrequirement{Solaris Support}{Started}{1}{?}{}{} +{The software must run on Solaris} + +\requirement{Run on laptop}{Done1}{}{}{}{} +{It must be possible for users to install the software on their +laptops and run with no network connection.} + +\requirement{Easy upgrade}{Done1}{}{}{}{} +{It should be relatively easy to upgrade to the latest version of the +software.} + +\requirement{MacOS/X support}{Not started}{1}{3+d}{}{} +{The software should run on MacOS/X} + +\requirement{Windows support}{Not started}{3}{}{}{} +{It would be desirable for the software to run on Windows.} + +\section{Known Issues} +\label{sec:issues} +The following issue are known problems with the data from ATNF +telescopes, which probably should be automatically corrected for if at +all possible. The best place to do this is while loading the data. + +\subsection{General} + +\begin{itemize} + \item All polarisations in the RPFITS files are labelled as + XX/YY. These need to be relabelled as LL/RR when appropriate. +\end{itemize} + +\subsection{Mopra} + +\begin{itemize} +\item Data obtained in 2002 \& 2003 (and probably before) have an + error in the frequency headers (this may be corrected by an external + program). \makenote{Nedd Ladd} + +\item The (RA,Dec) positions in the data file are in date coordinates + not J2000. This causes problems for packages like Class when + averaging the data. \makenote{Maria Hunt} + +\item It is possible Tsys calibration is inconsistent currently. + \makenote{Cormac Purcell??} + +\end{itemize} + +\subsection{Parkes} + +\begin{itemize} +\item For pulsar data the automatic gain control is disabled. This +means the nominal Tsys measurement does not change and Tsys per +integration is encoded in a non-standard way. \makenote{Simon +Johnston} +\end{itemize} + +\subsection{Tidbinbilla} + +\begin{itemize} +\item All 20-GHz data is calibrated in flux units of Kelvin. +\item Elevation is not written into the rpfits file. +\end{itemize} + + +\section{Requirements Matrix} + +\begin{longtable}{|l|l|l|c|l|} + +\hline +\bf Requirement & & \bf Status & \bf Priority & \bf Effort \\ +\hline +\endhead +\hline +\endfoot +\input{reqsum.tex} + +\end{longtable} + + +\end{document} Index: /tags/asap-4.4.0+atnf2/admin/smartref.sty =================================================================== --- /tags/asap-4.4.0+atnf2/admin/smartref.sty (revision 3150) +++ /tags/asap-4.4.0+atnf2/admin/smartref.sty (revision 3150) @@ -0,0 +1,207 @@ +\def\fileversion{v1.9} +\def\filedate{2002/02/28} +% smartref.sty +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% +% Giuseppe Bilotta +% +% Phone +39 095 338103 +% +% Email: bourbaki@bigfoot.com +% +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% +% This package is distributed under the terms +% of the LaTeX Project Public License +% +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% +% Please read the readme.txt file for details +% +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\NeedsTeXFormat{LaTeX2e} +\ProvidesPackage{smartref}[\filedate\space\fileversion\space Increase +reference capability (deep reference)] +% +\newcounter{@smartlistlen} +\newcounter{less@smartlist} +\setcounter{less@smartlist}{-2} +\newcommand*{\@increasesmartlist}{% + \addtocounter{@smartlistlen}{1}% + \addtocounter{less@smartlist}{1}} +\def\sm@rtreflist{{\@currentlabel}} +\@increasesmartlist +% +\newcommand*{\@getsmartreflist}[3]{% + \ifx#1% + \relax\protect\G@refundefinedtrue% + \@latex@warning {SmartReference `#2' on page % + \thepage \space undefined}% + \nfss@text{\reset@font \bfseries ??}% + \else% + \expandafter #2#1% + \fi} +\newcounter{@currsmartlistplace} +\newcommand*{\@getsmartref}[3]{%Paramaters are: #1: Where #2: Label, #3: place in list + \edef\@smartlistplace{#3}% + \setcounter{@currsmartlistplace}{0}% + \edef\@originalsmartlist{% + \expandafter\@getsmartreflist\csname sr@#2\endcsname{}{}}% + \edef\@currsmartlist{\@originalsmartlist}% + \loop% + \edef\@currsmartvalue{\expandafter\@car\@currsmartlist\@nil}% + \ifnum\the@currsmartlistplace=\theless@smartlist + \edef\@currsmartlist{\noexpand{\expandafter\@cdr\@currsmartlist\@nil\noexpand}}% + \else + \edef\@currsmartlist{\expandafter\@cdr\@currsmartlist\@nil}% + \fi + \ifnum\the@currsmartlistplace<\@smartlistplace% + \addtocounter{@currsmartlistplace}{1}% + \repeat + \edef#1{\@currsmartvalue}% +% \typeout{Got Smart Reference (place #3, value \@currsmartvalue)}% + } +% Hack label: also write the SmartRef data ... +\def\newsmartlabel{\@newl@bel {sr}} +%save previous \label +\AtBeginDocument{% + \let\sr@ldlabel=\label + \renewcommand*{\label}[1]{% + \sr@ldlabel{#1}% + \@bsphack% + \protected@write\@auxout{}% + {\string\newsmartlabel{#1}{\sm@rtreflist}}% + \@esphack}% +% This one is needed for those who use AMS-LaTeX, to ensure that +% smartref labelling system is used wih equations too (AMS-LaTeX +% uses its own labeling system for equations + \let\ltx@label=\label} +% Command to add new items to reflist: +% +\newtoks\sm@rtintern@ltok +\newcommand*{\addtoreflist}[1]{% Add item ... + \@ifundefined{c@#1}% Check if real counter; + {\@nocounterr{#1}}% If not, give error + {\@ifundefined{#1posinlist}{% If yes, check if already defined: + \sm@rtintern@ltok=\expandafter{\sm@rtreflist}% If not, define everything ... + \expandafter\edef\csname sm@rtreflist\endcsname{% + \the\sm@rtintern@ltok{\noexpand\csname the#1\endcsname}}% Add it ... +% Set position of counter in list: + \expandafter\edef\csname #1posinlist\endcsname{\the@smartlistlen}% + \@increasesmartlist% +% Define SmartCommands: +% Define command to get number of for