Difference: CemHelicalPrograms (1 vs. 20)

Migration to Unwin software

• hfts has replaced hft for calculating the FFT from tubular crystals. This program requires long axis to be parallel to X. axchgmrc can be used for this purpose. Both hfts and axchgmrc are derived from Unwin fortran
  • hfts was modified to calculate the projection of the tube and produce a file (prj.dat) containing the projection data. This data can be plotted with gnuplot (see helix/script/prjplt.gnuplot)
  • Toyoshima programs renamed to : hftsk, axchgmrck
• hftout now taken from Unwin's program. Minor changes to Unwin's program were made to allow it to compile and to modify input format slightly
• acf can be replaced with Unwin's correl.com. This script was modified somewhat. Viewing of the output cross-correlation is still in progress
• nltable (Unwin) can be used instead of nltabl. However, nltable only outputs a id.tbl file, whereas nltabl outputs both id.tbl and id.id file. EMIP was modified to create an id.id file based on the input parameters.
• hlxmk was replaced with hlxmk.py
  • hlxmk.py is compatible with both nltable (unwin) and nltabl (koji), which differ by one line
  • hlxmk.py is more intelligent about finding the start of the ll data
• lnl.com is not necessary when running EMIP. This program (lnl) reads id.goodll file, which contains selected layer lines, and makes an output file consisting of only the selected layer lines as a template for hlxsall.pl
• unwin hlxfl replaces toyoshima hlxflk
• unwin nfavg replaces toyoshima nfavgk
• hlx2fd (Unwin) now can replace hlx2fld (toyoshima). The fortran was modified to produce resolution-dependent phase statistics
  • python wrapper hlx2fd.py was written to run hlx2fd iteratively to find the nearest minimum. Otherwise, hlx2fd only searches within specified range. Takes two arguments: controlfile 2fd-constrained-outputfile(optional)
• ltlg(.com) (Unwin) now can replace hlxfb (toyoshima). I found that the weight for the equator should be set to 1.0. The small scale factor is probably required because of the ASCII file output for little g's. If the values are too large, they overflow the format specifier. The value for IRMAX is used to calculate the number of terms to use for little g calculation. It should correspond to the layer line extent. Too big is probably ok.
• hlxsec.com (Unwin) can replace hx (toyoshima). This reads little g file and produces MRC map file. Not much too this. ystep is in degrees and actually corresponds to the range of the map in the azimuthal direction (in degrees)
• imgplot.com uses CCP4 programs (npo and pltdev) to create a contour map.

EMIP implementation

• implemented Unwin style box file
• implemented hfts for calculating fft
  • hfts-prj written to output prj data
• implemented plotting of projection data using gnuplot
• implemented hftout from unwin
• implemented SRCH button (nltable, lnl)
  • values of omega and dx seem different - investigate this point
  • only slightly different - doesn't seem significant
• hlxstats
  • replaced hfts
  • modified hlxmk to be compatible with tbl file produced by both nltable (unwin) and nltabl (koji)
    • wrote hlxmk.py, which looks for first line of ll data rather than simply counting number of lines until this data starts
    • updated setup_hlxdat.pl and mkhlxs
    • made link hlxmk.py -> hlxmk
  • replaced hlx2fld (toyo) with hlx2fd.py (unwin)
    • in one case found false minimum of 46deg - had to change origin of initial search
• hlxfl
  • replaced hfts
  • doesn't work yet
• unbendprep
  • replaced box2box.pl with code to add extra lines to box file as needed for unbending
  • replaced setup_hlxdat with necessary code to create full.hlxdat and ctf0.hlxdat (templates for hlxfl during unbending)
  • this required fixing hlxmk amongst other things - carefully checked result
• unbend
  • uses same script as before (hlx_unbend.com) - no modifications required once setup complete
• 2nd page map making needs to be implemented with unwin programs (hlxfb, hxsec, imgplt)
  • rewrote code for OnTwofold^? - needs testing

Ximdisp

• 24-bit support as long as DirectColor^? are supported. TrueColor^? is not supported. Looks like 24-bit vncserver only uses TrueColor^?, so 8-bit is necessary there.
• added to the lattice refinement so that spot peak is automatically found within 15x15 pixel region. Also, the 1st 3 spots chosen are used to guess the h,k indices for all susequent spots

Consolidation of programs

A new directory called "helix" was created with a consolidation of source files and scripts from rice and unwin. This helix directory was the old rice directory in which all unique unwin programs (both source and binary) have been added. The original rice and unwin directories are preserved in an "archive" directory. All future development will be done in this helix directory. koji directory remains distinct.

FFTRANS

Major incompatibility between old MRC header format and MRC2000 image format creates problem with helical processing. If new fftrans is used, then the phases are completely wacky (wrong phase origin), as seen from output of hftout
This is because the image2000 software keeps a machine stamp in a location that was previously reserved for the origin
Specifically, header location 54 and 55 were previously designated for the xorigin and yorigin, respectively. These locations have now been reassigned.

This problem has now fixed at NYSBC and at NYU. This required recompiling several programs to take into account the new position of the origin in the MRC header.

• hlxfl.f (unwin): simply changed the IRTORG call to include 3 parameters (XOR,YOR,ZOR) and recompiled with image2000 libraries
• hlxs_threshold.f (rice): same as hlxfl
• openmrcf.c (koji): changed the location of the origin to start at byte 49 (c arrays start at zero) and added this modified routine to mrc.a
• hlxs (koji): simply recompiled using new openmrcf.o
• hftout (koji) same as hlxs
• hlxflk (koji): same as hlxs (THIS IS CURRENTLY UNTESTED)

Previous to these repairs and recompilations (e.g. implementation at NYU), the following fix had been applied:
hft, must use older version of fftrans - pre image2000 - we called this fftrans.old

Note that the changes above have now resolved this situation and the newer (image2000) fftrans should be used
Following are from the file "image.doc" from the older and newer release of MRC software:

older image.doc

25 EXTRA Extra, user defined storage space. 29 words max.
. "
. "
. " (all set to zero by default)
. "
53 "
54 XORIGIN X origin
55 YORIGIN Y origin
56 NLABL Number of labels being used

newer image.doc (released with image2000)

* 25-49 EXTRA extra space used for anything - 0 by default *
* 50-52 ORIGIN origin in X,Y,Z used for transforms *
* 53 MAP character string 'MAP ' to identify file type *
* 54 MACHST machine stamp *
* 55 RMS rms deviation of map from mean density *
* 56 NLABL number of labels being used *

Compiling libraries

General strategy for creating these libraries

• • cd compile go into temp directory
  • unzip ../XX.zip extract source files from zip file
  • gcc -c -O -I../ *.c ! compile source files
  • ar rvf XX.a *.o ! create object library
  • mv XX.a .. ! put library into main directory
  • rm *.c *.o clean up
• So far: mrc.a, ccf.a, hlxq.a, ctfft.a, img.a, ctsys.a, graph.a, graph-prjplt
  • img.a contains object files from img.zip, boxmask.zip and vector.zip
  • hlxq.a contains object files from hlxq.zip and hlx.zip

• todo: pltulib.a, pltctfx.a, nrc.a, graphn.a ctf.a, cmath.a

Size of long integers (major bug)

The long integers were used extensively in MRC file handling routines stored in mrc.zip (and mrc.a). e.g., openmrcf.c. Also, structure elements defined in mrc.h and imgn.h. Under the old system, both long integers and integers were 4 bytes long (check this using sizeof(int) and sizeof(long) c functions). Under new system, long integers were 8 bytes and integers were 4 bytes:

• • at NYSBC under Centos 5, 64 bit machine

• • at NYU under Fedora Core 4, 32-bit machine

Compilation problems under Centos5

undefined builtin functions

The compiler with glibc-2.5-24 (Centos 5) are picker than the compiler with glibc-2.3.6-3 (Fedora Core 4).
To get rid of warnings about redefinition of builtin functions, I had to explicitly:

• • #include <string.h>
  • #include <stdlib.h>
  • #include <stdio.h>

no newline at end of file

• • added new line at the end of many files to suppress this warning message

order of functions in files

• • had to move functions from the bottom of the file up to the top of the file in several cases. This was apparently because the main function was calling a secondary function, but the declarations weren't being handled correctly.

Problematic source modules

• sqsumtbl from ccf.zip
  • compile sqsumtbl with -g flag, otherwise imgccf crashes
  • not tested extensively

• now() function declaration
  • segmentation fault in imgccf, mrccut, pds2mrc was due to now() function. This was fixed with declaration
    • char *now();
  • this will likely show up in other programs
  • actually, this may just require recompilation of code - also showed up in cgraph.c

• a couple of unresolved, but unimportant, issues
  • rfshffl.c from ctfft.zip gives two errors, which are acknowledged in the header of the source file
  • strstr.c and toupper.c left out of ctsys.a - these functions should be builtin <string.h>
    • strstr.c gave errors, toupper is just redundant, modf also seems redundant and gave warning
  • putdotsq.c in img.zip gives warning, which is stupid and can be ignored
    • unsigned char mode
    • if (mode > 255) ! well, mode cannot be greater than 255 if it is an unsigned char!

• graph and graph-prjplt
  • had to reorder several of the source modules with static declarations to put them at the front of the file (cgraph, pshandler)
  • put new line at the end of some files
  • randtbli.c - was modified to declare a dummy integer rather than use a scalar
  • a few routines did not compile

further notes

• wjr 16 March 2009 -- update of CentOS 5 to latest gcc (2.5-24.el5_2.2) required recompile of imgccf. Used same libraries and headers as before for compilation.
  • imgccf will not run on CentOS4

• Set ALLOWTOPICVIEW =

-- DavidStokes - 27 Nov 2008

Migration to Unwin software

• hfts has replaced hft for calculating the FFT from tubular crystals. This program requires long axis to be parallel to X. axchgmrc can be used for this purpose. Both hfts and axchgmrc are derived from Unwin fortran
  • hfts was modified to calculate the projection of the tube and produce a file (prj.dat) containing the projection data. This data can be plotted with gnuplot (see helix/script/prjplt.gnuplot)
  • Toyoshima programs renamed to : hftsk, axchgmrck
• hftout now taken from Unwin's program. Minor changes to Unwin's program were made to allow it to compile and to modify input format slightly
• acf can be replaced with Unwin's correl.com. This script was modified somewhat. Viewing of the output cross-correlation is still in progress
• nltable (Unwin) can be used instead of nltabl. However, nltable only outputs a id.tbl file, whereas nltabl outputs both id.tbl and id.id file. EMIP was modified to create an id.id file based on the input parameters.

• lnl.com is not necessary when running EMIP. This program (lnl) reads id.goodll file, which contains selected layer lines, and makes an output file consisting of only the selected layer lines as a template for hlxsall.pl
• unwin hlxfl replaces toyoshima hlxflk
• unwin nfavg replaces toyoshima nfavgk
• hlx2fd (Unwin) now can replace hlx2fld (toyoshima). The fortran was modified to produce resolution-dependent phase statistics
  • python wrapper hlx2fd.py was written to run hlx2fd iteratively to find the nearest minimum. Otherwise, hlx2fd only searches within specified range. Takes two arguments: controlfile 2fd-constrained-outputfile(optional)
• ltlg(.com) (Unwin) now can replace hlxfb (toyoshima). I found that the weight for the equator should be set to 1.0. The small scale factor is probably required because of the ASCII file output for little g's. If the values are too large, they overflow the format specifier. The value for IRMAX is used to calculate the number of terms to use for little g calculation. It should correspond to the layer line extent. Too big is probably ok.
• hlxsec.com (Unwin) can replace hx (toyoshima). This reads little g file and produces MRC map file. Not much too this. ystep is in degrees and actually corresponds to the range of the map in the azimuthal direction (in degrees)
• imgplot.com uses CCP4 programs (npo and pltdev) to create a contour map.

EMIP implementation

• implemented Unwin style box file
• implemented hfts for calculating fft

• implemented hftout from unwin
• implemented SRCH button (nltable, lnl)
  • values of omega and dx seem different - investigate this point

• hlxstats
  • replaced hfts

• • replaced hlx2fld (toyo) with hlx2fd.py (unwin)
    • in one case found false minimum of 46deg - had to change origin of initial search
• hlxfl
  • replaced hfts
  • doesn't work yet

• 2nd page map making needs to be implemented with unwin programs (hlxfb, hxsec, imgplt)
  • rewrote code for OnTwofold^? - needs testing

Ximdisp

• 24-bit support as long as DirectColor^? are supported. TrueColor^? is not supported. Looks like 24-bit vncserver only uses TrueColor^?, so 8-bit is necessary there.
• added to the lattice refinement so that spot peak is automatically found within 15x15 pixel region. Also, the 1st 3 spots chosen are used to guess the h,k indices for all susequent spots

Consolidation of programs

A new directory called "helix" was created with a consolidation of source files and scripts from rice and unwin. This helix directory was the old rice directory in which all unique unwin programs (both source and binary) have been added. The original rice and unwin directories are preserved in an "archive" directory. All future development will be done in this helix directory. koji directory remains distinct.

FFTRANS

Major incompatibility between old MRC header format and MRC2000 image format creates problem with helical processing. If new fftrans is used, then the phases are completely wacky (wrong phase origin), as seen from output of hftout
This is because the image2000 software keeps a machine stamp in a location that was previously reserved for the origin
Specifically, header location 54 and 55 were previously designated for the xorigin and yorigin, respectively. These locations have now been reassigned.

This problem has now fixed at NYSBC and at NYU. This required recompiling several programs to take into account the new position of the origin in the MRC header.

