| |
This FAQ page is obviously very incomplete. If you have contributions -- suggested questions and (especially) answers -- or corrections, please e-mail them to me at radforddc@ornl.gov.
Last updated on 15 May 2000.
RadWare is a powerful, user-friendly software package for interactive graphical analysis of gamma-ray coincidence data. It is used by many physicists around the world as they study the structure of the atomic nucleus and analyze the results of their experiments.
A few of the more commonly-used RadWare programs are:
Each of the above programs has at least two versions with different user interfaces; gf3, xmgf3 and gf3x; escl8r and xmesc; levit8r and xmlev; and 4dg8r and xm4dg.
Other programs are: 4play, addmat, algndiag, branch, calib_ascii, combine, divide, dixie_gls, drawstr_ps, effit, encal, energy, escl8r, ex_diff, foldout, gls, gls_conv, incub8r, legft, lufwhm, make4cub, pedit, plot, plot2ps, pro3d, pro4d, pslice, rdm, rdmfit, sdgen, split4cub, slice, Source, spec_ascii, statft, subbgm2, subbgmat, symmat, unfold, unix2unix, vms2unix, win2tab and xmgls.
A partial list of the files included in the RadWare distribution is given here. There are lots of demo*, *.hlp and *.txt files that you might like to peruse. All the command-driven programs have internal help available; typing HELP from inside a program will usually bring at least a hint of what you can try.
You can get the latest versions of RadWare (currently rw99) for unix or VMS via web download. Just follow the links given here. Or you can just visit radware.phy.ornl.gov/ftp/radware/unix, radware/vms. Then get README and follow the instructions therein.
Follow the instructions given in the README files. You can get them here:
README file for unix
README file for VMS
Just reinstall everything as if it was the first time. You may want to keep some of your old files; for example, your old Makefile and the .PAR or .h files.
Please send bug reports to
David Radford
at radforddc@ornl.gov.
Ideas, suggestions and contributions are also very much appreciated.
Here is a gf3 help file (in html).
First, make sure you understand the functional form of the peaks fitted by gf3, and which parameters you may wish to fix or free.
Then display the part of the spectrum that you want to fit, and use the AF command or the NF command.
Depending on what you want the results for, you may wish to save the fitted peak areas and centroids with the SA command.
Use the ST command.
For both efficiency and energy calibrations, you need to create a .sto file with gf3, containing stored areas and centroids of the peaks in your source calibration spectra. You can do this with the autocalibrate feature of gf3, i.e. the CA command, or in the more old-fashioned way, by fitting the peaks and then using the SA command.
Once you have your .sto file, use the program Source to combine your experimental numbers with the intensities and energies of the gamma-ray peaks from the calibration source. Source will generate a .sin file, that can then be used as input into the programs effit or encal.
See the above instructions for making .sto and .sin files with gf3 and Source, and then run the program encal. Alternatively, if you know the energy calibration coefficients, you can create an ASCII version of the .cal file, an .aca file, being sure to use the correct formatting of the fields. You can use a copy of demo/demo.aca as a starting point.
The answer to this depends on what you want the .tab file for.
For incub8r / levit8r, or 4play / 4dg8r, where you want a lookup-table
that does a possibly non-linear mapping of ADC channels (for the data on tape) to
(hyper)cube channels, then the simplest solution is to use the program
lufwhm. You will need to have some
idea of the range of ADC channels that you wish to include in your cube.
If you wish to use nonlinear gains, you should also have some idea of how
the width (FWHM) of the peaks varies with energy; you will need to specify
this in terms of parameters like those used to define the starting width
in gf3, see gf3.hlp or the
escl8r/levit8r NIM paper for details.
If you do not want to use nonlinear gains, you can simply enter
1, 0, 0
as the FWHM parameters, to pretend that you have a constant FWHM of 1 channel.
Lookup-table files can be used for other purposes, however; for example, they are very useful in scanning tapes for setting gates on your raw Ge energies to select certain reaction products or bands for selective analysis. It was for this application that the .tab file format was first developed. They can be easily created in gf3 by using the LU and WI commands. You can also display the windows in any .tab file, including those from lufwhm, by using the DW command.
Here are html-ised versions of my NIM papers on
ESCL8R and LEVIT8R: Software for
interactive graphical analysis of HPGe coincidence data sets
(D.C. Radford, Nucl. Instr. Meth. A361(1995)297)
and
Background subtraction from in-beam
HPGe coincidence data sets
(D.C. Radford, Nucl. Instr. Meth. A361(1995)306)
Use gf3 and read in the projection. Then use the BG command (autoBackGround) to create a background spectrum under the peaks. Or use SC (Set Counts) to draw a background spectrum by hand, by cutting off the peaks. When you're finished, write the modified spectrum out as the background spectrum. I generally leave the X-rays in as background. I also sometimes put in (n, n' gamma) peaks/shoulders, though this is not necessary especially for a first stab.
There are two answers to this question:
1) It depends on your data set, and
2) Only if you think it's needed.
I usually don't bother with the E2 correction for a first look at the data. Then, if I see problems with the background subtraction, such as differences in the background subtraction for different reaction channels (e.g. 4n undersubtracted, 5n oversubtracted at around 1.4 MeV) then I try using the E2 correction. The bottom line is: If it helps, use it, otherwise not. Sometimes it can make things worse rather than better. Don't be afraid to experiment.
To make use of the E2-enhanced background, you need to have the original symmetrized matrix. Call up gf3, read in the total projection, and use the SL and WI commands to create a .win file for slice, containing one or more wide gates on the E2-bump region of the spectrum. Depending on the nucleus, this is usually in the region of 1.1 to 1.6 MeV, but you should also be guided by the observed E2-bump problems in your escl8r gates. You don't need to worry about small peaks in the gate(s), but try to exclude large peaks.
Then exit from gf3, and use slice to take an x-projected gate on the matrix, summing all of the windows in your .win file. Keep the .win file for use later in escl8r. In gf3 again, read in the summed gate and draw a background under it with the BG or SC commands, just as you did for the total projection. Save this background spectrum.
Now in escl8r, use the CB (Change 2D Background) command to put in the new background, as in the following example:
Change background? (Y/N)y
Use enhanced background from E2-bump gates? (Y/N)y
Total projection spectrum file name = ?hfs
E2 projection spectrum file name = ?hfe2
Total background spectrum file name = ?hfb
E2 background spectrum file name = ?hfe2b
Default value for factor 1 is 10.43896
Factor 1 = ? (rtn for default)
E2 gate file = ? (default .EXT = .win)hfe2
Default value for factor 2 is 61194.43
Factor 2 = ? (rtn for default)
If you like, you could get the Unix demonstration dataset hfdemo.tar.gz (4.3MB) from https://radware.phy.ornl.gov/ftp/radware/unix. There is a .esc file in there, together with the .spe and .win files that were used to generate it. For VMS, there is hfdemo.zip (5.4MB) in https://radware.phy.ornl.gov/ftp/radware/vms.
First create a 1D projection from the cube using pro3d. Then, in gf3, divide the projection with the "compression spectrum" width.spe from lufwhm, and create a background spectrum using BG or SC in gf3, as described above for escl8r. Finally, multiply this background spectrum with width.spe, which gives the final background spectrum that should be used as input to levit8r. Save this spectrum with the WS command.
I'm sorry that it's so complicated.
As for the E2 correction in levit8r, well, it's even more tricky. The present version needs a bit more work to make it a permanent, user-friendly solution to setting up the E2 correction term. Here is a rough prescription for how I do it in the meantime.
I put the background spectrum to zero (by using a zero-multiplied projection as my background spectrum and using the levit8r CB command) and then take a big (single) gate on the E2 bump in levit8r, using the G command. I then write this gate as a gf3-type .spe file. This is my E2 spectrum. In gf3 I do the usual trick of drawing the background and multiplying by the width again; the only difference from the total projection is that levit8r writes the spectrum as counts/keV, so I need to divide by two to get counts/channel (assuming 0.5-keV channels) and NOT divide by the width spectrum to start with. I also make a note of the window limits in the gate in levit8r, and use them now in gf3 to create a .win file to use back in levit8r.
When you now put the new backgrounds into levit8r, the program will go away and be very busy for a long time. This is because in order to do the E2 background properly for double-gates, it needs an E2-gated 2D-projection of the cube, which it reads from the cube directly. This may take a long time, so be patient.
In Unix (csh or tcsh), type
setenv RADWARE_CURSOR_BELL n
and then restart the program.
This will kill the beeping for the cursor in all radware programs.
If you want to make this the default action,
put the setenv RADWARE_CURSOR_BELL n command into your .cshrc
or .login file, or edit your .radwarerc file and change the line
setenv RADWARE_CURSOR_BELL y
to
setenv RADWARE_CURSOR_BELL n.
Of course, to make this change take effect immediately, you then have to
source .radwarerc
In VMS, the equivalent command is
$ DEFINE RADWARE_CURSOR_BELL n,
or you can change the file radware:commands.com,
where the line
$ DEFINE/NOLOG RADWARE_CURSOR_BELL y
should be changed to
$ DEFINE/NOLOG RADWARE_CURSOR_BELL n,
and then type @radware:commands
Use the RG [read new .gls level scheme file] or AD [add (combine) a second .gls level scheme file] commands, or their equivalent menu options in xmesc / xmlev / xm4dg.
This site (http://radware.phy.ornl.gov) provides a repository of gls-format level schemes, from several different sources, that you can use as initial guesses at what you might expect to see in your data. There are schemes converted from the Evaluated Nuclear Structure Data File (ENSDF), and schemes deposited by anonymous ftp by generous physicists (like YOU) resulting from their own analysis using escl8r etc.
When you keep adding levels and gammas into the level scheme window, the level scheme will eventually go off the top of the level scheme graphics window, and you will not be able to see the top of the level scheme. When this happens, you need to use the RD1 command, or select "redraw entire level scheme" from the display menu. It will recalculate the level scheme limits and redraw.
Escl8r and levit8r can write gf3-style .spe files. These spectra are not corrected for the efficiency. You can correct for efficiency in gf3 with the DE command. The spectra as displayed in escl8r / levit8r are not corrected for efficiency, either; rather, the calculated spectrum has the efficiency built into it.
See the NIM paper for accurate details.
The intensities are in arbitrary units. The absolute values depends on the normalization coefficient which you can inspect and/or change with the RN (renormalize gates:scheme) command. This is normalization coefficient is automatically chosen by the program when you create the .esc or .lev file, in order to make the strongest coincidence have an intensity value of about 100 units.
Escl8r always fits the 2D matrix, and not the gate. In other words, the fits are to the coincidence data in 2 dimensions. The only exception to this is the FW command to fit the width parameters, which fits to the gate. You should be careful using this command, and not always assume that it is giving the best values for the parameters. In particular, choose a gate (or sum of gates) with lots of strong well-fitted lines, especially at high energies.
You can fit as few or as many gammas at a time as you like (up to a max. of 500 parameters). If you do not have all the transitions in the level scheme, or you have ones that are not really there, or you have them in the wrong order, then of course the results of the fit will not be as good. Also, since the fit is in 2D, the background subtraction needs to be reasonably good. A bad efficiency calibration also can have a big effect. The energies of the transitions also affect their fitted intensities too, of course, so it's a good idea to fit both energies and intensities together once you are reasonably happy that you are close to the correct values.
You can check the fitted values by taking gates and seeing that the calculated spectra reproduce the observed spectra.
When I put in a new band, I usually fit the intensities of all the gammas in the band, then their energies, to get things roughly right, and then either both intensities and energies or just intensities again. Just two iterations is usually enough to get things roughly right. Then every once in a while (once a day or so) I fit all the intensities and energies of the whole level scheme (or large chunks of it). If you change the calibrations, width parameters or background spectra, the level scheme can change quite a bit, and it is usually worth refitting.
Negative intensities can arise from a number of things. Perhaps the most common is another gamma of the same or similar energy which has too large an intensity, causing the program to compensate by making the other gamma negative. You can sometimes get around this by fitting both gammas and their neighbors at the same time. If that doesn't work, fix one of them to a value that looks right and fit the other one.
Other things that can give negative intensities are bad efficiency calibrations and other branches out of the same initial level which are doublets. If the other half of the doublet is not yet in the level scheme, the program can sometimes force a strong coincidence by making a negative branching ratio. Anyway, a negative intensity can mean either that the gamma doesn't really go where you have put it, or that there are other gammas that you have left out that you need to find and put in place. You can often get a clue as to why the intensity is going negative from a close look at a gate on the offending transition or ones feeding it.
You will notice that the program does not usually fit the intensity of the lowest gamma in a band. When this happens, it is because the intensity of that transition should be taken from intensity balances. If there are two or more transitions from the bottom of a band, sometimes it will fit all but one of them to get the branching ratio(s) right, but then the absolute magnitudes should again be taken from the intensity balance.
The intensities of gamma lines obtained from escl8r can sometimes be incorrect because of an anisotropic distribution of the detectors used in data collection. For example, in Early Implementation GAMMASPHERE the detectors were heavily concentrated at forward and backward angles, with very few close to 90 degrees. This improved the Doppler-broadened resolution, but greatly changed the relative efficiencies for detection of E2 -vs- dipole transitions. Escl8r et al. assume an isotropic detector distribution.
The maximum number of fitted parameters in escl8r and levit8r used to be fixed at 500. There is now a parameter MAXFIT in the files esclev.h and gls.h that determines the maximum allowed number of fitted parameters. Be a little cautious in increasing this beyond the default of 500.
The maximum of 500 parameters is not really a major limitation. You can fit large chunks of the scheme by specifying the bands that you want to fit. If these chunks are reasonably well decoupled, then you end up with just as good a fit (maybe better) as if you had fitted everything at once.
It doesn't do intensity balances. You can check the intensity balances by running gls_conv to generate a .dat file and looking at the last section, containing a list of intensity balances and energy sums that fall outside of two- or three-sigma tolerances.
The program simply calculates branching ratios for each level. All the flux coming in is assumed to be divided according to those branching ratios. This can be a real problem for isomers; if you encounter that, let me know, and I will provide you with a work-around.
The intensity of a coincidence depends only on:
1. the intensity of the higher transition,
2. the branching ratio from the final state of the higher transition
through to the lower transition, and
3. the conversion coefficient of the lower transition.
This is why the intensity of the lowest transition in a band never gets
fitted, and why its coincidences with the higher transitions do not depend on
its intensity. The branching ratio from its initial state is always unity.
If there are two or more transitions from the bottom of a band, sometimes it will fit all but one of them to get the branching ratio(s) right, but then the absolute magnitudes should again be taken from the intensity balance.
For now, I guess you have to write your own program, or convert your own native format to one of the RadWare ones. The RadWare formats are very simple, just direct-access, unformatted integers, one record per row of 4096 channels. These integers can be either 2 Bytes per channel (for the .mat format) or 4 Bytes per channel (for the .spn / .m4b format).
Use the program incub8r3.
Use the program 4play.
Symmat is a simple program to symmetrize a 4k x 4k matrix. In other words, if you have a matrix that has Counts(i,j) not equal to Counts(j,i), running symmat on it will replace both Counts(i,j) and Counts(j,i) with Counts(i,j)+Counts(j,i).
To run symmat, just type symmat.
Here is some html documentation on how to use the program slice to apply gates to a 4k x 4k matrix.
Assuming you have a level scheme in the gls format (e.g. from escl8r or levit8r) then you can easily make a postscript figure directly in gls, xmgls, escl8r or xmesc etc. Use the HC command, or the "Create Postscript Hardcopy File" option from the Files menu. Note that if you select a portion of the scheme to display in an expanded mode (with the EX command) then this will be reflected in the postscript hardcopy too. Alternatively, you can use gls_conv to generate a postscript file.
If you have a level scheme in the gls format (e.g. from escl8r or levit8r) then you can easily make figures of alignments, routhians, moments of inertia etc, as a function of either rotational frequency or spin, by using the program dixie_gls. Run dixie_gls, read in and display your level scheme, and then check out the available commands by typing HE (help). When you are able to generate a figure that you want to keep, use the WP (write displayed data to plot-type file) command. This will generate a .pdc file.
You can find out about .pdc files by looking at the documentation on how to use plot. You can edit the .pdc file with your favorite text editor, then run plot and edit the result with pedit. Finally, when you are ready to make a postscript file, you can do that by running plot2ps.
RadWare has a program to make and edit data and/or spectrum plots; you can look here for documentation on how to use plot.
Many and various. The best (and most accurate) way to find the format is to look at the source code for routines that read / write the files that you are interested in.
The RadWare matrix formats are very simple, just direct-access, unformatted integers, one record per row of 4096 channels. These integers can be either 2 Bytes per channel (for the .mat format) or 4 Bytes per channel (for the .spn / .m4b format).
A standard matrix (.mat) file is 4096*4096*2 bytes, with one unformatted direct-access record of 8192 bytes per row. Subroutine rmat in src/libsutil/util.c reads such a file, but it's very simple to write. In FORTRAN, you would do something like this:
INTEGER*2 MATRIX(4096,4096)
OPEN (1, FILE=FILENAME, ACCESS='DIRECT', FORM='UNFORMATTED',
+ RECL=8192 (bytes, or 2048 long-words for VMS) )
DO IY = 1, 4096
WRITE(1, REC=IY) MATRIX(IX,IY), IX = 1, 4096)
ENDDO
CLOSE(1)
If you need a 4-byte matrix file, you could use my .spn format, which is integer*4, and can go to 4096 chs in the y-axis. You would just change integer*2 to integer*4 and double the record length. These .spn files are not as common but can be read by gf3 and escl8r (though not by slice).
This is a little more complex, since it is written as a sequential-access, unformatted FORTRAN file. This means that the hidden fields in the actual physical records on disk are different between VMS and Unix. These hidden fields tell the FORTRAN run-time-library routines how long the records are.
You can read and write .spe files in FORTRAN by calling the subroutines read_spe_file.f and wspec.f in util.a / util.olb.
The .spe file format is 2 records. The first of these contains information on the spectrum name and length, the second has the data in real*4 format. C code to do this is in the routine
wspec(char *filnam, float *spec, int idim)at the end of the file
src/libs/util/rwspec.c.The FORTRAN code could be:
SUBROUTINE WSPEC(FILNAM,SPEC,IDIM)
C subroutine to write spectra in gf3 format....
C FILNAM = name of file to be created and written....
C SPEC = REAL spectrum of dimension IDIM....
CHARACTER*(*) FILNAM
REAL SPEC(IDIM)
INTEGER IDIM
CHARACTER*8 NAMESP
C this sets the default extension on the file name....
CALL SETEXT(FILNAM,'.spe',J)
NAMESP = FILNAM(1:8)
IF (J.LE.8) NAMESP(J:8) = ' '
C this opens a new file to receive the data....
CALL OPEN_NEW_UNF(1,FILNAM,0,0)
WRITE(1) NAMESP,IDIM,1,1,1
WRITE(1) SPEC
CLOSE(1)
RETURN
END
You could link your program with util.a to get the subroutines read_spe_file, wspec, setext and open_new_unf, if you like.
Documentation on the format of the ASCII gls Level Scheme Files can be found here.
email: radforddc@ornl.gov