|Return to release.notes CVS log||Up to [Development] / JSOC / CM / V5.11|
File: [Development] / JSOC / CM / V5.11 / release.notes
Revision: 1.2, Wed Oct 6 18:13:46 2010 UTC (12 years, 8 months ago) by arta
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 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.10 - Sep 1, 2010) -------------------------------------------------------- NEW FEATURES: - 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). DEFECTS FIXED: - 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 * EXISTING DEFECTS: - Please see http://jsoc.stanford.edu/trac/report/1 for a list and description of most known bugs.