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

File: [Development] / JSOC / CM / V5.11 / release.notes (download)
Revision: 1.2, Wed Oct 6 18:13:46 2010 UTC (12 years, 8 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-14, Ver_5-13, Ver_5-12, Ver_5-11, 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 -0 lines
One more change before the release

                       Release Notes JSOC V5.11        06OCT2010
                       ------------------------        ---------

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.10 - Sep 1, 2010)

- First release that contains full hmi-level1 processing.
- Initial check-in of lev 1.5 observable processing code.
- jsoc_export_as_fits - Modify to allow record limit via n=limit command line.
- show_coverage - added bulk fetch of SUM_info for the -o flag.
- jv2helio - Added 2 keywords for synoptic char usage, MAPLGMIN, MAPLGMAX.
- dsdf.pl - For TRAC ticket #312. Added new code to process thermal data from moc
- polcal.c - New version with better DC correction of I->Q,U leakage and DC preserving kernels.
- fresize.c - Now allows for user defined convolution kernel.
- hmi_patch_module.c - added DATE and BLD_VERS.
- Modify Slony-replication configuration so that the production version of code is used.
- Ticket #306 - Add case statements in argtypename (returns the name associated with a cmdparams argument type enum value).

- The lowest-level DRMS keyword-setting function no longer returns an error if it receives a DRMS_INEXACT status code. This allows drms_copykeys() to convert from (for example) a double to a float without reporting an error (but there will be a loss of precision).
- The function that calculates the number of records in a record-set subset (drms_recordset_getssnrecs()) was improperly handling the case there were no records in a subset. This has been corrected.
- Fix crash in jsoc_export_as_fits.
- Ticket #293 - when determining if the per-segment keyword is relevant to the segment being exported, use %03d for the format, not %d, when converting the segment number into the search string. The code looks for the presence of the search string in the keyword name - eg, it is looking for 002 in TOTALVALS_001. If the search string is present, then the keyword is relevant to the segment being exported.
- Fix for delete_series not passing to SUMS the SUNUMs of obsolete records.
- Fix for broken drms_commit_all_units() - a variable initialization bug was preventing the ability to archive any SUs.
- Fix for export failure reported, but at least one file got exported successfully.
- Fix n=xx count for show_info in export as-is case.
- Fix show_info call for as-is exports of hg_patch.
- jsoc_fetch - fix for variable 'now' not being initialized when op=exp_su.
- jsoc_info - When stripping off filters, etc, from a record-set query to isolate the series name, also strip off curly braces.
- exputil.c - Added format changes for regular keywords and specila...
- jv2helio - fix problem with R_SUN vs. RSUN_OBS.  remove compiler warnings by casting input arguments to char *.
- do_flat.c - MINOUT/MAXOUT clipping was applied to first quadrant only; fix
- fresize.c - fix memory leak.
- arithtool.c - fix crash in clean up code; vars that hold the results of cmdparams_get_str are not const char *

- Please see http://jsoc.stanford.edu/trac/report/1 for a list and
description of most known bugs.

Karen Tian
Powered by
ViewCVS 0.9.4