• hlxfl.f (unwin): simply changed the IRTORG call to include 3 parameters (XOR,YOR,ZOR) and recompiled with image2000 libraries
• hlxs_threshold.f (rice): same as hlxfl
• openmrcf.c (koji): changed the location of the origin to start at byte 49 (c arrays start at zero) and added this modified routine to mrc.a
• hlxs (koji): simply recompiled using new openmrcf.o
• hftout (koji) same as hlxs
• hlxflk (koji): same as hlxs (THIS IS CURRENTLY UNTESTED)

Previous to these repairs and recompilations (e.g. implementation at NYU), the following fix had been applied:
hft, must use older version of fftrans - pre image2000 - we called this fftrans.old

Note that the changes above have now resolved this situation and the newer (image2000) fftrans should be used
Following are from the file "image.doc" from the older and newer release of MRC software:

older image.doc

25 EXTRA Extra, user defined storage space. 29 words max.
. "
. "
. " (all set to zero by default)
. "
53 "
54 XORIGIN X origin
55 YORIGIN Y origin
56 NLABL Number of labels being used

newer image.doc (released with image2000)

* 25-49 EXTRA extra space used for anything - 0 by default *
* 50-52 ORIGIN origin in X,Y,Z used for transforms *
* 53 MAP character string 'MAP ' to identify file type *
* 54 MACHST machine stamp *
* 55 RMS rms deviation of map from mean density *
* 56 NLABL number of labels being used *

Compiling libraries

General strategy for creating these libraries

• • cd compile go into temp directory
  • unzip ../XX.zip extract source files from zip file
  • gcc -c -O -I../ *.c ! compile source files
  • ar rvf XX.a *.o ! create object library
  • mv XX.a .. ! put library into main directory
  • rm *.c *.o clean up
• So far: mrc.a, ccf.a, hlxq.a, ctfft.a, img.a, ctsys.a, graph.a, graph-prjplt
  • img.a contains object files from img.zip, boxmask.zip and vector.zip
  • hlxq.a contains object files from hlxq.zip and hlx.zip

• todo: pltulib.a, pltctfx.a, nrc.a, graphn.a ctf.a, cmath.a

Size of long integers (major bug)

The long integers were used extensively in MRC file handling routines stored in mrc.zip (and mrc.a). e.g., openmrcf.c. Also, structure elements defined in mrc.h and imgn.h. Under the old system, both long integers and integers were 4 bytes long (check this using sizeof(int) and sizeof(long) c functions). Under new system, long integers were 8 bytes and integers were 4 bytes:

• • at NYSBC under Centos 5, 64 bit machine

• • at NYU under Fedora Core 4, 32-bit machine

Compilation problems under Centos5

undefined builtin functions

The compiler with glibc-2.5-24 (Centos 5) are picker than the compiler with glibc-2.3.6-3 (Fedora Core 4).
To get rid of warnings about redefinition of builtin functions, I had to explicitly:

• • #include <string.h>
  • #include <stdlib.h>
  • #include <stdio.h>

no newline at end of file

• • added new line at the end of many files to suppress this warning message

order of functions in files

• • had to move functions from the bottom of the file up to the top of the file in several cases. This was apparently because the main function was calling a secondary function, but the declarations weren't being handled correctly.

Problematic source modules

• sqsumtbl from ccf.zip
  • compile sqsumtbl with -g flag, otherwise imgccf crashes
  • not tested extensively

• now() function declaration
  • segmentation fault in imgccf, mrccut, pds2mrc was due to now() function. This was fixed with declaration
    • char *now();
  • this will likely show up in other programs
  • actually, this may just require recompilation of code - also showed up in cgraph.c

• a couple of unresolved, but unimportant, issues
  • rfshffl.c from ctfft.zip gives two errors, which are acknowledged in the header of the source file
  • strstr.c and toupper.c left out of ctsys.a - these functions should be builtin <string.h>
    • strstr.c gave errors, toupper is just redundant, modf also seems redundant and gave warning
  • putdotsq.c in img.zip gives warning, which is stupid and can be ignored
    • unsigned char mode
    • if (mode > 255) ! well, mode cannot be greater than 255 if it is an unsigned char!

• graph and graph-prjplt
  • had to reorder several of the source modules with static declarations to put them at the front of the file (cgraph, pshandler)
  • put new line at the end of some files
  • randtbli.c - was modified to declare a dummy integer rather than use a scalar
  • a few routines did not compile

further notes

• wjr 16 March 2009 -- update of CentOS 5 to latest gcc (2.5-24.el5_2.2) required recompile of imgccf. Used same libraries and headers as before for compilation.
  • imgccf will not run on CentOS4

• Set ALLOWTOPICVIEW =

-- DavidStokes - 27 Nov 2008

Migration to Unwin software

• hfts has replaced hft for calculating the FFT from tubular crystals. This program requires long axis to be parallel to X. axchgmrc can be used for this purpose. Both hfts and axchgmrc are derived from Unwin fortran
  • hfts was modified to calculate the projection of the tube and produce a file (prj.dat) containing the projection data. This data can be plotted with gnuplot (see helix/script/prjplt.gnuplot)
  • Toyoshima programs renamed to : hftsk, axchgmrck
• hftout now taken from Unwin's program. Minor changes to Unwin's program were made to allow it to compile and to modify input format slightly
• acf can be replaced with Unwin's correl.com. This script was modified somewhat. Viewing of the output cross-correlation is still in progress
• nltable (Unwin) can be used instead of nltabl. However, nltable only outputs a id.tbl file, whereas nltabl outputs both id.tbl and id.id file. EMIP was modified to create an id.id file based on the input parameters.
• hlxmk modified very slightly to be compatible with output from nltable
• lnl.com is not necessary when running EMIP. This program (lnl) reads id.goodll file, which contains selected layer lines, and makes an output file consisting of only the selected layer lines as a template for hlxsall.pl
• unwin hlxfl replaces toyoshima hlxflk
• unwin nfavg replaces toyoshima nfavgk
• hlx2fd (Unwin) now can replace hlx2fld (toyoshima). The fortran was modified to produce resolution-dependent phase statistics
  • python wrapper hlx2fd.py was written to run hlx2fd iteratively to find the nearest minimum. Otherwise, hlx2fd only searches within specified range. Takes two arguments: controlfile 2fd-constrained-outputfile(optional)
• ltlg(.com) (Unwin) now can replace hlxfb (toyoshima). I found that the weight for the equator should be set to 1.0. The small scale factor is probably required because of the ASCII file output for little g's. If the values are too large, they overflow the format specifier. The value for IRMAX is used to calculate the number of terms to use for little g calculation. It should correspond to the layer line extent. Too big is probably ok.
• hlxsec.com (Unwin) can replace hx (toyoshima). This reads little g file and produces MRC map file. Not much too this. ystep is in degrees and actually corresponds to the range of the map in the azimuthal direction (in degrees)
• imgplot.com uses CCP4 programs (npo and pltdev) to create a contour map.

EMIP implementation

• implemented Unwin style box file
• implemented hfts for calculating fft
• implemented plotting of projection data
• implemented hftout from unwin
• implemented SRCH button (nltable, lnl)
  • values of omega and dx seem different - investigate this point
• hlxstats
  • replaced hfts

• hlxfl
  • replaced hfts

• 2nd page map making needs to be implemented with unwin programs (hlxfb, hxsec, imgplt)

Ximdisp

• 24-bit support as long as DirectColor^? are supported. TrueColor^? is not supported. Looks like 24-bit vncserver only uses TrueColor^?, so 8-bit is necessary there.
• added to the lattice refinement so that spot peak is automatically found within 15x15 pixel region. Also, the 1st 3 spots chosen are used to guess the h,k indices for all susequent spots

Consolidation of programs

A new directory called "helix" was created with a consolidation of source files and scripts from rice and unwin. This helix directory was the old rice directory in which all unique unwin programs (both source and binary) have been added. The original rice and unwin directories are preserved in an "archive" directory. All future development will be done in this helix directory. koji directory remains distinct.

FFTRANS

Major incompatibility between old MRC header format and MRC2000 image format creates problem with helical processing. If new fftrans is used, then the phases are completely wacky (wrong phase origin), as seen from output of hftout
This is because the image2000 software keeps a machine stamp in a location that was previously reserved for the origin
Specifically, header location 54 and 55 were previously designated for the xorigin and yorigin, respectively. These locations have now been reassigned.

This problem has now fixed at NYSBC and at NYU. This required recompiling several programs to take into account the new position of the origin in the MRC header.

• hlxfl.f (unwin): simply changed the IRTORG call to include 3 parameters (XOR,YOR,ZOR) and recompiled with image2000 libraries
• hlxs_threshold.f (rice): same as hlxfl
• openmrcf.c (koji): changed the location of the origin to start at byte 49 (c arrays start at zero) and added this modified routine to mrc.a
• hlxs (koji): simply recompiled using new openmrcf.o
• hftout (koji) same as hlxs
• hlxflk (koji): same as hlxs (THIS IS CURRENTLY UNTESTED)

Previous to these repairs and recompilations (e.g. implementation at NYU), the following fix had been applied:
hft, must use older version of fftrans - pre image2000 - we called this fftrans.old

Note that the changes above have now resolved this situation and the newer (image2000) fftrans should be used
Following are from the file "image.doc" from the older and newer release of MRC software:

older image.doc

25 EXTRA Extra, user defined storage space. 29 words max.
. "
. "
. " (all set to zero by default)
. "
53 "
54 XORIGIN X origin
55 YORIGIN Y origin
56 NLABL Number of labels being used

newer image.doc (released with image2000)

* 25-49 EXTRA extra space used for anything - 0 by default *
* 50-52 ORIGIN origin in X,Y,Z used for transforms *
* 53 MAP character string 'MAP ' to identify file type *
* 54 MACHST machine stamp *
* 55 RMS rms deviation of map from mean density *
* 56 NLABL number of labels being used *

Compiling libraries

General strategy for creating these libraries

• • cd compile go into temp directory
  • unzip ../XX.zip extract source files from zip file
  • gcc -c -O -I../ *.c ! compile source files
  • ar rvf XX.a *.o ! create object library
  • mv XX.a .. ! put library into main directory
  • rm *.c *.o clean up
• So far: mrc.a, ccf.a, hlxq.a, ctfft.a, img.a, ctsys.a, graph.a, graph-prjplt
  • img.a contains object files from img.zip, boxmask.zip and vector.zip
  • hlxq.a contains object files from hlxq.zip and hlx.zip

• todo: pltulib.a, pltctfx.a, nrc.a, graphn.a ctf.a, cmath.a

Size of long integers (major bug)

The long integers were used extensively in MRC file handling routines stored in mrc.zip (and mrc.a). e.g., openmrcf.c. Also, structure elements defined in mrc.h and imgn.h. Under the old system, both long integers and integers were 4 bytes long (check this using sizeof(int) and sizeof(long) c functions). Under new system, long integers were 8 bytes and integers were 4 bytes:

• • at NYSBC under Centos 5, 64 bit machine

• • at NYU under Fedora Core 4, 32-bit machine

Compilation problems under Centos5

undefined builtin functions

The compiler with glibc-2.5-24 (Centos 5) are picker than the compiler with glibc-2.3.6-3 (Fedora Core 4).
To get rid of warnings about redefinition of builtin functions, I had to explicitly:

• • #include <string.h>
  • #include <stdlib.h>
  • #include <stdio.h>

no newline at end of file

• • added new line at the end of many files to suppress this warning message

order of functions in files

• • had to move functions from the bottom of the file up to the top of the file in several cases. This was apparently because the main function was calling a secondary function, but the declarations weren't being handled correctly.

Problematic source modules

• sqsumtbl from ccf.zip
  • compile sqsumtbl with -g flag, otherwise imgccf crashes
  • not tested extensively

• now() function declaration
  • segmentation fault in imgccf, mrccut, pds2mrc was due to now() function. This was fixed with declaration
    • char *now();
  • this will likely show up in other programs
  • actually, this may just require recompilation of code - also showed up in cgraph.c

• a couple of unresolved, but unimportant, issues
  • rfshffl.c from ctfft.zip gives two errors, which are acknowledged in the header of the source file
  • strstr.c and toupper.c left out of ctsys.a - these functions should be builtin <string.h>
    • strstr.c gave errors, toupper is just redundant, modf also seems redundant and gave warning
  • putdotsq.c in img.zip gives warning, which is stupid and can be ignored
    • unsigned char mode
    • if (mode > 255) ! well, mode cannot be greater than 255 if it is an unsigned char!

• graph and graph-prjplt
  • had to reorder several of the source modules with static declarations to put them at the front of the file (cgraph, pshandler)
  • put new line at the end of some files
  • randtbli.c - was modified to declare a dummy integer rather than use a scalar
  • a few routines did not compile

further notes

• wjr 16 March 2009 -- update of CentOS 5 to latest gcc (2.5-24.el5_2.2) required recompile of imgccf. Used same libraries and headers as before for compilation.
  • imgccf will not run on CentOS4

• Set ALLOWTOPICVIEW =

-- DavidStokes - 27 Nov 2008

Migration to Unwin software

• hfts has replaced hft for calculating the FFT from tubular crystals. This program requires long axis to be parallel to X. axchgmrc can be used for this purpose. Both hfts and axchgmrc are derived from Unwin fortran
  • hfts was modified to calculate the projection of the tube and produce a file (prj.dat) containing the projection data. This data can be plotted with gnuplot (see helix/script/prjplt.gnuplot)
  • Toyoshima programs renamed to : hftsk, axchgmrck
• hftout now taken from Unwin's program. Minor changes to Unwin's program were made to allow it to compile and to modify input format slightly
• acf can be replaced with Unwin's correl.com. This script was modified somewhat. Viewing of the output cross-correlation is still in progress
• nltable (Unwin) can be used instead of nltabl. However, nltable only outputs a id.tbl file, whereas nltabl outputs both id.tbl and id.id file. EMIP was modified to create an id.id file based on the input parameters.

