Add RadfordImpurityDensity model to the SSD extension

[fhagemann]

Follow-up of #72 (got closed by accident when resolving the merge conflicts)

[codecov]

Codecov Report

Attention: Patch coverage is 59.61538% with 21 lines in your changes missing coverage. Please review.

Project coverage is 39.67%. Comparing base (8e1da65) to head (76d2825).
Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
ext/LegendDataManagementSolidStateDetectorsExt.jl	59.61%	21 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #74      +/-   ##
==========================================
+ Coverage   33.95%   39.67%   +5.72%     
==========================================
  Files          26       27       +1     
  Lines        1944     2009      +65     
==========================================
+ Hits          660      797     +137     
+ Misses       1284     1212      -72     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[fhagemann]

This PR does, by default, not read the crystal metadata for the impurity density.
However, the default value is increased from -1e9cm^-3 to -5e9cm^-3.

[fhagemann]

Last changes (but should be good to go now):

• Changed the default impurity density to -1e10cm^-3
• Apply the correct order of magnitude (and sign for p-type) when reading the impurity density data
• Add tests for the impurity density read-in

[fhagemann]

@oschulz wants to remove the LsqFit dependency by including relevant fitting code into this package.

[fhagemann]

I would also change the default impurity density value (when no crystal metadata is available) to -0.9e10/cm^3 to match the default value used for fieldgen in LegendGeSim.

[hervasa2]

Note that I've already added this to legend-exp/LegendDetectorDesign.jl#1 (LDD) as SegregationImpurityDensity. Since LDD depends on LegendDataManagent where should this impurity density live? I think a better place for users to simulate detectors from metadata would be in LDD. Or maybe we should move the SSD extension there entirely and drop the LegendDataManagent dep?

[oschulz]

I think we should move the impurity density fit to LDD. But the RadfordImpurityDensity struct and implementation must live in LegendDataManagement, otherwise it can't be used without depending on LDD. LDD should not become the primary package for simulating pulses in LEGEND, that's what LegendGeSim is for. Also, without having RadfordImpurityDensity in LegendDataManagement (in it's SSD extension), how can LegendDataManagement properly instantiate a detector from metadata?

[fhagemann]

We could also move RadfordImpurityDensityModel to SolidStateDetectors.jl

[hervasa2]

I would argue not to move RadfordImpurityDensityModel into SSD because we might want to keep it private. In general there will be a lot of overlap between LegendGeSim and LDD, so we should be careful on where to put all their shared functionality. One should not depend on the other.

[oschulz]

We could also move RadfordImpurityDensityModel to SolidStateDetectors.jl

Oh, yes, that would be best!

[oschulz]

because we might want to keep it private.

I don't think so - it would be open-source in any case, and we'd need to publish it as part of analysis papers anyway. We can ask David, of course, but I don't think he'll object.