|Message: How to stop at a given plane||Not Logged In (login)|
Click on the Forum title, e.g. on the "Forums by Category" page, to read a sequence of postings to the Forum and its threads all in one page. If you are only interested in one thread or the thread following a specific posting, click the thread or the posting, which takes you to a smaller page, which contains only the part you are interested in and may be easier to navigate.
Messages are "chained" if there are only replies at the first level, i.e. 1/1.html, 1/1/1.html etc. In case of "chained" messages the message number is replaced by the icon and there is no indentation.
Inline: Display the subject line only or also the text of the posting(s); for the choice "All" the "Outline" choices are switched off.
|1||0||1||no text / full text of posting|
|2||1||All||text for level 1 only / text for All postings|
Outline: Choose the depth of the posting thread, successive toggle controls provide increasing detail.
|1||2||1||2 levels / 1 level (original posting)|
|2||3||2||3 levels / 2 levels|
|3||3||All||3 levels / all levels (all postings)|
I need to arrange for all tracks to take a step located on a given coordinate plane (not necessarily parallel to any axis). At present I have a process that limits the step when approaching the plane, but it is extremely inefficient to hit it exactly, so it makes sure there are two steps bracketing the plane and within 4 mm of it; UserSteppingAction then interpolates to the desired plane. This is still inefficient (and rather ugly).
Is it possible to construct a "pseudo volume" or modify the navigator so it will treat this plane as a geometry boundary and make transportation naturally stop at it? A normal volume won't work because of invalid intersections with the real geometry of the system. No volume transition is needed, just having a step on the plane (within the usual tolerance) is enough, and UserSteppingAction will sense it and use it.
Note I actually have a std::vector<> of such planes. Think a few dozen entries, not thousands. They need not be parallel to each other. Due to other details of the problem, they are ordered (because tracks are restricted to be inside a beam pipe, and the planes are perpendicular to the pipe; bending magnets make corners in the pipe), so only 2 entries are relevant at any given step (one in front and one behind; particles can go backwards).
[why do I need this? because I implement a "virtual detector" that fills an NTuple at a given coordinate Z value; the coordinates used are not the global coordinates (though the transform is known).]
|Inline Depth:||Outline Depth:||Add message:|