Fix: apply global density scaling factor in MaterialManager::getDensity

[alcaliva]

Hi,
I believe that the existing function is not scaling the material density by the global factor.
I also added a warning and changed the return value if the density map is not found.

@amorsch

[github-actions]

REQUEST FOR PRODUCTION RELEASES:
To request your PR to be included in production software, please add the corresponding labels called "async-" to your PR. Add the labels directly (if you have the permissions) or add a comment of the form (note that labels are separated by a ",")

+async-label <label1>, <label2>, !<label3> ...

This will add <label1> and <label2> and removes <label3>.

The following labels are available
async-2023-pbpb-apass4
async-2023-pp-apass4
async-2024-pp-apass1
async-2022-pp-apass7
async-2024-pp-cpass0
async-2024-PbPb-apass1
async-2024-ppRef-apass1
async-2024-PbPb-apass2
async-2023-PbPb-apass5

[amorsch]

Hi @alcaliva,
I think the function name is a misnomer. It gives back either the local scaling factor for a module, or if the module is not in the list, the global scaling factor. The actual scaling is performed in Material(...) and Mixture(...).
The list of modules and corresponding scaling factors can be provided via
SimMaterialParams.localDensityFactor and is initialized in InitDensityMap().

Actually local density factors are more appropriate since it avoid scaling densities outside the ITS.

Of course, this still does not explain why it seems not to work.

[alcaliva]

localDensityFactor

Hi Andreas,
I do not see where the local density of a given module gets scaled by the globalDensity Factor.
If I look at the function MaterialManager::Material, it calls the getDensity function, but as it is now, it returns the module density without scaling it.

[amorsch]

Hi Alberto,
for example in Material(...)
auto densityFactor = getDensity(modname);
..
TVirtualMC::GetMC()->Material(kmat, uniquename.Data(), a, z,
dens * densityFactor, radl, absl, buf, nwbuf);

[alcaliva]

Hi Alberto, for example in Material(...) auto densityFactor = getDensity(modname); .. TVirtualMC::GetMC()->Material(kmat, uniquename.Data(), a, z, dens * densityFactor, radl, absl, buf, nwbuf);

Hi Andreas,

with the current implementation, the variable "auto densityFactor = getDensity(modname)" contains the (unscaled) density of a given module. I see that this gets scaled by the variable "Float_t dens". Where is this latter variable set to the globalDensityFactor? I do not see it.

[amorsch]

Hi Alberto,
initDensityMap parses the string
o2::conf::SimMaterialParams::Instance().localDensityFactor

which contains comma separated pairs of modules and density factors
and creates the mDensityMap

The way I understand it, mDensityMap contains actually scaling factors. If this was not the case one would multiply densities with densities.

->Where is this latter variable set to the globalDensityFactor? I do not see it.

The global density factor is the default of the getDensity function, in case the module is not in th mDensityMap list.
"dens" is the density set for this material in the code. getDensity gives back the scaling factor.

[amorsch]

I've added a print statement in Material
with
o2-sim-serial -n 100 -g pythia8pp --configKeyValues "SimMaterialParams.globalDensityFactor=2." -m ITS

I get:
In Material(...), density factor for ITS is 2.000 for density 2.330
In Material(...), density factor for ITS is 2.000 for density 1.848
In Material(...), density factor for ITS is 2.000 for density 8.960
In Material(...), density factor for ITS is 2.000 for density 1.700
In Material(...), density factor for ITS is 2.000 for density 0.315
In Material(...), density factor for ITS is 2.000 for density 1.643
In Material(...), density factor for ITS is 2.000 for density 1.583
In Material(...), density factor for ITS is 2.000 for density 2.133
In Material(...), density factor for ITS is 2.000 for density 2.210
In Material(...), density factor for ITS is 2.000 for density 1.630
In Material(...), density factor for ITS is 2.000 for density 1.725
In Material(...), density factor for ITS is 2.000 for density 1.600
In Material(...), density factor for ITS is 2.000 for density 0.400
In Material(...), density factor for ITS is 2.000 for density 1.480
In Material(...), density factor for ITS is 2.000 for density 1.480
In Material(...), density factor for ITS is 2.000 for density 0.958
In Material(...), density factor for ITS is 2.000 for density 2.699
In Material(...), density factor for ITS is 2.000 for density 19.250
In Material(...), density factor for ITS is 2.000 for density 4.506
In Material(...), density factor for ITS is 2.000 for density 1.550
In Material(...), density factor for ITS is 2.000 for density 1.750
In Material(...), density factor for ITS is 2.000 for density 0.060
In Material(...), density factor for ITS is 2.000 for density 0.725

[alibuild]

