refactor: RootMaterialDecorator as default for the ODD #3415
Conversation
|
Tagging @andiwand @Corentin-Allaire |
📊: Physics performance monitoring for 2e993a9physmon summary
|
|
Makes sense to me - thanks for making this sound @benjaminhuth |
That might change output slightly, but ok. Anyhow - we again and again run into the situation that the ODD ships with files generated by ACTS which are strictly only valid for the ACTS version they are produced. Probably we should remove those and change to a setup where we guarantee that the standard material maps and digitisation files can be generated using ACTS for the ODD version it ships with? |
|
Yes I think what should be done is to have the files in ODD and in ACTS. The parsing of these files are done by ACTS and this broke a couple of times in the past. This way the ACTS repo can have config files that work with the targeting ODD version and the current parser. The same way ODD repo can have a config file that works with the references ACTS version and the current ODD version. |
|
If we go that route (which I think is a great idea), maybe it would be worth having a CI run when we create a new tag to generate new material map for that tag/version ? That way we can at least ensure that in ACTS if you use a tag you are guaranty to have a working map ? |
|
And just for your information, here the reason it doesn't work is because that json file is not a material map... It is a config file that should be use to tell the material mapping where you want to map your material. If this is read instead of a proper map it won't load any material. So thanks for catching this ! And we should definitly change this ! |
|
Okay very good to know, thx @Corentin-Allaire ! Just to be sure: the |
|
It's interesting that |
|
@benjaminhuth, there is none in the odd directory as it take too much space (but it should be fully equivalent to the root one). But by default the material is written to json when the mapping is performed. So yes it is useful ! @andiwand the reason is that the way I implemented this is that when you configure the material mapping you actually decorate you detector with a placeholder material that is then pickup by the mapping. The mapping then see this material (which has the same binning as the one we want for our map) and understand it should replace it with the real material it computed. Long story short, in a way the config is a map but without physical material. (We could add a check to the material interactor to error if that typr is encountered) |
|
I see makes sense @Corentin-Allaire. I wonder if we could in this case either have different I/O formats for input and output or instruct the reader to expect (valid) material properties. Do we use the same reader for mapping configuration and map reading? |
It is exactly the same format since they are both material map. But there will be a difference at the level of material class, in the config the surfaces will be associated with ProtoSurfaceMaterial (in json : |
|
acts-project-service
added
the
Breaks Athena build
getOpenDataDetector()gives by default theJsonMaterialDecorator, which does not give good results (at least in my use cases), and for most usecases, we anyways give directly the Root based one.