WARN ++ Overwriting/updating Header structure is very dangerous

[danieljeans]

Check duplicate issues.

• Checked for duplicates

Goal

When using MDI_o1_CADBased_v01, I'm getting several warnings like:

Compact WARN ++ Overwriting/updating Header structure is very dangerous. Try to avoid this.
Compact WARN ++ Header definition in: file://..../k4geo/FCCee/MDI/compact/MDI_o1_CADBased_v01/Beampipe_CADimport_o1_v03.xml

I think they are caused by the "info" sections in
FCCee/MDI/compact/MDI_o1_CADBased_v01/BeamInstrumentation_o1_v01.xml
FCCee/MDI/compact/MDI_o1_CADBased_v01/Beampipe_CADimport_o1_v03.xml
FCCee/MDI/compact/MDI_o1_CADBased_v01/FFQuads_params_v572_Z.xml
FCCee/MDI/compact/MDI_o1_CADBased_v01/FFQuads_v01.xml
FCCee/MDI/compact/MDI_o1_CADBased_v01/fields_antisol_map.xml

Thanks,
Daniel.

Operating System and Version

EL9

compiler

gcc11.4.1

The version of the key4hep stack

nightly

Package Version

current

Reproducer

run any model using MDI_o1_CADBased_v01

Additional context

No response

[aciarma]

Hello Daniel,

I tried running on the ALLEGRO_o1_v03 with the shape based and the same warning pops out also from all other detector elements, this is not related to CAD shapes.

source /cvmfs/sw-nightlies.hsf.org/key4hep/setup.sh

ddsim --compactFile $K4GEO/FCCee/ALLEGRO/compact/ALLEGRO_o1_v03/ALLEGRO_o1_v03.xml --runType batch --enableGun --numberOfEvents 1

Compact          WARN  ++ Overwriting/updating Header structure is very dangerous. Try to avoid this.
Compact          WARN  ++     Header definition in: file:///cvmfs/sw-nightlies.hsf.org/key4hep/releases/2025-12-10/x86_64-almalinux9-gcc14.2.0-opt/k4geo/b0087c8cbda29cc8c69172581b6df033c644d0cf_develop-cz2dnu/share/k4geo/FCCee/ALLEGRO/compact/ALLEGRO_o1_v03/DectDimensions.xml
Compact          WARN  ++ Overwriting/updating Header structure is very dangerous. Try to avoid this.
Compact          WARN  ++     Header definition in: file:///cvmfs/sw-nightlies.hsf.org/key4hep/releases/2025-12-10/x86_64-almalinux9-gcc14.2.0-opt/k4geo/b0087c8cbda29cc8c69172581b6df033c644d0cf_develop-cz2dnu/share/k4geo/FCCee/MDI/compact/MDI_o1_v00/Beampipe_o4_v05.xml
Compact          WARN  ++ Overwriting/updating Header structure is very dangerous. Try to avoid this.
Compact          WARN  ++     Header definition in: file:///cvmfs/sw-nightlies.hsf.org/key4hep/releases/2025-12-10/x86_64-almalinux9-gcc14.2.0-opt/k4geo/b0087c8cbda29cc8c69172581b6df033c644d0cf_develop-cz2dnu/share/k4geo/FCCee/MDI/compact/MDI_o1_v00/BeamInstrumentation_o1_v01.xml
Compact          WARN  ++ Overwriting/updating Header structure is very dangerous. Try to avoid this.
Compact          WARN  ++     Header definition in: file:///cvmfs/sw-nightlies.hsf.org/key4hep/releases/2025-12-10/x86_64-almalinux9-gcc14.2.0-opt/k4geo/b0087c8cbda29cc8c69172581b6df033c644d0cf_develop-cz2dnu/share/k4geo/FCCee/ALLEGRO/compact/ALLEGRO_o1_v03/LumiCal.xml
Compact          WARN  ++ Overwriting/updating Header structure is very dangerous. Try to avoid this.
Compact          WARN  ++     Header definition in: file:///cvmfs/sw-nightlies.hsf.org/key4hep/releases/2025-12-10/x86_64-almalinux9-gcc14.2.0-opt/k4geo/b0087c8cbda29cc8c69172581b6df033c644d0cf_develop-cz2dnu/share/k4geo/FCCee/ALLEGRO/compact/ALLEGRO_o1_v03/VertexComplete_IDEA_o1_v03.xml
Compact          WARN  ++ Overwriting/updating Header structure is very dangerous. Try to avoid this.
Compact          WARN  ++     Header definition in: file:///cvmfs/sw-nightlies.hsf.org/key4hep/releases/2025-12-10/x86_64-almalinux9-gcc14.2.0-opt/k4geo/b0087c8cbda29cc8c69172581b6df033c644d0cf_develop-cz2dnu/share/k4geo/FCCee/ALLEGRO/compact/ALLEGRO_o1_v03/SiliconWrapper_o1_v03.xml
Compact          WARN  ++ Overwriting/updating Header structure is very dangerous. Try to avoid this.
Compact          WARN  ++     Header definition in: file:///cvmfs/sw-nightlies.hsf.org/key4hep/releases/2025-12-10/x86_64-almalinux9-gcc14.2.0-opt/k4geo/b0087c8cbda29cc8c69172581b6df033c644d0cf_develop-cz2dnu/share/k4geo/FCCee/ALLEGRO/compact/ALLEGRO_o1_v03/ECalBarrel_thetamodulemerged.xml
Compact          WARN  ++ Overwriting/updating Header structure is very dangerous. Try to avoid this.
Compact          WARN  ++     Header definition in: file:///cvmfs/sw-nightlies.hsf.org/key4hep/releases/2025-12-10/x86_64-almalinux9-gcc14.2.0-opt/k4geo/b0087c8cbda29cc8c69172581b6df033c644d0cf_develop-cz2dnu/share/k4geo/FCCee/ALLEGRO/compact/ALLEGRO_o1_v03/HCalBarrel_TileCal_v03.xml
Compact          WARN  ++ Overwriting/updating Header structure is very dangerous. Try to avoid this.
Compact          WARN  ++     Header definition in: file:///cvmfs/sw-nightlies.hsf.org/key4hep/releases/2025-12-10/x86_64-almalinux9-gcc14.2.0-opt/k4geo/b0087c8cbda29cc8c69172581b6df033c644d0cf_develop-cz2dnu/share/k4geo/FCCee/ALLEGRO/compact/ALLEGRO_o1_v03/ECalEndcaps_Turbine_o1_v03.xml
Compact          WARN  ++ Overwriting/updating Header structure is very dangerous. Try to avoid this.
Compact          WARN  ++     Header definition in: file:///cvmfs/sw-nightlies.hsf.org/key4hep/releases/2025-12-10/x86_64-almalinux9-gcc14.2.0-opt/k4geo/b0087c8cbda29cc8c69172581b6df033c644d0cf_develop-cz2dnu/share/k4geo/FCCee/ALLEGRO/compact/ALLEGRO_o1_v03/HCalEndcaps_ThreeParts_TileCal_v03.xml
Compact          WARN  ++ Overwriting/updating Header structure is very dangerous. Try to avoid this.
Compact          WARN  ++     Header definition in: file:///cvmfs/sw-nightlies.hsf.org/key4hep/releases/2025-12-10/x86_64-almalinux9-gcc14.2.0-opt/k4geo/b0087c8cbda29cc8c69172581b6df033c644d0cf_develop-cz2dnu/share/k4geo/FCCee/ALLEGRO/compact/ALLEGRO_o1_v03/MuonTaggerPhiTheta.xml

