I am fitting curves to the peaks in roughly 25000 detector events. My code just loops through all of the events, fitting to all peaks it finds and grabbing parameter info. It takes FOREVER!
I stopped my code from actually drawing the curves, but I'm wondering if I can do anything else to speed up this processing. I thought that if I stopped ROOT from printing the parameters from each fit to the screen that maybe it would run faster.
Is this true? If so, how can I do it? Any other ideas?
TGraphErrors * gr1 = view_waveform_ebars(run,evtNum,21);
mygaus -> SetParameters(671.55e3,-1000,S2loc,500);
gr1 -> Fit(mygaus,"","",tspulse_sum[j],tepulse_sum[j]);
fitResult = gr1 -> GetFunction("mygaus");
pchi2[j] = fitResult -> GetChisquare();
I was hoping not to need to copy the functions I'm using into my post. But mygaus has 4 parameters, and every time I call it using gr1-> Fit(mygaus,...) I see the parameters on the screen. So the question is whether or not that screen output is slowing me down, and, if so, how do I turn it off?
Thanks
You can also start root with the option -b
root -b
Maybe, just maybe, you want to run ROOT in batch mode, like this:
{
gROOT->SetBatch(1);
...
}
Did you try to limit the general ROOT output using
gROOT->ProcessLine( "gErrorIgnoreLevel = 1001;")
?
The higher the ignore level the less printout you will get.
To ignore INFO messages, 1001 is enough. To ignore WARNING it has to be above 2001. To ignore ERROR it has to be above 3001. Check what level the printouts are and set it as appropriate.
This is more like a comment:
There is also the "N" option which forces ROOT to not store the graphics function and not draw anything.
So I would use both, i.e.:
gr1 -> Fit(mygaus,"QN","",tspulse_sum[j],tepulse_sum[j]);
Related
When I make a OOT block in gnuradio
class mod(gr.sync_block):
"""
docstring for block mod
"""
def __init__(self):
gr.sync_block.__init__(self,
name="mod",
in_sig=[np.byte],
out_sig=[np.complex64])
def work(self, input_items, output_items):
in0 = input_items[0]
out = output_items[0]
result=do(....)
out[:]=result
return len(output_items[0])
I get:
ValueError: could not broadcast input array from shape (122879) into shape (4096)
How can I solve it?
GRC is as below:
selector :input index and output index are controlled by WX GUI Chooser block
FSK4 MOD: modulate fsk4 signal and write data to raw.bin
FSK4 DEMOD : read data from raw.bin and demodulate
file source -> /////// -> FSK4 MOD -> FSK4 DEMOD -> NULL SINK
selector
file source -> ////// -> GMKS MOD -> GMSK DEMOD ->NULL SINK
when the input index or output index is changed,the whole flow graph will be not responding.
There's two things:
You have a bug somewhere, and the solution is not to change something, but fix that bug. The full Python error message will tell you exactly in which line the error is.
noutput_items is a variable that GNU Radio sets at runtime to let you know how much output you might produce in this call to work. Hence, it's not something you can set, but it's something your work method must respect.
I think it's fair to assume that you're not very aware of how GNU Radio works:
GNU Radio is based on calling your block's work function when there is enough output space available and enough input items to process. The amount of output space that your block can use is passed to your work as a parameter, and will change between calls to work.
I very strongly recommend going through chapters 1-3 of the official Guided Tutorials if you haven't already. We always try to keep these tutorials up-to-date.
EDIT: Your command shows that you have not really understood what I meant, sorry. So: GNU Radio calls your work method over and over again while it's executing.
For example, it might call work with 4000 input items and 4000 output items space (you have a sync block, therefore number of input==number of output). Your work processes the first 1000 of that, and therefore return 1000. So there's 3000 items left.
Now, the upstream block does something, so there's 100 new items. Because the 3000 from before are still there, your block's work will get called with 3100 items.
Your work processes any number of items, and returns that number. GNU Radio makes sure that the "remaining" items stay available and will call your work again if there is enough in- our output.
I try to get current monitor status and found GetMonitorInfo function at http://msdn.microsoft.com/en-us/library/windows/desktop/dd144901(v=vs.85).aspx but I do not know c++ and how to use it in autohotkey. DllCall line is just a guess so this is what I wrote for now.
MonitorStatus := 1 > 2 ; Creates a boolean variable so size of it is determined.
Sleep 1000
DllCall("GetMonitorInfo","HMONITOR",1,"LPMONITORINFO",MonitorStatus,"int")
Sleep 1000
MsgBox Monitor status is %MonitorStatus%. ; Status should be turned to 1.
Return
Shortly how to detect if monitor is on or off with assuming it has power?
The DllCall returns a pointer to the structure. I think it's somehow possible to use pointers in Autohotkey but i don't think is going to be easy. If you don't know what any of that means don't even bother.
Hmm.. looks like autohotkeys does have everything; Try this:
http://www.autohotkey.com/docs/commands/SysGet.htm
And don't forget to check the examples at the bottom of the page!
I am using the IBM cplex optimizer to solve an optimization problem and I don't want all terminal prints that the optimizer does. Is there a member that turns this off in the IloCplex or IloModel class? These are the prints about cuts and iterations. Prints to the terminal are expensive and my problem will eventually be on the order of millions of variables and I don't want to waste time with these superfluous outputs. Thanks.
Using cplex/concert, you can completely turn off cplex's logging to the console with
cpx.setOut(env.getNullStream())
Where cpx is an IloCplex object. You can also use the setOut function to redirect logs to a file.
There are several cplex parameters to control what gets logged, for example MIPInterval will set the number of MIP nodes searched between lines. Turning MIPDisplay to 0 will turn off the display of cuts except when new solutions are found, while MIPDisplay of 5 will show detailed information about every lp-subproblem.
Logging-related parameters include MIPInterval MIPDisplay SimDisplay BarDisplay NetDisplay
You set parameters with the setParam function.
cpx.setParam(IloCplex::MIPInterval, 1000)
At the moment I'm using an eclipse-like IDE and the corresponding debug perspective, that most of you are probably familiar with. While debugging code I quite often find myself stepping through many lines of code and observing variables and double checking if everything is as it is supposed to be.
But suppose there is something like this:
1. important line, e.g. generating a new object;
2. another important line, e.g. some tricky class method;
3. for (int i = 0; i < some_limit; ++i)
4. some_array[i]++;
5. more important stuff;
Obviously I'm interested in what happens in lines 1,2 and 5 (I know this is a poor example, but please bear with me for a little while longer) but I don't want to step through all hundreds (or even thousands) of iterations of lines 3/4.
So, finally, my question: Is there some way to step directly over the for-cycle? What I do right now is set a new breakpoint at line 5 and let the program run as soon as I hit line 3 and I believe this is not an optimal solution.
edit: The eclipse implementation of what ks1322 proposed is called "Run to line" and is mapped to ctrl-r
Use until command instead of next.
From gdb documentation:
Continue running until a source line past the current line, in the
current stack frame, is reached. This command is used to avoid single
stepping through a loop more than once.
If you will use until instead of next, gdb will step over loops only once, which almost exactly what you want.
I'm having a problem on Vista with the Listview control, in particular setting custom icons on the header. Normally under XP or any of the previous version of Windows, if I added an icon (in C++), I could do so with the following:
HeaderItem.mask = HDI_FORMAT | HDI_IMAGE;
Header_GetItem(HeaderHWND, Column, &HeaderItem);
TurnOn(HeaderItem.fmt, HDF_IMAGE);
HeaderItem.iImage = Image;
if (Header_SetItem(HeaderHWND, Column, &HeaderItem) == 0)
printf("Failed to set header [%d:%.8X]\n", GetLastError(), GetLastError());
and then to remove the image, on a particular column, I could use the same process but instead of turning on the HDF_IMAGE bit, you just turn it off.
On Vista, however, when I turn it off it doesn't seem to actually be accepting the change. So, for instance, when I start my fmt is:
0x4000 (or basically HDF_STRING)
I turn on the icon, and it becomes:
0x5800 (or basically HDF_STRING | HDF_IMAGE | HDF_BITMAP_ON_RIGHT)
I then turn it off again, but the result is:
0x4800 (or basically HDF_STRING | HDF_IMAGE)
I've checked, and I setting it to HDF_STRING only, but once HDF_IMAGE is set, it seems to be impossible to remove. Header_SetImage doesn't return any errors, so I'm at a loss as far as what to do. I've also tried removing the Imagelist from the control, but it still leaves the space as if there still was an image there.
At the end of the day I need to be able to add and remove icons from the header, and when they are removed I need all the header space available again (as they were before any were displayed. Any help would be greatly appreciated - thanks in advance!
If you read the documentation http://msdn.microsoft.com/en-us/library/bb775247(VS.85).aspx, if you indicate HDI_IMAGE in mask then iImage should be a valid index, you have to set it to I_IMAGENONE in order to remove it.
If you want to remve an image you have to do something like this:
HeaderItem.mask = HDI_FORMAT | HDI_IMAGE;
Header_GetItem(HeaderHWND, Column, &HeaderItem);
HeaderItem.fmt &= ~(HDF_IMAGE | HDF_BITMAP_ON_RIGHT);
HeaderItem.iImage = I_IMAGENONE;
Header_SetItem(HeaderHWND, Column, &HeaderItem);
Uhg, I just figured it out - they've changed slightly the way things work now as far as passed parameters.
Before, I always set the iImage to 0 when I was removing the HDF_IMAGE attribute - but it looks like now if you perform a Set, and your mask includes HDI_IMAGE, then it will not remove the HDF_IMAGE bit, even though you explicitly do.
So, the solution is to make sure not to send anything image-related if you're trying to remove it. Since I scoured the net and couldn't find anything about this, hopefully this post will now help anyone else who has a similar problem.