We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hi,
k4geo/FCCee/CLD/compact/CLD_o2_v07/InnerTracker_o2_v08.xml
Line 41 in 9e9c87f
wouldn't it be more geometrically-correct to use
rmin="tan ( ITEnvelopeClearanceConeHalfAngle ) * ConeBeamPipe_zmax"
rather than
rmin="ITEnvelopeClearanceConeHalfAngle * ConeBeamPipe_zmax" ? (the difference is <3 mm in this case, but for ease of understanding the code...)
rmin="ITEnvelopeClearanceConeHalfAngle * ConeBeamPipe_zmax"
Similar construction in few other places, too.
The text was updated successfully, but these errors were encountered:
Hi @danieljeans ,
You are correct, and as long as there are no overlaps I don't care about the precise dimensions of the envelope there. But you know #369 (comment) ...
So it depends how those inner tracker endcap inner radii were calculated and a few mm difference there could be painful...
Sorry, something went wrong.
This also confused me before (but I was also not aware of tan() being possible in the xml...). We should probably improve this at some point.
tan()
No branches or pull requests
Hi,
k4geo/FCCee/CLD/compact/CLD_o2_v07/InnerTracker_o2_v08.xml
Line 41 in 9e9c87f
wouldn't it be more geometrically-correct to use
rmin="tan ( ITEnvelopeClearanceConeHalfAngle ) * ConeBeamPipe_zmax"
rather than
rmin="ITEnvelopeClearanceConeHalfAngle * ConeBeamPipe_zmax"
? (the difference is <3 mm in this case, but for ease of understanding the code...)
Similar construction in few other places, too.
The text was updated successfully, but these errors were encountered: