Extend magnetic field to full tracker volume

[andread3vita]

BEGINRELEASENOTES

• Update the z boundary of the magnetic field definition from Solenoid_Coil_half_length to 1.2 * Solenoid_Coil_half_length

ENDRELEASENOTES

Hello all!
This pull request extends the magnetic field map currently used in IDEA v3 o1 to cover the full tracker volume. In the current implementation, the magnetic field returns zero in the endcap region of the silicon wrapper.
This modification is necessary to ensure consistent track propagation from the last hit in the tracker to the calorimeter surface. This step is performed by the track fitter, which checks the magnetic field value at the last hit before propagating the track. If the field value is zero or invalid, the propagation is skipped, because it should occur only for tracks outside the tracker, that do not require propagation to the inner calorimeter surface.
Furthermore, the magnetic field value directly affects the estimation of track parameters at the last track state. Ensuring a consistent field in the endcap region therefore improves the reliability of the reconstructed track parameters.

Thank you!
Andrea

[BrieucF]

Hi Andrea,

• please apply any change also to IDEA_o1_v04
• the field extent depends on the IDEA design, we can't really change it as we want for reco purposes. In this case it is mainly a placeholder so I guess it is ok to change it slightly but... see next point
• it would be much better to do the track propagation with a proper algorithm that takes local B-field values, can this be done?

[s6anloes]

it would be much better to do the track propagation with a proper algorithm that takes local B-field values, can this be done?

Can you elaborate, @BrieucF ? I'm failing to see the relation to this PR.
Whether the tracking algorithm takes a local B-field (presumably from a field map), doesn't change that the B-Field is currently 0 in the SiWrapper endcaps, no?

Are you proposing that GenFit should work with detailed field maps instead of using the simplified field from the XML file?

@andread3vita

• please apply any change also to IDEA_o2_v01

[BrieucF]

Can you elaborate, @BrieucF ?

Yes. These are indeed two separated topics, let me explain further what I meant:

• regardless of the field being defined from a map or analytically, the B-field value can be retrieved from the DD4hep geometry at any spacial point (detector.field().magneticField(posV, bfieldV)). The track propagation should be done by steps, using the local field values, instead of taking the field value from a fixed point and assuming the field will remain constant over the extrapolated trajectory. This way the track extrapolation is 1) more correct and 2) robust against any change we apply in the geometry regarding the field. But this can of course be tackled in other PRs.
• regarding the other point, yes, I agree to update the field here so that it has the expected value in the silicon wrapper.

Regarding the modification itself, what about modifying its value from DectDimension instead of what is done here? I see two advantages: 1) everything still runs if we remove the calorimeter xml from the master xml 2) with the current modification, the solenoid geometry becomes in-consistent with the magnetic field. If that leads to overlaps, we have to fix them but we should try to keep a "physical" detector where the field is more or less in sync with the solenoid dimension (this is what I meant with "field extent depends on the IDEA design")

[andread3vita]

Thank you @BrieucF and @s6anloes! According to your comments, I see three possible solutions:

• I can use Solenoid_Coil_half_length instead of Solenoid_half_length
• I can modify the value of Solenoid_Coil_half_length
• I can use 1.5 * Solenoid_Coil_half_length

Probably the first option is more conservative, as it does not change the detector dimensions. Am I missing any other solution?

[BrieucF]

I can use Solenoid_Coil_half_length instead of Solenoid_half_length

This is what is done already, no? Maybe you meant the other way around?

Mind that this still changes some real geometries (see here). Since this geometry is not the baseline anymore, nothing will be re-optimize here. Given that, I think the easiest is to alter <constant name="Solenoid_Coil_half_length" value="Solenoid_half_length-200*mm"/> to lower the margin until the field covers the silicon wrapper (I hope 20 cm will be enough).

Please run the overlap check for this change, as it does modify geometries.

[andread3vita]

Yes sorry, I meant the other way around. I will do that and I will also check if there are overlaps.

[andread3vita]

Just to make sure I understand correctly: why do you think the first solution would also modify the geometry? Wouldn’t it only affect the magnetic field map?

I would change only this line:

k4geo/FCCee/IDEA/compact/IDEA_o1_v03/IDEA_o1_v03.xml

Line 95 in d197ae2

zmax="Solenoid_Coil_half_length"

[mahmoudali2]

Hello all,
I would also like to take the opportunity and raise a point regarding the definition of the magnetic field in the endcap region.

Currently, both the calorimeter and the muon system in the endcap are set to 0 T. Until a detailed field map becomes available, I suggest assigning fixed reversed field values in this region as well, to ensure a more realistic configuration.

Please let me know your thoughts.

