Release v0.11.0

[fhagemann]

Some things that would still need to be done:

• Draft release note with breaking changes --> look at what we had to change in Change AbstractCoordinatePoint to not be a FieldVector #489 (tests and code-wise) and what behavior is not supported anymore. Think about whether we want to have functions that throw verbose warnings (for example when the user tries to add two CartesianPoints or converting an AbstractVector to a CartesianPoint)
• Operations with CartesianPoints not supported and causing errors #552: make sure all current code works with the new implementation of CartesianPoint
• Check that all documentation is updated or add documentation about the new things where missing
  --> should be done now with Update documentation for 0.11 release #593
• Add tests for cases that might be needed or for weird things we discovered

Possible other breaking changes to incorporate in this release:

• Redefinition of offsets in linear and cylindrical impurity/charge densities #573: for LinearImpurityDensity and CylindricalImpurityDensity, change offsets from being an NTuple to being just a number T at the origin of the coordinate system.
• The user should be able to choose the "unit" of waveforms. #284: allow the user to choose whether the output should be given in units of charge or units of energy.
• Update default value of min_tick_distance in potential calculation #448: choose a better min_tick_distance, e.g. based on the dimensions of the world (might also be relevant for the dead-layer simulations)
• Fully support CartesianPoints with units #183: units in general (?)

Feature request:

• Right now, the Lithium drifted contact can only be one of them (just one contact id), should we also allow for multiple contact IDs, as for example for the p-type segBEGe detector, that has 4 segments, each of which are Lithium drifted --> moved this to new issue Allow ThermalDiffusionLithiumDensity to be built using multiple contacts #595

Thinking about breaking changes:

• If there are any other breaking changes, now is the time to merge them:
  • Remove old deprecation warnings #554

[zpdg]

[ ] Update default value of min_tick_distance in potential calculation #448: choose a better min_tick_distance, e.g. based on the dimensions of the world (might also be relevant for the dead-layer simulations)

My solution for dead-layer simulations is to pass a custom tick list, which is very fine in the dead-layer. But it will make the field calculation very slow. When using 2um in dead-layer and 100 um in bulk for the ~80x40 p-type BEGe, it takes around half hour using 8 threads.

[fhagemann]

[ ] Update default value of min_tick_distance in potential calculation #448: choose a better min_tick_distance, e.g. based on the dimensions of the world (might also be relevant for the dead-layer simulations)

My solution for dead-layer simulations is to pass a custom tick list, which is very fine in the dead-layer. But it will make the field calculation very slow. When using 2um in dead-layer and 100 um in bulk for the ~80x40 p-type BEGe, it takes around half hour using 8 threads.

I see, thanks for the insight.
The thing is that currently you MUST pass custom ticks if you want to have a grid finer than 10μm tick distance. We might want to change this

[oschulz]

The thing is that currently you MUST pass custom ticks if you want to have a grid finer than 10μm tick distance. We might want to change this

Can we make the default minimum-tick depend on the detector region (point type)?

[fhagemann]

Not in its current implementation, because we FIRST create the grid and THEN determine the point types for those grid points.

[oschulz]

Not in its current implementation, because we FIRST create the grid and THEN determine the point types for those grid points.

Yes, I know, but during refinement?