(file) Return to release.notes CVS log (file) (dir) Up to [Development] / JSOC / CM / V5.2

  1 arta  1.1                        Release Notes JSOC V5.2         30Jul2009
  2                                  -----------------------         ---------
  5           A release is a set of files, each having a specific version.  And a release typcially
  6           has a version number because over time you have newer and newer releases of the 
  7           same product.  For example, a hypothetical 1.3 release may contain fileA#1.8, 
  8           fileB#1.2, fileC#2.2 and a 1.4 release may contain fileA#2.5, fileB#2.1, fileC#2.9. 
  9           JSOC releases are similarly versioned and contain a set of such files.  JSOC release
 10           code is guaranteed to compile on cluster nodes (eg., n00, n02).  The resulting binaries
 11           have been minimally tested.  At the time of the creation of the release, the
 12           release versions of each file will be the most recent.  But as time passes, newer versions 
 13           of some files will be made, and there is no guarantee that these changes will
 14           not destabilize JSOC (ie., they may cause JSOC to no longer compile or execute
 15           properly).  
 17           There are several ways to use this release.  If you wish to simply use pre-built
 18           binaries, you can simply use the production binaries, which are located at 
 19           /home/production/cvs/JSOC.  Every time a release is created, the binaries in
 20           this location get updated.  Only the production user can update these binaries.
 21           So, you could run /home/production/cvs/JSOC/bin/linux_x86_64/show_keys, for example.
 22 arta  1.1 If instead you want to work with stable source files, then you must have a sandbox,
 23           which is a local copy (in your home directory) of the files in the cvs depot.  
 24           You would probably want to work with a sandbox if you plan on making eventual 
 25           changes to the depot files.  Changes you make to your sandbox files are not visible 
 26           to other users until you "commit" those changes back to the cvs depot.  Please see
 27           "If You Don't Have a Sandbox" below for more information on how to create a sandbox.  
 28           There is also a "working" release which resides in in /home/jsoc/cvs/JSOC.  New 
 29           files may be placed here and existing files may be edited for common use before the 
 30           next official release.  Each time a release gets created, the source and binaries of 
 31           the working release get updated.  WARNING: the files you see here may not be stable 
 32           since by the time you see them, another user may have edited them. Only the production 
 33           release is guaranteed to be stable and unchanged between releases.
 35           Obtaining the Release
 36           ---------------------
 37           To update your working directory to this release, or to check-out this release anew, 
 38           please visit http://jsoc.stanford.edu/jsocwiki/CvsInit. Please keep in mind that
 39           users may have modified files since the release was created, so use of the 
 40           scripts documented in the web page may result in a working directory whose
 41           content is not identical to the release.  If updating, you can supply 
 42           the flag "-R" to the jsoc_update.pl and jsoc_sync.pl scripts to download the
 43 arta  1.1 latest release.  This will ensure that your working directory has the exact, latest
 44           release versions of the files (eg., jsoc_sync.csh -R). If checking-out, 
 45           you can supply the argument "-r Ver_LATEST" to the "cvs checkout" command
 46           to achieve the analogous result, but for a fresh checkout.  WARNING: if you use 
 47           the "-R" or "-r" flags, please use only jsoc_update.pl or jsoc_sync.pl to update 
 48           your sources thereafter.  Use of "-R" or "-r Ver_LATEST" will result in a cvs
 49           "sticky flag" being set.  jsoc_update.pl and jsoc_sync.pl clear this sticky flag.
 51           Additional Info
 52           ---------------
 53           If you are unfamiliar with the use of cvs see the file:
 54           JSOC/CM/working_with_sandbox.txt.
 56           There's a linux4 cvs gui at xim:/usr/bin/lincvs
 57           Also on our jsoc web page:
 59           http://jsoc.stanford.edu/cvs/JSOC/
 61           Use the Apache cvs gui to see the diffs. For example, go to
 62           http://jsoc.stanford.edu/cvs/JSOC/base/drms/
 63           and click on the name in the File column and then click on
 64 arta  1.1 "diffs to previous #" to see the diffs.
 66           Changes since previous release (V5.1 - May 1, 2009)
 67           --------------------------------------------------------
 69           NEW FEATURES: 
 70           * Support for gfortran compiler. 
 71           * Compilers can now be specified with environment variables (JSOC_COMPILER and JSOC_FCOMPILER). Otherwise the configure script now determines the defaults.
 72           * Made PGIPATH and ECPL customizable.
 73           * Made the base SUMS dir and the linux group that contains the SUMS manager account customizable. 
 74           * Add "-L" flag to drms_server and drms_run. If set in drms_run, then it is passed along to drms_server. "-L" means create a log storage unit to contain the stdout and stderr of module execution.
 75           * Masterlists now has a "-g" flag to be used when creating "guest" postgres accounts.
 76           * binfile headers now contain bzero and bscale fields. 
 77           * Series being replicated via Slony can no longer be deleted by delete_series. They must be manually deleted.
 78           * Added drms_fitsrw_write() - exports generic FITS files.
 79           * Added drms_fitsrw_read() - reads any arbitrary FITS file (that contains an image extension) into DRMS_Array_t (for image) and HContainer_t (for keys) structures. 
 80           * Added drms_keyword_setdate() - to set an implicit DRMS keyword (a double) with the current date. This value gets exported as an ISO date string to the FITS DATE keyword during export.
 81           * Added drms_keyword_getdate() - to read an implicit DRMS keyword that contains a date that was previously set.
 82           * During ingestion, all COMMENT FITS keywords are appended into a single DRMS keyword. The values are separated by newline characters. During export, the DRMS values are separated into multiple FITS COMMENT keywords.
 83           * Modify the parser invoked by create_series to provide useful debugging information: the line number of the source code where the error occurred is now printed; and the line number of the .jsd that triggered the error is now printed.
 84           * exportdata and jsoc_export_as_fits now support the specification of the type of compression to apply when exporting FITS files.
 85 arta  1.1 * Added sum_chmown. This program changes the ownership of files written to SUMS by non-SUMS managers to the SUMS manager. It also modifies the permissions of those files so that they can only be modified by the SUMS manager.
 86           * jpe added.
 87           * Code to make level 1.5 observables added.
 90           BUG FIXES:
 91           * gen_init.csh assuming a third-party library-directory structure that was inconsistent with the structure at Stanford. gen_init.csh was modified to assume that libraries are stored in platform-specific subdirectories (eg., <dir>/lib/linux_x86_64/libfftw3f.a, <dir>/lib/linux_ia32/libfftw3f.a)
 92           * In configure, pre-pended "./" to moreconfigure.pl since not all users will have their JSOC root or current directory in their path
 93           * Fix ifort compiler flags - removed bad combination of -ftrapuv and -xW.
 94           * Remove large leaks in drms_server_begin_transaction()/drms_server_end_transaction().
 95           * Remove erroneous warning string 'Potentially invalid time string' that appeared when calling create_series.
 96           * Removed several memory leaks.
 97           * Fixed several problems, including deadlocks and crashes, that could happen during module termination.
 98           * Hide all implicit DRMS keywords from users (via show_info -j, etc.).
 99 arta  1.2 
100           IMPORTANT NOTE:
101           Third-party libraries must exist in platform-specific subdirectories (eg., /usr/local/lib/linux_x86_64/libcfitsio.a, /usr/local/lib/linux_ia32/libcfitsio.a)

Karen Tian
Powered by
ViewCVS 0.9.4