Here's what I suggest to add:

    <field name="CompensatingSolenoidZplus" type="solenoid"
           inner_field="-1.7*Tesla"
           outer_field="0*Tesla"
           zmax="1000*cm"
           zmin="Solenoid_Coil_half_length"
           outer_radius="1000*cm">
    </field>

    <field name="CompensatingSolenoidZminus" type="solenoid"
           inner_field="-1.7*Tesla"
           outer_field="0*Tesla"
           zmax="-Solenoid_Coil_half_length"
           zmin="-1000*cm"
           outer_radius="1000*cm">
    </field>

[BrieucF]

Just to make sure I understand correctly: why do you think the first solution would also modify the geometry? Wouldn’t it only affect the magnetic field map?

I would change only this line:

k4geo/FCCee/IDEA/compact/IDEA_o1_v03/IDEA_o1_v03.xml

Line 95 in d197ae2

zmax="Solenoid_Coil_half_length"

Because the solenoid itself (i.e. the physical cylinder hosting equivalent material budget as per current estimation - probably slightly outdated though) is built using this value see the link in my previous message and it is inside a Steel cassette which may cause overlaps.

@mahmoudali2 we can also try to add a more or less realistic field outside of the coil z-extent. But isn't 1.7 way too big (for now we still have 2 T inside the tracking volume)?

[BrieucF]

Just to make sure I understand correctly: why do you think the first solution would also modify the geometry? Wouldn’t it only affect the magnetic field map?
I would change only this line:

k4geo/FCCee/IDEA/compact/IDEA_o1_v03/IDEA_o1_v03.xml

Line 95 in d197ae2

zmax="Solenoid_Coil_half_length"

Because the solenoid itself (i.e. the physical cylinder hosting equivalent material budget as per current estimation - probably slightly outdated though) is built using this value see the link in my previous message and it is inside a Steel cassette which may cause overlaps.

@mahmoudali2 we can also try to add a more or less realistic field outside of the coil z-extent. But isn't 1.7 way too big (for now we still have 2 T inside the tracking volume)?

I should have added that changing this just in the field definition ends up in an inconsistent definition between the coil and the field which is not super nice. But yes, you are right that changing it only there won't change any geometry.

[mahmoudali2]

@mahmoudali2 we can also try to add a more or less realistic field outside of the coil z-extent. But isn't 1.7 way too big (for now we still have 2 T inside the tracking volume)?

@BrieucF Yes, I agree it should be less, I'll check the new field maps from Samuele and try to put an average value.

[s6anloes]

Mind that this still changes some real geometries (see here). Since this geometry is not the baseline anymore, nothing will be re-optimize here. Given that, I think the easiest is to alter to lower the margin until the field covers the silicon wrapper (I hope 20 cm will be enough).

In principle, removing the 20cm space for services would be enough to cover the SiWrapper endcaps.

However, I have checked with Samuele, and he said if anything, 20cm is on the low side of volume to account for support/cryostat/auxiliaries. He is expecting more it to be 20–35cm, though this depends on the field strength and moreover, he is only actively investigating IDEA_o2 with the ECAL in the cryostat at the moment (larger solenoid radius). So this might have an impact as well.

Regarding your comment about IDEA_o1 no longer being the baseline, I guess we could live without the space for the services in the magnet if the material budget is still approximately the same when filling the space with the coil.

To me, the most elegant solution would be to use 1.2 * Solenoid_Coil_half_length (Andrea's third suggestion, though 1.5, which he wrote, might be a bit large, to be confirmed).
It seems a bit silly to assume that the magnetic field stops the exact moment it leaves the volume enclosed by the coil, no?

[BrieucF]

It seems a bit silly to assume that the magnetic field stops the exact moment it leaves the volume enclosed by the coil, no?

Yes, we do need a more realistic description of the field, that is clear. Meanwhile, please proceed with Andreas' suggestion.

But I would still propose that we investigate a step by step track extrapolation which fetches the local B-field value. There seem to be tools in Genfit to do that: https://github.com/GenFit/GenFit/blob/6fd68a96ecc61ca11e2635a48611cee2259a8de4/trackReps/include/RKTrackRep.h#L272

[andread3vita]

Yes, we do need a more realistic description of the field, that is clear. Meanwhile, please proceed with Andreas' suggestion.

But I would still propose that we investigate a step by step track extrapolation which fetches the local B-field value. There seem to be tools in Genfit to do that: https://github.com/GenFit/GenFit/blob/6fd68a96ecc61ca11e2635a48611cee2259a8de4/trackReps/include/RKTrackRep.h#L272

Done! In the other PR I have also commented the track extrapolation.

[BrieucF]

Can you confirm that this covers the silicon wrapper?

[andread3vita]

Can you confirm that this covers the silicon wrapper?

I confirm it. I have checked both numerically and with the fitter.