--- Begin Message ---
Edward d'Auvergne wrote:
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.
One of the problems with this sort of thing is that warnings can be lost
in the rest of the output. It maybe worthwhile putting warnings into a
different stream say the error stream or even better/as well print a
message along the lines of warnings were generated... see output for
details at the end of each run. Other thoughts are that warnings could
go into a weakly referenced buffer (to prevent out of memory problems)
and then be re-reported at completion. Certainly all warnings should
start with a clearly delineated string which is easily grepped for. This
might be forced by making warningsgo via a specific function which
prepends the relevant text. Of course a flag to turn warnings into
failures can also be useful as found out by man y generations of comiler
users and writers and would be made available by the same use of a
bottlneck function.
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
_______________________________________________
relax (http://nmr-relax.com)
This is the relax-devel mailing list
relax-devel@xxxxxxx
To unsubscribe from this list, get a password
reminder, or change your subscription options,
visit the list information page at
https://mail.gna.org/listinfo/relax-devel
.
--
-------------------------------------------------------------------
Dr Gary Thompson
Astbury Centre for Structural Molecular Biology,
University of Leeds, Astbury Building,
Leeds, LS2 9JT, West-Yorkshire, UK Tel. +44-113-3433024
email: garyt@xxxxxxxxxxxxxxx Fax +44-113-2331407
-------------------------------------------------------------------
--- End Message ---
[Fwd: Re: [bug #6503] Uncaught nan in xh_vect]