• lnl.com is not necessary when running EMIP. This program (lnl) reads id.goodll file, which contains selected layer lines, and makes an output file consisting of only the selected layer lines as a template for hlxsall.pl
• unwin hlxfl replaces toyoshima hlxflk
• unwin nfavg replaces toyoshima nfavgk
• hlx2fd (Unwin) now can replace hlx2fld (toyoshima). The fortran was modified to produce resolution-dependent phase statistics
  • python wrapper hlx2fd.py was written to run hlx2fd iteratively to find the nearest minimum. Otherwise, hlx2fd only searches within specified range. Takes two arguments: controlfile 2fd-constrained-outputfile(optional)
• ltlg(.com) (Unwin) now can replace hlxfb (toyoshima). I found that the weight for the equator should be set to 1.0. The small scale factor is probably required because of the ASCII file output for little g's. If the values are too large, they overflow the format specifier. The value for IRMAX is used to calculate the number of terms to use for little g calculation. It should correspond to the layer line extent. Too big is probably ok.
• hlxsec.com (Unwin) can replace hx (toyoshima). This reads little g file and produces MRC map file. Not much too this. ystep is in degrees and actually corresponds to the range of the map in the azimuthal direction (in degrees)
• imgplot.com uses CCP4 programs (npo and pltdev) to create a contour map.

EMIP implementation

• implemented Unwin style box file
• implemented hfts for calculating fft
• implemented plotting of projection data
• implemented hftout from unwin
• implemented SRCH button (nltable, lnl)
  • values of omega and dx seem different - investigate this point
• hlxstats
  • replaced hfts
  • need to check compatibility of id.tbl file which is read by hlxmk
  • need to replace hlx2fld (toyo) with hlx2fd (unwin)
• hlxfl
  • replaced hfts
  • need to check compatibility o id.tbl file with hlxmk
• 2nd page map making needs to be implemented with unwin programs (hlxfb, hxsec, imgplt)

Ximdisp

• 24-bit support as long as DirectColor^? are supported. TrueColor^? is not supported. Looks like 24-bit vncserver only uses TrueColor^?, so 8-bit is necessary there.
• added to the lattice refinement so that spot peak is automatically found within 15x15 pixel region. Also, the 1st 3 spots chosen are used to guess the h,k indices for all susequent spots

Consolidation of programs

A new directory called "helix" was created with a consolidation of source files and scripts from rice and unwin. This helix directory was the old rice directory in which all unique unwin programs (both source and binary) have been added. The original rice and unwin directories are preserved in an "archive" directory. All future development will be done in this helix directory. koji directory remains distinct.

FFTRANS

Major incompatibility between old MRC header format and MRC2000 image format creates problem with helical processing. If new fftrans is used, then the phases are completely wacky (wrong phase origin), as seen from output of hftout
This is because the image2000 software keeps a machine stamp in a location that was previously reserved for the origin
Specifically, header location 54 and 55 were previously designated for the xorigin and yorigin, respectively. These locations have now been reassigned.

This problem has now fixed at NYSBC and at NYU. This required recompiling several programs to take into account the new position of the origin in the MRC header.

• hlxfl.f (unwin): simply changed the IRTORG call to include 3 parameters (XOR,YOR,ZOR) and recompiled with image2000 libraries
• hlxs_threshold.f (rice): same as hlxfl
• openmrcf.c (koji): changed the location of the origin to start at byte 49 (c arrays start at zero) and added this modified routine to mrc.a
• hlxs (koji): simply recompiled using new openmrcf.o
• hftout (koji) same as hlxs
• hlxflk (koji): same as hlxs (THIS IS CURRENTLY UNTESTED)

Previous to these repairs and recompilations (e.g. implementation at NYU), the following fix had been applied:
hft, must use older version of fftrans - pre image2000 - we called this fftrans.old

Note that the changes above have now resolved this situation and the newer (image2000) fftrans should be used
Following are from the file "image.doc" from the older and newer release of MRC software:

older image.doc

25 EXTRA Extra, user defined storage space. 29 words max.
. "
. "
. " (all set to zero by default)
. "
53 "
54 XORIGIN X origin
55 YORIGIN Y origin
56 NLABL Number of labels being used

newer image.doc (released with image2000)

* 25-49 EXTRA extra space used for anything - 0 by default *
* 50-52 ORIGIN origin in X,Y,Z used for transforms *
* 53 MAP character string 'MAP ' to identify file type *
* 54 MACHST machine stamp *
* 55 RMS rms deviation of map from mean density *
* 56 NLABL number of labels being used *

Compiling libraries

General strategy for creating these libraries

• • cd compile go into temp directory
  • unzip ../XX.zip extract source files from zip file
  • gcc -c -O -I../ *.c ! compile source files
  • ar rvf XX.a *.o ! create object library
  • mv XX.a .. ! put library into main directory
  • rm *.c *.o clean up
• So far: mrc.a, ccf.a, hlxq.a, ctfft.a, img.a, ctsys.a, graph.a, graph-prjplt
  • img.a contains object files from img.zip, boxmask.zip and vector.zip
  • hlxq.a contains object files from hlxq.zip and hlx.zip

• todo: pltulib.a, pltctfx.a, nrc.a, graphn.a ctf.a, cmath.a

Size of long integers (major bug)

The long integers were used extensively in MRC file handling routines stored in mrc.zip (and mrc.a). e.g., openmrcf.c. Also, structure elements defined in mrc.h and imgn.h. Under the old system, both long integers and integers were 4 bytes long (check this using sizeof(int) and sizeof(long) c functions). Under new system, long integers were 8 bytes and integers were 4 bytes:

• • at NYSBC under Centos 5, 64 bit machine

• • at NYU under Fedora Core 4, 32-bit machine

Compilation problems under Centos5

undefined builtin functions

The compiler with glibc-2.5-24 (Centos 5) are picker than the compiler with glibc-2.3.6-3 (Fedora Core 4).
To get rid of warnings about redefinition of builtin functions, I had to explicitly:

• • #include <string.h>
  • #include <stdlib.h>
  • #include <stdio.h>

no newline at end of file

• • added new line at the end of many files to suppress this warning message

order of functions in files

• • had to move functions from the bottom of the file up to the top of the file in several cases. This was apparently because the main function was calling a secondary function, but the declarations weren't being handled correctly.

Problematic source modules

• sqsumtbl from ccf.zip
  • compile sqsumtbl with -g flag, otherwise imgccf crashes
  • not tested extensively

• now() function declaration
  • segmentation fault in imgccf, mrccut, pds2mrc was due to now() function. This was fixed with declaration
    • char *now();
  • this will likely show up in other programs
  • actually, this may just require recompilation of code - also showed up in cgraph.c

• a couple of unresolved, but unimportant, issues
  • rfshffl.c from ctfft.zip gives two errors, which are acknowledged in the header of the source file
  • strstr.c and toupper.c left out of ctsys.a - these functions should be builtin <string.h>
    • strstr.c gave errors, toupper is just redundant, modf also seems redundant and gave warning
  • putdotsq.c in img.zip gives warning, which is stupid and can be ignored
    • unsigned char mode
    • if (mode > 255) ! well, mode cannot be greater than 255 if it is an unsigned char!

• graph and graph-prjplt
  • had to reorder several of the source modules with static declarations to put them at the front of the file (cgraph, pshandler)
  • put new line at the end of some files
  • randtbli.c - was modified to declare a dummy integer rather than use a scalar
  • a few routines did not compile

further notes

• wjr 16 March 2009 -- update of CentOS 5 to latest gcc (2.5-24.el5_2.2) required recompile of imgccf. Used same libraries and headers as before for compilation.
  • imgccf will not run on CentOS4

• Set ALLOWTOPICVIEW =

-- DavidStokes - 27 Nov 2008

Migration to Unwin software

• hfts has replaced hft for calculating the FFT from tubular crystals. This program requires long axis to be parallel to X. axchgmrc can be used for this purpose. Both hfts and axchgmrc are derived from Unwin fortran
  • hfts was modified to calculate the projection of the tube and produce a file (prj.dat) containing the projection data. This data can be plotted with gnuplot (see helix/script/prjplt.gnuplot)
  • Toyoshima programs renamed to : hftsk, axchgmrck
• hftout now taken from Unwin's program. Minor changes to Unwin's program were made to allow it to compile and to modify input format slightly
• acf can be replaced with Unwin's correl.com. This script was modified somewhat. Viewing of the output cross-correlation is still in progress

• hlx2fd (Unwin) now can replace hlx2fld (toyoshima). The fortran was modified to produce resolution-dependent phase statistics
  • python wrapper hlx2fd.py was written to run hlx2fd iteratively to find the nearest minimum. Otherwise, hlx2fd only searches within specified range. Takes two arguments: controlfile 2fd-constrained-outputfile(optional)
• ltlg(.com) (Unwin) now can replace hlxfb (toyoshima). I found that the weight for the equator should be set to 1.0. The small scale factor is probably required because of the ASCII file output for little g's. If the values are too large, they overflow the format specifier. The value for IRMAX is used to calculate the number of terms to use for little g calculation. It should correspond to the layer line extent. Too big is probably ok.
• hlxsec.com (Unwin) can replace hx (toyoshima). This reads little g file and produces MRC map file. Not much too this. ystep is in degrees and actually corresponds to the range of the map in the azimuthal direction (in degrees)
• imgplot.com uses CCP4 programs (npo and pltdev) to create a contour map.

Ximdisp

• 24-bit support as long as DirectColor^? are supported. TrueColor^? is not supported. Looks like 24-bit vncserver only uses TrueColor^?, so 8-bit is necessary there.
• added to the lattice refinement so that spot peak is automatically found within 15x15 pixel region. Also, the 1st 3 spots chosen are used to guess the h,k indices for all susequent spots

Consolidation of programs

A new directory called "helix" was created with a consolidation of source files and scripts from rice and unwin. This helix directory was the old rice directory in which all unique unwin programs (both source and binary) have been added. The original rice and unwin directories are preserved in an "archive" directory. All future development will be done in this helix directory. koji directory remains distinct.

FFTRANS

Major incompatibility between old MRC header format and MRC2000 image format creates problem with helical processing. If new fftrans is used, then the phases are completely wacky (wrong phase origin), as seen from output of hftout
This is because the image2000 software keeps a machine stamp in a location that was previously reserved for the origin
Specifically, header location 54 and 55 were previously designated for the xorigin and yorigin, respectively. These locations have now been reassigned.

This problem has now fixed at NYSBC and at NYU. This required recompiling several programs to take into account the new position of the origin in the MRC header.

• hlxfl.f (unwin): simply changed the IRTORG call to include 3 parameters (XOR,YOR,ZOR) and recompiled with image2000 libraries
• hlxs_threshold.f (rice): same as hlxfl
• openmrcf.c (koji): changed the location of the origin to start at byte 49 (c arrays start at zero) and added this modified routine to mrc.a
• hlxs (koji): simply recompiled using new openmrcf.o
• hftout (koji) same as hlxs
• hlxflk (koji): same as hlxs (THIS IS CURRENTLY UNTESTED)

Previous to these repairs and recompilations (e.g. implementation at NYU), the following fix had been applied:
hft, must use older version of fftrans - pre image2000 - we called this fftrans.old

Note that the changes above have now resolved this situation and the newer (image2000) fftrans should be used
Following are from the file "image.doc" from the older and newer release of MRC software:

older image.doc

25 EXTRA Extra, user defined storage space. 29 words max.
. "
. "
. " (all set to zero by default)
. "
53 "
54 XORIGIN X origin
55 YORIGIN Y origin
56 NLABL Number of labels being used

newer image.doc (released with image2000)

* 25-49 EXTRA extra space used for anything - 0 by default *
* 50-52 ORIGIN origin in X,Y,Z used for transforms *
* 53 MAP character string 'MAP ' to identify file type *
* 54 MACHST machine stamp *
* 55 RMS rms deviation of map from mean density *
* 56 NLABL number of labels being used *

Compiling libraries

General strategy for creating these libraries

• • cd compile go into temp directory
  • unzip ../XX.zip extract source files from zip file
  • gcc -c -O -I../ *.c ! compile source files
  • ar rvf XX.a *.o ! create object library
  • mv XX.a .. ! put library into main directory
  • rm *.c *.o clean up
• So far: mrc.a, ccf.a, hlxq.a, ctfft.a, img.a, ctsys.a, graph.a, graph-prjplt
  • img.a contains object files from img.zip, boxmask.zip and vector.zip
  • hlxq.a contains object files from hlxq.zip and hlx.zip

• todo: pltulib.a, pltctfx.a, nrc.a, graphn.a ctf.a, cmath.a

Size of long integers (major bug)

The long integers were used extensively in MRC file handling routines stored in mrc.zip (and mrc.a). e.g., openmrcf.c. Also, structure elements defined in mrc.h and imgn.h. Under the old system, both long integers and integers were 4 bytes long (check this using sizeof(int) and sizeof(long) c functions). Under new system, long integers were 8 bytes and integers were 4 bytes:

• • at NYSBC under Centos 5, 64 bit machine

• • at NYU under Fedora Core 4, 32-bit machine

Compilation problems under Centos5

undefined builtin functions

The compiler with glibc-2.5-24 (Centos 5) are picker than the compiler with glibc-2.3.6-3 (Fedora Core 4).
To get rid of warnings about redefinition of builtin functions, I had to explicitly:

• • #include <string.h>
  • #include <stdlib.h>
  • #include <stdio.h>

no newline at end of file

• • added new line at the end of many files to suppress this warning message

order of functions in files

• • had to move functions from the bottom of the file up to the top of the file in several cases. This was apparently because the main function was calling a secondary function, but the declarations weren't being handled correctly.

Problematic source modules

• sqsumtbl from ccf.zip
  • compile sqsumtbl with -g flag, otherwise imgccf crashes
  • not tested extensively

