[Gate-users] Report of GATEv8.2 bugs (PETscanner "level5" is NOT working)

Thu Mar 12 11:07:42 CET 2020

Hi,

many thanks to all for this really interesting discussion/report! It is
really useful.

May I suggest that you gather all those pieces of information in a folder
with example macro and an explaining pdf, and propose a PR in GateContrib
(do not forget to enable git LFS first please)?

It will allow to keep track and help a lot of users.

(Note this is not related to the V9.0 release, it is an example for users
so don't be in a rush. Note also that we can help if needed to create the
PR)

Sincerely,
David

On Wed, Mar 11, 2020 at 6:08 PM Zhengzhi Liu <zliu36 at stanford.edu> wrote:

> I have achieved my goal by averaging the location of hits in each crystal.
> But just wondering if there is a deterministic way to get the spatial
> position of crystals.
>
> On Wed, Mar 11, 2020 at 9:03 AM Zhengzhi Liu <zliu36 at stanford.edu> wrote:
>
>> Hi Maxime,
>>
>> Thanks for reading my email and looking into it. Thanks for confirming
>> the legitimacy of my doubt. I wish it would allow users to
>> use TakeEnergyCentroid.
>>
>> Please allow me to rephrase my sentences as follows:
>> In my system, each crystal is coupled to a single readout channel. In
>> order to align my simulated system with my real system, I wanted to
>> register the center of each crystal in Gate then to compare it with that of
>> my real system, for which I have already got the data.  The way I can think
>> of to achieve the measurement of crystal center location in Gate is by
>> using TakeEnergyCentroid and setting readout depth to crystal level.
>>
>> To be short, Yes, I want the spatial position of my crystals.
>>
>>
>> Thanks for your time and wisdom.
>>
>> Warmest regards,
>> Zhengzhi
>>
>>
>>
>> On Wed, Mar 11, 2020 at 8:43 AM Maxime Toussaint <
>> Maxime.Toussaint at usherbrooke.ca> wrote:
>>
>>> Greetings,
>>>
>>> The documentation claim that this policy is applied relative to a
>>> "crystal" component. Since PetScanner configuration do not possess that
>>> component, it make sense that it will not work. When in doupt, the code
>>> can't(Most of the time) lie. In [1], you can see that the "crystal"
>>> component is required. I have no idea why, however.
>>>
>>> Also, i am not sure I understand the following: "Basically, what I am
>>> trying to achieve is to measure the location of each crystal center since
>>> each crystal is coupled to a single readout PMT/readout channel in my
>>> design." You want to know the spatial position of your crystals?
>>>
>>> Have a nice day,
>>> Maxime Toussaint
>>>
>>>
>>> [1]
>>> https://github.com/OpenGATE/Gate/blob/f2d9a5e19d568c71fe11b64a05d4f6037a208841/source/digits_hits/src/GateReadout.cc
>>>
>>> ------------------------------
>>> *De :* Zhengzhi Liu <zliu36 at stanford.edu>
>>> *Envoyé :* 9 mars 2020 20:34
>>> *À :* 강한규 <lovehangulp at naver.com>; Maxime Toussaint
>>> <Maxime.Toussaint at USherbrooke.ca>
>>> *Cc :* gate-users <gate-users at lists.opengatecollaboration.org>
>>> *Objet :* Re: [Gate-users] Report of GATEv8.2 bugs (PETscanner "level5"
>>> is NOT working)
>>>
>>> A follow-up question, does PETScanner work with TakeEnergyCentroid
>>> policy?
>>>
>>> In my simulation using the PETScanner system, everything works fine and
>>> it has been validated to a certain degree. However, soon as I switched to
>>> TakeEnergyCentroid policy, no matter what the readout depth is, the core
>>> dumped. The error message is shown in the screenshot below. According to
>>> the error message, it looks like it was trying to find the system component
>>> "crystal", however, "crystal" is not defined in the PETScanner/scanner as
>>> shown in its hierarchy below.
>>>
>>> Basically, what I am trying to achieve is to measure the location of
>>> each crystal center since each crystal is coupled to a single readout
>>> PMT/readout channel in my design. The way I can think of is setting the
>>> readout depth to crystal level and using TakeEnergyCentroid policy,
>>> however, it crashes in the PETScanner system.
>>>
>>> Any suggestions? Is PETScanner compatible with akeEnergyCentroid policy?
>>> Or I have messed something up.
>>>
>>> Thank you very much for help.
>>>
>>> Zhengzhi
>>>
>>>
>>>
>>>
>>>
>>> On Sat, Mar 7, 2020 at 2:48 PM Zhengzhi Liu <zliu36 at stanford.edu> wrote:
>>>
>>> Dr. Han Gyu,
>>>
>>> Thank you for your detailed explanation and for showing us your
>>> excellent work. You have been a great help to many GATE users (like me) in
>>> this community.
>>> Thank you very much and look forward to meeting you in person in future
>>> conferences.
>>>
>>> Sincerely,
>>> Zhengzhi
>>>
>>> On Fri, Mar 6, 2020 at 10:25 PM 강한규 <lovehangulp at naver.com> wrote:
>>>
>>> Dear Zhengzhi and Maxime,
>>>
>>>
>>>
>>> Recently, I have been busy so I was not able to answer your questions.
>>>
>>>
>>>
>>> I also experienced that the *"level5" is NOT working for "PETscanner"
>>> in GATEv6.2*.(slide#3-4)
>>>
>>> The solution was *to attach the "layer1"* to the 4th layer crystal as
>>> Maxime mentioned.
>>>
>>>
>>>
>>> Attached is my work about GATEv6.2 simulation for *staggered 4-layer
>>> DOI PET scanner*.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> After GATE simulation and image reconstruction, I obtained the PET image
>>> successfully.(slide#5-11)
>>>
>>> The GATE output and crystal ID information are summarized.(slide#12-18)
>>>
>>>
>>>
>>> By the way, if you want more layers, then you can use just
>>> "genericRepeater".
>>>
>>> In doing so you can place the crystal array whatever you like.
>>>
>>> In this case, you need two system attachments as below.
>>>
>>> -level1 (for PET block)
>>>
>>> -level2 (for crystal with genericRepeater)
>>>
>>>
>>>
>>> Hopefully, my answer would be helpful for your works.
>>>
>>>
>>>
>>> Best regards,
>>>
>>>
>>>
>>> Han Gyu
>>>
>>>
>>>
>>>
>>> --------Han Gyu Kang, Ph.D, Researcher
>>>
>>> National Institute of Radiological Sciences (NIRS)
>>> National Institutes for Quantum and Radiological Science and Technology
>>> (QST)
>>>  4-9-1 Anagawa, Inage-ku, Chiba 263-8555, JAPAN
>>>
>>>
>>>
>>> -----Original Message-----
>>> *From:* "Maxime Toussaint"<Maxime.Toussaint at USherbrooke.ca>
>>> *To:* "gate-users at lists.opengatecollaboration.org"<
>>> gate-users at lists.opengatecollaboration.org>;
>>> *Cc:*
>>> *Sent:* 2020-03-07 (토) 12:46:38 (GMT+09:00)
>>> *Subject:* Re: [Gate-users] Report of GATEv8.2 bugs
>>>
>>> Greetings,
>>>
>>> Sorry, I explained myself poorly. level1 to level4 are okay. What I
>>> meant was to change level5 to either layer0 or layer1.
>>>
>>> Bests,
>>> Maxime Toussaint
>>> ------------------------------
>>> *De :* Zhengzhi Liu <zliu36 at stanford.edu>
>>> *Envoyé :* 6 mars 2020 22:39
>>> *À :* Maxime Toussaint <Maxime.Toussaint at USherbrooke.ca>
>>> *Objet :* Re: [Gate-users] Report of GATEv8.2 bugs
>>>
>>> Hi Maxime,
>>>
>>> Thank you very much as well. I tried your suggestion of replacing level1
>>> to level5 with layer0 to layer4 in PETScaner. It failed at layer2 and does
>>> not allow me to add layer2 and later layers. It worked fine with 2layers.
>>> Could you please verify this with your code by adding some simple dummy
>>> layers to your code?
>>> Here is the errormsg:
>>> [image: Screenshot from 2020-03-06 19-37-02.png]
>>>
>>> Thank you very much sincerely.
>>>
>>> Zhengzhi
>>>
>>> On Fri, Mar 6, 2020 at 7:04 PM Maxime Toussaint <
>>> Maxime.Toussaint at usherbrooke.ca> wrote:
>>>
>>> Greetings,
>>>
>>> I quickly looked at the code and I think I found the problem. In short,
>>> the documentation is correct for the current version of the Gate code on
>>> github but not for Gate 8.2.
>>>
>>> If we look at [1], we see that a change was made from having
>>> PETscanner/scanner system with components called layer0/layer1 to one
>>> called level5. That change was committed the 9th of May 2019 while Gate 8.2
>>> seems to be a Februray 2019 version of the code.
>>>
>>> I tried using layer0 (and later layer1) and Gate did not produce any
>>> warning nor bug. Note that this does not prove that the resulting system
>>> work.
>>>
>>> Also, "PETscanner" is a valid system definition. I will propose a
>>> modification of the table 1.2 to make it more explicit.
>>>
>>> This situation does highlight a little problem. From my understanding,
>>> the current version of the user guide follow the code on github but it is
>>> also used for the current stable version of Gate (8.2 at the moment). If I
>>> am correct, I would propose that a version of the user guide, extracted at
>>> the same time as the official version, be saved separately from the
>>> "latest" and a note added saying something like "correction to the user
>>> guide are only applied on the latest version". After all, we can't expect
>>> anyone to adapt all versions of the user guide each time the user guide is
>>> enhanced.
>>>
>>> Hope that I could help and have a nice day,
>>> Maxime Toussaint
>>>
>>>
>>> [1]
>>> https://github.com/OpenGATE/Gate/blame/cbe7ffb1c3222b5c1801eb7bc8b703253540e6b1/source/geometry/src/GateScannerSystem.cc
>>> <https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOpenGATE%2FGate%2Fblame%2Fcbe7ffb1c3222b5c1801eb7bc8b703253540e6b1%2Fsource%2Fgeometry%2Fsrc%2FGateScannerSystem.cc&data=02%7C01%7CMaxime.Toussaint%40usherbrooke.ca%7C7c194e0ad8b8458980d208d7c48ae8d6%7C3a5a8744593545f99423b32c3a5de082%7C0%7C0%7C637193973212126017&sdata=L%2B6wmzXNj%2BY5CEAxtwyT9T5QLqOgteVaFv3O%2FhIfdcA%3D&reserved=0>
>>> ------------------------------
>>> *De :* Gate-users <gate-users-bounces at lists.opengatecollaboration.org>
>>> de la part de Matthew Strugari <matthew.strugari at dal.ca>
>>> *Envoyé :* 6 mars 2020 20:57
>>> *À :* Zhengzhi Liu <zliu36 at stanford.edu>; gate-users <
>>> gate-users at lists.opengatecollaboration.org>
>>> *Objet :* Re: [Gate-users] Report of GATEv8.2 bugs
>>>
>>>
>>> Hi Zhengzhi,
>>>
>>>
>>>
>>> According to the user manual (Section 1.5.1
>>> https://opengate.readthedocs.io/en/latest/defining_a_system_scanner_ct_pet_spect_optical.html#defining-the-systems
>>> <https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopengate.readthedocs.io%2Fen%2Flatest%2Fdefining_a_system_scanner_ct_pet_spect_optical.html%23defining-the-systems&data=02%7C01%7CMaxime.Toussaint%40usherbrooke.ca%7C7c194e0ad8b8458980d208d7c48ae8d6%7C3a5a8744593545f99423b32c3a5de082%7C0%7C0%7C637193973212126017&sdata=pKVc7m0txcRWujIUCIAbhUzqmwyonTNuM9ToKD7MbFo%3D&reserved=0>),
>>> the system name must be one of those available in Table 1.1. In the image
>>> you provided, this would be Table 4.1. I’m not sure which version of the
>>> user manual you are referring to, but the most up to date information can
>>> be found on readthedocs. Nonetheless, your error of COMMAND NOT FOUND shows
>>> that you defined the system name to be PETscanner which is not a valid
>>> system name. Replace “PETscanner” with “scanner” and you should be able to
>>> assign level5 with the defined functionality.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Matthew
>>>
>>>
>>>
>>> *From: *Gate-users <gate-users-bounces at lists.opengatecollaboration.org>
>>> on behalf of Zhengzhi Liu <zliu36 at stanford.edu>
>>> *Date: *Friday, March 6, 2020 at 7:30 PM
>>> *To: *gate-users <gate-users at lists.opengatecollaboration.org>
>>> *Subject: *Re: [Gate-users] Report of GATEv8.2 bugs
>>>
>>>
>>>
>>> According to the user manual, 5 levels can be attached. However, I am
>>> not able to attach any 5th level. Please share your thoughts if you have
>>> some experience.  Thanks a lot.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Mar 6, 2020 at 3:17 PM Zhengzhi Liu <zliu36 at stanford.edu> wrote:
>>>
>>> Report of a potential bug:
>>>
>>>
>>>
>>> It looks PETScanner only allows 4 layers to be attached, whenever I
>>> tried to attach the 5th layer (no matter what the geometry is), it throws
>>> the errormsg.  Has anyone been able to attach a 5 level to PETScanner?  My
>>> understanding is Gate doesn't recognize the keyword *level5*.
>>>
>>>
>>>
>>> Thanks for reading.
>>>
>>>
>>>
>>> Sincere greetings,
>>>
>>> Zhengzhi
>>>
>>> _______________________________________________
>>> Gate-users mailing list
>>> Gate-users at lists.opengatecollaboration.org
>>> http://lists.opengatecollaboration.org/mailman/listinfo/gate-users
>>> <https://can01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.opengatecollaboration.org%2Fmailman%2Flistinfo%2Fgate-users&data=02%7C01%7CMaxime.Toussaint%40usherbrooke.ca%7C7c194e0ad8b8458980d208d7c48ae8d6%7C3a5a8744593545f99423b32c3a5de082%7C0%7C0%7C637193973212136013&sdata=vQ23ttE5IYM8ViHLXNUhFoT4ehhxAg3qkBkA3Gnubbg%3D&reserved=0>
>>>
>>> _______________________________________________
>>> Gate-users mailing list
>>> Gate-users at lists.opengatecollaboration.org
>>> http://lists.opengatecollaboration.org/mailman/listinfo/gate-users
>>
>> _______________________________________________
> Gate-users mailing list
> Gate-users at lists.opengatecollaboration.org
> http://lists.opengatecollaboration.org/mailman/listinfo/gate-users

-- 
David Sarrut, Phd
Directeur de recherche CNRS
CREATIS, UMR CNRS 5220, Inserm U1206
Centre de lutte contre le cancer Léon Bérard
28 rue Laënnec, 69373 Lyon cedex 08
Tel : 04 78 78 51 51 / 06 74 72 05 42
http://www.creatis.insa-lyon.fr/~dsarrut
_________________________________
 "2 + 2 = 5,  for extremely large values of 2"
_________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengatecollaboration.org/pipermail/gate-users/attachments/20200312/b8f4e297/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 110290 bytes
Desc: not available
URL: <http://lists.opengatecollaboration.org/pipermail/gate-users/attachments/20200312/b8f4e297/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 75696 bytes
Desc: not available
URL: <http://lists.opengatecollaboration.org/pipermail/gate-users/attachments/20200312/b8f4e297/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2020-03-06 19-37-02.png
Type: image/png
Size: 62507 bytes
Desc: not available
URL: <http://lists.opengatecollaboration.org/pipermail/gate-users/attachments/20200312/b8f4e297/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1583560761537.png
Type: image/png
Size: 193277 bytes
Desc: not available
URL: <http://lists.opengatecollaboration.org/pipermail/gate-users/attachments/20200312/b8f4e297/attachment-0007.png>