mailRe: [bug #5501] residue deselection problem on relax_data.read()


Others Months | Index by Date | Thread Index
>>   [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Header


Content

Posted by Edward d'Auvergne on March 17, 2006 - 05:01:
Chris, would you be able to forward or resubmit your post to
relax-devel, thanks.  That way there won't be a gap in the thread.

of issue which arise in that test.  Possibly the most critical is that
relax results files cannot be read (well no data is extracted).

This is now fixed in the auto_select branch. The problem was just that
there was a couple of if not data.select : continue expressions in the
relax_data.read code. Deleting these seems to have no ill effects, and
the test runs without problem now.

I've removed the selection test on line 3316 of
'specific_fns/model_free.py' but when there is a results file in which
residues aren't selected, a trackback occurs.

I think there should also be a test of the run type.  Relaxation
curve-fitting, the NOE calculation, reduced spectral density mapping
(RSDM), and any future run types will not have the residue specific
structure 'relax_data'.

This should also be fixed, I think. Required passing the global data
structures in relax.data through to relax.data.res[run][index]. The side
effect is that we can potentially be even more sophisticated with what
we deselect, eg. deselecting residues lacking structural data when the
diffusion tensor requires it. I havn't yet implimented anything like
this, but it should be trivial

That's a good idea.

# The end user.

The automatic prevention of over-fitting is good, except how do we
communicate that to a user?

Not sure about the best approach here. The minimalist option is to
simply document the behaviour and assume the user is smart enough to
work out what is happening. Alternatively we could warn the user
whenever user_select is set differently to auto_select. This could get
overly verbose though, for opperations like select.all(). Was there a
particular issue you had in mind that we need to be clear about?

Actually if the over-fit residues are deselected, then they stand out
in the results file as there is a line of nothing.  That should
probably be enough, the user should be checking the results files
along the way and not just the final results file.  If they aren't
checking, then it probably won't matter to them too much if the
default behaviour prevents accidental over-fitting.

  And what should happen if there is a
residue which only has one data point (n = 1)?  Should we allow the
user to blindly minimise the model-free models m0 and m1 and leave it
to the user to appropriately create an 'unselected' file and include
that residue?  Or should we set a minimum of maybe n > 2?

That is now set for mf and jw runs

Looks good.

Edward



Related Messages


Powered by MHonArc, Updated Fri Mar 17 05:40:25 2006