The main paper presenting the current version of the Gifa program has recently been accepted at J.Bio.NMR. When published, the reference will be :
You may also use the following references :
Guess what, your licence is not valid! If you already registered, then check again the installation procedure. If you are not registered, just contact me ( mad@cbs.univ-montp1.fr ) I will send you the licence agreement. Relax, the licence of Gifa is free for academic labs.
then Gifa runs correctly, without the graphical environment.
The installation is not complete. To work correctly, Gifa needs a set of directories and file which should in /usr/local/gifa . Usually this is done by using the installation procedure distributed with the program, which sets a link (ln -s) between the location where Gifa actually is and this standard address.
then Gifa stops on error during the start-up procedure.
You did not connect correctly to an X-server display. Gifa is perfectly able to run without X-window, but obviously, all the graphic commands won't work. In the case described here, the standard startup.g macro stops when trying to set-up the graphic environment. To set-up the X-window environment, do (in csh) :
setenv DISPLAY the_name_of_your_X-terminal:0.0
if you use a remote work-station for displaying, check that you enabled the remote display by doing :
xhost +.
To work in graphic-less mode, create your own startup.g (in HOME/macro or in local directory (.)) which will take precedence over the general startup.g.
This is a typical message when the available memory on the machine is not sufficient to handle a big program. Try -to use a smaller version of Gifa (There should 3 sizes on the distribution kit), -to extend the swap area of your machine.
This message means that Gifa could not create the gifa.log journaling file in your $HOME directory. When running, Gifa copy all the commands to this file. This file permits to redo a processing, or to find the result of a previous one. When exiting, you are asked for keeping or removing that file.
Gifa cannot create the journaling file in several cases :
Each spectrum in Gifa is displayed relative to its larger point, the parameter SCALE describes how this larger point will appear on screen, SCALE = 1 means that the larger point will be full screen. To make absolute display (and plots) you need to force the program to scale to the same larger point for display. The value of the larger point is called ABSMAX. when the data are changed, or when set to 0, it is recomputed as the largest point in the data-set. But you can change it by setting its value to any non-null positive value. Thus using the same ABSMAX for 2 different data-sets will result in absolute display.
Those 2 macros are based on the SHOWC command which works in ppm coordinates. Thus to be able to superpose spectra, you should have correctly calibrated all your spectra. Note also that an earlier bug in ux2cach was making Gifa files with all spectral parameters wrong (before version 4.05b).
There are several answers to this question, which depend on the kind of spectrometer you use and the nature of the link.
No problem there, there is a READV command in Gifa to access directly the Varian files
Use the ux2cach utility (in gifa/util/ux2cache) which convert UXNMR data files (not the pdata) into native Gifa files.
This is always a problem, because of the difficulty to get out of the Aspect computer. An additional problem is that the Aspect computer stores data on 24bits, instead of the 32 bits modern computers use. Some utilities are given here, but expect to have some tuning to do because of the numerous options available.
Try to use the nmrlink program, the source is in util/moul4
Try to use the program in util/bruknet
Try to use the transdata program, the source is in util/moul3
There are several possibilities :
* The simplest way is to write Ascii files, and load them with the READT
command. Use the WRITET command to get an example of the correct format (most
parameters are optional).
* If you use MATLAB, there is a READM command for you.
* You can look into the gifa/util/ux2cache where you will find the library
for accessing the native Gifa file format, and the source of the utility which
converts UXNMR files into native files (Again, most parameters are optional).
There is also the older gifa/util/ux2gifa utility which converts into the FTNMR
compatible format (the READH command) which is somewhat simpler to implement,
but much less powerful.
with the bcorr 3 commands for instance.
These command use alternate buffers which are not available because of the size of the current data-set. You can : i) choose a bigger version of the program (there should be three in the distribution) memory allocation is static in Gifa. ii) choose another algorithm. For instance remember that
chsize (%*2) ft phase x y real
and
ft phase x y ift ftbis
give the same data, however the second method requires twice as small buffers.
Gifa handles the data in several buffers that overlap (see "UNDERSTANDING MEMORY SET-UP"). when the data gets too big some of the less needed buffers are used for handling the data. Thus certain operations becomes not available. See precedent Question.
When a buffer is going to be overflowed by the current command, and when the command is issued from the main level (from the prompt or from a menu/form) then you (the user) are asked if it is ok to overflow. The command is aborted if you answer no. This question is not asked when the command which creates this overflow is issued from within a macro. This permits to write macro that will always work. If you want to protect from within a macro, you should make the test in the macro.
There several data format possible for NMR : in 1D, data can be real, complex, or acquired in the sequential "Redfield trick" mode. in 2D and 3D, data can be in tppi, in States-Haberkorn, in gradient N+P interleaved, in phase-modulation modes, or even in a mixture of these. Complex parts can be interleaved or separated, there are different conventions on the sign of the imaghinary parts; etc... etc...
There are many possibilities in Gifa, try to play with FT RFT FTBIS; REVF INVF; SWA USWA. Once you have found a set-up, you might want to propagate it in the macros ft_* found in the distribution.
The DMX machines, equipped with a digital filter, do not store the FID in its genuine acquisition format, but after a first processing which is done on-the-fly during the acquisition. This processing appears to be "non-causal", i.e. there non-zero data-points before the actual initial time t=0 of the acquisition. These points are stored by Bruker at the beginning of the file and are usually of the order of ~140 (but it is not constant and seems to be related to the acquisition parameter DECIM). There are actually several ways of processing such data-sets.
- throw those points awy with a lshift (leads to not-so-nice baselines)
- append this non-causal part at the end of the FID (a bit complicated to do)
- process as usal and then apply a ~25000 degrees first order phase correction. Formally equivalent to the former, but much simpler to do.
There is a complete discution of this problem at : gopher://gopher.nmrfam.wisc.edu/00/digfilt2 due to W. M. Westler and F. Abildgaard.
the exact definition of the SIN command is :
with the parameter X [0.0 0.5] and N points to process
s = 2*(1-x)
w = PI/((N-1)*s)
phi = PI*(s-1)/s
after the
SIN x command, the ith point of the current buffer is multiplied by :
SIN(i) = sin( (i-1)*w + phi ) with i : 1..N
See documentation above.
Gifa builds plots by adding to a file the different graphics to be plotted. The command PAGE has the effect of closing the plot_file (equivalent to FORGET) and to send the plot_file to the plotter with the shell script 'gifaplot'. This shell script is copied into /usr/local/bin at installation (check that it is in your PATH), and should be adapted to your particular set-up. A very common reason why plots do not work is either that the shell script has not been adapted. This shell script is called with 2 parameters : the name of the plot_file; the type of plotter (HPGL or postscript). As sent, it is configured to use lpr, and to remove the file if it is called Gifa_Temp.Plot. Another reason is when for some reason the internal memory of plot-files, and the state on disk are different (for instance if a write fails, or if CD is used), in this case, remove the corrupted file, and use FORGET to clear the internal counter part.
Gifa internal variables are sometimes a bit confusing. They look like user variable when you fetch them, however you cannot write into them. In the case of the question above, $si1_2d has to be changed with CHSIZE. Actually, the command :
set si1_2d = 2048
creates a user variable, with the (unfortunate) name si1_2d, which will 'hide' the nternal variable. Next time, when you will evaluate $si1_2d, you will get the value of your user variable (in this case 2048), not the size of the current 2D, which is no more available.
This happens when the memory is very loaded on the machine, and that the fork() call fails. Try to : remove useless processes; use a smaller version of Gifa; expand the swap area (or the physical memory) of your machine.
Same as above (the exit n command internally uses the SH mechanism)
The fundamental file format (READ command) is a bit complicated to describe, but the library for accessing it is fully available in util/ux2cache/cache_mad.c in the distribution. This is a library, which permit all accesses (1D, 2D, 3D), the format is also described. This code has been made public domain.
There are also data format which are easier to handle for a small program :
ft-nmr kind or format (READH); ascii format (READT); matlab format (READM).