Seedouble for autopeak seems not to work

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Autopeak the attached curves
2. Watch at them really well, you can see two fit for the same fit

What is the expected output? What do you see instead?
I expect that the parameter "seedouble" work (in these cases was 10 nm),
but it seem that does not work in this case. 

What version of the product are you using? On what operating system?
hooke 0.83, Linux

Please provide any additional information below.

Original issue reported on code.google.com by fabrizio...@gmail.com on 19 Jun 2009 at 2:53

Attachments:

• 06161236.007
• 06161447.019

[GoogleCodeExporter]

I cannot reproduce the problem here. Could you provide an image and the 
"setconv"
parameters you are using, and the autopeak command line (that is, parameters 
you give
autopeak?)

Original comment by devicera...@gmail.com on 3 Jul 2009 at 5:30

[GoogleCodeExporter]

Original comment by devicera...@gmail.com on 3 Jul 2009 at 5:33

[GoogleCodeExporter]

Ok, I have found another curve in my playlist that present the same problem. I 
put 
here the output of autopeak, look careful at the numbers (in particular the 
first two
in the arrays):

contour (nm) [34.77707489292748, 34.77707489292748, 50.213578996142786,
83.073071720742277, 104.89904244271879, 115.39123293212891, 150.06686377264282,
155.70101783231109, 170.27898124920054, 197.49653487484076, 225.34863438437532,
248.34478483725238, 302.68054286468686, 4915.0076590472963]
sigma contour (nm) [0.4855236800393396, 0.4855236800393396, 0.77988243625580589,
1.7313749615137253, 2.72286181847553, 1.6909013328214515, 8.1356531088008097,
2.4356541470617916, 2.1837974721200637, 9.5971373923856191, 6.1498418681064821,
7.584229212374578, 40.55342516829581, 1384733.8684284217]
p (nm) [0.059313382216548326, 0.059313382216548326, 0.040516923234271571,
0.43430986773210906, 0.35102521447866519, 0.77560723681760713, 
0.25227086289076306,
0.54698830119204245, 0.62252782415609353, 0.37508334562163814, 
0.56463374675547351,
0.45661583006698858, 0.16754130763400671, 0.0260339074553507]
sigma p (nm) [0.0046286553401865237, 0.0046286553401865237, 
0.0041852640098119986,
0.082405846777091021, 0.075893201396965385, 0.15899036774563335,
0.087837163900078424, 0.10722672854410067, 0.11081003270632146, 
0.15429834447325461,
0.19111225231436968, 0.15405231278625608, 0.11357710171272796, 
7.6699365725203252]
forces (pN) [462.23179659212724, 462.23179659212724, 828.77013259491127,
109.40046490062703, 125.65820619214254, 126.81704787794804, 140.7036845005222,
141.39738431816306, 146.79953934755753, 120.81494869420736, 133.17499998077446,
130.08386830072544, 131.95071299354163, 48.108673467835835]
slopes (N/m) [0.064021496395577526, 0.064021496395577526, 0.18826510485840922,
0.0095666483221954635, 0.010898057015526763, 0.011956238625533707,
0.0094749622560340273, 0.0092615223498270262, 0.015253813381902927,
0.0099642070915265269, 0.0059152680026701588, 0.0070473972452778279,
0.0014623816097847455, 0.00035124744298820266]

There is also "another" anomaly, look at the image that I have attacched. The 
lines
in the first two are superimpose, but I know that at the beginning there should 
be a
red line in the first or the second peak.

Original comment by fabrizio...@gmail.com on 7 Jul 2009 at 12:20

Attachments:

• temp.jpg

[GoogleCodeExporter]

I believe you, but if I can't reproduce the problem it's hard for me to debug 
it. I
wasn't able with the previous two curves.

Are you using the latest Hooke SVN version?

Can you give me the output of "setconv" and any other parameter you use for 
autopeak?

Original comment by devicera...@gmail.com on 7 Jul 2009 at 1:00

[GoogleCodeExporter]

Original comment by devicera...@gmail.com on 7 Jul 2009 at 1:00

• Changed state: Accepted
• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Ok, for the setconv I have used this:
<convfilt minpeaks="5" mindeviation="4" seedouble="10"
convolution="[6.0,-1.0,-1.0,-1.0,-1.0,-1.0,-1.0]" blindwindow="30"/>

but I had to change the mindeviation to 3 with "setconv mindeviation 3"
I have just upgrade Hooke but I get immediatly this other bug...

