Appion

r16682 adds the interface changes.
1. Niko thinks we can get rid of the Recon stack selection drop down from the frealign params.
2. We need to add the new parameters to the database so that we can import parameters from a previous run.
3. We still need help blurbs from Niko.

Niko, if you have the list of parameters and defaults in a document, it would be great if you could upload it to this issue after you add the help message text for future reference.

I started a spread sheet for the help text and default values that the gui should contain.
You can access and edit here:
http://sdrv.ms/KMpP24

r16914 change the call to frealign.exe to frealign_v8.exe because frealign changes its input card from version to version. The current appion script is only good for v8.10.
r16916 change the refine part to call frealign_v8_mp.exe in order to run across nodes
r16920 makes fbfact part of card 1 input which makes number of variables in there one higher.

Will need to merge to branch 2.2 if we want frealign function there.

From Niko regarding mp and non-mp version and where to use what.

There is no paralellization inside Frealign when you do refinement. The only paralellization inside Frealign is done when doing a
reconstruction. However, I am not uing openmpi, just openmp. So when you use frealign_v8_mp.exe, you cannot run the job on several nodes, just several CPUs on a single node. To paralellize refinement, use either frealign_v8.exe or frealign_v8_mp.exe (with _mp you will have to set env variable NCPUS = 1, otherwise the job will hog all CPUs it can get without actually using them for calculation) and break up the job by running several instances of Frealign, each refining a fraction of the particle stack.

Maybe it would be safest for Appion to use frealign_v8.exe for refinement (do not use it with mpirun) and frealign_v8_mp.exe for reconstruction (again, do not use mpirun, it should simply use all the processors it has available, please check that this is indeed th
case).

Anchi, can we close this out? I think #1922 takes care of what is left to do, which is figuring out a way to keep the GUI from reporting that the job is done until it actually is. I know we have both looked into that without real success.