[bug] Direction cosines are scaled by length_unit for the UNIFORM/NORMAL distribution.

[GuySten]

Description
Currently the code at src/input.rs scales direction cosines by length_unit for the UNIFORM/NORMAL distribution cases.
Because the unit direction is normalized afterwards it affects only cases where a user mixes uniform/normal distributions on some cosine directions and fixed values for the other components.

Location

RustBCA/src/input.rs

Lines 593 to 607 in 328f468

	ux: match cosx {
	Distributions::NORMAL{mean, std} => {let normal = Normal::new(mean, std).unwrap(); normal.sample(&mut rng)*length_unit},
	Distributions::UNIFORM{min, max} => {let uniform = Uniform::new(min, max).unwrap(); uniform.sample(&mut rng)*length_unit},
	Distributions::POINT(ux) => ux
	},
	uy: match cosy {
	Distributions::NORMAL{mean, std} => {let normal = Normal::new(mean, std).unwrap(); normal.sample(&mut rng)*length_unit},
	Distributions::UNIFORM{min, max} => {let uniform = Uniform::new(min, max).unwrap(); uniform.sample(&mut rng)*length_unit},
	Distributions::POINT(uy) => uy,
	},
	uz: match cosz {
	Distributions::NORMAL{mean, std} => {let normal = Normal::new(mean, std).unwrap(); normal.sample(&mut rng)*length_unit},
	Distributions::UNIFORM{min, max} => {let uniform = Uniform::new(min, max).unwrap(); uniform.sample(&mut rng)*length_unit},
	Distributions::POINT(uz) => uz,
	},

Reproduction

Input with meter units for the particle position:

[options]
name = "meter_"
track_trajectories = true
track_recoils = false

[particle_parameters]
length_unit = "M"
energy_unit = "EV"
mass_unit = "AMU"
N = [ 3 ]
m = [ 4.0026 ]
Z = [ 2 ]
E = [ 1000.0 ]
Ec = [ 1.0 ]
Es = [ 0.0 ]
pos = [ [ 1.0e-7, 0.0, 0.0 ] ]
dir = [ [ {min = 0.5, max = 0.6}, 0.8, 0.0 ] ]

[geometry_input]
length_unit = "ANGSTROM"
densities = [ 0.059 ]
electronic_stopping_correction_factor = 1.0

[material_parameters]
energy_unit = "EV"
mass_unit = "AMU"
Eb = [ 0.0 ]
Es = [ 0.0 ]
Ec = [ 1.0 ]
Z = [ 79 ]
m = [ 196.967 ]

Input with angstrom units for the particle position:

[options]
name = "angstrom_"
track_trajectories = true
track_recoils = false

[particle_parameters]
length_unit = "ANGSTROM"
energy_unit = "EV"
mass_unit = "AMU"
N = [ 3 ]
m = [ 4.0026 ]
Z = [ 2 ]
E = [ 1000.0 ]
Ec = [ 1.0 ]
Es = [ 0.0 ]
pos = [ [ 1000.0, 0.0, 0.0 ] ]
dir = [ [ {min = 0.5, max = 0.6}, 0.8, 0.0 ] ]

[geometry_input]
length_unit = "ANGSTROM"
densities = [ 0.059 ]
electronic_stopping_correction_factor = 1.0

[material_parameters]
energy_unit = "EV"
mass_unit = "AMU"
Eb = [ 0.0 ]
Es = [ 0.0 ]
Ec = [ 1.0 ]
Z = [ 79 ]
m = [ 196.967 ]

Current behavior

❯ RustBCA 0D mwe_angstrom.toml
❯ head -3 angstrom_trajectories.output
4.0026,2,1000,1000,0,0
4.0026,2,999.9111591680867,1000,0,0
4.0026,2,995.9127187898878,1000.0000000001257,1.7620556276702002,0
❯ awk -F, 'NR==1{x=$4;y=$5;z=$6} NR==3{dx=$4-x;dy=$5-y;dz=$6-z;n=sqrt(dx*dx+dy*dy+dz*dz);printf "%.4f %.4f %.4f\n",dx/n,dy/n,dz/n; exit}' angstrom_trajectories.output
0.0000 1.0000 0.0000

❯ RustBCA 0D mwe_meter.toml
❯ head -3 meter_trajectories.output
4.0026,2,1000,0.0000001,0,0
4.0026,2,999.9111591680867,0.0000001,0,0
4.0026,2,995.9127187898878,0.00000010010235553881618,0.0000000001434285328088165,0
❯ awk -F, 'NR==1{x=$4;y=$5;z=$6} NR==3{dx=$4-x;dy=$5-y;dz=$6-z;n=sqrt(dx*dx+dy*dy+dz*dz);printf "%.4f %.4f %.4f\n",dx/n,dy/n,dz/n; exit}' meter_trajectories.output
0.5809 0.8140 0.0000

The initial direction is different even though the inputs are equivalent.

Expected behavior
A unit-less quantity should not be scaled by length units.
The initial direction should be the same in both runs.

Generative AI Use
This problem was found with the help of Claude Opus 5.5.
The inputs and the short awk command were also generated with its help.

[drobnyjt]

Thank you @GuySten for opening this issue and PR. I would request that, should you submit future issues/PRs, the bodies thereof include meaningful context (e.g., line numbers, tests/simulation output demonstrating the issue, understanding of its effect, etc.). In this instance, a quick examination of the code reveals the following facts:

First, while I agree this is an obvious mistake (I assume a copy-and-paste error from position distributions), it is neutralized by the following sequence of operations:

1. The inappropriately scaled unit directions are stored in a ParticleInput struct
2. ParticleInput is processed by from_input (also here)
3. from_input normalizes particle directions at initialization.

So there is no detectable effect; the actual behavior is the expected behavior. It's not clear if you ran the code or not.

Second, your title and your description "Currently the code at src/input.rs scale direction cosines by length_unit" neglects to mention the fact that this only happens for the relatively obscure case of using uniform/normal distributions for particle directions. The overly broad phrasing implies a much more significant problem than would exist even if the directions were not subsequently normalized.

As permanent records of development, issues and PRs are important in and of themselves, and should be complete, accurate, and reflect a familiarity with and understanding of the code. External contributions to scientific software thus have to meet a fairly high bar; anonymous contributions even more so. Maybe that's on me for not making that expectation clear in a contribution policy or similar; prior to LLMs, I did not think it necessary. I'll spend some time putting one together and adding it to the repo.

Thanks again; I would really appreciate it if you would update your PR according to this feedback.

[GuySten]

Thanks @drobnyjt for the prompt reply.
As a very recent user of the code I am not familiar with how much each function is used in practice.
I do think that if you use a fixed direction on two coordination and a uniform distribution on the third you will get a result that depends on the lenght_unit.
I still have no idea how common is that usage.

I will update my PR according to your feedback.

[drobnyjt]

@GuySten Thanks!

I think you might be right, I guess it is technically reachable in that case, but I don't know what the desired behavior would even be - I feel fairly confident that nobody has ever tried it. As far as I know, the only use case for the normal distributions is to sample from a unit sphere, and even that is an unusual enough use-case that I think I might be the only one who has ever done it; I'm not sure sampling one component of a unit vector from any distribution would be a physically meaningful input, but regardless it should be fixed anyway.

[GuySten]

@drobnyjt, I've updated the issue body according to your feedback.