>> 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've always had in the back of my mind the creation of RelaxWarnings.
The messages go to stderr but the program continues. I've tended
towards RelaxErrors rather than RelaxWarnings though because it is
very easy to miss the warning - relax is deliberately quite verbose.
This PDB case may be perfect for introducing a RelaxWarning as the
message appears at the very start and is a lot more noticable. The
easily greppable string is 'RelaxWarning', and the implementation
would be within 'error.py'. In most other situations I would prefer
the RelaxError as the program terminates at the error and hence the
user is fully aware that there is a problem and what the issue is.
My idea would be to have a second class in the 'error.py' file called
RelaxWarnings. This would be activated in the file 'relax' just under
the line 'RelaxErrors()'. The RelaxWarnings class would have exactly
the same structure as the RelaxErrors class, i.e. loop over all the
objects in 'self' and place them into '__builtin__', create the
BaseWarning class which uses 'Warning' as it's base class, and then
create the specific warning called something like
RelaxZeroVectorWarning. I don't currently have access to the svn
repository so feel free to give this a go if you like. Otherwise I
might give it a go tomorrow.
Edward
Re: [Fwd: Re: [bug #6503] Uncaught nan in xh_vect]