Error while checking build/O2/fullCI_slc9 for 4c00039 at 2025-07-29 07:46:

## sw/BUILD/O2-full-system-test-latest/log
ERROR: Full system test did generate no raw data for FV0


## sw/BUILD/o2checkcode-latest/log
--
========== List of errors found ==========
++ GRERR=0
++ grep -v clang-diagnostic-error error-log.txt
++ grep ' error:'
++ GRERR=1
++ [[ 1 == 0 ]]
++ mkdir -p /sw/INSTALLROOT/7e5ec4e4c140c021e0999a77d94820019330e0b8/slc9_x86-64/o2checkcode/1.0-local39/etc/modulefiles
++ cat
--

Full log here.

[alcaliva]

Hi Alberto, initDensityMap parses the string o2::conf::SimMaterialParams::Instance().localDensityFactor

which contains comma separated pairs of modules and density factors and creates the mDensityMap

The way I understand it, mDensityMap contains actually scaling factors. If this was not the case one would multiply densities with densities.

->Where is this latter variable set to the globalDensityFactor? I do not see it.

The global density factor is the default of the getDensity function, in case the module is not in th mDensityMap list. "dens" is the density set for this material in the code. getDensity gives back the scaling factor.

Hi Andreas,

ok, mDensityMap contains scaling factors and not densities. The actual density is contained in the variable "Float_t dens". If I want to increase the material density by a factor of 2, I would set globalDensityFactor=2.0.

-> The global density factor is the default of the getDensity function, in case the module is not in th mDensityMap list

what if the module is instead found inside the list (like the ITS), where is it's density scaled by globalDensityFactor?

[amorsch]

In this case the module is found, i.e.

mDensityMap.find(modname) != mDensityMap.end()

and getDensity gives back

return mDensityMap[modname];

o2-sim-serial -n 100 -g pythia8pp --configKeyValues "SimMaterialParams.localDensityFactor=ITS:2.,TPC:3." -m ITS TPC

In Material(...), density factor for TPC is 3.000 for density 2.700
In Material(...), density factor for TPC is 3.000 for density 2.330
In Material(...), density factor for TPC is 3.000 for density 8.960
In Material(...), density factor for TPC is 3.000 for density 2.265
In Material(...), density factor for TPC is 3.000 for density 7.870

In Material(...), density factor for ITS is 2.000 for density 2.330
In Material(...), density factor for ITS is 2.000 for density 1.848
In Material(...), density factor for ITS is 2.000 for density 8.960

[amorsch]

I think you should replace
 "-gen pythia8 -confKey SimMaterialParams.globalDensityFactor=0.9f"
by 
 "-gen pythia8 -confKey SimMaterialParams.globalDensityFactor=0.9"

i.e. remove the "f"
At least locally the "f" causes the problem.

o2-sim-serial -n 100 -g pythia8pp --configKeyValues "SimMaterialParams.globalDensityFactor=2.f" -m ITS
In Material(...), density factor for ITS is 1.000 for density 2.330
In Material(...), density factor for ITS is 1.000 for density 1.848
In Material(...), density factor for ITS is 1.000 for density 8.960
In Material(...), density factor for ITS is 1.000 for density 1.700

[alcaliva]

I've run a simulation where I changed the material by a large factor and still no change is seen in the efficiency.

The script is here

https://its.cern.ch/jira/browse/O2-6184

[amorsch]

I don't know how the JDL is interpreted, however, locally I have to use
SimMaterialParams.globalDensityFactor=10.0

to make this work.

[alcaliva]

Thanks! I will try that too and let you know

[amorsch]

I'm not sure it will work. All jobs execute the following for simulation:
Launching task: ${O2_ROOT}/bin/o2-sim -e TGeant4 --skipModules ZDC -n 750 --seed 505180213 --field ccdb -j 8 --configKeyValues "MFTBase.buildAlignment=true;GeneratorPythia8.config=pythia8.cfg;" -o sgn --timestamp 1730411339958 --run 559387 -g extkinO2 --extKinFile genevents_Kine.root --vertexMode kNoVertex --readoutDetectors ITS TPC TRD TOF PHS CPV EMC HMP MFT MCH MID FT0 FV0 FDD CTP --fromCollContext collisioncontext.root &> sgnsim_1.log &

The config option related to the scaling is not contained. It seems that the setting of the SIM_OPTIONS variable in the JDL is ignored. This is also the reason that it does not crash with the wrong syntax.

[amorsch]

... but the aliprod jobs use yet another syntax:
ANCHOR_SIM_OPTIONS = "-gen pythia8 -confKey SimCutParams.globalDensityFactor= 0.9f";

[alcaliva]

I'm trying with

