Put field into stepper state #294
Conversation
| @@ -68,6 +73,8 @@ class rk_stepper final : public base_stepper<track_t, constraint_t, policy_t> { | |||
| array_t<scalar, 4> k_qop; | |||
| } _step_data; | |||
|
|
|||
| const magnetic_field_t _magnetic_field; | |||
There was a problem hiding this comment.
Is this a good idea? A stepper state exists for every track as part of the propagator state, which would mean we end up with thousands of b-field copies if we don't pass this by pointer. Also, the b-field [pointer] in the stepper instead of the e.g. the propagator state means, we get a b-field data member in the line stepper, which does not seem right in terms of inheritance. For the navigator we have the tracking geometry as a pointer already. I know its bad design to have to guarantee the lifetime of the data outside the class that uses it, but I don't see a good way to do it differently?
There was a problem hiding this comment.
I agree. I changed it to a pointer
Ok, I was just lazy to calculate the surface placement myself when the stepper essentially does the same thing already :D |
|
Yeah Using ray or helix would make the interface easier.
|
|
It's also ready |
…eld-into-state
…eld-into-state
…eld-into-state
|
@niermann999 Do you have more comments for this PR? |
Oh, sorry, I forgot about this one. Please go ahead |
|
Can we merge my PRs first, though? |
…eld-into-state
|
It's also rebased |
|
This probably only works precisely for homogeneous b fields, come to think of it, but I don't think that's a problem, so let's get this in |
Depends on #293.
Actually it was a painful job because the stepper is used in the telescope geometry. In my opinion, we should use
rayandhelixinstead...@niermann999 I made
create_telescope_detectortake ray/helix instead of track_parameters