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

File: [Development] / JSOC / CM / V5.5 / release.notes (download)
Revision: 1.2, Fri Oct 9 17:50:41 2009 UTC (13 years, 7 months 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-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: +1 -1 lines
fix typo in release notes

                       Release Notes JSOC V5.5         9OCT2009
                       -----------------------         ---------


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
properly).  

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:
JSOC/CM/working_with_sandbox.txt.

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

http://jsoc.stanford.edu/cvs/JSOC/

Use the Apache cvs gui to see the diffs. For example, go to
http://jsoc.stanford.edu/cvs/JSOC/base/drms/
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.3 - Aug 5, 2009)
--------------------------------------------------------

NEW FEATURES:
+ Cleaned up make system and configuration script. lib_third_party
removed. Instead, config.local contains paths to the third-part
libraries, which are placed into make variables that are used during
compilation and linking. Added support for machine-specific output
directories (so you can generate binaries in directories other than
linux_x86_64 and linux_ia32).  
+ Reworked config.local/gen_init.csh/customizedefs.pl to provide additional
parameters that can be customized, including fields that allow the
user to customize the cmd-line used to copy remote storage units
locally (the remoteSUMS process).  
+ icc compilation/linking displays default warnings, remarks, 
and error messages (no -W flags supplied to icc cmd-line).  
+ Addition of support for JSOC_WARNICC environment
variable. The string assigned to this variable will be passed onto the
icc compile cmd-line.  
+ Move remotesums_master.pl and remotesums_ingest from Stanford-specific 
locations in the CVS tree (part of the full JSOC release), to the NetDRMS 
part of the CVS tree.
+ Modify remotesums export so that sites can override the sums_url
field in jsoc.drms_sites to specify their own copy program cmd-line.
+ Added SUMS_MANAGER_UID, the SUMS manager's UID, to config.local
(actually, there is code that runs that will generate this from the
SUMS_MANAGER field, which contains the linux-account name of the SUMS
manager).  
+ Change from caching ALL series in the series_cache during
module startup to lazy loading of the cache (on-demand). Stanford has
over 43K series and caching all of them, despite most of them never
being used, was inefficient.  
+ Certain keywords can be marked 'reserved' so that they don't 
get exported or imported.  
+ There are two new functions in the API - base_fitskeycheck and 
base_drmskeycheck - that check for invalid fits and drms keywords, and check 
to see if keywords are reserved.  
+ Implementation of drms_segment_fopen() and drms_segment_fclose() - 
two new API functions to open and close a FILE * to the segment's file, 
so that, especially for the generic segment
protocol, you can write to a FILE * directly (and not have to COPY a
generic file into a storage unit).  
+ When writing data slices to compressed data files belonging to vardims 
segments use the dimensions of the array to be written as the compression-tile size.  
+ SUMS now uses a sum_chmown script to change ownership of files in SUMS to
production. Previously a sudo was used, which, under certain
circumstances, could require user interaction. This would cause
sum_svc to stop responding. sum_chmown has setuid set to run as root.
+ New utility show_coverage added. For certain types of series,
displays how complete the data coverage is (if data are expected to
exist at a certain cadence, shows how many expected items are
missing).  
+ jsoc_fetch now returns more information, as soon as it
has it, when exporting storage units. The information is provided per
storage-unit, as a list.  
+ jsoc_export_SU_as_is now will not fail if an SUNUM is unknown. Instead, 
it will simply set an appropriate status string in the status field of the 
information returned to the user.  
+ ingest_from_fits added, a simple program to ingest FITS files that
contain single image extensions.  
+ Add a new flag, p, to time_convert that allows the user to specify 
the precisions of seconds.

BUG FIXES:
+ Remove the compilation of the DRMS fortran interface from the
NetDRMS build if no acceptable fortran compiler is found.  
+ Remove the ricecomp library - it was unused.  
+ Code that writes images with all blank values - shorts, ints, and 
long longs - was not working properly.  
+ Add a workaround to overcome a fitsio bug where it was
not properly updating the TFORM1 keyword when writing compressed
images. The workaround is to manually write the TFORM1 keyword.  
+ Modify drms_copy_keys to not fail if one or more of the target
keywords cannot be set because they are not present in the set of
source keywords.  
+ timeio library fixes: 1. Fix parse_zone so it
handle timezone strings that have trailing non-timezone chars,
2. Another fix to parse_zone to handle +- time offsets, 3. Fix for
time parser looking for JD anywhere in timestring when checking for a
Julian Day time string (should only have MJD or JD at the beginning of
the time string), 4. In DRMS, when parsing a time range, if a time
string is of the form 2009.02.05_12:00:00-2009.02.05_15:00:00,
associate -2009 with the second time string, not the time zone of the
first, 5. Handle invalid time strings properly 
+ drms_ismissing_time wasn't properly comparing against the 
missing time (JD_0) 
+ cmdparams library fixes: 1. cmdparams had the wrong value for JD_0, 2. memory
corruption fixed (appeared with sufficiently long argument string
lengths), 3. buffer overrun fixed.  
+ Don't copy the keyword description from a slotted key to the associated 
index key.  
+ Modify the default file extension for generic-protocol-segment files - it
used to be .generic, but now it is the empty string. There is no such
thing as a .generic file type.  
+ When converting integer keyword values that are represented as ascii 
strings to integers, properly supports hexidecimal strings 
(0x08af35de is properly recognized now).
+ Fix to script that ingests slony logs into slony log-shipping
receiver.  
+ In database connection code, initialize variable "on" to
1 in db_tcp_listen().

NOTE:
+ If using icc/ifort to compile and link, you must use icc version 11, otherwise 
use gcc/gfortran. icc compilation and linking flags were modified to support 
version 11 only.

Karen Tian
Powered by
ViewCVS 0.9.4