This is about an old issue involving multiple color palettes in the same canvas, by using the “TExec trick”.
I have defined a simple Python class for better handling and extended functionality of color palettes in ROOT: ppalette.py (3.6 KB)
This is a demo script which shows its functionality, drawing 4 different TH2F with colz option and 4 different palettes: testPalettes3.py (3.8 KB)
The color palettes can be defined by the user by providing am arbitrary color tuple.
For example, the script uses two of the (many) color palettes provided by palettable.
The program runs just fine, producing the following output: testPalettes3.pdf (206.0 KB)
In the script, the ppalette objects needs to be defined globally, to let TExec have access to them.
However, the strategy that I am following here is failing for other more complex programs that I use to obtain histograms from simulation data…
I managed to realize that the program stops responding whenever ROOT.gPad.Update() is called after the TExec command. It freezes completely without any output message. I have to kill the process from another terminal session to go on.
Unfortunately, I was not able to reproduce the problem with the script above.
Since I have already spent some time trying to figure out why this is happening with no success, I have decided to post it here.
Perhaps there is something simple that I am missing…
I would need more details and know better the context to be able to tell what is going on. From what I understand, you are running some C++ ROOT graphics code with TExec from Python (it should not matter if you use TExec from Python or C++), and that code that you run interferes with gPad.Update() (which again, in Python it just redirects to the C++ implementation).
@couet can you think of what code executed with TExec can make gPad.Update hang?
Hello @etejedor and @couet,
Thanks for the quick response.
The code is all contained in the testPalettes3.py script which I quoted above.
It uses TExec to change the active palette for different histograms in the same canvas.
This is done through a python object of class Palette.
(defined in the ppalette.py script also quoted above).
Since this is a python object, it needs to be called through TExec by using TPython.
So in the end TExec is executing python code through TPython.
By the way, is there another way to do this directly?
Some sort of version of TExec that allows running python code directly?
Anyway, the program should run OK in your ROOT installation if you want to try.
You just need to download both scripts and execute testPalettes3.py.
(ah! you would also need palettable from pip for the specific color palettes that I am using).
The problem that I have is precisely that the example runs just fine, but it fails when I implement the same logic into my real program for analysis.
Unfortunately I have no clue of what is different with respect to the example and why only hangs when calling gPad.Update().
I could share that code here too, if that would help to find out the problem.
However, you won’t be able to run it without the data source and other needed packages…
I appreciate the help a lot.
(this was driving me crazy over the weekend…)
Cheers!
@couet has more experience on the use of TExec, but a priori I don’t see any issue with using it to run some Python code through TPython.
I would really try to find out what the difference is between the working and the non-working solution. I would proceed incrementally, adding stuff to the solution that works until it hangs.
Thanks @etejedor,
That is exactly what I have been doing until I could pin down the problem:
The not-working program was using argparse to enable command line parsing of arguments.
Among them I was using “-t” for setting up the time step of the simulation to be read.
Well… this was causing the issue! If I don’t use “-t” in the command line, it works just like the example.
I have no idea why this was happening.
From the root help we can see:
-t Enable thread-safety and implicit multi-threading (IMT)
So, I thought that by adding -t to the working example I should reproduce the problem.
The funny thing is that it does when I do it remotely in a linux machine, but not in my macbook…
I am seriously considering to change the default for this option to True in ROOT master, so that by default ROOT does not parse your arguments. But for now, setting it to True yourself should help you.
