Since we are not using SC2 and SC3 calculations anymore in SGEMME, I decided to remove them. They were making the computations quite slow due to multiple external calls to JET. In addition, I updated the bash script in the examples directory. We have an example to calculate all possible single point mutations. Besides, we have an example to calculate only mutations of interest given in a blah-blah.mut file.

Added maxhalftracepchalftracecvhalfcvpc maxtracehalftracecvhalfcvpc.
In addition, increased java memory request from -Xmx2048m to -Xmx4096m.

SC3 calculation options to JET2 calls.

Changed N=20000 to N=40000. Increased CPU load to 2000000 in default.config
file. Finally, modified jetcmd in gemmeAnal.py file so that we can calculate
SC1, SC2 and SC3.

Once upon a time, we tested the idea of changing the weight
of epistatic (0.6) and independent (1-0.6) component depending
on the residue features such as frequency of aa in the MSA.
Therefore, I had made alpha a list instead of a single value.
Now, I reverted it back to a single value (0.6).

1-Moved the normweighmode to the beginning of the program.
In this way, the weight will be applied at the beginning
instead of just the final normalization step. Our tests
show that it improves the results when Max(JET, (PC+CV)2)
is used at the beginning. Most of the changes in this part
are in computePred.R file.
2-When the user provides a mutation list
as a file, it was giving an error. The error in apply(...)
part of normalizePredWithNbSeqsPCSelMult function. The bug
is corrected now and it produces results consistent with
the web server.

3-A small bug in gemme.py was also corrected.
If a mutation list file is given, the model is not 'simple'
and therefore, it will not produce a map of single point
mutations.

If the user does not provide a pdbfile and asks the program to calculate
structural-dynamical parameters like Bfactor, CV or DFI, the program will
give an error and quit. Before, there was not such a thing.

Reverted NA values from 2.0 to 0.0 bbc it was causing too much difference in the epistatic model maps.

If the query sequence contains a gap, createPDB() was blowing up.
This bug was corrected!