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

File: [Development] / JSOC / CM / V8.3 / release.notes (download)
Revision: 1.2, Thu Feb 6 14:39:56 2014 UTC (9 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-12, Ver_8-11, Ver_8-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-3, NetDRMS_Ver_8-12, NetDRMS_Ver_8-11, NetDRMS_Ver_8-10, HEAD
Changes since 1.1: +29 -0 lines
Release notes for the 8.3 DRMS release.

                       Release Notes JSOC V8.3        5FEB014
                       -----------------------        --------

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).  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/jsoc/cvs/Development/JSOC (The release binaries are actually in
/home/jsoc/cvs/JSOC, but as our production code changes emore quickly
than releases are generated, we put critical fixes in the
"Development" tree. To be sure you use code that has been built with
these critical fixes, you'll need to use the "Development" tree. As
time passes our production code will stabilize. When that happens, you should use
/home/jsoc/cvs/JSOC. But for now, you should use the "Development"
tree.). Every time a release is created, the binaries in
this location get updated.  Only the jsoc user can update these binaries.
You could run /home/production/cvs/JSOC/Development/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.  

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 see the section entitled
Update Your Existing Working Directory ("Sandbox")). 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.  

Additional Info
Use the Apache cvs gui to see the diffs between file revisions. 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 (V8.2 - November 20, 2013)

+ When DRMS records are staged (their SUMS data are brought online from tape, if they were offline; storage-unit information is also cached in memory), if those records link to other records, the target records are first cached in memory, and then the records are staged.
+ Additional DRMS-SUMS interface logging was added, but is only seen in verbose mode. We are trying to trackdown a deadlock that occurs near the end of a module's run.
+ SQL to create the 'drms' namespace and the 'sumsadmin' user were moved to the NetDRMS.sql used for new NetDRMS installations. Previously, this SQL had to be typed and executed manually.
+ The script copySeriesTable.pl was added. It copies database records, identified by a file containing a list or recnums, from one drms-series database table to another.
+ The localization process was modified to allow the separation of the DRMS database host from the SUMS database host.
+ store_dir now now specifies a DATE keyword when creating the JSD for the output series. Also, the description for the 'perm' parameter was removed. This parameter had never been implemented.
+ The 'notify' and 'requestor' fields of the export web app have been revamped. The behavior has been improved.
+ The export-web-app cutout edit boxes will now retain their current settings when the user switches the input series. This allows users to quickly do analogous cutouts from similar series. Previously, a change in input series would cause the settings to be cleared.
+ New global helioseismology features: calculate image statistics and properly propagate the QUALITY keyword, add the MCORLevel2 keyword, change to c-style preprocessor directives, conditionally include lines from fitcom24.f, decrease detrending length and constant.
+ The make rule that checks source-code version consistency was optimized to run much faster.
+ Use of /scr21 was replaced with use of /surge40 in various places in our code tree.
+ The location of the SUMS server was changed. All supporting code was updated to "point" to the new location.
+ The disambiguation's log file is now being used as a lock file too. Several processes write to that log file.
+ brblossynoptic is a new module that produces both Br and Blos synpoptic charts.
+ Some flight-data files were updated.
+ A new parameter for sumstapestat.pl was added. When set, it allows users to print usage statistics on specified tape groups. Without the flag, the statistics are collected for all tape groups, which can take a long time.
+ The IRIS-processing status entries of the processing-status web page were modified so that longer delays are considered acceptable.
The UI was correspondingly updated to account for these changes.
+ The --loopconn DRMS argument was added to the pipeline module command lines. The effect is for these modules to now wait for SUMS to be up and running and accepting requests if it is in fact down when the module first attempts to connect to SUMS.
+ The scripts in proj/rings, proj/timed, and proj/farside were modified to (a) further generalize options for run-time localization of scratch- and temp-directory roots; and (b) allow for gatekeeper functions to dynamically suspend script submission to queue.
+ The ephemeris-determination code used to build proj/rings/apps/rdcover was cleaned up.

+ A problem in the localization script was fixed. It now properly obtains compiler versions if the auto-detect-compilers feature is enabled.
+ The refcount on linked records was inappropriately incremented at times (when in fact no reference was being created). Now the bookkeeping for record recounts is accurate.
+ The code that creates new DRMS records was requesting too large a storage unit because, for records linked to other records, it was accounting for the file sizes of linked segments. This code no longer estimates the size of the SU needed. Instead it always requests SUs of 100MB - a small amount that is virtually guaranteed to be present always.
+ There was a long-standing malloc(0) in some lower database-interface code that was triggered by new code. The code now uses the proper expression to determine the needed amount of bytes.
+ There was magnetic code that was misinterpreting CRPIX1-2. This has been fixed.
+ The computations of CRPIX1, CRPIX2, CRVAL1, and CRVAL2 by misynoptic were not correct. This has been fixed.
+ The makeimageslowhigh script in the gatekeeper was not checking for the existence of a directory before using it. This has been fixed.

Karen Tian
Powered by
ViewCVS 0.9.4