G4Exception : Cache001

[chris-clem]

Hi,

I am getting the following error at the end of my simulation:

-------- EEEE ------- G4Exception-START -------- EEEE -------
*** G4Exception : Cache001
      issued by : G4CacheReference<V>::Destroy
Internal fatal error. Invalid G4Cache size (requested id: 50 but cache has size: 48 Possibly client created G4Cache object in a thread and tried to delete it from another thread!
*** Fatal Exception *** core dump ***
[G4-cerr]  **** Track information is not available at this moment
[G4-cerr]  **** Step information is not available at this moment
[G4-cerr]
-------- EEEE -------- G4Exception-END --------- EEEE -------

[G4-cerr]
[G4-cerr] *** G4Exception: Aborting execution ***
Aborted

Do you know where it could come from? It might be related to the Coincidence sorting as I get many more Singles than Coincidences, e.g. the eventIDs go to 250 in the Singles file, they only go to 30 in the Coincidences file.

Best
Christoph

[dsarrut]

Hi,
I don't know. Did you have Multithreading enabled in your Geant4 version ?
And for sure, the number of Coincidences must not be higher than the nb of Singles. Try to disable the sorter to check if it is related

[chris-clem]

Hello,

thank you for your quick answer.

I don't have Multithreading enabeld.
I disabled the sorter and got the same problem.

I know that the number of Coincidences is lower than the number of Singles but find it weird that the eventIDs on the Coincidences suddenly stop. It seems like the CacheError is preventing more Coincidences to be written.

[djboersma]

Can you make a short and simplified version of your simulation, which still results in a crash, and then share the scripts for that simulation with us so that others can try to reproduce the crash? Also please specify exactly which version of GATE you are using, with which Geant4 release. Info about the OS (e.g. which version of Linux or MacOSX) could also be important. I think it could be useful to run that example in a debugger (e.g. "gdb") to find out where and why this crash happens.

[chris-clem]

Hi,

I played around with my digitizer and figured out that adding Time Resolution removes the error:

/gate/digitizer/Singles/insert timeResolution
/gate/digitizer/Singles/timeResolution/setTimeResolution 1.4 ns

I still have the problem with the eventIDS in the Coincidences file, but I will first do some more debugging on my side and try to produce a simplified version of the script.

[chris-clem]

I figured the problem out: I was testing it with too few primaries. If I increase the number of primaries, the ratio of Coincidences vs. Singles becomes reasonable.

Thanks for your help!

[djboersma]

It's nice that increasing the number of primaries made your crash go away, but it's still not nice that the code crashes with a lower number of primaries. That is still a bug that needs to be fixed, I think.

[chris-clem]

Hi,

I played around with my digitizer and figured out that adding Time Resolution removes the error:

/gate/digitizer/Singles/insert timeResolution
/gate/digitizer/Singles/timeResolution/setTimeResolution 1.4 ns

I still have the problem with the eventIDS in the Coincidences file, but I will first do some more debugging on my side and try to produce a simplified version of the script.

The crash was fixed by adding the timeResolution steps.
The low-number-of-coincidences problem was fixed by increasing the number of primaries.

[dsarrut]

Hi, sorry to be late on this, but indeed, I already experienced such a crash with a low number of particles. A that time, I think a patch was done (#267) but it seems it was not enough. I think we should keep the issue open and try to correct the bug. It must not crash in this case.

@chris-clem do you mind sharing the macro files that lead to a crash ? thanks !

[kochebina]

Do you know where it could come from? It might be related to the Coincidence sorting as I get many more Singles than Coincidences, e.g. the eventIDs go to 250 in the Singles file, they only go to 30 in the Coincidences file

This comportment of Coincidence Sorter is known: it is the matter of the buffer used for Coincidence Sorter.
The way how Coincidence Sorter works:
Starting from the 1st event, event-by-event it fills a buffer that would be read to construct coincidences. When buffer reaches the needed size, starting from nth event, also event-by-event sorter starts to create pairs of coincidences. It means that at the end of the run we have a buffer with some pairs that are not processed and just lost.
For simulations with a high number of events (usually our work cases), it is almost invisible to lost 200 events from millions
but in such test cases as yours we see it directly.

[kochebina]

Hi Chris,

I tried to reproduce your problem but without any success. I am not sure that it is Coincidence Sorter problem.
Could you share all your macros somewhere that bring you to the crash, please ?

Cheers,
Olga