[Gate-users] Issues on voxelized dose calculations for a phantom
Alex Vergara Gil
alexvergaragil at gmail.com
Mon May 18 15:24:57 CEST 2015
Dear David
I have found a critical bug in GateVImageVolume when using
RangeTranslator that makes a replacement in the first range material
always to Air, if I try to replace this behavior to actually use the
material, then it replace all the Air occurrences by this material, I
think this is a wrong behavior, the range file should be the one that
describes ranges and there should not be a default first range to Air,
this doesn't happens with Hounsfiled translator, but just because it
happens that the first Material is always Air in Hounsfield table. So
either move to Hounsfield translator (avoid using range translator,
therefore no more user segmentation is allowed) or try to use always
Air as first material segmentation, it wont be used at all, but at
least simulation will have some meaning.
Specific details as follow:
void GateVImageVolume::LoadImageMaterialsFromRangeTable()
...
G4String parentMat = GetParentVolume()->GetMaterialName();
mRangeMaterialTable.AddMaterial(pImage->GetOutsideValue(),pImage->GetOutsideValue()+1,parentMat);
/*
the GetOutsideValue procedure returns the lowest value in the
segmentation minus 1
so if you have a segmentation from 1 to 5 the returned value is 0 and
the parent material
will have the range from 0 to 1
*/
...
if(r2> pImage->GetOutsideValue()+1){
if(r1<pImage->GetOutsideValue()+1) r1=pImage->GetOutsideValue()+1;
mRangeMaterialTable.AddMaterial(r1,r2,material,
new G4VisAttributes(visible, G4Colour(red, green, blue, alpha)));
}
/*
here lies the bug, so the end of first material range must be higher
than the minor element in the segmentation, odd since this first
material have a value of 1 which is already taken by the parent
material
*/
now trying to do something like:
if(r2> pImage->GetOutsideValue()){
if(r1<pImage->GetOutsideValue()+1) r1=pImage->GetOutsideValue()+1;
mRangeMaterialTable.AddMaterial(r1,r2,material,
new G4VisAttributes(visible, G4Colour(red, green, blue, alpha)));
}
/*
forcing to use the first range material is also wrong, since this
replaces the already defined first material (Air), so it is no longer
used.
*/
I can't manage myself to find a good solution for this, so I will move
my segmentation definitions to use Air as first material, this is not
elegant, since the air I define is not used at all, but default Air
created inside Gate, so the bug remains but at least I can still
simulate something since the Air is present in my simulation. Now
imagine a situation where there is no Air at all, then how should I
proceed then?
Regards
Alex
2015-05-07 11:01 GMT-04:00, Alex Vergara Gil <alexvergaragil at gmail.com>:
> Dear David
>
> Except case 3 which does not exists, yes that's right. The problem is
> not when converting to dose from edep, but when creating the voxelized
> density matrix, somewhere is assigning a wrong material.
>
> Regarding a big pull request, I created several small commits and push
> one by one, it creates a big pull request, so I must ask how to create
> a small request since pushing changes are accumulative in the pull
> request. Again sorry for my ignorance on git ;)
>
> Regards
> Alex
>
> 2015-05-06 2:21 GMT-04:00, David Sarrut
> <David.Sarrut at creatis.insa-lyon.fr>:
>> Hello Alex,
>>
>> I just merge your pull-request, thanks again for the contribution !
>> Please
>> for the future, if possible try to propose several smaller "pull request"
>> rather than a single big one, it makes it more simple for me to update.
>>
>> regarding the question about the three classes and the
>> same ReadTranslationTable, this is probably not intented but the history
>> of
>> Gate is close to the one of the dinosaurs, so I dont know ;) As you
>> describe in the github thread
>> (https://github.com/OpenGATE/Gate/issues/18)
>> there is probably a bug somewhere around material affectation in this
>> configuration. To be sure I understand:
>>
>> - case1: analytical phantom + gps = correct result
>> - case2: voxelized phantom + gps = correct result
>> - case3: analytical phantom + voxelized source = correct result
>> - case4: voxelized phantom + voxelized source = wrong result
>>
>> is that true ?
>>
>> David
>>
>>
>>
>>
>> On Tue, May 5, 2015 at 10:33 PM, Alex Vergara Gil
>> <alexvergaragil at gmail.com>
>> wrote:
>>
>>> Dear All
>>>
>>> I have created an Issue on github for this thread where I explain my
>>> problems (and my findings).
>>>
>>> Regards
>>> Alex
>>>
>>> 2015-05-04 12:11 GMT-04:00, Alex Vergara Gil <alexvergaragil at gmail.com>:
>>> > Dear All
>>> >
>>> > I have seen three files
>>> >
>>> > GateVImageVolume
>>> > GateGeometryVoxelRangeTranslator
>>> > GateGeometryVoxelTabulatedTranslator
>>> >
>>> > with the same ReadTranslationTable procedure. Is this intended? Is
>>> > there an intention to put this procedure in the last two classes?
>>> > There is currently no relation between these three classes more than
>>> > the last two inherits from the same class. What is the intention in
>>> > this case? It affects how a translation table is read and passed to
>>> > G4.
>>> >
>>> > Regards
>>> > Alex
>>> >
>>> > 2015-04-30 11:26 GMT-04:00, Alex Vergara Gil
>>> > <alexvergaragil at gmail.com>:
>>> >> Dear all
>>> >>
>>> >> I think I have found a posible bug related to my issue (possible
>>> >> wrong
>>> >> material handler in voxelized range translator, giving bad density
>>> >> values and therefore bad dose calculations). In the file
>>> >> GateGeometryVoxelRangeTranslator.cc, specifically in the function
>>> >>
>>> >> G4String GateGeometryVoxelRangeTranslator::GetNextMaterial(G4bool
>>> >> doReset)
>>> >> {
>>> >> static GateVoxelMaterialTranslationRangeVector::iterator anIterator
>>> >> = m_voxelMaterialTranslation.begin();
>>> >>
>>> >> if (doReset)
>>> >> anIterator = m_voxelMaterialTranslation.begin();
>>> >>
>>> >> G4String aMaterial = ( anIterator!=m_voxelMaterialTranslation.end()
>>> >> ) ? anIterator->second : G4String("") ;
>>> >> if (aMaterial!="")
>>> >> anIterator++;
>>> >>
>>> >> return aMaterial;
>>> >> }
>>> >>
>>> >> Here you may see that the iterator is initialized every time the
>>> >> function is called, I think it is better to put the iterator as a
>>> >> variable, but you know better than me, so please could you explain
>>> >> why
>>> >> it is used a static iterator here?
>>> >>
>>> >> Regards
>>> >> Alex
>>> >>
>>> >>
>>> >> 2015-04-30 8:07 GMT-04:00, Kiran Joshi <kiran.j88 at gmail.com>:
>>> >>> On Thu, 30 Apr 2015 at 13:01 Alex Vergara Gil <
>>> alexvergaragil at gmail.com>
>>> >>> wrote:
>>> >>>
>>> >>>> Dear all
>>> >>>>
>>> >>>> Attached I explain my problems.
>>> >>>>
>>> >>>> Regards
>>> >>>> Alex
>>> >>>> _______________________________________________
>>> >>>> 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 U 1044
>> 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"
>> _________________________________
>>
>
More information about the Gate-users
mailing list