python hooke.py
Starting Hooke.
Traceback (most recent call last):
  File "hooke.py", line 61, in <module>
    config=config_obj.load_config('hooke.conf')
  File "/home/phdstudent/hooke/libhooke.py", line 165, in load_config
    self.config_tree=xml.dom.minidom.parseString(the_file)
  File "/usr/lib/python2.5/xml/dom/minidom.py", line 1925, in parseString
    return expatbuilder.parseString(string)
  File "/usr/lib/python2.5/xml/dom/expatbuilder.py", line 940, in parseString
    return builder.parseString(string)
  File "/usr/lib/python2.5/xml/dom/expatbuilder.py", line 223, in parseString
    parser.Parse(string, True)
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 1, column 1

Original comment by fabrizio...@gmail.com on 7 Jul 2009 at 2:13

[GoogleCodeExporter]

I know that one; it is due to SVN messing up when people modify their 
hooke.conf .I
will post another bug (and try to get a temporary solution).

I will try to see the seedouble thing as soon as possible.

Original comment by devicera...@gmail.com on 7 Jul 2009 at 2:26

[GoogleCodeExporter]

Ok, we can discuss about the expat thing on the appropriate bug.

Original comment by devicera...@gmail.com on 7 Jul 2009 at 2:31

[GoogleCodeExporter]

