Closed ianna closed 3 years ago
@ianna Several comments here: 1) Given the code in G4 I have difficulties to imagine how you could have physical volume assemblies in G4 with such a naming. This must be a naming convention in DDD and hence is not supported by G4. In G4 you have no handle on the names, they are simply generated. 2) If you want things to be changed, you have to define an exact syntax how the naming convention of assemblies should look like.
@MarkusFrankATcernch - ROOT keeps an Assembly as a layer without a shape, but with a name and copy number.
So, it's in your hands to convert it to G4 accordingly. One solution could be that when you encounter an Assembly, you append the Assembly children names with the Assembly name and the Assembly copy number, for example:
VOLUME_NAME__in__ASSEMBLY_NAME_#ASSEMBLY_COPY_NO_#VOLUME_COPY_NO
so __in__
(or something more unique) would be a separator between the Volume name and its mother name. Doesn't G4 provide something that is suitable/configurable?
G4 to my knowledge does not provide anything like this. The PV-name of imprints is determined by the sequence id of the imprint ans the sequence id of the placement within the imprint. Since on none of these numbers you have a handle I was amazed you depend on something you did not have before.
G4 to my knowledge does not provide anything like this. The PV-name of imprints is determined by the sequence id of the imprint ans the sequence id of the placement within the imprint. Since on none of these numbers you have a handle I was amazed you depend on something you did not have before.
We did not use Assemblies before. The numbering scheme that assigns DetId depends on the full path of the Volume names and their Copy Numbers. If G4 optimises an Assembly out and drops a Name/Copy# at a certain level, we cannot assign a proper DetId :-(
You will have to live with what G4 provides here, but for me it is clear: concerning assemblies G4 screwed it.
I suggest for assemblies to use a convention like:
G4-ASSEMBLY_ID:ASSEMBLYNAME#ASSEMBLY_COPY_NO:VOLUME_NAME#VOLUME_COPY_NO
You first split by ':', then item 1,2 by '#'. Should be straight forward.
You will have to live with what G4 provides here, but for me it is clear: concerning assemblies G4 screwed it. I suggest for assemblies to use a convention like: G4-ASSEMBLY_ID:ASSEMBLYNAME#ASSEMBLY_COPY_NO:VOLUME_NAME#VOLUME_COPY_NO You first split by ':', then item 1,2 by '#'. Should be straight forward.
We use :
for a namespace. Could it be !
or ?
OK. I will put this: G4-ASSEMBLY_ID!ASSEMBLYNAME#ASSEMBLY_COPY_NO!VOLUME_NAME#VOLUME_COPY_NO
@bsunanda - FYI
@ianna Good morning! Could you give a try to the git master please?
@ianna Good morning! Could you give a try to the git master please?
thanks, will do it asap
Yana, can there be a special build of CMSSW with these changes? That will help the test. Sunanda
From: Ianna Osborne @.*** Sent: 15 April 2021 13:02 To: AIDASoft/DD4hep Cc: Sunanda Banerjee; Mention Subject: Re: [AIDASoft/DD4hep] Geant4Converter to keep a parent Assembly copy number in the name of its children (#804)
@iannahttps://github.com/ianna Good morning! Could you give a try to the git master please?
thanks, will do it asap
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/AIDASoft/DD4hep/issues/804#issuecomment-820335469, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABGMZOVKZDHH3YBE45GX33DTI3BTRANCNFSM42ZD33CQ.
@MarkusFrankATcernch - it looks good. Thanks!
Currently the copy numbers of the daughter as well as the mother (Assembly) both are lost.
This is the default hierarchy and numbering from DDD: EBRY_04:1, ECLR_04:1, EWRA_04:1, EWAL_04:5, EHAWR:1, EFAW:6, ESPM:12, EBAR:1, ECAL:1, CALO:1, CMSE:1, DDDWorld:0
One expects the copy #'s in a given range: for EWAL to be between 1 and 5 EHAWR to be between 1 and 2 EFAW to be between 1 and 10 ESPM to be between 1 and 36
These are 2 examples from the new code where
ESPM
andEHAWR
are defined asAssemblies
:EBRY_17_1:1, ECLR_17_1:1, EWRA_17_1:1, EWAL_17_pv_89:92, EFAW_pv_4:7, EBAR_1:1, ECAL_1:1, CALO_1:1, CMSE_1:1, OCMS_1:1, world_volume_1:1
EBRY_06_1:1, ECLR_06_1:1, EWRA_06_1:1, EWAL_06_pv_28:31, EFAW_pv_12:28, EBAR_1:1, ECAL_1:1, CALO_1:1, CMSE_1:1, OCMS_1:1, world_volume_1:1
The copy numbers for EWAL or EFAW are combinations. They do not satisfy the above relations. How can to explain EWAL_17_pv_89 with copy # 92 and EFAW_pv_4 with copy # 7 EWAL_06_pv_28 with copy # 31 and EFAW_pv_12 with copy # 28