I'm resonably convinced by this as far as it goes - NaN in Chi2 almost
certainly reflects a serious error in the input, and will likely be
evident from the very begining of the calculation. As such I no longer
have concerns about Chi2 == NaN raising RelaxError. The only exception
would be the case of a corrupt PDB file, where not all residues are
affected. The current behaviour for missing protons is to print a
warning, deselect the affected residue, and continue. I believe a
similar approach should also apply in the case of bad proton positions.
The warning should be sufficient for the user to notice something is
wrong. The setting of the vector to None rather than deselecting the
residue in your change to 'pdb.py' is good as isotropic diffusion and
the local tm models, which are independent of the XH bond orientation,
will be unaffected. In addition the PDB reader in Scientific Python
is not perfect and may trigger the problem.
I'm still not sure that other variables won't become NaN at some point.
One example might be internal variables in the optimisation routines. I
can't give specific examples, but concievably might become NaN or INF as
a result of under- or overflow. Clearly this means that this specific
optimisation will fail, but its not clear to me that it is necessarily a
globally fatal error.
I've never seen a NaN produced in the minimisation code before, but it
shouldn't matter. The changes to the code in the 'nan_catch_test'
branch allows minimisation to terminate and then the problem is
caught. The generation of NaN or Inf still indicates a fatal flaw -
it should never be produced under any circumstance.
Edward
Re: [bug #6503] Uncaught nan in xh_vect