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

File: [Development] / JSOC / CM / V5.2 / release.notes (download)
Revision: 1.2, Tue Aug 4 13:04:56 2009 UTC (14 years, 1 month ago) by arta
Branch: MAIN
CVS Tags: Ver_LATEST, Ver_9-5, Ver_9-41, Ver_9-4, Ver_9-3, Ver_9-2, Ver_9-1, Ver_9-0, Ver_8-8, Ver_8-7, Ver_8-6, Ver_8-5, Ver_8-4, Ver_8-3, Ver_8-2, Ver_8-12, Ver_8-11, Ver_8-10, Ver_8-1, Ver_8-0, Ver_7-1, Ver_7-0, Ver_6-4, Ver_6-3, Ver_6-2, Ver_6-1, Ver_6-0, Ver_5-9, Ver_5-8, Ver_5-7, Ver_5-6, Ver_5-5, Ver_5-3, Ver_5-2, Ver_5-14, Ver_5-13, Ver_5-12, Ver_5-11, Ver_5-10, NetDRMS_Ver_LATEST, NetDRMS_Ver_9-5, NetDRMS_Ver_9-41, NetDRMS_Ver_9-4, NetDRMS_Ver_9-3, NetDRMS_Ver_9-2, NetDRMS_Ver_9-1, NetDRMS_Ver_9-0, NetDRMS_Ver_8-8, NetDRMS_Ver_8-7, NetDRMS_Ver_8-6, NetDRMS_Ver_8-5, NetDRMS_Ver_8-4, NetDRMS_Ver_8-12, NetDRMS_Ver_8-11, NetDRMS_Ver_8-10, HEAD
Changes since 1.1: +3 -0 lines
Add important note to release notes

                       Release Notes JSOC V5.2         30Jul2009
                       -----------------------         ---------

A release is a set of files, each having a specific version.  And a release typcially
has a version number because over time you have newer and newer releases of the 
same product.  For example, a hypothetical 1.3 release may contain fileA#1.8, 
fileB#1.2, fileC#2.2 and a 1.4 release may contain fileA#2.5, fileB#2.1, fileC#2.9. 
JSOC releases are similarly versioned and contain a set of such files.  JSOC release
code is guaranteed to compile on cluster nodes (eg., n00, n02).  The resulting binaries
have been minimally tested.  At the time of the creation of the release, the
release versions of each file will be the most recent.  But as time passes, newer versions 
of some files will be made, and there is no guarantee that these changes will
not destabilize JSOC (ie., they may cause JSOC to no longer compile or execute

There are several ways to use this release.  If you wish to simply use pre-built
binaries, you can simply use the production binaries, which are located at 
/home/production/cvs/JSOC.  Every time a release is created, the binaries in
this location get updated.  Only the production user can update these binaries.
So, you could run /home/production/cvs/JSOC/bin/linux_x86_64/show_keys, for example.
If instead you want to work with stable source files, then you must have a sandbox,
which is a local copy (in your home directory) of the files in the cvs depot.  
You would probably want to work with a sandbox if you plan on making eventual 
changes to the depot files.  Changes you make to your sandbox files are not visible 
to other users until you "commit" those changes back to the cvs depot.  Please see
"If You Don't Have a Sandbox" below for more information on how to create a sandbox.  
There is also a "working" release which resides in in /home/jsoc/cvs/JSOC.  New 
files may be placed here and existing files may be edited for common use before the 
next official release.  Each time a release gets created, the source and binaries of 
the working release get updated.  WARNING: the files you see here may not be stable 
since by the time you see them, another user may have edited them. Only the production 
release is guaranteed to be stable and unchanged between releases.

Obtaining the Release
To update your working directory to this release, or to check-out this release anew, 
please visit http://jsoc.stanford.edu/jsocwiki/CvsInit. Please keep in mind that
users may have modified files since the release was created, so use of the 
scripts documented in the web page may result in a working directory whose
content is not identical to the release.  If updating, you can supply 
the flag "-R" to the jsoc_update.pl and jsoc_sync.pl scripts to download the
latest release.  This will ensure that your working directory has the exact, latest
release versions of the files (eg., jsoc_sync.csh -R). If checking-out, 
you can supply the argument "-r Ver_LATEST" to the "cvs checkout" command
to achieve the analogous result, but for a fresh checkout.  WARNING: if you use 
the "-R" or "-r" flags, please use only jsoc_update.pl or jsoc_sync.pl to update 
your sources thereafter.  Use of "-R" or "-r Ver_LATEST" will result in a cvs
"sticky flag" being set.  jsoc_update.pl and jsoc_sync.pl clear this sticky flag.

Additional Info
If you are unfamiliar with the use of cvs see the file:

There's a linux4 cvs gui at xim:/usr/bin/lincvs
Also on our jsoc web page:


Use the Apache cvs gui to see the diffs. For example, go to
and click on the name in the File column and then click on
"diffs to previous #" to see the diffs.

Changes since previous release (V5.1 - May 1, 2009)

* Support for gfortran compiler. 
* Compilers can now be specified with environment variables (JSOC_COMPILER and JSOC_FCOMPILER). Otherwise the configure script now determines the defaults.
* Made PGIPATH and ECPL customizable.
* Made the base SUMS dir and the linux group that contains the SUMS manager account customizable. 
* 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.
* Masterlists now has a "-g" flag to be used when creating "guest" postgres accounts.
* binfile headers now contain bzero and bscale fields. 
* Series being replicated via Slony can no longer be deleted by delete_series. They must be manually deleted.
* Added drms_fitsrw_write() - exports generic FITS files.
* 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. 
* 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.
* Added drms_keyword_getdate() - to read an implicit DRMS keyword that contains a date that was previously set.
* 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.
* 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.
* exportdata and jsoc_export_as_fits now support the specification of the type of compression to apply when exporting FITS files.
* 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.
* jpe added.
* Code to make level 1.5 observables added.

* 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)
* In configure, pre-pended "./" to moreconfigure.pl since not all users will have their JSOC root or current directory in their path
* Fix ifort compiler flags - removed bad combination of -ftrapuv and -xW.
* Remove large leaks in drms_server_begin_transaction()/drms_server_end_transaction().
* Remove erroneous warning string 'Potentially invalid time string' that appeared when calling create_series.
* Removed several memory leaks.
* Fixed several problems, including deadlocks and crashes, that could happen during module termination.
* Hide all implicit DRMS keywords from users (via show_info -j, etc.).

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