InputStreamFromROOTFileForCylindricalPET uses wrong conventions for blocks and buckets? about stir HOT 9 CLOSED

Hi Kris,
Alright so the get_num_dets_per_ring() looks clearly a bug to me, right now. They should been the "_y" components.

And I also agree about the get_num_axial_blocks_per_bucket_v().
But then:
int get_num_axial_crystals_per_block_v() const { return static_cast<int>(this->crystal_repeater_z * this->submodule_repeater_z); }

That looks better I think

from stir.

I don't know about "_z" vs "_y". I thought that made sense in the original code.

I don't understand your suggestion for get_num_axial_crystals_per_block_v. Aren't the repeater variables saying how many of the items there are in the encompassing unit? So I'd have thought that my suggestion was correct (of course I thought that!)

from stir.

So the get_num_rings() and get_num_dets_per_ring() must flip. This is a bug.

GATE has one extra level which you have to choose were to merge. I have always considered:
bucket = rsector
block = module+submodule

So num of blocks per bucket is the number of modules per rsector. So, the number of crystals per block is that product of the number of crystals in a submodule by the number of modules in that block.

from stir.

ok. i think we don't see the bug because of the CListModeDataROOT constructor actually swaps them around when making the scanner.

to me, it makes most sense to do

bucket=rsector+module
block=submodule

but I don't know what that means for GATE. I don't really mind which one of these 2 we use, as long as we make it clear...

from stir.

But an rsector moves around the FOV and circulates it completely (most of the time). So you will end having e.g. 4 axial modules and 4 (transaxial modules in an rsector) * 48 (rsectors) = 192 buckets. Does this sound reasonable?

from stir.

I'm a bit confused about what you're trying to say. sorry.

I don't know if an rsector can contain modules that both circle round and translate along the axis (we'd need that letting them correspond to buckets). but really, the only thing that matters here is it somehow corresponds to what GATE does with these things, and what STIR would do with them.

As the Scanner doc says, the bucket stuff is mostly intended for dead-time modelling. In fact, right now STIR ignores all the block stuff, except in the ECAT7 dead-time modelling code. In the near future, STIR will think about blocks (using Parisa's stuff) in the projector. It'd be possible to let the projector think about "modules of blocks" (i.e. "buckets").

what does GATE do?

from stir.

This image tries to describe the concept:
http://wiki.opengatecollaboration.org/images/2/22/Depth-p4.jpg
Then the submodule is just a subdivision of the module.

from stir.

nice figure. thanks.

question is if the rsector/module stuff has anbything to do with how GATE does dead-time modelling, or as that entirely flexible and you can specify that outside?
(I don't see why it'd be useful to merge submodule into a "block", unless a submodule might be a single PMT, but that wouldn't make sense with all the sharing going on)

from stir.

The dead time 'level' is defined by the Singles readout depth := . 1=rsector,2= module etc.
So, as long as the user has is 2 then

bucket=rsector+module
block=submodule]

will check out

from stir.