removed unnecessary files

CMakeLists.txt

-cmake_minimum_required(VERSION 2.6)
-project(BioEM)
-
-###Set up options
-option (USE_CUDA "Build BioEM with CUDA support" OFF)
-option (USE_OPENMP "Build BioEM with OpenMP support" ON)
-option (USE_MPI "Build BioEM with MPI support" ON)
-option (PRINT_CMAKE_VARIABLES "List all CMAKE Variables" OFF)
-option (CUDA_FORCE_GCC "Force GCC as host compiler for CUDA part (If standard host compiler is incompatible with CUDA)" ON)
-
-###Set up general variables
-set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CMAKE_SOURCE_DIR}/cmake/Modules/")
-set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CMAKE_SOURCE_DIR}")
-
-include_directories(include)
-
-set (BIOEM_ICC_FLAGS "-xHost -O3 -fno-alias -fno-fnalias -unroll -g0 -ipo")
-set (BIOEM_GCC_FLAGS "-O3 -march=native -fweb -mfpmath=sse -frename-registers -minline-all-stringops -ftracer -funroll-loops -fpeel-loops -fprefetch-loop-arrays -ffast-math -ggdb")
-
-if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Intel")
-        set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${BIOEM_ICC_FLAGS}")
-else()
-        set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${BIOEM_GCC_FLAGS}")
-endif()
-
-set (BIOEM_SOURCE_FILES "bioem.cpp" "main.cpp" "map.cpp" "model.cpp" "param.cpp" "timer.cpp")
-
-###Find Required Packages
-find_package(PkgConfig)
-if (PKG_CONFIG_FOUND)
-    pkg_check_modules(FFTW fftw3)
-endif()
-if (NOT FFTW_FOUND)
-    find_package(FFTW 3 REQUIRED)
-endif()
-include_directories(${FFTW_INCLUDE_DIRS})
-
-find_package(Boost 1.43 REQUIRED)
-include_directories(${Boost_INCLUDE_DIRS})
-
-###Find Optional Packages
-
-###Find CUDA
-set (BIOEM_CUDA_STATUS "Disabled")
-if (INCLUDE_CUDA)
-        set (BIOEM_CUDA_STATUS "Not Found")
-        find_package(CUDA)
-endif()
-
-if (CUDA_FOUND)
-        if (CUDA_FORCE_GCC)
-                cmake_minimum_required(VERSION 2.8.10.1)
-                #Use GCC as host compiler for CUDA even though host compiler for other files is not GCC
-                set (CUDA_HOST_COMPILER gcc)
-        endif()
-        set(CUDA_NVCC_FLAGS "${CUDA_NVCC_FLAGS};--use_fast_math;-ftz=true;-O4;-Xptxas -O4")
-
-#        list(APPEND CUDA_NVCC_FLAGS "-gencode=arch=compute_13,code=sm_13")
-        list(APPEND CUDA_NVCC_FLAGS "-gencode=arch=compute_20,code=sm_20")
-        list(APPEND CUDA_NVCC_FLAGS "-gencode=arch=compute_20,code=sm_21")
-        list(APPEND CUDA_NVCC_FLAGS "-gencode=arch=compute_30,code=sm_30")
-        list(APPEND CUDA_NVCC_FLAGS "-gencode=arch=compute_35,code=sm_35")
-        list(APPEND CUDA_NVCC_FLAGS "-gencode=arch=compute_52,code=sm_52")
-        add_definitions(-DWITH_CUDA)
-        set (BIOEM_CUDA_STATUS "Found")
-endif()
-
-###Find OpenMP
-set (BIOEM_OPENMP_STATUS "Disabled")
-if (INCLUDE_OPENMP)
-        set (BIOEM_OPENMP_STATUS "Not Found")
-        find_package(OpenMP)
-endif()
-
-if(OPENMP_FOUND)
-        set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS}")
-        add_definitions(-DWITH_OPENMP)
-        set (BIOEM_OPENMP_STATUS "Found")
-endif()
-
-###Find MPI
-set (BIOEM_MPI_STATUS "Disabled")
-if (INCLUDE_MPI)
-        set (BIOEM_MPI_STATUS "Not Found")
-        find_package(MPI)
-endif()
-
-if (MPI_FOUND)
-        include_directories(${MPI_INCLUDE_PATH})
-        set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${MPI_COMPILE_FLAGS} ${MPI_LINK_FLAGS}")
-        add_definitions(-DWITH_MPI)
-        set (BIOEM_MPI_STATUS "Found")
-endif()
-
-###Build Executable
-if (CUDA_FOUND)
-        set(BIOEM_TMP_CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
-        if (CUDA_FORCE_GCC)
-                #Hack to use GCC flags for GCC host compiler during NVCC compilation, although host compiler is in fact not GCC for other files
-                set(CMAKE_CXX_FLAGS ${BIOEM_GCC_FLAGS})
-        endif()
-        cuda_add_executable(bioEM ${BIOEM_SOURCE_FILES} bioem_cuda.cu)
-        set(CMAKE_CXX_FLAGS ${BIOEM_TMP_CMAKE_CXX_FLAGS})
-else()
-        add_executable(bioEM ${BIOEM_SOURCE_FILES})
-endif()
-
-#Additional CXX Flags not used by CUDA compiler
-#Additional CXX Flags not used by CUDA compiler
-if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Intel")
-        set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -Wall -pedantic")
-else()
-        set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-vla -Wno-long-long  -Wall -pedantic")
-endif()
-
-###Add Libraries
-if (CUDA_FOUND)
-        cuda_add_cufft_to_target(bioEM)
-#set(CUDA_LIBRARIES "/afs/ipp/.cs/cuda/6.5-gtx9/amd64_sles11/lib64/stubs/libcuda.so")
-#cuda_add_library() 
-        target_link_libraries(bioEM ${CUDA_CUDA_LIBRARY})
-#	  target_link_libraries(bioEM ${CUDA_LIBRARIES})
-endif()
-
-if (FFTWF_LIBRARIES)
-        target_link_libraries(bioEM ${FFTWF_LIBRARIES})
-else()
-        target_link_libraries(bioEM -L${FFTW_LIBDIR} -lfftw3 -lfftw3f)
-endif()
-target_link_libraries(bioEM -L${Boost_LIBRARY_DIRS} -lboost_program_options)
-
-if (MPI_FOUND)
-        target_link_libraries(bioEM ${MPI_LIBRARIES})
-endif()
-
-###Show Status
-message(STATUS "Build Status")
-message(STATUS "FFTW library: ${FFTW_LIBDIR}")
-message(STATUS "Boost directory: ${Boost_LIBRARY_DIRS}")
-message(STATUS "FFTW includedir: ${FFTW_INCLUDEDIR}")
-message(STATUS "CUDA libraries:  ${CUDA_CUDA_LIBRARY}")
-message(STATUS "CUDART libraries:  ${CUDA_LIBRARIES}")
-message(STATUS "CUDA: ${BIOEM_CUDA_STATUS}")
-message(STATUS "OpenMP: ${BIOEM_OPENMP_STATUS}")
-message(STATUS "MPI: ${BIOEM_MPI_STATUS}")
-
-if (PRINT_CMAKE_VARIABLES)
-        get_cmake_property(_variableNames VARIABLES)
-        foreach (_variableName ${_variableNames})
-                message(STATUS "${_variableName}=${${_variableName}}")
-        endforeach()
-endif()
-

OPTIONS

-BioEM has two sets of parameters:
-- One set describes the problem, like tjenumber of Pixels.
-  These parameters are specified in a file passed to BioEM via the --Inputfile command line option.
-- Another set describes the runtime configuration, which involves how to parallelize, whether to
-  use a GPU, and some other algorithmic settings. These parameters do not (or only slightly)
-  change the output, but have a large influence on the compute performance. They are passed to
-  BioEM via environment variables.
-
-The two sets are treated differently, because the first set is related to the actual problem, while
-the second set belongs to the compute node where the problem is processed. These runtime parameters
-should be tuned for every particular architecture where BioEM is executed.
-
-This document will explain the types of parallelization used within BioEM (1), list all relevant
-environment variables (2), and provide some suggestions for runtime configurations in different
-situations (3).
-
-1. Ways of parallelization
-BioEM compares various projections of a model to a set of reference maps.
-Technically, the model is first projected along a given angular orientation,
-then it is convoluted with a convolution kernel in Fourier space to cope with imaging artifacts,
-next it is shifted by a certain number of pixels to tread find the best position for a match,
-and finally this modified projection is compared to a reference map.
-
-From a computational complexity perspective, the comparison of a given projection and convolution
-with all the reference map is by far the most time consuming part. Calculating the projectiond and
-performing the convolution both make up for only 0-5% of the overall execution time (depending on
-the number of maps and convolution kernels).
-
-BioEM facilitates this task using an all to all comparison through a nested loop.
-- The outermost loop is over the orientations.
-- Next next loop goes over the different convolution kernels.
-- An inner loop runs over all maps.
-- And finally the innermost loop iterates over the shifts.
-
-This offers in principle four dimensions for parallelization. BioEM provides the following options:
-- MPI: Bioem can use MPI to parallelize over the orientations in the outermost loop. In this case
-  the probabilities for all reference maps / convolution kernels / shifts are calculated for a
-  certain subset of orientations by each MPI process. Afterward, the probabilities computed by
-  every  MPI process are reduced to the final probabilities. If started via 'mpirun', BioEM will
-  automatically distribute the orientations evenly among all MPI processes.
-- OpenMP: BioEM can use OpenMP to parallelize over the maps in the inner loop. As processing of
-  these maps is totally independent, there is no synchronization required at all. BioEM will
-  automatically multithread over the maps. The number of employed threads can be controlled with
-  the standard OMP_NUM_THREADS environment variable for OpenMP.
-- Graphics Processing Unites (GPUs): BioEM can use GPUs to speed up the processing. In this case,
-  the inner loop over all maps with all shifts is processed by the GPU in one step with
-  parallelization over the maps. The projections and the convolutions are still processed by the
-  CPU. This process is pipelined such that the CPU prepares the next projections and convolutions
-  while the GPU calculates the probabilities for all maps and for the previous projection and
-  convolution. Hence this is a horizontal parallelization layer among the maps with an additional
-  vertical layer through the pipeline. Usage of GPUs must be enabled with the GPU=1 environment
-  variable. One BioEM process will always only use one GPU, by default the fastest one. A GPU
-  device can be explicitly configured with the GPUDEVICE=[x] environment variable. Multiple GPUs
-  can be used through MPI. In this case every GPU will process all maps but calculate the
-  probabilities only for a subset of the orientations (see description of MPI above). Selection
-  of GPU devices for each MPI processed must be carried out by:
-   * Either the scheduler must mask all GPUs but one, such that the MPI processes sees only 1
-     GPU device.
-   * Or the GPUDEVICE=[x] environment variable must be set differently for each MPI process.
-   * Or it is possible to set GPUDEVICE=-1. In this case the MPI process with rank N on a system
-     with G GPUs will take the GPU with ID (N % G).
-- GPU / CPU combined processing: Besides the pipeline approach described in the previous point,
-  which employs the CPU for creating the convoluted projection maps and the GPU for calculating
-  the probabilies for every combination with a map, there is also the possibility to split the
-  set of maps among the CPU and the GPU. This is facilitated by the GPUWORKLOAD=[x] environment
-  variable, which sets the percentage of the number of maps processed by the GPU to x%. The
-  pipeline is still used, i.e. in an optimal situation the CPU will:
-   * Issue a GPU kernel call such that the GPU calculates the probabilities for x% of the maps
-     for the current orientation and convolution.
-   * Process its own fraction of (100-x)% of the maps for the current orientation and convolution
-     in parallel to the GPU.
-   * Afterward, finish the preparation of the next orientation and convolution before the GPU has
-     finished calculating the probabilities for the current orientation and convolution.
-- Multiple Projections at once via OpenMP: BioEM can prepare the projection of multiple
-  orientations at once using OpenMP. The benefit compared to the pure OpenMP parallelization over
-  the maps is however tiny. This is relevant if: MPI is not used, OpenMP is used and usually if
-  no GPU is used, and if the number of reference maps is small. The number of projections at once
-  is determined by the BIOEM_PROJECTIONS_AT_ONCE=[x] environment variable.
-- Fourier-algorithm to process all shifts in parallel: BioEM can operate using two algorithms:
-  A Fourier-algorithm and a non-Fourier-algorithm. Besides numberical effects, both produce
-  identical results assuming certain boundary conditions. The Fourier-algorithm automatically
-  takes all shifts into account without having to loop over the shifts. Hence, its runtime is
-  almost independent from the number of shifts. The non-Fourier-algorithms is faster for very
-  few shifts. Benchmarks have shown, that the Fourier-algorithm is faster if the number of shifts
-  per direction is four or larger, which is the case for almost every relevant configuration.
-  Hence, the Fourier-algorithm should almost always be used. It can be activated / deactivated
-  through the FFTALGO=[x] environment variable, which defaults to 1. With the Fourier-algorithm
-  used normally, the number of nested loops is reduced to three, which maks the loop over the
-  maps the innermost loop.
-
-For the parallelization over the CPU cores of one node, there are in principle two options:
-- One can simply use OpenMP to paralleliza over the maps (optionally using the
-  BIOEM_PROJECTIONS_AT_ONCE=[x] variable to prepare multiple projections at once.
-- One can use MPI with as many MPI processes as there are CPU cores and with OMP_NUM_THREAD=1.
-  In this case, the parallelization is done over the projections only.
-In general, the first option is better for many maps while the second option is faster for
-few maps.
-
-Naturally, different methods of parallelization can be combined:
-- The Fourier-algorithm can be combined (and is by default combined) with any chosen option
-  automatically.
-- One can combine MPI with the GPU algorithm to use multiple GPUs at once (as described in
-  the GPU section).
-- As stated in the previous paragraph, on one node OpenMP works better for many maps while MPI
-  is better with few maps. For a medium number of maps, both methods can be combined. For
-  instance, OMP_NUM_THREADS=[x] can be set to x = 1/4th of the number of CPU cores on the system,
-  and BioEM can be called with 'mpirun' and 4 MPI processes. In that case always four
-  orientations are processed in parallel and x maps are processed in parallel.
-- On multiple nodes, one can either use MPI exclusively, using as many MPI processes as there are
-  CPU cores in total. Alternatively, one can use one MPI process per node and do the intra-node
-  parallelization with OpenMP. Naturally this can also be combined with the previous option, to
-  mix MPI and OpenMP inside a single node.
-- One can use GPUs and CPU cores jointly to calculate the probabilities for all maps. For more
-  than one GPU, MPI must be employed. In this case, the number of MPI processes must match the
-  number of GPUs. So the above method to combine MPI and OpenMP inside one node must be employed,
-  in order to use all CPU cores.
-  
-
-2. List of environment variables.
-
-FFTALGO=[x] (Default: 1)
-Set to 1 to enable the Fourier-algorithm (default) or to 0 to use the non-Fourier-algorithm.
-
-GPU=[x] (Default: 0)
-Set to 1 to enable GPU usage, set to 0 to use only the CPU.
-GPU will be used to calculate the probabilities for all maps. The preparation of projections
-and convolutions will be processed by the CPU. This is arranged in a pipeline to ensure
-continuous GPU utilization.
-
-GPUALGO=[x] (Default: 2)
-This option is only relevant if GPU=1 and FFTALGO=0.
-Hence, it is commonly not used any more, since FFTALGO defaults to 1.
-For the non-Fourier-algorithm there are three GPUALGO implementations:
-- GPUALGO=2: This will parallelize over the maps and over the shifts. The approach requires less
-             memory bandwidth than GPUALGO=0 or GPUALGO=1. However, it poses several contraints
-			 on the problem configuration:
-			  * The number of shifts per dimension must be a power of 2.
-			  * The total number of shifts must be a factor of the number of CUDA threads per
-			    block.
-- GPUALGO=1: This will parallelize over the maps and then loop over the shifts on the GPU. It is
-             usually slower than GPUALGO=2 but there are no constraints on the problem
-			 configuration. The maps are not processed all at once but in chunks.
-- GPUALGO=0: As GPUALGO=1, but all maps are processed at once. It is always slower than GPUALGO=1
-             and should not be used anymore.
-
-GPUDEVICE=[x] (Default: fastest)
-Only relevant if GPU=1.
-- If this is not set, BioEM will autodetect the fastest GPU.
-- If x >= 0, BioEM will use GPU number x.
-- If x = -1, BioEM runs with N MPI threads, and the system has G GPUs, then BioEM will use GPU
-  with number (N % G). The idea is that one can place multiple MPI processes on one node, and
-  each will use a different GPU. For a multi-node configuration, one must make sure that
-  consecutive MPI ranks are placed on the same node, i.e. four processes on two nodes (node0 and
-  node1) must be placed as (node0, node0, node1, node1) and not as (node0, node1, node0, node1),
-  because in the latter case only 1 GPU per node will be used (by two MPI processes each).
-
-GPUWORKLOAD=[x] (Default: 100)
-Only relevant if GPU=1.
-This defines the fraction of the workload in percent. To be precise: the fraction of the number
-of maps processed by the GPU. The remaining maps will be processed by the CPU. Preparation
-of projection and convolution will be processed by the CPU in any case.
-
-GPUASYNC=[x] (Default: 1)
-Only relevant if GPU=1.
-This uses a pipeline to overlap the processing on the GPU, the preparation of projections and
-convolutions on the CPU, and the DMA transfer. There is no reason to disable this except for
-debugging purposes.
-
-GPUDUALSTREAM=[x] (Default: 1)
-Only relevant if GPU=1.
-If this is set to 1, the GPU will use two streams in parallel. This can help to improve the GPU
-utilization. Benchmarks have shown that there is a very little positive effect by this setting.
-
-OMP_NUM_THREADS=[x] (Default: Number of CPU cores)
-This is the standard OpenMP environment variable to define the number of OpenMP threads.
-It can be used for profiling purposes to analyze the scaling.
-If one choses to use MPI for intra-node parallelization (See last two paragraphs of chapter 1),
-this can be set to x=1 (to use MPI exclusively) or to other values for a mixed MPI / OpenMP
-configuration.
-
-BIOEM_PROJECTIONS_AT_ONCE=[x] (Default: 1)
-This defines the number of projections prepared at once. Benchmarks have shown that the effect is
-negligible. OpenMP is used to prepare these projections in parallel. It is mostly relevant, if
-- OpenMP is used.
-- No GPU is used.
-- The number of reference maps is very small.
-
-BIOEM_DEBUG_BREAK=[x] (Default: deactivated)
-This is a debugging option. It will reduce the number of projection and convolutions to a maximum
-of x both. It can be used for profiling to analyze scaling, and for fast sanity tests.
-
-BIOEM_DEBUG_NMAPS=[x] (Default: deactivated)
-As BIOEM_DEBUG_BREAK, with the difference that this limits the number of reference maps to a
-maximum of x.
-
-BIOEM_DEBUG_OUTPUT=[x] (Default: 2)
-Change the verbosity of the output. Higher means more output, lower means less output.
-- 0: Stands for no debug output.
-- 1: Limited timing output.
-- 2: Standard timing output showing durations of projection, convolution, and comparison (creation
-     of probabilities.
-Values above 2 add successively more extensive output.
-
-
-3. Suggestions for runtime configurations
-
-The following settings should not be touched and left at theirs defaults:
-FFTALGO (Default 1), GPUALGO (Default 2), GPUASYNC (Default 1), GPUDUALSTREAM (Default 1)
-
-For profiling, one should limit the number of orientations and projections.
-Good settings are BIOEM_DEBUG_BREAK=4, BIOEM_DEBUG_BREAK=16, BIOEM_DEBUG_BREAK=64.
-BIOEM_DEBUG_OUTPUT=2 is a goo choice to get the timing. For a few number of maps it might
-make sense to switch to BIOEM_DEBUG_OUTPUT=1.
-
-For a production environment, BIOEM_DEBUG_OUTPUT=0 can reduce the size of the text output.
-
-BIOEM_PROJECTIONS_AT_ONCE=[x] has usually a tiny or none but never a negative effect.
-The memory footprint increases with x, so it should not be set unnecessarily large.
-For best performance, choose a multiple of the number of OpenMP threads.
-
-GPU=1 should usually be used if a GPU is available.
-Performancewise, one Titan GPU corresponds roughly to 20 cores at 3 GHz.
-If the CPU has significant compute capabilities, one should use GPUWORKLOAD=[x] for combined
-CPU / GPU processing.
-
-If one uses combined CPU / GPU processing, a good value for GPUWORKLOAD=[x] must be determined.
-A good starting point is to measure CPU and GPU individually with
-"BIOEM_DEBUG_OUTPUT=2 BIOEM_DEBUG_BREAK=4 GPU=0/1"
-and compare the time for the comparison. Assuming the CPU takes c seconds for the comparison and the
-GPU takes g second, a good starting point for GPUWORKLOAD=[x] is x = 100 * g / (c + g).
-
-On a single node, one should use OpenMP parallelization for many maps (> 1000) and MPI
-parallelization for few maps (< 100). Assume a system with N CPU cores, the command would be:
-BIOEM_PROJECTIONS_AT_ONCE=[4*N] OMP_NUM_THREADS=[N] BioEM (for many maps)
-OMP_NUM_THREADS=1 mpirun -n [N] BioEM (for few maps)
-
-For a medium number of maps, a combined MPI / OpenMP configuration can be beser.
-Assume 20 CPU cores, possible options would be (among others):
-OMP_NUM_THREADS=1 mpirun -n 20 BioEM (20 MPI processes with 1 OMP thread each)
-OMP_NUM_THREADS=2 mpirun -n 10 BioEM (10 MPI processes with 2 OMP threads each)
-OMP_NUM_THREADS=5 mpirun -n 4 BioEM (5 MPI processes with 4 OMP threads each)
-OMP_NUM_THREADS=10 mpirun -n 2 BioEM (2 MPI processes with 10 OMP threads each)
-In any case, you should make sure that the number of MPI processes times the number of OMP threads
-per process equals the number of (virtual) CPU cores.
-In general, the more MPI processes, the better for few maps, the more OMP threads, the better for
-many maps.
-
-If a system offers multiple GPUs, all GPUs should be used. This must be accomplished via MPI.
-In this case, the number of MPI processes per node must match the number of GPUs per node.
-There are different ways to make sure every MPI process uses a different GPU (as discussed in
-the GPU paragraph of chapter 1). Assuming the MPI processes are placed such, that consecutive MPI
-ranks are placed on one node, one can use the GPUDEVICE=-1 setting. This is assumed here.
-Let us assume an example of N nodes with C CPU cores each and G GPUs each.
-The following command will use all GPUs and ignore the CPUs:
-OMP_NUM_THREADS=1 GPU=1 GPUDEVICE=-1 mpirun -n [N*G] BioEM
-With the following command, you can use all the CPU cores as well. A combined MPI / OpenMP setting
-as discussed in the previous paragraph must be used, under the constraint that the number of MPI
-processes matches the number of GPUs:
-BIOEM_PROJECTIONS_AT_ONCE=[4*C/G] OMP_NUM_THREADS=[C/G] GPU=1 GPUDEVICE=-1 GPUWORKLOAD=[x] mpirun -n [N*G]
-Here, GPUWORKLOAD must be tuned as described before.

README

-*************************************************************
-    BioEM:  Bayesian inference of Electron Microscopy
-*************************************************************
-
-	     PRE-ALPHA VERSION: April 25, 2014
-
-**************************************************************
-Requisites: 
-
-	**** FFTW libraries:   http://www.fftw.org/
-
-        **** BOOST libraries:  http://www.boost.org/
-
-        **** OpenMP:           http://openmp.org/
-
-Optional: 
-        **** CMake:            http://www.cmake.org/
-	     for compliation with CMakeLists.txt file.
- 
-        **** Cuda:             Parallel Code for GPUs.             
-  
-***************************************************************
-
-DESCRIPTION:
-
- *** The BioEM code compares one Model to multiple experimental
-     EM images.
-
- *** Command line input & help is found by just running the
-     compiled executable ./bioEM
-
-      ++++++++++++ FROM COMMAND LINE +++++++++++
-
-	Command line inputs:
-	  --Inputfile arg       (Mandatory) Name of input parameter file
-	  --Modelfile arg       (Mandatory) Name of model file
-	  --Particlesfile arg   (Mandatory) Name of paricles file
-	  --ReadPDB             (Optional) If reading model file in PDB format
-	  --ReadMRC             (Optional) If reading particle file in MRC format
-	  --ReadMultipleMRC     (Optional) If reading Multiple MRCs
-	  --DumpMaps            (Optional) Dump maps after they were red from maps file
-	  --LoadMapDump         (Optional) Read Maps from dump instead of maps file
-	  --help                (Optional) Produce help message
-
-
- *** OUTPUT:
-     -- Main output file: "Output_Probabilities"
-     with
-     RefMap #(number Particle Map) Probability  #(log(P))
-     RefMap #(number Particle Map) Maximizing Param: #(Euler Angles) #(PSF parameters) #(center displacement)
-
-     **Important: It is recommended to compare log(P) with respect to other Models or to Noise as in [1].
-
-    -- (Optional) Write the probailities for each triplet of Euler Angles (key word: WRITE_PROB_ANGLES in InputFile).
-
- *** EXAMPLE DIRECTORY:
-     A directory with example EM particles, c-alpha PDB & simple Model, and
-     the corresponding launch scripts are provided.
-     -- Standard input file parameters are provided and recommened.
-
-REMARKS:
-
- *** EXPERIMENTAL IMAGE FORMAT:
-     Two options are allowed for the map-particle files:
-    	 A) Simple *.txt or .dat with data formated as
-	    printf"%8d%8d%12.4f\n" where the first two columns are
-	    the pixel indexes and the third column is the intensity.
-	    Multiple particles are read in the same file with the
-	    separator "PARTICLE" & Number.
-            -- For this case it is recommended  all particles 
-	    to be normalized to zero average and unit standard deviation. 
-         B) Standard MRC particle file. If reading multiple MRCs
-            provide in command line 
-		--Particlesfile FILE --ReadMRC --ReadMultipleMRC
-	    where FILE contains the names of each mrc file to be read.
-	    If only one MRC on command line 
-                    --Particlesfile FILEMRC --ReadMRC
-            where FILEMRC is the name of the single mrc file.     
-
- *** MODEL FORMAT:
-     -- Standard PDB file: Reading only CA atoms and corresponding
-     residues with proper density.
-     -- *.txt *.dat file: With format printf"%f %f %f %f %f\n",
-     the first three columns as the coordinates of atoms or
-     voxels, fourth column is the radius (\AA) and the 
-     last column is the corresponding density.
-     (Useful for all atom representation or 3D EM density maps).
-
-  [1] Cossio, P and Hummer, G. J Struct Biol. 2013 Dec;184(3):427-37. doi: 10.1016/j.jsb.2013.10.006.