• now() function declaration
  • segmentation fault in imgccf, mrccut, pds2mrc was due to now() function. This was fixed with declaration
    • char *now();
  • this will likely show up in other programs
  • actually, this may just require recompilation of code - also showed up in cgraph.c

• a couple of unresolved, but unimportant, issues
  • rfshffl.c from ctfft.zip gives two errors, which are acknowledged in the header of the source file
  • strstr.c and toupper.c left out of ctsys.a - these functions should be builtin <string.h>
    • strstr.c gave errors, toupper is just redundant, modf also seems redundant and gave warning
  • putdotsq.c in img.zip gives warning, which is stupid and can be ignored
    • unsigned char mode
    • if (mode > 255) ! well, mode cannot be greater than 255 if it is an unsigned char!

• graph and graph-prjplt
  • had to reorder several of the source modules with static declarations to put them at the front of the file (cgraph, pshandler)
  • put new line at the end of some files
  • randtbli.c - was modified to declare a dummy integer rather than use a scalar
  • a few routines did not compile

further notes

• wjr 16 March 2009 -- update of CentOS 5 to latest gcc (2.5-24.el5_2.2) required recompile of imgccf. Used same libraries and headers as before for compilation.
  • imgccf will not run on CentOS4

• Set ALLOWTOPICVIEW =

-- DavidStokes - 27 Nov 2008

Migration to Unwin software

• hfts has replaced hft for calculating the FFT from tubular crystals. This program requires long axis to be parallel to X. axchgmrc can be used for this purpose. Both hfts and axchgmrc are derived from Unwin fortran
  • hfts was modified to calculate the projection of the tube and produce a file (prj.dat) containing the projection data. This data can be plotted with gnuplot (see helix/script/prjplt.gnuplot)
  • Toyoshima programs renamed to : hftsk, axchgmrck
• hftout now taken from Unwin's program. Minor changes to Unwin's program were made to allow it to compile and to modify input format slightly
• acf can be replaced with Unwin's correl.com. This script was modified somewhat. Viewing of the output cross-correlation is still in progress
• hlx2fd (Unwin) now can replace hlx2fld (toyoshima). The fortran was modified to produce resolution-dependent phase statistics

Ximdisp

• 24-bit support as long as DirectColor^? are supported. TrueColor^? is not supported. Looks like 24-bit vncserver only uses TrueColor^?, so 8-bit is necessary there.
• added to the lattice refinement so that spot peak is automatically found within 15x15 pixel region. Also, the 1st 3 spots chosen are used to guess the h,k indices for all susequent spots

Consolidation of programs

A new directory called "helix" was created with a consolidation of source files and scripts from rice and unwin. This helix directory was the old rice directory in which all unique unwin programs (both source and binary) have been added. The original rice and unwin directories are preserved in an "archive" directory. All future development will be done in this helix directory. koji directory remains distinct.

FFTRANS

Major incompatibility between old MRC header format and MRC2000 image format creates problem with helical processing. If new fftrans is used, then the phases are completely wacky (wrong phase origin), as seen from output of hftout
This is because the image2000 software keeps a machine stamp in a location that was previously reserved for the origin
Specifically, header location 54 and 55 were previously designated for the xorigin and yorigin, respectively. These locations have now been reassigned.

This problem has now fixed at NYSBC and at NYU. This required recompiling several programs to take into account the new position of the origin in the MRC header.

• hlxfl.f (unwin): simply changed the IRTORG call to include 3 parameters (XOR,YOR,ZOR) and recompiled with image2000 libraries
• hlxs_threshold.f (rice): same as hlxfl
• openmrcf.c (koji): changed the location of the origin to start at byte 49 (c arrays start at zero) and added this modified routine to mrc.a
• hlxs (koji): simply recompiled using new openmrcf.o
• hftout (koji) same as hlxs
• hlxflk (koji): same as hlxs (THIS IS CURRENTLY UNTESTED)

Previous to these repairs and recompilations (e.g. implementation at NYU), the following fix had been applied:
hft, must use older version of fftrans - pre image2000 - we called this fftrans.old

Note that the changes above have now resolved this situation and the newer (image2000) fftrans should be used
Following are from the file "image.doc" from the older and newer release of MRC software:

older image.doc

25 EXTRA Extra, user defined storage space. 29 words max.
. "
. "
. " (all set to zero by default)
. "
53 "
54 XORIGIN X origin
55 YORIGIN Y origin
56 NLABL Number of labels being used

newer image.doc (released with image2000)

* 25-49 EXTRA extra space used for anything - 0 by default *
* 50-52 ORIGIN origin in X,Y,Z used for transforms *
* 53 MAP character string 'MAP ' to identify file type *
* 54 MACHST machine stamp *
* 55 RMS rms deviation of map from mean density *
* 56 NLABL number of labels being used *

Compiling libraries

General strategy for creating these libraries

• • cd compile go into temp directory
  • unzip ../XX.zip extract source files from zip file
  • gcc -c -O -I../ *.c ! compile source files
  • ar rvf XX.a *.o ! create object library
  • mv XX.a .. ! put library into main directory
  • rm *.c *.o clean up
• So far: mrc.a, ccf.a, hlxq.a, ctfft.a, img.a, ctsys.a, graph.a, graph-prjplt
  • img.a contains object files from img.zip, boxmask.zip and vector.zip
  • hlxq.a contains object files from hlxq.zip and hlx.zip

• todo: pltulib.a, pltctfx.a, nrc.a, graphn.a ctf.a, cmath.a

Size of long integers (major bug)

The long integers were used extensively in MRC file handling routines stored in mrc.zip (and mrc.a). e.g., openmrcf.c. Also, structure elements defined in mrc.h and imgn.h. Under the old system, both long integers and integers were 4 bytes long (check this using sizeof(int) and sizeof(long) c functions). Under new system, long integers were 8 bytes and integers were 4 bytes:

• • at NYSBC under Centos 5, 64 bit machine

• • at NYU under Fedora Core 4, 32-bit machine

Compilation problems under Centos5

undefined builtin functions

The compiler with glibc-2.5-24 (Centos 5) are picker than the compiler with glibc-2.3.6-3 (Fedora Core 4).
To get rid of warnings about redefinition of builtin functions, I had to explicitly:

• • #include <string.h>
  • #include <stdlib.h>
  • #include <stdio.h>

no newline at end of file

• • added new line at the end of many files to suppress this warning message

order of functions in files

• • had to move functions from the bottom of the file up to the top of the file in several cases. This was apparently because the main function was calling a secondary function, but the declarations weren't being handled correctly.

Problematic source modules

• sqsumtbl from ccf.zip
  • compile sqsumtbl with -g flag, otherwise imgccf crashes
  • not tested extensively

• now() function declaration
  • segmentation fault in imgccf, mrccut, pds2mrc was due to now() function. This was fixed with declaration
    • char *now();
  • this will likely show up in other programs
  • actually, this may just require recompilation of code - also showed up in cgraph.c

• a couple of unresolved, but unimportant, issues
  • rfshffl.c from ctfft.zip gives two errors, which are acknowledged in the header of the source file
  • strstr.c and toupper.c left out of ctsys.a - these functions should be builtin <string.h>
    • strstr.c gave errors, toupper is just redundant, modf also seems redundant and gave warning
  • putdotsq.c in img.zip gives warning, which is stupid and can be ignored
    • unsigned char mode
    • if (mode > 255) ! well, mode cannot be greater than 255 if it is an unsigned char!

• graph and graph-prjplt
  • had to reorder several of the source modules with static declarations to put them at the front of the file (cgraph, pshandler)
  • put new line at the end of some files
  • randtbli.c - was modified to declare a dummy integer rather than use a scalar
  • a few routines did not compile

further notes

• wjr 16 March 2009 -- update of CentOS 5 to latest gcc (2.5-24.el5_2.2) required recompile of imgccf. Used same libraries and headers as before for compilation.
  • imgccf will not run on CentOS4

• Set ALLOWTOPICVIEW =

-- DavidStokes - 27 Nov 2008

Consolidation of programs

A new directory called "helix" was created with a consolidation of source files and scripts from rice and unwin. This helix directory was the old rice directory in which all unique unwin programs (both source and binary) have been added. The original rice and unwin directories are preserved in an "archive" directory. All future development will be done in this helix directory. koji directory remains distinct.

FFTRANS

Major incompatibility between old MRC header format and MRC2000 image format creates problem with helical processing. If new fftrans is used, then the phases are completely wacky (wrong phase origin), as seen from output of hftout
This is because the image2000 software keeps a machine stamp in a location that was previously reserved for the origin
Specifically, header location 54 and 55 were previously designated for the xorigin and yorigin, respectively. These locations have now been reassigned.

This problem has now fixed at NYSBC and at NYU. This required recompiling several programs to take into account the new position of the origin in the MRC header.

• hlxfl.f (unwin): simply changed the IRTORG call to include 3 parameters (XOR,YOR,ZOR) and recompiled with image2000 libraries
• hlxs_threshold.f (rice): same as hlxfl
• openmrcf.c (koji): changed the location of the origin to start at byte 49 (c arrays start at zero) and added this modified routine to mrc.a
• hlxs (koji): simply recompiled using new openmrcf.o
• hftout (koji) same as hlxs
• hlxflk (koji): same as hlxs (THIS IS CURRENTLY UNTESTED)

Previous to these repairs and recompilations (e.g. implementation at NYU), the following fix had been applied:
hft, must use older version of fftrans - pre image2000 - we called this fftrans.old

Note that the changes above have now resolved this situation and the newer (image2000) fftrans should be used
Following are from the file "image.doc" from the older and newer release of MRC software:

older image.doc

25 EXTRA Extra, user defined storage space. 29 words max.
. "
. "
. " (all set to zero by default)
. "
53 "
54 XORIGIN X origin
55 YORIGIN Y origin
56 NLABL Number of labels being used

newer image.doc (released with image2000)

* 25-49 EXTRA extra space used for anything - 0 by default *
* 50-52 ORIGIN origin in X,Y,Z used for transforms *
* 53 MAP character string 'MAP ' to identify file type *
* 54 MACHST machine stamp *
* 55 RMS rms deviation of map from mean density *
* 56 NLABL number of labels being used *

Compiling libraries

General strategy for creating these libraries

• • cd compile go into temp directory
  • unzip ../XX.zip extract source files from zip file
  • gcc -c -O -I../ *.c ! compile source files
  • ar rvf XX.a *.o ! create object library
  • mv XX.a .. ! put library into main directory
  • rm *.c *.o clean up
• So far: mrc.a, ccf.a, hlxq.a, ctfft.a, img.a, ctsys.a, graph.a, graph-prjplt
  • img.a contains object files from img.zip, boxmask.zip and vector.zip
  • hlxq.a contains object files from hlxq.zip and hlx.zip

• todo: pltulib.a, pltctfx.a, nrc.a, graphn.a ctf.a, cmath.a

Size of long integers (major bug)

The long integers were used extensively in MRC file handling routines stored in mrc.zip (and mrc.a). e.g., openmrcf.c. Also, structure elements defined in mrc.h and imgn.h. Under the old system, both long integers and integers were 4 bytes long (check this using sizeof(int) and sizeof(long) c functions). Under new system, long integers were 8 bytes and integers were 4 bytes:

• • at NYSBC under Centos 5, 64 bit machine

• • at NYU under Fedora Core 4, 32-bit machine

Compilation problems under Centos5

undefined builtin functions

The compiler with glibc-2.5-24 (Centos 5) are picker than the compiler with glibc-2.3.6-3 (Fedora Core 4).
To get rid of warnings about redefinition of builtin functions, I had to explicitly:

• • #include <string.h>
  • #include <stdlib.h>
  • #include <stdio.h>

no newline at end of file

• • added new line at the end of many files to suppress this warning message

order of functions in files

• • had to move functions from the bottom of the file up to the top of the file in several cases. This was apparently because the main function was calling a secondary function, but the declarations weren't being handled correctly.

Problematic source modules

• sqsumtbl from ccf.zip
  • compile sqsumtbl with -g flag, otherwise imgccf crashes
  • not tested extensively

• now() function declaration
  • segmentation fault in imgccf, mrccut, pds2mrc was due to now() function. This was fixed with declaration
    • char *now();
  • this will likely show up in other programs
  • actually, this may just require recompilation of code - also showed up in cgraph.c

• a couple of unresolved, but unimportant, issues
  • rfshffl.c from ctfft.zip gives two errors, which are acknowledged in the header of the source file
  • strstr.c and toupper.c left out of ctsys.a - these functions should be builtin <string.h>
    • strstr.c gave errors, toupper is just redundant, modf also seems redundant and gave warning
  • putdotsq.c in img.zip gives warning, which is stupid and can be ignored
    • unsigned char mode
    • if (mode > 255) ! well, mode cannot be greater than 255 if it is an unsigned char!

• graph and graph-prjplt
  • had to reorder several of the source modules with static declarations to put them at the front of the file (cgraph, pshandler)
  • put new line at the end of some files
  • randtbli.c - was modified to declare a dummy integer rather than use a scalar
  • a few routines did not compile

further notes

• wjr 16 March 2009 -- update of CentOS 5 to latest gcc (2.5-24.el5_2.2) required recompile of imgccf. Used same libraries and headers as before for compilation.
  • imgccf will not run on CentOS4

• Set ALLOWTOPICVIEW =

-- DavidStokes - 27 Nov 2008

FFTRANS

• hlxfl.f (unwin): simply changed the IRTORG call to include 3 parameters (XOR,YOR,ZOR) and recompiled with image2000 libraries
• hlxs_threshold.f (rice): same as hlxfl
• openmrcf.c (koji): changed the location of the origin to start at byte 49 (c arrays start at zero) and added this modified routine to mrc.a
• hlxs (koji): simply recompiled using new openmrcf.o
• hftout (koji) same as hlxs
• hlxflk (koji): same as hlxs (THIS IS CURRENTLY UNTESTED)