export ALIEN_JDL_O2SIM_OPTIONS="--configKeyValues SimCutParams.globalDensityFactor=2.0"

and

export ALIEN_JDL_O2SIM_OPTIONS="--configKeyValues SimCutParams.globalDensityFactor=0.2"

[amorsch]

as I wrote before, locally I use
SimMaterialParams.globalDensityFactor

I just wanted to point out that in the production job JDLs I found 2 variations of this setting, and I believe that they are not correct.

[alcaliva]

ok, I submitted another couple of jobs with SimMaterialParams.globalDensityFactor

[amorsch]

I think the arguments passed to o2dpg_sim_workflow.py are in ANCHOR_SIM_OPTIONS
and not in O2SIM_OPTIONS.

[shahor02]

Hi,

As far as I can see, the only option to use from the JDL is ALIEN_JDL_ANCHOR_SIM_OPTIONS.
The SimCutParams configurable has no globalDensityFactor data member (O2 would crash if SimCutParams.globalDensityFactor would reach it), both globalDensityFactor and localDensityFactor are in the SimMaterialParams.

I.e. the format to you in the JDL is e.g.

ALIEN_JDL_ANCHOR_SIM_OPTIONS="--gen pythia8 SimMaterialParams.globalDensityFactor=2;SimMaterialParams.localDensityFactor=ITS:3.2,TPC:4.5;"

[amorsch]

I think the explanation for the problem is the following.Before March '25 globalDensityFactor existed in SimCutParams and SimMaterialParamsHowever, MaterialManager only uses the one from SimMaterialParams.Hence, it was possible to use SimCutParams.globalDensityFactor without having o2-sim crashing, but it had no effect. This setting was used in aliprod.

Now globalDensityFactor has been removed from SimCutParams.

Note: the correct parameter is in any case SimMaterialParams.localDensityFactor=ITS:1.05and this existed always only in SimMaterialParams

[sawenzel]

Hi. Back from vacation. Let me try to make a point on the situation from my point of view. I suspect that the current problem might be a combination of multiple things (use of deprecated keys, parse errors of float literals such as 2.f in strings, and wrong configuration of DPL MC jobs).

I remember that we discussed the material budget in older productions before, for instance here: https://its.cern.ch/jira/browse/O2-5700. The suggestion then was already to use key SimMaterialParams as also outlined in the documentation https://aliceo2group.github.io/simulation/docs/transport/geometry.html?highlight=globalDensity

In order to set this parameter in an O2DPG anchored MC job, one should say

ALIEN_JDL_ANCHOR_SIM_OPTIONS="-gen pythia8 -confKey =\"SimMaterialParams.globalDensityFactor=2;SimMaterialParams.localDensityFactor=ITS:3.2,TPC:4.5;\""

This is the only environment variable available.

Please note that this env variable configures O2DPG MC ... and not directly o2-sim and that we use -confKey here to pass on configurable params to the simulation. This is in (unfortunate) contrast to --configKeyValues of o2-sim.

Using the deprecated key SimCutParams makes the simulation crash as expected.

@alcaliva : Could you let me know if this is already good enough or if your PR is still needed? I will try to improve the situation with the float literals. For now, please don't append f to numbers.

[alcaliva]

Hi. Back from vacation. Let me try to make a point on the situation from my point of view. I suspect that the current problem might be a combination of multiple things (use of deprecated keys, parse errors of float literals such as 2.f in strings, and wrong configuration of DPL MC jobs).

I remember that we discussed the material budget in older productions before, for instance here: https://its.cern.ch/jira/browse/O2-5700. The suggestion then was already to use key SimMaterialParams as also outlined in the documentation https://aliceo2group.github.io/simulation/docs/transport/geometry.html?highlight=globalDensity

In order to set this parameter in an O2DPG anchored MC job, one should say

ALIEN_JDL_ANCHOR_SIM_OPTIONS="-gen pythia8 -confKey =\"SimMaterialParams.globalDensityFactor=2;SimMaterialParams.localDensityFactor=ITS:3.2,TPC:4.5;\""

This is the only environment variable available.

Please note that this env variable configures O2DPG MC ... and not directly o2-sim and that we use -confKey here to pass on configurable params to the simulation. This is in (unfortunate) contrast to --configKeyValues of o2-sim.

Using the deprecated key SimCutParams makes the simulation crash as expected.

@alcaliva : Could you let me know if this is already good enough or if your PR is still needed? I will try to improve the situation with the float literals. For now, please don't append f to numbers.

Hi @sawenzel,

I opened this PR to start the discussion. Apparently the current implementation of the function is correct and I was wrong. Maybe, as suggested by @amorsch, we could rename some variables to avoid confusion, but this PR can actually be closed.

[alcaliva]

Closing this PR