Add effective DOS classes for the Charge solver #2375
Conversation
There was a problem hiding this comment.
Thanks Vasily for dealing with this. My main concern is that except for the ConstantEffectiveDOS model which is basically a float, the rest are variations of the same model.
In particular, ´IsotropicEffectiveDOS´ and MultiValleyEffectiveDOS can be combined into a single model in which we change the effective mass model. That is, the effective mass should not be a float but rather a model. This is also explained here in points 1 to 3. That way we can also add temperature dependence to the effective mass.
DualValleyEffectiveDOS can stay as is except that we should probably add the masses as models to allow temperature dependence.
| def _calc_eff_DOS(self, T: float): | ||
| """Abstract method to calculate the effective density of states.""" | ||
| pass | ||
|
|
||
| @abstractmethod | ||
| def _calc_eff_DOS_derivative(self, T: float): | ||
| """Abstract method to calculate the temperature derivative of the effective density of states.""" | ||
| pass | ||
|
|
||
| def get_effective_DOS(self, T: float): | ||
| if T <= 0: | ||
| raise DataError( | ||
| f"Incorrect temperature value ({T}) for the effectve density of states calculation." | ||
| ) | ||
|
|
||
| return self._calc_eff_DOS(T) | ||
|
|
||
| def get_effective_DOS_derivative(self, T: float): | ||
| if T <= 0: | ||
| raise DataError( | ||
| f"Incorrect temperature value ({T}) for the effectve density of states calculation." | ||
| ) | ||
|
|
||
| return self._calc_eff_DOS_derivative(T) |
There was a problem hiding this comment.
not sure we'll need these here since we formulation is in the back-end. We can leave them there for now though. We can decide once we know how this all will play out in the back-end.
There was a problem hiding this comment.
So far I added the temperature derivative for experimentation with the non-isothermal simulations. We should think about the final implementation later together with the model development.
|
I see here two ways: several simple DOS models that covers traditional cases (this is implemented now), or one complex model that cover all cases, but require many parameters. It's a matter of personal choice what to prefer. I don't think that we need to implement a special model for the effective mass (at least now). I've never seen that people do fine tuning of the effective mass as a function of the temperature, I believe it is a negligible effect. More useful case is the mass dependence on the strain in the material, this is important for quantum wells and for some Si transistor simulations. But we are not going to cover these cases now. So I think that we may stay with the constant effective mass assumption now and change it later, if necessary. |
|
So I think we should definitely merge With regards to So, in summary:
Does that make sense? What do you think @dbochkov-flexcompute @momchil-flex |
|
This is basically goes down to choose between a list of several simple models, that are traditional for semiconductor physics and device simulation, or to implement one flexible class that can cover all models. I, personally, like the first option, but the second one is also good in terms of the program logic. I can redesign the classes and merge everything into one universal class, if this is our common decision. What is your opinion @momchil-flex and @dbochkov-flexcompute ? |
There was a problem hiding this comment.
regarding class organization, no strong preference, but slightly lean towards having it more explicit, that is, keeping separate IsotropicEffectiveDOS, MultiValleyEffectiveDOS, and DualValleyEffectiveDOS. I imagine the simpler the model the more usage it could potentially get? In that sense, it's maybe not worth making the user to define an isotropic effective dos by setting up twice the same parameter (if I understand this correctly):
medium = SemiconductorMedium(
Nc=MultiValleyEffectiveDOS(m_eff_long=1, m_eff_trans=1, N_valley=1),
...
)
instead of
medium = SemiconductorMedium(
Nc=IsotropicEffectiveDOS(m_eff=1),
...
)
Also, if we implement dual valley effective dos as a tuple, then we would have to provide additional documentation that this is how you set it up and make sure the user can easily find that information. With having explicit DualValleyEffectiveDOS I think it should be easier for the user to understand that this is an option and how to set it up
|
I have updated the code according to your comments. As far as I understand, Daniil also prefers to keep several simple classes instead of a single complex one, |
|
I am mostly OK with the code. I still see, however, an unanswered question by Daniil (regarding units). I guess my only comment would be about the |
|
I personally prefer to remove possibility to define the DOS using float. It is more consistent when we have a special type for the effective DOS and it simplifies the code by removing additional checks of the type of the passes parameters. And I believe that most of the users will use the temperature-dependent DOS definition anyway. |
That's fair. So let's remove the possibility of defining Nc/Nv with a float. We still need to check types in the back-end though.
Yeah, don't worry about compatibility at this stage. |
Add effective DOS classes for the Charge solver