Not sure what triggers this. Which master xml did you use to only have warnings from the CAD elements?

[danieljeans]

Hi @aciarma

I noticed it when using the ILD models.

My guess is that dd4hep wants each detector model to have only one unique <info> </info> section.
Putting an <info> section also into included files, as you do in each of the MDI description xml files, seems to cause this warning.
Perhaps allegro also generally uses it everywhere?
For the record, I don't think it causes any problem for the actual geometry description: ie the simulation itself is not affected, and is not at all related to the CAD description.

In xml descriptions of ILD models, only the top ILD_++.xml has an info section; the included xml files do not.
If I remove the <info> section from all the used xml files in FCCee/MDI/compact/MDI_o1_CADBased_v01, leaving only the top one in the ILD...xml files, the error disappears.

perhaps @BrieucF or other dd4hep experts can comment on the correct/recommended way to use the <info> section?

Cheers,
Daniel.

[MarkusFrankATcernch]

@danieljeans
Ok. It all started with: Issue AIDASoft/DD4hep#1469 .
But the prior implementation was also not really correct:
only the last header won - and all others were silently dropped wit a memory leak.
Since all values then were overwritten it is no longer really clear what the content at the end really is,
so better print a warning. Wether it should be a warning or rather a informal message is debatable though.

[danieljeans]

@MarkusFrankATcernch
thanks for pointing out the underlying cause.

if it is recommended not to overwrite the <info> section, then I'd suggest it's better to advertise the fact, and have it implemented it in the various detector models.
if it's judged not serious, then the printed warning is maybe too frightening to the uninitiated: it could be a good idea to "soften" it.

[MarkusFrankATcernch]

This is all a good question. The messages are at warning level now to play safe.
In principle the header should be present only once - unless there should be many and not only one,
but this would be some enhancement of the current implementation.
Hence, updates are nearly always a mistake and typically only falsify information.
So what really to do is not clear.
I do not want to go simply the "convenient" way just to avoid discussions.

[danieljeans]

In my opinion, it seems more natural that the contents of <info> for a detector model should reflect the top-level detector, rather than the last-included sub-component.

If <info> is given in only the top-level xml (as we do in ILD), then we get that top-level info.

If every subcomponent has its own associated <info> (as is done in eg the FCCee-MDI descriptions, and in much of IDEA, as far as I can see), then the user would have access to just the last one, which has overwritten all the previous ones.
I would suggest that such sub-infos would be better as a <comment> (with eg author, short description, ...)

[MarkusFrankATcernch]

@danieljeans
I have no strong opinion here.
But I suggest that before changing things again we should get some consensus if the header info should be extended.
As you say, different parties have different opinions.

[BrieucF]

The fact that we have multiple <info> sections does not come from any "policy", it is just the result of copy pasting existing xml to start new ones and our ignorance that <info> should be only present once. So also no strong opinion here, we will align on what is decided.

But I do agree with Daniel that printing Overwriting/updating Header structure is very dangerous for something that does not affect the physics is too much.

[tmadlener]

I just stumbled over this and I now have an opinion ;). After AIDASoft/DD4hep#1525 the name field that is set by the last <info> tag wins. This makes it effectively impossible to simply do

  const auto  detName   = dd4hepDet->header().name();

in client code to see the name of the detector. In some cases, e.g. key4hep/k4ActsTracking#36, this would be helpful to dispatch to the correct configuration depending on the detector at hand.

Currently this is not possible, because, e.g. for ILD_FCCee_v01, I get fields_antisol_map as a detector name, simply because that is the last <info> tag that is found for that specific geometry.