older image.doc

25 EXTRA Extra, user defined storage space. 29 words max.
. "
. "
. " (all set to zero by default)
. "
53 "
54 XORIGIN X origin
55 YORIGIN Y origin
56 NLABL Number of labels being used

newer image.doc (released with image2000)

* 25-49 EXTRA extra space used for anything - 0 by default *
* 50-52 ORIGIN origin in X,Y,Z used for transforms *
* 53 MAP character string 'MAP ' to identify file type *
* 54 MACHST machine stamp *
* 55 RMS rms deviation of map from mean density *
* 56 NLABL number of labels being used *

Compiling libraries

General strategy for creating these libraries

• • cd compile go into temp directory
  • unzip ../XX.zip extract source files from zip file
  • gcc -c -O -I../ *.c ! compile source files
  • ar rvf XX.a *.o ! create object library
  • mv XX.a .. ! put library into main directory
  • rm *.c *.o clean up
• So far: mrc.a, ccf.a, hlxq.a, ctfft.a, img.a, ctsys.a, graph.a, graph-prjplt
  • img.a contains object files from img.zip, boxmask.zip and vector.zip
  • hlxq.a contains object files from hlxq.zip and hlx.zip

• todo: pltulib.a, pltctfx.a, nrc.a, graphn.a ctf.a, cmath.a

Size of long integers (major bug)

The long integers were used extensively in MRC file handling routines stored in mrc.zip (and mrc.a). e.g., openmrcf.c. Also, structure elements defined in mrc.h and imgn.h. Under the old system, both long integers and integers were 4 bytes long (check this using sizeof(int) and sizeof(long) c functions). Under new system, long integers were 8 bytes and integers were 4 bytes:

• • at NYSBC under Centos 5, 64 bit machine

• • at NYU under Fedora Core 4, 32-bit machine

Compilation problems under Centos5

undefined builtin functions

The compiler with glibc-2.5-24 (Centos 5) are picker than the compiler with glibc-2.3.6-3 (Fedora Core 4).
To get rid of warnings about redefinition of builtin functions, I had to explicitly:

• • #include <string.h>
  • #include <stdlib.h>
  • #include <stdio.h>

no newline at end of file

• • added new line at the end of many files to suppress this warning message

order of functions in files

• • had to move functions from the bottom of the file up to the top of the file in several cases. This was apparently because the main function was calling a secondary function, but the declarations weren't being handled correctly.

Problematic source modules

• sqsumtbl from ccf.zip
  • compile sqsumtbl with -g flag, otherwise imgccf crashes
  • not tested extensively

• now() function declaration
  • segmentation fault in imgccf, mrccut, pds2mrc was due to now() function. This was fixed with declaration
    • char *now();
  • this will likely show up in other programs
  • actually, this may just require recompilation of code - also showed up in cgraph.c

• a couple of unresolved, but unimportant, issues
  • rfshffl.c from ctfft.zip gives two errors, which are acknowledged in the header of the source file
  • strstr.c and toupper.c left out of ctsys.a - these functions should be builtin <string.h>
    • strstr.c gave errors, toupper is just redundant, modf also seems redundant and gave warning
  • putdotsq.c in img.zip gives warning, which is stupid and can be ignored
    • unsigned char mode
    • if (mode > 255) ! well, mode cannot be greater than 255 if it is an unsigned char!

• graph and graph-prjplt
  • had to reorder several of the source modules with static declarations to put them at the front of the file (cgraph, pshandler)
  • put new line at the end of some files
  • randtbli.c - was modified to declare a dummy integer rather than use a scalar
  • a few routines did not compile

further notes

• wjr 16 March 2009 -- update of CentOS 5 to latest gcc (2.5-24.el5_2.2) required recompile of imgccf. Used same libraries and headers as before for compilation.
  • imgccf will not run on CentOS4

• Set ALLOWTOPICVIEW =

-- DavidStokes - 27 Nov 2008

FFTRANS

Below issue is now fixed at NYSBC. This required recompiling several programs to take into account the new position of the origin in the MRC header.

• hlxfl.f (unwin): simply changed the IRTORG call to include 3 parameters (XOR,YOR,ZOR) and recompiled with image2000 libraries
• hlxs_threshold.f (rice): same as hlxfl
• openmrcf.c (koji): changed the location of the origin to start at byte 49 (c arrays start at zero) and added this modified routine to mrc.a
• hlxs (koji): simply recompiled using new openmrcf.o
• hftout (koji) same as hlxs
• hlxflk (koji): same as hlxs (THIS IS CURRENTLY UNTESTED)

Previous to these repairs and recompilations (e.g. implementation at NYU), the following fix has been applied:
hft, must use older version of fftrans - pre image2000 - we call this fftrans.old
If new fftrans is used, then the phases are completely wacky (wrong phase origin), as seen from output of hftout
This is because the image2000 software keeps a machine stamp in a location that was previously reserved for the origin
Specifically, header location 54 and 55 were previously designated for the xorigin and yorigin, respectively. These locations have now been reassigned.
Note that the changes above have now resolved this situation and the newer (image2000) fftrans should be used
Following are from the file "image.doc" from the older and newer release of MRC software:

older image.doc

25 EXTRA Extra, user defined storage space. 29 words max.
. "
. "
. " (all set to zero by default)
. "
53 "
54 XORIGIN X origin
55 YORIGIN Y origin
56 NLABL Number of labels being used

newer image.doc (released with image2000)

* 25-49 EXTRA extra space used for anything - 0 by default *
* 50-52 ORIGIN origin in X,Y,Z used for transforms *
* 53 MAP character string 'MAP ' to identify file type *
* 54 MACHST machine stamp *
* 55 RMS rms deviation of map from mean density *
* 56 NLABL number of labels being used *

Compiling libraries

General strategy for creating these libraries

• • cd compile go into temp directory
  • unzip ../XX.zip extract source files from zip file
  • gcc -c -O -I../ *.c ! compile source files
  • ar rvf XX.a *.o ! create object library
  • mv XX.a .. ! put library into main directory
  • rm *.c *.o clean up
• So far: mrc.a, ccf.a, hlxq.a, ctfft.a, img.a, ctsys.a, graph.a, graph-prjplt
  • img.a contains object files from img.zip, boxmask.zip and vector.zip
  • hlxq.a contains object files from hlxq.zip and hlx.zip

• todo: pltulib.a, pltctfx.a, nrc.a, graphn.a ctf.a, cmath.a

Size of long integers (major bug)

The long integers were used extensively in MRC file handling routines stored in mrc.zip (and mrc.a). e.g., openmrcf.c. Also, structure elements defined in mrc.h and imgn.h. Under the old system, both long integers and integers were 4 bytes long (check this using sizeof(int) and sizeof(long) c functions). Under new system, long integers were 8 bytes and integers were 4 bytes:

• • at NYSBC under Centos 5, 64 bit machine

• • at NYU under Fedora Core 4, 32-bit machine

Compilation problems under Centos5

undefined builtin functions

The compiler with glibc-2.5-24 (Centos 5) are picker than the compiler with glibc-2.3.6-3 (Fedora Core 4).
To get rid of warnings about redefinition of builtin functions, I had to explicitly:

• • #include <string.h>
  • #include <stdlib.h>
  • #include <stdio.h>

no newline at end of file

• • added new line at the end of many files to suppress this warning message

order of functions in files

• • had to move functions from the bottom of the file up to the top of the file in several cases. This was apparently because the main function was calling a secondary function, but the declarations weren't being handled correctly.

Problematic source modules

• sqsumtbl from ccf.zip
  • compile sqsumtbl with -g flag, otherwise imgccf crashes
  • not tested extensively

• now() function declaration

• • • char *now();
  • this will likely show up in other programs
  • actually, this may just require recompilation of code - also showed up in cgraph.c

• a couple of unresolved, but unimportant, issues
  • rfshffl.c from ctfft.zip gives two errors, which are acknowledged in the header of the source file
  • strstr.c and toupper.c left out of ctsys.a - these functions should be builtin <string.h>
    • strstr.c gave errors, toupper is just redundant, modf also seems redundant and gave warning
  • putdotsq.c in img.zip gives warning, which is stupid and can be ignored
    • unsigned char mode
    • if (mode > 255) ! well, mode cannot be greater than 255 if it is an unsigned char!

• graph and graph-prjplt
  • had to reorder several of the source modules with static declarations to put them at the front of the file (cgraph, pshandler)
  • put new line at the end of some files
  • randtbli.c - was modified to declare a dummy integer rather than use a scalar
  • a few routines did not compile

further notes

• wjr 16 March 2009 -- update of CentOS 5 to latest gcc (2.5-24.el5_2.2) required recompile of imgccf. Used same libraries and headers as before for compilation.
  • imgccf will not run on CentOS4

• Set ALLOWTOPICVIEW =

-- DavidStokes - 27 Nov 2008

FFTRANS

Below issue is now fixed at NYSBC. This required recompiling several programs to take into account the new position of the origin in the MRC header.

• hlxfl.f (unwin): simply changed the IRTORG call to include 3 parameters (XOR,YOR,ZOR) and recompiled with image2000 libraries
• hlxs_threshold.f (rice): same as hlxfl
• openmrcf.c (koji): changed the location of the origin to start at byte 49 (c arrays start at zero) and added this modified routine to mrc.a
• hlxs (koji): simply recompiled using new openmrcf.o
• hftout (koji) same as hlxs
• hlxflk (koji): same as hlxs (THIS IS CURRENTLY UNTESTED)

Previous to these repairs and recompilations (e.g. implementation at NYU), the following fix has been applied:
hft, must use older version of fftrans - pre image2000 - we call this fftrans.old
If new fftrans is used, then the phases are completely wacky (wrong phase origin), as seen from output of hftout
This is because the image2000 software keeps a machine stamp in a location that was previously reserved for the origin
Specifically, header location 54 and 55 were previously designated for the xorigin and yorigin, respectively. These locations have now been reassigned.
Note that the changes above have now resolved this situation and the newer (image2000) fftrans should be used
Following are from the file "image.doc" from the older and newer release of MRC software:

older image.doc

25 EXTRA Extra, user defined storage space. 29 words max.
. "
. "
. " (all set to zero by default)
. "
53 "
54 XORIGIN X origin
55 YORIGIN Y origin
56 NLABL Number of labels being used

newer image.doc (released with image2000)

* 25-49 EXTRA extra space used for anything - 0 by default *
* 50-52 ORIGIN origin in X,Y,Z used for transforms *
* 53 MAP character string 'MAP ' to identify file type *
* 54 MACHST machine stamp *
* 55 RMS rms deviation of map from mean density *
* 56 NLABL number of labels being used *

Compiling libraries

General strategy for creating these libraries

• • cd compile go into temp directory
  • unzip ../XX.zip extract source files from zip file
  • gcc -c -O -I../ *.c ! compile source files
  • ar rvf XX.a *.o ! create object library
  • mv XX.a .. ! put library into main directory
  • rm *.c *.o clean up
• So far: mrc.a, ccf.a, hlxq.a, ctfft.a, img.a, ctsys.a, graph.a, graph-prjplt
  • img.a contains object files from img.zip, boxmask.zip and vector.zip
  • hlxq.a contains object files from hlxq.zip and hlx.zip

• todo: pltulib.a, pltctfx.a, nrc.a, graphn.a ctf.a, cmath.a

Size of long integers (major bug)

The long integers were used extensively in MRC file handling routines stored in mrc.zip (and mrc.a). e.g., openmrcf.c. Also, structure elements defined in mrc.h and imgn.h. Under the old system, both long integers and integers were 4 bytes long (check this using sizeof(int) and sizeof(long) c functions). Under new system, long integers were 8 bytes and integers were 4 bytes:

• • at NYSBC under Centos 5, 64 bit machine

• • at NYU under Fedora Core 4, 32-bit machine

Compilation problems under Centos5

undefined builtin functions

The compiler with glibc-2.5-24 (Centos 5) are picker than the compiler with glibc-2.3.6-3 (Fedora Core 4).
To get rid of warnings about redefinition of builtin functions, I had to explicitly:

• • #include <string.h>
  • #include <stdlib.h>
  • #include <stdio.h>

no newline at end of file

• • added new line at the end of many files to suppress this warning message

order of functions in files

• • had to move functions from the bottom of the file up to the top of the file in several cases. This was apparently because the main function was calling a secondary function, but the declarations weren't being handled correctly.

Problematic source modules

• sqsumtbl from ccf.zip
  • compile sqsumtbl with -g flag, otherwise imgccf crashes
  • not tested extensively

• now() function declaration
  • segmentation fault in imgccf and also mrccut was due to now() function. This was fixed with declaration
    • char *now();
  • this will likely show up in other programs
  • actually, this may just require recompilation of code - also showed up in cgraph.c

• a couple of unresolved, but unimportant, issues
  • rfshffl.c from ctfft.zip gives two errors, which are acknowledged in the header of the source file
  • strstr.c and toupper.c left out of ctsys.a - these functions should be builtin <string.h>
    • strstr.c gave errors, toupper is just redundant, modf also seems redundant and gave warning
  • putdotsq.c in img.zip gives warning, which is stupid and can be ignored
    • unsigned char mode
    • if (mode > 255) ! well, mode cannot be greater than 255 if it is an unsigned char!

• graph and graph-prjplt
  • had to reorder several of the source modules with static declarations to put them at the front of the file (cgraph, pshandler)
  • put new line at the end of some files
  • randtbli.c - was modified to declare a dummy integer rather than use a scalar
  • a few routines did not compile

further notes

• Set ALLOWTOPICVIEW =

-- DavidStokes - 27 Nov 2008

FFTRANS