Ok, here you have another curve that create that kind of problem.
With these parameters you should get the same results (isn't it?!).

hooke: setconv
{u'seedouble': 10, u'convolution': [6.0, -1.0, -1.0, -1.0, -1.0, -1.0, -1.0],
u'positive': 0, u'stable': 0.0050000000000000001, u'minpeaks': 5, 
u'blindwindow': 30,
u'maxcut': 0.20000000000000001, u'mindeviation': 3}

hooke: autopeak
Measurements for all peaks detected:
contour (nm) [37.677658915648145, 37.677658915648145, 51.040525209456966,
67.90347629732085, 87.254337720842983, 110.97686884939087, 122.93081221573429,
143.80388594914101, 165.61100391981606, 173.38698517810437, 199.70431096531232,
226.12333561483638, 274.75629742326061, 343.81173739246498, 2779.0535454714031]
sigma contour (nm) [0.72845890506791722, 0.72845890506791722, 
0.71418189772141505,
1.2621070589900474, 2.5224542963081169, 4.7615569363510755, 3.4538726437761658,
5.8297248928791898, 4.5227948282172763, 2.3254236339893732, 8.5435584975645966,
4.9071824251980063, 29.959815459700074, 140.89224234429443, 558014.67118968267]
p (nm) [0.049431264610134799, 0.049431264610134799, 0.051620179648743894,
0.38701943194010402, 0.40359563045829205, 0.31262037888936167, 
0.58505064525296713,
0.53597873349417968, 0.43207655431362191, 0.92410773528269918, 
0.49296460633969102,
1.0279061852166742, 0.26427873124138629, 0.11748601093870085, 
0.065715912418564393]
sigma p (nm) [0.0047281727287232555, 0.0047281727287232555, 
0.005894634126991009,
0.067178114271994313, 0.10563923068172668, 0.10560252334395745, 
0.19696701027411903,
0.23848854945960479, 0.1306034759609761, 0.22455501152016433, 
0.23963594522475989,
0.40408975384452617, 0.22368648548110567, 0.18272775480307321, 
14.496925053686004]
forces (pN) [461.04322281921037, 461.04322281921037, 828.16808886942613,
146.97045914405081, 110.67652470170545, 126.17721312900821, 126.38609913310771,
139.9076154986584, 141.08446511672804, 147.07848771411943, 121.35904510296938,
132.61612325840008, 128.78290187884082, 130.51041769836209, 46.532837082728861]
slopes (N/m) [0.06067314032141382, 0.06067314032141382, 0.17313911029085219,
0.01572949145634114, 0.0091915980343087213, 0.010384426239921198,
0.011436610720349381, 0.0091351137856767548, 0.0089215037508466929,
0.014628851305950562, 0.0080343862665324915, 0.005649831531208095,
0.0067863700858045361, 0.0014475385923786342, 0.00016513084742611456]

Let me know...

Original comment by fabrizio...@gmail.com on 7 Jul 2009 at 3:02

Attachments:

• 06161237.013

[GoogleCodeExporter]

OMG, that's weird... I could not reproduce your bug at first, but then I ran 
into
something which could be the source of counfusion, *and* a brand-new bug to look
into. OK, basically I cannot reproduce your bug if I just use "autopeak" without
additional parameters. BUT, if I use "autopeak pl=0.35", neither "blindwindow" 
nor
"seedouble" seem to kick in, and the result is that you're given a lot more 
WLCs than
you'd like, and some of them do overlap as you describe.
Could you guys try to issue both "autopeak" and "autopeak pl=0.35" (or 
whatever) to
the same curve and look at the results?

Original comment by marcobru...@gmail.com on 7 Jul 2009 at 4:19

[GoogleCodeExporter]

What you describe is (probably) not a bug, but a feature.
autopeak when called without "pl=" discards automatically curves with 
"unreasonable"
persistence lengths (where "unreasonable" is described in the config file 
parameters
auto_min_p and auto_max_p , with values in nm).

See [Brief_Autopeak_HowTo|documentation]: 

"Finally, peaks are automatically excluded from the measurement if their 
persistence
length falls out of a certain range. The range is defined by the AUTO_MIN_P and
AUTO_MAX_P variables, in nanometers. If in some curve, the peaks command finds 
a peak
that autopeak does not find, check with the wlc command if the persistence 
length
falls out of the range." 

Of course, if pl is forced by the user, the check on the persistence length 
makes
little sense, so everything is measured.

Original comment by devicera...@gmail.com on 7 Jul 2009 at 4:33

[GoogleCodeExporter]

However this has little to do with the bug. You confirm you reproduced it when
forcing "pl=0.35" ?

Original comment by devicera...@gmail.com on 7 Jul 2009 at 4:35

[GoogleCodeExporter]

If you are asking to me, YES, I confirm.
You can see here that the first two are overlapped.

This is the output:

autopeak pl=0.35
Measurements for all peaks detected:
contour (nm) [29.616493197343686, 29.616493197343686, 42.919376881246542,
65.821054809158184, 85.145882966413652, 104.90845148969288, 123.95538023019513,
143.89143249838381, 161.95081035495366, 178.91896486671746, 199.28352320658078,
235.77406506209522, 254.47505918293007, 271.01392488675464, 558.55236569316025,
683.98499271925414]
sigma contour (nm) [0.1125910460721171, 0.1125910460721171, 
0.088332296907792041,
0.21781347636748263, 0.31275643629954947, 0.38298159437209212, 
0.49806211947030288,
0.62814814400482744, 0.36734374762471173, 0.47417077839428917, 
0.8594511908160114,
0.81302882242097063, 0.78936177576594524, 0.98310462289003897, 
44.553357480488174,
29.548861722951035]
p (nm) [0.34999999999999998, 0.34999999999999998, 0.34999999999999998,
0.34999999999999998, 0.34999999999999998, 0.34999999999999998, 
0.34999999999999998,
0.34999999999999998, 0.34999999999999998, 0.34999999999999998, 
0.34999999999999998,
0.34999999999999998, 0.34999999999999998, 0.34999999999999998, 
0.34999999999999998,
0.34999999999999998]
sigma p (nm) [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
forces (pN) [462.23179659212724, 462.23179659212724, 828.77013259491127,
146.20657625288848, 109.40046490062703, 125.65820619214254, 126.81704787794804,
140.7036845005222, 141.39738431816306, 146.79953934755753, 120.81494869420736,
133.17499998077446, 130.08386830072544, 131.95071299354163, 63.035067607757668,
48.108673467835835]
slopes (N/m) [0.064021496395577526, 0.064021496395577526, 0.18826510485840922,
0.01635046282993197, 0.0095666483221954635, 0.010898057015526763,
0.011956238625533707, 0.0094749622560340273, 0.0092615223498270262,
0.015253813381902927, 0.0099642070915265269, 0.0059152680026701588,
0.0070473972452778279, 0.0014623816097847455, 0.0030035443464426492,
0.00035124744298820266]

Original comment by fabrizio...@gmail.com on 9 Jul 2009 at 3:26

[GoogleCodeExporter]

I was asking Marco, kinda obviously.

Original comment by devicera...@gmail.com on 9 Jul 2009 at 11:43

[GoogleCodeExporter]

Are there news on this bug?

Original comment by devicera...@gmail.com on 24 Jul 2009 at 1:07

[GoogleCodeExporter]

Ping.

Original comment by devicera...@gmail.com on 28 Sep 2009 at 5:22

[GoogleCodeExporter]

Last ping. If I see no comments, next time I close the bug.

Original comment by devicera...@gmail.com on 31 Oct 2009 at 7:40