Allow user defined models

[eduard-kuhn]

Allow users to define their own models in order to modify the right hand side of the continuity equations and
to add charges to the poisson equation.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 96.00000% with 1 lines in your changes are missing coverage. Please review.

Project coverage is 54.99%. Comparing base (8f35631) to head (949f126).
Report is 11 commits behind head on master.

Files	Patch %	Lines
src/ct_datatypes.jl	66.66%	1 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##           master      #36      +/-   ##
==========================================
+ Coverage   52.68%   54.99%   +2.31%     
==========================================
  Files           5        7       +2     
  Lines        1211     1331     +120     
==========================================
+ Hits          638      732      +94     
- Misses        573      599      +26     

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

[dilaraabdel]

I just checked this implementation and realized that we receive with this way a problem of Type instability.

Thinking again about our discussion, the aim is to simply restructure only on the ct_physics.jl level, right?
Why dont we predefine all type of model classes by our own and let the user add something like

add_recombination_model!(ctsys, RadiativeRecombination(Radiative))?

[eduard-kuhn]

Yes those allocations seem to be a problem, this is probably because currently an Array is allocated for the densities,
that should probably be changed so that the memory for the densities is allocated on the stack or
is part of data, but that might be annoying because the densities are usually some Dual type for ForwardDiff.

My idea was that the new TeSCA would be mostly be a collection of different models that can be combined in various ways.
I dont quite see yet how there is a problem of type instability as there are no global variables involved,
would your idea be to put all the models in ct_physics and define a union type for them so that the type is better defined?

[j-fu]

There are at least 2.1 remedies for this:

• use PreallocationTools.jl - this was discovered as working for this purpose by Steffen Maaß (@smaasz)
• parametrize the data type by nspec (https://github.com/j-fu/VoronoiFVM.jl/blob/56f8d7f2a960e70aa7a97b8f25136be22966dd6f/examples/Example510_Mixture.jl#L70), and then declare MVectors from StaticArrays.jl
• (weight 0.1 as this would keep the allocations): switch off the warnings (by setting verbosity to "", default is "ea" as far as I recall. Anyway in that case you should do zeros(eltype(u),nspec) in order to store the duals, otherwise you won't get the full jacobian.

[eduard-kuhn]

Thank you, PreallocationTools.jl seems to work well here

[PatricioFarrell]

How important is it to be able to define different types of gain/recombination models outside as a user? So far the different types of gain/recombination models seemed to be limited. That's why we handled this internally and allowed the user to choose from predefined options. As for the wording, given that there are many types of "physical models", it would make sense to give the example and function names more descriptive names. So far it seems that "physical model" refers to recombination mechanisms.

[eduard-kuhn]

I think in the future there might a lot different kind of models regarding the interaction between the optical
field and the carriers (for example in 1D,2D and 3D the field will probably need to be treated differently, if the treat-power-as-a-parameter method is used or not, if the carriers in the quantum well are treated separately from ChargeTransport or not, maybe coupling to the traveling-wave method, different gain models etc.),
so it might be more convenient to put all of those things in a new package.

The names of the struct and the functions can be changed of course, maybe something like UserDefinedModel
makes more sense (which can add recombination/charges for now and maybe more later for things like tunnel injection but
I dont know yet how that would work).