Below issue is now fixed at NYSBC. This required recompiling several programs to take into account the new position of the origin in the MRC header.

• hlxfl.f (unwin): simply changed the IRTORG call to include 3 parameters (XOR,YOR,ZOR) and recompiled with image2000 libraries
• hlxs_threshold.f (rice): same as hlxfl
• openmrcf.c (koji): changed the location of the origin to start at byte 49 (c arrays start at zero) and added this modified routine to mrc.a
• hlxs (koji): simply recompiled using new openmrcf.o
• hftout (koji) same as hlxs
• hlxflk (koji): same as hlxs (THIS IS CURRENTLY UNTESTED)

Previous to these repairs and recompilations (e.g. implementation at NYU), the following fix has been applied:
hft, must use older version of fftrans - pre image2000 - we call this fftrans.old
If new fftrans is used, then the phases are completely wacky (wrong phase origin), as seen from output of hftout
This is because the image2000 software keeps a machine stamp in a location that was previously reserved for the origin
Specifically, header location 54 and 55 were previously designated for the xorigin and yorigin, respectively. These locations have now been reassigned.
Note that the changes above have now resolved this situation and the newer (image2000) fftrans should be used
Following are from the file "image.doc" from the older and newer release of MRC software:

older image.doc

25 EXTRA Extra, user defined storage space. 29 words max.
. "
. "
. " (all set to zero by default)
. "
53 "
54 XORIGIN X origin
55 YORIGIN Y origin
56 NLABL Number of labels being used

newer image.doc (released with image2000)

* 25-49 EXTRA extra space used for anything - 0 by default *
* 50-52 ORIGIN origin in X,Y,Z used for transforms *
* 53 MAP character string 'MAP ' to identify file type *
* 54 MACHST machine stamp *
* 55 RMS rms deviation of map from mean density *
* 56 NLABL number of labels being used *

Compiling libraries

General strategy for creating these libraries

• • cd compile go into temp directory
  • unzip ../XX.zip extract source files from zip file
  • gcc -c -O -I../ *.c ! compile source files
  • ar rvf XX.a *.o ! create object library
  • mv XX.a .. ! put library into main directory
  • rm *.c *.o clean up
• So far: mrc.a, ccf.a, hlxq.a, ctfft.a, img.a, ctsys.a, graph.a, graph-prjplt
  • img.a contains object files from img.zip, boxmask.zip and vector.zip
  • hlxq.a contains object files from hlxq.zip and hlx.zip

• todo: pltulib.a, pltctfx.a, nrc.a, graphn.a ctf.a, cmath.a

Size of long integers (major bug)

The long integers were used extensively in MRC file handling routines stored in mrc.zip (and mrc.a). e.g., openmrcf.c. Also, structure elements defined in mrc.h and imgn.h. Under the old system, both long integers and integers were 4 bytes long (check this using sizeof(int) and sizeof(long) c functions). Under new system, long integers were 8 bytes and integers were 4 bytes:

• • at NYSBC under Centos 5, 64 bit machine

• • at NYU under Fedora Core 4, 32-bit machine

Compilation problems under Centos5

undefined builtin functions

The compiler with glibc-2.5-24 (Centos 5) are picker than the compiler with glibc-2.3.6-3 (Fedora Core 4).
To get rid of warnings about redefinition of builtin functions, I had to explicitly:

• • #include <string.h>
  • #include <stdlib.h>
  • #include <stdio.h>

no newline at end of file

• • added new line at the end of many files to suppress this warning message

order of functions in files

• • had to move functions from the bottom of the file up to the top of the file in several cases. This was apparently because the main function was calling a secondary function, but the declarations weren't being handled correctly.

Problematic source modules

• sqsumtbl from ccf.zip
  • compile sqsumtbl with -g flag, otherwise imgccf crashes
  • not tested extensively

• now() function declaration
  • segmentation fault in imgccf and also mrccut was due to now() function. This was fixed with declaration
    • char *now();
  • this will likely show up in other programs
  • actually, this may just require recompilation of code - also showed up in cgraph.c

• a couple of unresolved, but unimportant, issues
  • rfshffl.c from ctfft.zip gives two errors, which are acknowledged in the header of the source file
  • strstr.c and toupper.c left out of ctsys.a - these functions should be builtin <string.h>
    • strstr.c gave errors, toupper is just redundant, modf also seems redundant and gave warning
  • putdotsq.c in img.zip gives warning, which is stupid and can be ignored
    • unsigned char mode
    • if (mode > 255) ! well, mode cannot be greater than 255 if it is an unsigned char!

• graph and graph-prjplt
  • had to reorder several of the source modules with static declarations to put them at the front of the file (cgraph, pshandler)
  • put new line at the end of some files
  • randtbli.c - was modified to declare a dummy integer rather than use a scalar
  • a few routines did not compile

further notes

• • imgccf will not run on CentOS4^?

• Set ALLOWTOPICVIEW =

-- DavidStokes - 27 Nov 2008

FFTRANS

Below issue is now fixed at NYSBC. This required recompiling several programs to take into account the new position of the origin in the MRC header.

• hlxfl.f (unwin): simply changed the IRTORG call to include 3 parameters (XOR,YOR,ZOR) and recompiled with image2000 libraries
• hlxs_threshold.f (rice): same as hlxfl
• openmrcf.c (koji): changed the location of the origin to start at byte 49 (c arrays start at zero) and added this modified routine to mrc.a
• hlxs (koji): simply recompiled using new openmrcf.o
• hftout (koji) same as hlxs
• hlxflk (koji): same as hlxs (THIS IS CURRENTLY UNTESTED)

Previous to these repairs and recompilations (e.g. implementation at NYU), the following fix has been applied:
hft, must use older version of fftrans - pre image2000 - we call this fftrans.old
If new fftrans is used, then the phases are completely wacky (wrong phase origin), as seen from output of hftout
This is because the image2000 software keeps a machine stamp in a location that was previously reserved for the origin
Specifically, header location 54 and 55 were previously designated for the xorigin and yorigin, respectively. These locations have now been reassigned.
Note that the changes above have now resolved this situation and the newer (image2000) fftrans should be used
Following are from the file "image.doc" from the older and newer release of MRC software:

older image.doc

25 EXTRA Extra, user defined storage space. 29 words max.
. "
. "
. " (all set to zero by default)
. "
53 "
54 XORIGIN X origin
55 YORIGIN Y origin
56 NLABL Number of labels being used

newer image.doc (released with image2000)

* 25-49 EXTRA extra space used for anything - 0 by default *
* 50-52 ORIGIN origin in X,Y,Z used for transforms *
* 53 MAP character string 'MAP ' to identify file type *
* 54 MACHST machine stamp *
* 55 RMS rms deviation of map from mean density *
* 56 NLABL number of labels being used *

Compiling libraries

General strategy for creating these libraries

• • cd compile go into temp directory
  • unzip ../XX.zip extract source files from zip file
  • gcc -c -O -I../ *.c ! compile source files
  • ar rvf XX.a *.o ! create object library
  • mv XX.a .. ! put library into main directory
  • rm *.c *.o clean up
• So far: mrc.a, ccf.a, hlxq.a, ctfft.a, img.a, ctsys.a, graph.a, graph-prjplt
  • img.a contains object files from img.zip, boxmask.zip and vector.zip
  • hlxq.a contains object files from hlxq.zip and hlx.zip

• todo: pltulib.a, pltctfx.a, nrc.a, graphn.a ctf.a, cmath.a

Size of long integers (major bug)

The long integers were used extensively in MRC file handling routines stored in mrc.zip (and mrc.a). e.g., openmrcf.c. Also, structure elements defined in mrc.h and imgn.h. Under the old system, both long integers and integers were 4 bytes long (check this using sizeof(int) and sizeof(long) c functions). Under new system, long integers were 8 bytes and integers were 4 bytes:

• • at NYSBC under Centos 5, 64 bit machine

• • at NYU under Fedora Core 4, 32-bit machine

Compilation problems under Centos5

undefined builtin functions

The compiler with glibc-2.5-24 (Centos 5) are picker than the compiler with glibc-2.3.6-3 (Fedora Core 4).
To get rid of warnings about redefinition of builtin functions, I had to explicitly:

• • #include <string.h>
  • #include <stdlib.h>
  • #include <stdio.h>

no newline at end of file

• • added new line at the end of many files to suppress this warning message

order of functions in files

• • had to move functions from the bottom of the file up to the top of the file in several cases. This was apparently because the main function was calling a secondary function, but the declarations weren't being handled correctly.

Problematic source modules

• sqsumtbl from ccf.zip
  • compile sqsumtbl with -g flag, otherwise imgccf crashes
  • not tested extensively

• now() function declaration
  • segmentation fault in imgccf and also mrccut was due to now() function. This was fixed with declaration
    • char *now();
  • this will likely show up in other programs
  • actually, this may just require recompilation of code - also showed up in cgraph.c

• a couple of unresolved, but unimportant, issues
  • rfshffl.c from ctfft.zip gives two errors, which are acknowledged in the header of the source file
  • strstr.c and toupper.c left out of ctsys.a - these functions should be builtin <string.h>
    • strstr.c gave errors, toupper is just redundant, modf also seems redundant and gave warning
  • putdotsq.c in img.zip gives warning, which is stupid and can be ignored
    • unsigned char mode
    • if (mode > 255) ! well, mode cannot be greater than 255 if it is an unsigned char!

• graph and graph-prjplt
  • had to reorder several of the source modules with static declarations to put them at the front of the file (cgraph, pshandler)
  • put new line at the end of some files
  • randtbli.c - was modified to declare a dummy integer rather than use a scalar
  • a few routines did not compile

• Set ALLOWTOPICVIEW =

-- DavidStokes - 27 Nov 2008

FFTRANS

Below issue is now fixed at NYSBC. This required recompiling several programs to take into account the new position of the origin in the MRC header.

• hlxfl.f (unwin): simply changed the IRTORG call to include 3 parameters (XOR,YOR,ZOR) and recompiled with image2000 libraries
• hlxs_threshold.f (rice): same as hlxfl
• openmrcf.c (koji): changed the location of the origin to start at byte 49 (c arrays start at zero) and added this modified routine to mrc.a
• hlxs (koji): simply recompiled using new openmrcf.o
• hftout (koji) same as hlxs
• hlxflk (koji): same as hlxs (THIS IS CURRENTLY UNTESTED)

Previous to these repairs and recompilations (e.g. implementation at NYU), the following fix has been applied:
hft, must use older version of fftrans - pre image2000 - we call this fftrans.old
If new fftrans is used, then the phases are completely wacky (wrong phase origin), as seen from output of hftout
This is because the image2000 software keeps a machine stamp in a location that was previously reserved for the origin
Specifically, header location 54 and 55 were previously designated for the xorigin and yorigin, respectively. These locations have now been reassigned.
Note that the changes above have now resolved this situation and the newer (image2000) fftrans should be used
Following are from the file "image.doc" from the older and newer release of MRC software:

older image.doc

25 EXTRA Extra, user defined storage space. 29 words max.
. "
. "
. " (all set to zero by default)
. "
53 "
54 XORIGIN X origin
55 YORIGIN Y origin
56 NLABL Number of labels being used

newer image.doc (released with image2000)

* 25-49 EXTRA extra space used for anything - 0 by default *
* 50-52 ORIGIN origin in X,Y,Z used for transforms *
* 53 MAP character string 'MAP ' to identify file type *
* 54 MACHST machine stamp *
* 55 RMS rms deviation of map from mean density *
* 56 NLABL number of labels being used *

Compiling libraries

General strategy for creating these libraries

• • cd compile go into temp directory
  • unzip ../XX.zip extract source files from zip file
  • gcc -c -O -I../ *.c ! compile source files
  • ar rvf XX.a *.o ! create object library
  • mv XX.a .. ! put library into main directory
  • rm *.c *.o clean up
• So far: mrc.a, ccf.a, hlxq.a, ctfft.a, img.a, ctsys.a, graph.a, graph-prjplt
  • img.a contains object files from img.zip, boxmask.zip and vector.zip

• todo: pltulib.a, pltctfx.a, nrc.a, graphn.a ctf.a, cmath.a

Size of long integers (major bug)

The long integers were used extensively in MRC file handling routines stored in mrc.zip (and mrc.a). e.g., openmrcf.c. Also, structure elements defined in mrc.h and imgn.h. Under the old system, both long integers and integers were 4 bytes long (check this using sizeof(int) and sizeof(long) c functions). Under new system, long integers were 8 bytes and integers were 4 bytes:

• • at NYSBC under Centos 5, 64 bit machine

• • at NYU under Fedora Core 4, 32-bit machine

Compilation problems under Centos5

undefined builtin functions

The compiler with glibc-2.5-24 (Centos 5) are picker than the compiler with glibc-2.3.6-3 (Fedora Core 4).
To get rid of warnings about redefinition of builtin functions, I had to explicitly:

• • #include <string.h>
  • #include <stdlib.h>
  • #include <stdio.h>

no newline at end of file

• • added new line at the end of many files to suppress this warning message

order of functions in files

• • had to move functions from the bottom of the file up to the top of the file in several cases. This was apparently because the main function was calling a secondary function, but the declarations weren't being handled correctly.

Problematic source modules

• sqsumtbl from ccf.zip
  • compile sqsumtbl with -g flag, otherwise imgccf crashes
  • not tested extensively

• now() function declaration
  • segmentation fault in imgccf and also mrccut was due to now() function. This was fixed with declaration
    • char *now();
  • this will likely show up in other programs
  • actually, this may just require recompilation of code - also showed up in cgraph.c

