Hi,
Seb, now that the secondary problem of Monte Carlo simulation failure
has been shifted to bug # 11476 (https://gna.org/bugs/?11476) and this
problem solved, I think that this bug #11454 report could probably be
closed. Suppressing the optimisation warning message for model m0
will be difficult and I have no easy solution at the moment.
Nevertheless, this could be now considered more as a feature than a
bug fix. So, unless you disagree, would you be able to close this
one?
Cheers,
Edward
On Fri, Apr 11, 2008 at 6:33 PM, Edward d'Auvergne
<edward.dauvergne@xxxxxxxxx> wrote:
Hi,
This secondary problem is quite severe. Could you create a new bug
report for this one rather than have it attached to this report, and
set the priority and severity to the maximal values? I would like to
get this one fixed as soon as possible and to release a new version of
relax with this fix, as there is a good chance that any user may
randomly encounter the problem. Could you also attach enough
information (truncated files, etc.) to the new report so I am able to
replicate the bug?
Cheers,
Edward
On Fri, Apr 11, 2008 at 6:12 PM, Sébastien Morin
<NO-REPLY.INVALID-ADDRESS@xxxxxxx> wrote:
>
Update of bug #11454 (project relax):
>
> Priority: 5 - Normal => 7 - High
>
> _______________________________________________________
>
> Follow-up Comment #3:
>
> Hi,
>
> I had a look at some "final" run with 500 simulations and found out
> something.
>
> The simulations are affected by this break of the minimise() function
when
> encountering model "m0"...
>
> See, for example, errors for S2 for residues before residue 218 (for
which
> "m0" was chosen) and after this residue. Before the residue, errors in
S2 are
> fine, but after they are excessively small...
>
>
> ==============================
> ...
> 216 val 1 error N m7 ... 0.031361478644779991
> 217 thr 1 error N m7 ... 0.038211292618960502
> 218 gly 1 error N m0 ... None
> 219 asn 1 error N m1 ... 1.112698441354078e-15
> 220 leu 1 error N m3 ... 3.2268254799268261e-15
> ...
> ==============================
>
> If we have a look at some simulations, for example simulations 1, 2 and
3 :
>
> ==============================
> ...
> 216 val 0 sim_1 N m7 ... 0.78494175630280139
> 217 thr 0 sim_1 N m7 ... 0.82059932724210649
> 218 gly 0 sim_1 N m0 ... None
> 219 asn 0 sim_1 N m1 ... 0.9225077650606851
> 220 leu 0 sim_1 N m3 ... 0.84861925081698242
> ...
> 216 val 1 sim_2 N m7 ... 0.81063701088779105
> 217 thr 1 sim_2 N m7 ... 0.8206973815627201
> 218 gly 1 sim_2 N m0 ... None
> 219 asn 1 sim_2 N m1 ... 0.9225077650606851
> 220 leu 1 sim_2 N m3 ... 0.84861925081698242
> ...
> 216 val 1 sim_3 N m7 ... 0.83600457272281326
> 217 thr 1 sim_3 N m7 ... 0.81752904637249857
> 218 gly 1 sim_3 N m0 ... None
> 219 asn 1 sim_3 N m1 ... 0.9225077650606851
> 220 leu 1 sim_3 N m3 ... 0.84861925081698242
> ...
> ==============================
>
> we see that simulated values vary for residues before 218 (with model
"m0"),
> but never vary (obviously are not simulated) for residues following this
> first instance of model "m0" in the sequence.
>
> This is a serious bug.
>
>
>
> _______________________________________________________
>
> Reply to this item at:
>
> <http://gna.org/bugs/?11454>
>
> _______________________________________________
> Message sent via/by Gna!
> http://gna.org/
>
>
Re: [bug #11454] Constraint incorrectly supplied when using the "full_analysis.py" script