• a couple of unresolved, but unimportant, issues
  • rfshffl.c from ctfft.zip gives two errors, which are acknowledged in the header of the source file
  • strstr.c and toupper.c left out of ctsys.a - these functions should be builtin <string.h>
    • strstr.c gave errors, toupper is just redundant, modf also seems redundant and gave warning
  • putdotsq.c in img.zip gives warning, which is stupid and can be ignored
    • unsigned char mode
    • if (mode > 255) ! well, mode cannot be greater than 255 if it is an unsigned char!

• graph and graph-prjplt
  • had to reorder several of the source modules with static declarations to put them at the front of the file (cgraph, pshandler)
  • put new line at the end of some files
  • randtbli.c - was modified to declare a dummy integer rather than use a scalar
  • a few routines did not compile

• Set ALLOWTOPICVIEW =

-- DavidStokes - 27 Nov 2008

FFTRANS

Below issue is now fixed at NYSBC. This required recompiling several programs to take into account the new position of the origin in the MRC header.

• hlxfl.f (unwin): simply changed the IRTORG call to include 3 parameters (XOR,YOR,ZOR) and recompiled with image2000 libraries
• hlxs_threshold.f (rice): same as hlxfl
• openmrcf.c (koji): changed the location of the origin to start at byte 49 (c arrays start at zero) and added this modified routine to mrc.a
• hlxs (koji): simply recompiled using new openmrcf.o
• hftout (koji) same as hlxs
• hlxflk (koji): same as hlxs (THIS IS CURRENTLY UNTESTED)

Previous to these repairs and recompilations (e.g. implementation at NYU), the following fix has been applied:
hft, must use older version of fftrans - pre image2000 - we call this fftrans.old
If new fftrans is used, then the phases are completely wacky (wrong phase origin), as seen from output of hftout
This is because the image2000 software keeps a machine stamp in a location that was previously reserved for the origin

older image.doc

25 EXTRA Extra, user defined storage space. 29 words max.
. "
. "
. " (all set to zero by default)
. "
53 "
54 XORIGIN X origin
55 YORIGIN Y origin
56 NLABL Number of labels being used

newer image.doc (released with image2000)

* 25-49 EXTRA extra space used for anything - 0 by default *
* 50-52 ORIGIN origin in X,Y,Z used for transforms *
* 53 MAP character string 'MAP ' to identify file type *
* 54 MACHST machine stamp *
* 55 RMS rms deviation of map from mean density *
* 56 NLABL number of labels being used *

Compiling libraries

General strategy for creating these libraries

• • cd compile go into temp directory
  • unzip ../XX.zip extract source files from zip file
  • gcc -c -O -I../ *.c ! compile source files
  • ar rvf XX.a *.o ! create object library
  • mv XX.a .. ! put library into main directory
  • rm *.c *.o clean up
• So far: mrc.a, ccf.a, hlxq.a, ctfft.a, img.a, ctsys.a, graph.a, graph-prjplt
  • img.a contains object files from img.zip, boxmask.zip and vector.zip

• todo: pltulib.a, pltctfx.a, nrc.a, graphn.a ctf.a, cmath.a

Size of long integers (major bug)

The long integers were used extensively in MRC file handling routines stored in mrc.zip (and mrc.a). e.g., openmrcf.c. Also, structure elements defined in mrc.h and imgn.h. Under the old system, both long integers and integers were 4 bytes long (check this using sizeof(int) and sizeof(long) c functions). Under new system, long integers were 8 bytes and integers were 4 bytes:

• • at NYSBC under Centos 5, 64 bit machine

• • at NYU under Fedora Core 4, 32-bit machine

Compilation problems under Centos5

undefined builtin functions

The compiler with glibc-2.5-24 (Centos 5) are picker than the compiler with glibc-2.3.6-3 (Fedora Core 4).
To get rid of warnings about redefinition of builtin functions, I had to explicitly:

• • #include <string.h>
  • #include <stdlib.h>
  • #include <stdio.h>

no newline at end of file

• • added new line at the end of many files to suppress this warning message

order of functions in files

• • had to move functions from the bottom of the file up to the top of the file in several cases. This was apparently because the main function was calling a secondary function, but the declarations weren't being handled correctly.

Problematic source modules

• sqsumtbl from ccf.zip
  • compile sqsumtbl with -g flag, otherwise imgccf crashes
  • not tested extensively

• now() function declaration
  • segmentation fault in imgccf and also mrccut was due to now() function. This was fixed with declaration
    • char *now();
  • this will likely show up in other programs
  • actually, this may just require recompilation of code - also showed up in cgraph.c

• a couple of unresolved, but unimportant, issues
  • rfshffl.c from ctfft.zip gives two errors, which are acknowledged in the header of the source file
  • strstr.c and toupper.c left out of ctsys.a - these functions should be builtin <string.h>
    • strstr.c gave errors, toupper is just redundant, modf also seems redundant and gave warning
  • putdotsq.c in img.zip gives warning, which is stupid and can be ignored
    • unsigned char mode
    • if (mode > 255) ! well, mode cannot be greater than 255 if it is an unsigned char!

• graph and graph-prjplt
  • had to reorder several of the source modules with static declarations to put them at the front of the file (cgraph, pshandler)
  • put new line at the end of some files
  • randtbli.c - was modified to declare a dummy integer rather than use a scalar
  • a few routines did not compile

• Set ALLOWTOPICVIEW =

-- DavidStokes - 27 Nov 2008

FFTRANS

Below issue is now fixed at NYSBC. This required recompiling several programs to take into account the new position of the origin in the MRC header.

• hlxfl.f (unwin): simply changed the IRTORG call to include 3 parameters (XOR,YOR,ZOR) and recompiled with image2000 libraries
• hlxs_threshold.f (rice): same as hlxfl
• openmrcf.c (koji): changed the location of the origin to start at byte 49 (c arrays start at zero) and added this modified routine to mrc.a
• hlxs (koji): simply recompiled using new openmrcf.o
• hftout (koji) same as hlxs
• hlxflk (koji): same as hlxs (THIS IS CURRENTLY UNTESTED)

older image.doc

25 EXTRA Extra, user defined storage space. 29 words max.
. "
. "
. " (all set to zero by default)
. "
53 "
54 XORIGIN X origin
55 YORIGIN Y origin
56 NLABL Number of labels being used

newer image.doc (released with image2000)

* 25-49 EXTRA extra space used for anything - 0 by default *
* 50-52 ORIGIN origin in X,Y,Z used for transforms *
* 53 MAP character string 'MAP ' to identify file type *
* 54 MACHST machine stamp *
* 55 RMS rms deviation of map from mean density *
* 56 NLABL number of labels being used *

Compiling libraries

General strategy for creating these libraries

• • cd compile go into temp directory
  • unzip ../XX.zip extract source files from zip file
  • gcc -c -O -I../ *.c ! compile source files
  • ar rvf XX.a *.o ! create object library
  • mv XX.a .. ! put library into main directory
  • rm *.c *.o clean up
• So far: mrc.a, ccf.a, hlxq.a, ctfft.a, img.a, ctsys.a, graph.a, graph-prjplt
  • img.a contains object files from img.zip, boxmask.zip and vector.zip

• todo: pltulib.a, pltctfx.a, nrc.a, graphn.a ctf.a, cmath.a

Size of long integers (major bug)

The long integers were used extensively in MRC file handling routines stored in mrc.zip (and mrc.a). e.g., openmrcf.c. Also, structure elements defined in mrc.h and imgn.h. Under the old system, both long integers and integers were 4 bytes long (check this using sizeof(int) and sizeof(long) c functions). Under new system, long integers were 8 bytes and integers were 4 bytes:

• • at NYSBC under Centos 5, 64 bit machine

• • at NYU under Fedora Core 4, 32-bit machine

Compilation problems under Centos5

undefined builtin functions

The compiler with glibc-2.5-24 (Centos 5) are picker than the compiler with glibc-2.3.6-3 (Fedora Core 4).
To get rid of warnings about redefinition of builtin functions, I had to explicitly:

• • #include <string.h>
  • #include <stdlib.h>
  • #include <stdio.h>

no newline at end of file

• • added new line at the end of many files to suppress this warning message

order of functions in files

• • had to move functions from the bottom of the file up to the top of the file in several cases. This was apparently because the main function was calling a secondary function, but the declarations weren't being handled correctly.

Problematic source modules

• sqsumtbl from ccf.zip
  • compile sqsumtbl with -g flag, otherwise imgccf crashes
  • not tested extensively

• now() function declaration
  • segmentation fault in imgccf and also mrccut was due to now() function. This was fixed with declaration
    • char *now();
  • this will likely show up in other programs
  • actually, this may just require recompilation of code - also showed up in cgraph.c

• a couple of unresolved, but unimportant, issues
  • rfshffl.c from ctfft.zip gives two errors, which are acknowledged in the header of the source file
  • strstr.c and toupper.c left out of ctsys.a - these functions should be builtin <string.h>
    • strstr.c gave errors, toupper is just redundant, modf also seems redundant and gave warning
  • putdotsq.c in img.zip gives warning, which is stupid and can be ignored
    • unsigned char mode
    • if (mode > 255) ! well, mode cannot be greater than 255 if it is an unsigned char!

• graph and graph-prjplt
  • had to reorder several of the source modules with static declarations to put them at the front of the file (cgraph, pshandler)
  • put new line at the end of some files
  • randtbli.c - was modified to declare a dummy integer rather than use a scalar
  • a few routines did not compile

• Set ALLOWTOPICVIEW =

-- DavidStokes - 27 Nov 2008

FFTRANS

Below issue is now fixed at NYSBC. This required recompiling several programs to take into account the new position of the origin in the MRC header.

• hlxfl.f (unwin): simply changed the IRTORG call to include 3 parameters (XOR,YOR,ZOR) and recompiled with image2000 libraries
• hlxs_threshold.f (rice): same as hlxfl
• openmrcf.c (koji): changed the location of the origin to start at byte 49 (c arrays start at zero) and added this modified routine to mrc.a
• hlxs (koji): simply recompiled using new openmrcf.o
• hftout (koji) same as hlxs
• hlxflk (koji): same as hlxs (THIS IS CURRENTLY UNTESTED)

older image.doc

25 EXTRA Extra, user defined storage space. 29 words max.
. "
. "
. " (all set to zero by default)
. "
53 "
54 XORIGIN X origin
55 YORIGIN Y origin
56 NLABL Number of labels being used

newer image.doc (released with image2000)

* 25-49 EXTRA extra space used for anything - 0 by default *
* 50-52 ORIGIN origin in X,Y,Z used for transforms *
* 53 MAP character string 'MAP ' to identify file type *
* 54 MACHST machine stamp *
* 55 RMS rms deviation of map from mean density *
* 56 NLABL number of labels being used *

Compiling libraries

General strategy for creating these libraries

• • cd compile go into temp directory
  • unzip ../XX.zip extract source files from zip file
  • gcc -c -O -I../ *.c ! compile source files
  • ar rvf XX.a *.o ! create object library
  • mv XX.a .. ! put library into main directory
  • rm *.c *.o clean up
• So far: mrc.a, ccf.a, hlxq.a, ctfft.a, img.a, ctsys.a, graph.a, graph-prjplt
  • img.a contains object files from img.zip, boxmask.zip and vector.zip

• todo: pltulib.a, pltctfx.a, nrc.a, graphn.a ctf.a, cmath.a

Size of long integers (major bug)

The long integers were used extensively in MRC file handling routines stored in mrc.zip (and mrc.a). e.g., openmrcf.c. Also, structure elements defined in mrc.h and imgn.h. Under the old system, both long integers and integers were 4 bytes long (check this using sizeof(int) and sizeof(long) c functions). Under new system, long integers were 8 bytes and integers were 4 bytes:

• • at NYSBC under Centos 5, 64 bit machine

• • at NYU under Fedora Core 4, 32-bit machine

Compilation problems under Centos5

undefined builtin functions

The compiler with glibc-2.5-24 (Centos 5) are picker than the compiler with glibc-2.3.6-3 (Fedora Core 4).
To get rid of warnings about redefinition of builtin functions, I had to explicitly:

• • #include <string.h>
  • #include <stdlib.h>
  • #include <stdio.h>

no newline at end of file

• • added new line at the end of many files to suppress this warning message

order of functions in files

• • had to move functions from the bottom of the file up to the top of the file in several cases. This was apparently because the main function was calling a secondary function, but the declarations weren't being handled correctly.

Problematic source modules

• sqsumtbl from ccf.zip
  • compile sqsumtbl with -g flag, otherwise imgccf crashes
  • not tested extensively

• now() function declaration
  • segmentation fault in imgccf and also mrccut was due to now() function. This was fixed with declaration
    • char *now();
  • this will likely show up in other programs
  • actually, this may just require recompilation of code - also showed up in cgraph.c

• a couple of unresolved, but unimportant, issues
  • rfshffl.c from ctfft.zip gives two errors, which are acknowledged in the header of the source file
  • strstr.c and toupper.c left out of ctsys.a - these functions should be builtin <string.h>
    • strstr.c gave errors, toupper is just redundant, modf also seems redundant and gave warning
  • putdotsq.c in img.zip gives warning, which is stupid and can be ignored
    • unsigned char mode
    • if (mode > 255) ! well, mode cannot be greater than 255 if it is an unsigned char!

• graph and graph-prjplt
  • had to reorder several of the source modules with static declarations to put them at the front of the file (cgraph, pshandler)
  • put new line at the end of some files
  • randtbli.c - was modified to declare a dummy integer rather than use a scalar
  • a few routines did not compile

• Set ALLOWTOPICVIEW =

-- DavidStokes - 27 Nov 2008

FFTRANS

Below issue is now fixed at NYSBC. This required recompiling several programs to take into account the new position of the origin in the MRC header.

• hlxfl.f (unwin): simply changed the IRTORG call to include 3 parameters (XOR,YOR,ZOR) and recompiled with image2000 libraries
• hlxs_threshold.f (rice): same as hlxfl
• openmrcf.c (koji): changed the location of the origin to start at byte 49 (c arrays start at zero) and added this modified routine to mrc.a
• hlxs (koji): simply recompiled using new openmrcf.o
• hftout (koji) same as hlxs
• hlxflk (koji): same as hlxs (THIS IS CURRENTLY UNTESTED)

For hft, must use older version of fftrans - pre image2000 - we call this fftrans.old
If new fftrans is used, then the phases are completely wacky (wrong phase origin), as seen from output of hftout
This is because the image2000 software keeps a machine stamp in a location that was previously reserved for the origin
Specifically, header location 54 and 55 were previously designated for the xorigin and yorigin, respectively. These locations have now been reassigned. Following are from the file "image.doc" from the older and newer release of MRC software:

older image.doc

25 EXTRA Extra, user defined storage space. 29 words max.
. "
. "
. " (all set to zero by default)
. "
53 "
54 XORIGIN X origin
55 YORIGIN Y origin
56 NLABL Number of labels being used

newer image.doc (released with image2000)

* 25-49 EXTRA extra space used for anything - 0 by default *
* 50-52 ORIGIN origin in X,Y,Z used for transforms *
* 53 MAP character string 'MAP ' to identify file type *
* 54 MACHST machine stamp *
* 55 RMS rms deviation of map from mean density *
* 56 NLABL number of labels being used *

Compiling libraries

General strategy for creating these libraries

• • cd compile go into temp directory
  • unzip ../XX.zip extract source files from zip file
  • gcc -c -O -I../ *.c ! compile source files
  • ar rvf XX.a *.o ! create object library
  • mv XX.a .. ! put library into main directory
  • rm *.c *.o clean up

• • img.a contains object files from img.zip, boxmask.zip and vector.zip

Size of long integers (major bug)

The long integers were used extensively in MRC file handling routines stored in mrc.zip (and mrc.a). e.g., openmrcf.c. Also, structure elements defined in mrc.h and imgn.h. Under the old system, both long integers and integers were 4 bytes long (check this using sizeof(int) and sizeof(long) c functions). Under new system, long integers were 8 bytes and integers were 4 bytes:

• • at NYSBC under Centos 5, 64 bit machine

• • at NYU under Fedora Core 4, 32-bit machine

Compilation problems under Centos5

undefined builtin functions

The compiler with glibc-2.5-24 (Centos 5) are picker than the compiler with glibc-2.3.6-3 (Fedora Core 4).
To get rid of warnings about redefinition of builtin functions, I had to explicitly:

• • #include <string.h>
  • #include <stdlib.h>
  • #include <stdio.h>

no newline at end of file

• • added new line at the end of many files to suppress this warning message

order of functions in files

• • had to move functions from the bottom of the file up to the top of the file in several cases. This was apparently because the main function was calling a secondary function, but the declarations weren't being handled correctly.

Problematic source modules

• sqsumtbl from ccf.zip
  • compile sqsumtbl with -g flag, otherwise imgccf crashes
  • not tested extensively

• now() function declaration
  • segmentation fault in imgccf and also mrccut was due to now() function. This was fixed with declaration
    • char *now();
  • this will likely show up in other programs

• a couple of unresolved, but unimportant, issues
  • rfshffl.c from ctfft.zip gives two errors, which are acknowledged in the header of the source file
  • strstr.c and toupper.c left out of ctsys.a - these functions should be builtin <string.h>
    • strstr.c gave errors, toupper is just redundant, modf also seems redundant and gave warning
  • putdotsq.c in img.zip gives warning, which is stupid and can be ignored
    • unsigned char mode
    • if (mode > 255) ! well, mode cannot be greater than 255 if it is an unsigned char!

• Set ALLOWTOPICVIEW =

-- DavidStokes - 27 Nov 2008

FFTRANS

older image.doc

25 EXTRA Extra, user defined storage space. 29 words max.
. "
. "
. " (all set to zero by default)
. "
53 "
54 XORIGIN X origin
55 YORIGIN Y origin
56 NLABL Number of labels being used

newer image.doc (released with image2000)

* 25-49 EXTRA extra space used for anything - 0 by default *
* 50-52 ORIGIN origin in X,Y,Z used for transforms *
* 53 MAP character string 'MAP ' to identify file type *
* 54 MACHST machine stamp *
* 55 RMS rms deviation of map from mean density *
* 56 NLABL number of labels being used *

Compiling libraries

General strategy for creating these libraries

• • cd compile go into temp directory
  • unzip ../XX.zip extract source files from zip file
  • gcc -c -O -I../ *.c ! compile source files
  • ar rvf XX.a *.o ! create object library
  • mv XX.a .. ! put library into main directory
  • rm *.c *.o clean up
• So far: mrc.a, ccf.a, hlxq.a, ctfft.a, img.a, ctsys.a
  • img.a contains object files from img.zip, boxmask.zip and vector.zip
• todo: graph-prjplt.a, graph.a, pltulib.a, pltctfx.a, nrc.a, graphn.a ctf.a, cmath.a

Size of long integers (major bug)

The long integers were used extensively in MRC file handling routines stored in mrc.zip (and mrc.a). e.g., openmrcf.c. Also, structure elements defined in mrc.h and imgn.h. Under the old system, both long integers and integers were 4 bytes long (check this using sizeof(int) and sizeof(long) c functions). Under new system, long integers were 8 bytes and integers were 4 bytes:

• • at NYSBC under Centos 5, 64 bit machine

• • at NYU under Fedora Core 4, 32-bit machine

Compilation problems under Centos5

undefined builtin functions

The compiler with glibc-2.5-24 (Centos 5) are picker than the compiler with glibc-2.3.6-3 (Fedora Core 4).
To get rid of warnings about redefinition of builtin functions, I had to explicitly:

• • #include <string.h>
  • #include <stdlib.h>
  • #include <stdio.h>

no newline at end of file

• • added new line at the end of many files to suppress this warning message

order of functions in files

• • had to move functions from the bottom of the file up to the top of the file in several cases. This was apparently because the main function was calling a secondary function, but the declarations weren't being handled correctly.

Problematic source modules

• sqsumtbl from ccf.zip
  • compile sqsumtbl with -g flag, otherwise imgccf crashes
  • not tested extensively

• now() function declaration
  • segmentation fault in imgccf and also mrccut was due to now() function. This was fixed with declaration
    • char *now();
  • this will likely show up in other programs

• a couple of unresolved, but unimportant, issues
  • rfshffl.c from ctfft.zip gives two errors, which are acknowledged in the header of the source file
  • strstr.c and toupper.c left out of ctsys.a - these functions should be builtin <string.h>
    • strstr.c gave errors, toupper is just redundant, modf also seems redundant and gave warning
  • putdotsq.c in img.zip gives warning, which is stupid and can be ignored
    • unsigned char mode
    • if (mode > 255) ! well, mode cannot be greater than 255 if it is an unsigned char!

• Set ALLOWTOPICVIEW =

-- DavidStokes - 27 Nov 2008

FFTRANS

older image.doc

25 EXTRA Extra, user defined storage space. 29 words max.
. "
. "
. " (all set to zero by default)
. "
53 "
54 XORIGIN X origin
55 YORIGIN Y origin
56 NLABL Number of labels being used

newer image.doc (released with image2000)

* 25-49 EXTRA extra space used for anything - 0 by default *
* 50-52 ORIGIN origin in X,Y,Z used for transforms *
* 53 MAP character string 'MAP ' to identify file type *
* 54 MACHST machine stamp *
* 55 RMS rms deviation of map from mean density *
* 56 NLABL number of labels being used *

Compiling libraries

General strategy for creating these libraries

• • cd compile go into temp directory
  • unzip ../XX.zip extract source files from zip file
  • gcc -c -O -I../ *.c ! compile source files
  • ar rvf XX.a *.o ! create object library
  • mv XX.a .. ! put library into main directory
  • rm *.c *.o clean up
• So far: mrc.a, ccf.a, hlxq.a, ctfft.a, img.a, ctsys.a
  • img.a contains object files from img.zip, boxmask.zip and vector.zip
• todo: graph-prjplt.a, graph.a, pltulib.a, pltctfx.a, nrc.a, graphn.a ctf.a, cmath.a

Size of long integers (major bug)

The long integers were used extensively in MRC file handling routines stored in mrc.zip (and mrc.a). e.g., openmrcf.c. Also, structure elements defined in mrc.h and imgn.h. Under the old system, both long integers and integers were 4 bytes long (check this using sizeof(int) and sizeof(long) c functions). Under new system, long integers were 8 bytes and integers were 4 bytes:

• • at NYSBC under Centos 5, 64 bit machine

• • at NYU under Fedora Core 4, 32-bit machine

Compilation problems under Centos5

undefined builtin functions

The compiler with glibc-2.5-24 (Centos 5) are picker than the compiler with glibc-2.3.6-3 (Fedora Core 4).
To get rid of warnings about redefinition of builtin functions, I had to explicitly:

• • #include <string.h>
  • #include <stdlib.h>
  • #include <stdio.h>

no newline at end of file

• • added new line at the end of many files to suppress this warning message

order of functions in files

• • had to move functions from the bottom of the file up to the top of the file in several cases. This was apparently because the main function was calling a secondary function, but the declarations weren't being handled correctly.

Problematic source modules

• sqsumtbl from ccf.zip
  • compile sqsumtbl with -g flag, otherwise imgccf crashes
  • not tested extensively

• now() function declaration
  • segmentation fault in imgccf and also mrccut was due to now() function. This was fixed with declaration
    • char *now();
  • this will likely show up in other programs

• a couple of unresolved, but unimportant, issues
  • rfshffl.c from ctfft.zip gives two errors, which are acknowledged in the header of the source file
  • strstr.c and toupper.c left out of ctsys.a - these functions should be builtin <string.h>
    • strstr.c gave errors, toupper is just redundant, modf also seems redundant and gave warning
  • putdotsq.c in img.zip gives warning, which is stupid and can be ignored
    • unsigned char mode
    • if (mode > 255) ! well, mode cannot be greater than 255 if it is an unsigned char!

• Set ALLOWTOPICVIEW =

-- DavidStokes - 27 Nov 2008

Notes on Compiling and Using Helical Reconstruction Programs from Toyoshima Lab

FFTRANS

Must use older version of fftrans - pre image2000
If not, then the phases are completely wacky (wrong phase origin), as seen from output of hftout
This is because the image2000 software keeps a machine stamp in a location that was previously reserved for the origin
Specifically, header location 54 and 55 were previously designated for the xorigin and yorigin, respectively. These locations have now been reassigned. Following are from the file "image.doc" from the older and newer release of MRC software:

older image.doc

25 EXTRA Extra, user defined storage space. 29 words max.
. "
. "
. " (all set to zero by default)
. "
53 "
54 XORIGIN X origin
55 YORIGIN Y origin
56 NLABL Number of labels being used

newer image.doc (released with image2000)

* 25-49 EXTRA extra space used for anything - 0 by default *
* 50-52 ORIGIN origin in X,Y,Z used for transforms *
* 53 MAP character string 'MAP ' to identify file type *
* 54 MACHST machine stamp *
* 55 RMS rms deviation of map from mean density *
* 56 NLABL number of labels being used *

Compiling libraries

General strategy for creating these libraries

• • cd compile go into temp directory
  • unzip ../XX.zip extract source files from zip file
  • gcc -c -O -I../ *.c ! compile source files
  • ar rvf XX.a *.o ! create object library
  • mv XX.a .. ! put library into main directory
  • rm *.c *.o clean up
• So far: mrc.a, ccf.a, hlxq.a, ctfft.a, img.a, ctsys.a
  • img.a contains object files from img.zip, boxmask.zip and vector.zip
• todo: graph-prjplt.a, graph.a, pltulib.a, pltctfx.a, nrc.a, graphn.a ctf.a, cmath.a

Size of long integers (major bug)

The long integers were used extensively in MRC file handling routines stored in mrc.zip (and mrc.a). e.g., openmrcf.c. Also, structure elements defined in mrc.h and imgn.h. Under the old system, both long integers and integers were 4 bytes long (check this using sizeof(int) and sizeof(long) c functions). Under new system, long integers were 8 bytes and integers were 4 bytes:

• • at NYSBC under Centos 5, 64 bit machine

• • at NYU under Fedora Core 4, 32-bit machine

Compilation problems under Centos5

undefined builtin functions

The compiler with glibc-2.5-24 (Centos 5) are picker than the compiler with glibc-2.3.6-3 (Fedora Core 4).
To get rid of warnings about redefinition of builtin functions, I had to explicitly:

• • #include <string.h>
  • #include <stdlib.h>
  • #include <stdio.h>

no newline at end of file

• • added new line at the end of many files to suppress this warning message

order of functions in files

• • had to move functions from the bottom of the file up to the top of the file in several cases. This was apparently because the main function was calling a secondary function, but the declarations weren't being handled correctly.

Problematic source modules

• sqsumtbl from ccf.zip
  • compile sqsumtbl with -g flag, otherwise imgccf crashes
  • not tested extensively

• now() function declaration
  • segmentation fault in imgccf and also mrccut was due to now() function. This was fixed with declaration
    • char *now();
  • this will likely show up in other programs

• a couple of unresolved, but unimportant, issues
  • rfshffl.c from ctfft.zip gives two errors, which are acknowledged in the header of the source file
  • strstr.c and toupper.c left out of ctsys.a - these functions should be builtin <string.h>
    • strstr.c gave errors, toupper is just redundant, modf also seems redundant and gave warning
  • putdotsq.c in img.zip gives warning, which is stupid and can be ignored
    • unsigned char mode
    • if (mode > 255) ! well, mode cannot be greater than 255 if it is an unsigned char!

• Set ALLOWTOPICVIEW =

-- DavidStokes - 27 Nov 2008