Closed whedon closed 2 years ago
whedon
commented
2 years ago PDF failed to compile for issue #3727 with the following error:
Error reading bibliography file paper.bib:
(line 171, column 3):
unexpected "%"
expecting space, white space or "}"
Looks like we failed to compile the PDF
kostergroup
commented
2 years ago @whedon generate pdf
whedon
commented
2 years ago PDF failed to compile for issue #3727 with the following error:
Error reading bibliography file paper.bib:
(line 184, column 3):
unexpected "y"
expecting space, ",", white space or "}"
Looks like we failed to compile the PDF
@whedon generate pdf
whedon
commented
2 years ago :point_right::page_facing_up: Download article proof :page_facing_up: View article proof on GitHub :page_facing_up: :point_left:
kostergroup
commented
2 years ago @roderickmackenzie Your use of the V in equations 2.1 -2.6 is a bit confusing because commonly V is only used in the DD equations when hetero-junctions are not taken into account. When the model has been adjusted to handle hetero-junctions (as yours seems to be 2.13-2.14) it's conmen to write Ec and Ev in the DD equations instead of V, to explicitly say that heterosteps can drive current. This is especially confusing as your fig 2.1 shows hetero steps so made me scratch me head as soon as I started reading until I reached the interfaces section. If you rewrite in terms of Ec and Ev you can get rid of equations 2.13-2.14, it would make the description look more like the classical DD literature as used for things like the III-V materials - and make things a bit clearer.
ANS: Fair point. We have chosen a slightly different way of presenting the DD equations to 1) improve the connection to other literature, while 2) remaining close to what is in the actual code: In the code, one simply replace V(x) in the DD equations by generalized potentials (see K. Zojer et al., Organic Electronics 11 (2010) 1999–2011 and the book by Snowden (ref in reference manual)) that include both the offsets in Ec/Ev as well as any changes in the effective DOS. Both points 1 and 2 are relevant here. So, we have modified the description of the DD equations (in the reference manual) to stress that these take the generalized potentials (Vgn, Vgp) in case there are offsets in Ec/v or the effective DOS. These reduce to V if there are no heterojunctions/internal interface, and refer to section 2.3 to explain how Vgn and Vgp are obtained if Ec,Ev,Ncv are not constant.
As I understand it there are two parts to the model a transient part and a steady state part. In the intro you talk about transient photovoltage and AC analysis. However your equation 2.22 is the steady state form of the SRH equation, so you are assuming your trapped carrier distribution is in quasi-steady state. This means that although you can do time domain simulations your trapped carriers will always think they are in quasi-equilibrium. This won't matter for DC or for slow small perturbation stuff. But you won't for example be able to simulate things far from equilibrium, e.g. ToF transients are an extreme example of this where carriers are initially captured then gradually released from deeper and deeper traps as time goes on. TPV transients could also meet this large signal condition depending on the power of the laser pulse, and AC depending on carrier trapping/detrapping rates and the frequency you are at (and trap depth). CELIV will also fall into large perturbation regime etc... etc... I think the user should be alerted to the fact that your carriers are in SS and the model does not explicitly solve the SRH equations in time domain. Many users won't grasp this so I think it needs to be clearly pointed out and what the implications of this are for results. I think my main concern with points 2 and 3 is that the user knows what he/she is dealing with. There are a tonne of papers where people just use software (aka COMSOL etc..) to produce a paper without understand what is going on under the hood and results in miss interpretation of data which is not a good thing.
ANS We fully agree, and this is one of the main reasons for making this project open-source and for spending the time to write a reference manual. Ultimately, we decided that it was less work to make it fully transient instead of trying to precisely define when our original approach worked/did not work (especially since this had been on the wishlist). We have added a description of how the trapping and detrapping is accounted for (reference manual).
QUESTION: We would like to add a reference to your code (in the paper), how would you like to be cited?
@UTH-Tuan 1) We have included references to commercial, freeware, and open-source alternatives to SIMsalabim, as requested. 2) In order to better highlight the relation between the SIMsalabim project as a whole and the steady-state and transient flavours, we have renamed the steady-state code (SimSS, simulates steady-state). 3) We have made the tests fully automated!
roderickmackenzie
commented
2 years ago @kostergroup Thanks for this. I'm currently out of action due to illness. I hope I will be better next week. Will look at this as a priority then. best, Rod
roderickmackenzie
commented
2 years ago @kostergroup Thanks for your comments and work. And apologies for the delay in getting back to you I was taken out by covid for a while. Comments:
*So in the manual I think the section on trapping should be separated from the potential section (2.1.1) and given it’s own heading. I think in the trapping section you should explicitly call it SRH trapping/recombination – at the moment you cite the SR paper but don’t call it SRH. And possibly move the steady state SRH equation up into this section and explain the relationship between these two approaches. At the moment the casual reader may not make the connection.
*I think you need to write how Cn/Cp are calculated from SRH theory.
*You asked “We would like to add a reference to your code (in the paper), how would you like to be cited?” I presume this was aimed at me – thanks :). I think it would be good if you could cite https://doi.org/10.1002/aenm.201100709 in the trapping section of the manual as doing dynamic SRH trapping for organics in this way was first demonstrated there. Maybe also cite the webpage www.gpvdm.com if you want to cite the code base.
*Now, I don’t want to be overly critical and I appreciate the effort you went to, to put in traps. And a model with traps is infinity better than a model with no traps. But I still don’t think you can simulate a TPC transient. But, I would be interested to see if you can reverse bias your device to say -2V then apply a laser pulse and then from the transient extract say a 100meV Urbach energy as done here https://doi.org/10.1021/jp4010828. This is the acid test of a transient model.
The reason I don’t think you can do this is because my reading of the manual is that you have a single trap level with one capture/escape cross section. In reality the escape coefficients will change depending on the energetic depth of the trap. (See eqn. 2.9 in the original SR paper) This is the reason TPC transients look as they do. Early current comes from shallow traps deep current comes from deep traps. Also my reading of your manual is that you have a single trap density Ntb, rather than a distribution of traps over energy space which is another reason you won’t be able to model TPC transients. Furthermore, you are assuming that all traps will have the same occupational probability ftb which is true as you only have one trap but in reality there is no reason why shallow traps should have the same occupation as deep traps.
Furthermore, for a given trap energy range dE your occupation probability ftb, will not be a single number but a range of numbers dictated by fermi-dirrac statistics. So all trap information such as density of carriers/escape rates etc.. have to be calculated by integrating the fermi-dirrac occupation function multipled by a density of states which also changes over energy space. (say Nexp(-E/Eu)). Thus you should really be solving for Fermi-level rather than ftb directly. I suspect you need to do this last step to get smooth TPC transients.
If this were an APL letter, I would probably not bother pushing this point. However, as I mentioned before my concern with publishing models, is they tend to be used by other people who don’t understand the bounds of validity of the model. So either I would I would like you to simulate a TPC transient and extract the Urbach energy out of it and demonstrate this in the manual as a test case. Or very clearly say where you think your model is valid and where it is not.
For example, I’m fairly sure it won’t be able to simulate ToF/TPC transients – if my reading of the manual is correct. I also suspect as it is, it won’t be able to simulate CELIV transients very well as multiple trap levels are required for those simulations (https://doi.org/10.1063/1.4818267), I would also have doubts about simulating TPV transients with such a model because there is no reason why in a fast experiment such as TPV deep and shallow traps should have a single occupation probability. I do think the model is valid for slow scans of perovskite JV curves though.
rkurchin
commented
2 years ago Hi @ljakoster, just pinging to check in on this.
And @roderickmackenzie, no worries about the delay, glad you're feeling better!
kostergroup
commented
2 years ago *So in the manual I think the section on trapping should be separated from the potential section (2.1.1) and given its own heading. I think in the trapping section you should explicitly call it SRH trapping/recombination – at the moment you cite the SR paper but don’t call it SRH. And possibly move the steady state SRH equation up into this section and explain the relationship between these two approaches. At the moment the casual reader may not make the connection.
ANS We, as per your request, specified explicitly which terms enter C(x) (in the Poisson equation, eq 2.1) and how this term (C(x)) is computed. Indeed, this part of the manual was not very clear. So, we have renamed section 2.5 ‘Recombination and Trapping’. In this section, we specify how the occupancy of the trap level and the capture/emission rates are computed in S-S and in the transient case.
*I think you need to write how Cn/Cp are calculated from SRH theory.
ANS Our Cn and Cp are simply the capture coefficients as related to the capture cross section (sigma) and the carrier velocity. So Cn/p are not calculated, but are input parameters and their unit is volume/time, as used in for example doi: 10.1038/srep37511 or in textbooks like eqs (7-155) and (7-156) in K.C. Kao, Dielectric phenomena in Solids. *Now, I don’t want to be overly critical and I appreciate the effort you went to, to put in traps. And a model with traps is infinitely better than a model with no traps. But I still don’t think you can simulate a TPC transient. But, I would be interested to see if you can reverse bias your device to say -2V then apply a laser pulse and then from the transient extract say a 100meV Urbach energy as done here https://doi.org/10.1021/jp4010828. This is the acid test of a transient model.
ANS: I think there is some misunderstanding about what we did in response to your previous comments: Trapping was included from the start. However, as you pointed out correctly, the transient code (ZimT) did use a quasi-static approach to trapping rather than a fully transient one. So, we changed the way we calculate the trap occupancy. Instead of relying on an (artificial) equilibrium between trapped and free charges (quasi-S-S), we now use capture and emission rates to explicitly solve for the trap occupancy. We did not, however, introduce elaborate distributions of trapping levels in energy.
The reason I don’t think you can do this is because my reading of the manual is that you have a single trap level with one capture/escape cross section. In reality the escape coefficients will change depending on the energetic depth of the trap. (See eqn. 2.9 in the original SR paper) This is the reason TPC transients look as they do. Early current comes from shallow traps deep current comes from deep traps. Also my reading of your manual is that you have a single trap density Ntb, rather than a distribution of traps over energy space which is another reason you won’t be able to model TPC transients. Furthermore, you are assuming that all traps will have the same occupational probability ftb which is true as you only have one trap but in reality there is no reason why shallow traps should have the same occupation as deep traps.
ANS: No, we are not assuming that ftb is static. We solve for ftb explicitly for every step and grid point. (Just as an
<\aside>) Furthermore, for a given trap energy range dE your occupation probability ftb, will not be a single number but a range of numbers dictated by fermi-dirrac statistics. So all trap information such as density of carriers/escape rates etc.. have to be calculated by integrating the fermi-dirrac occupation function multipled by a density of states which also changes over energy space. (say Nexp(-E/Eu)). Thus you should really be solving for Fermi-level rather than ftb directly. I suspect you need to do this last step to get smooth TPC transients.
ANS f_tb is indeed obtained from F-D statistics (in steady-state of course). However, we only have a single trap level as pointed out in the manual. Extending the code to more elaborate trap distributions (in energy and / or space) is not difficult, yet beyond the scope of the present work.
If this were an APL letter, I would probably not bother pushing this point. However, as I mentioned before my concern with publishing models, is they tend to be used by other people who don’t understand the bounds of validity of the model. So either I would I would like you to simulate a TPC transient and extract the Urbach energy out of it and demonstrate this in the manual as a test case. Or very clearly say where you think your model is valid and where it is not.
ANS Yes, we agree. This is crucial, as we have stated before, and one of the motivations for making this open-source rather than freeware. The assumptions underlying the codes are outlined in the part of the manual that lists the basic equations. However, some users might not be so keen on looking at these equations so we have summarized what is in the model in the beginning of chapter 2 (“What is currently included?”). Here, among other things, we explicitly state that we have one 1 trap level. The responsibility for assessing whether SIMsalabim is suited to describe experiments on some materials system lies squarely with the user (we also point this out in the manual and paper). We are not claiming to have the perfect physical model (drift-diffusion has plenty of assumptions, no matter how sophisticated). Rather, we are trying to get a software package out there including a description of the underlying assumptions. It is up to the users (if any:)) to verify whether the model is applicable or not. If the worst comes to the worst and a user tries to describe the experiments you’re referring to, they will find that the model does not fit the data.
We would like to point out that we are not advocating a model. We are publishing a software package that is capable of simulating the model described in the manual, but this model is constantly evolving and has been for a long time. Publishing physical models is not the scope of the Journal of Open Source Software. We would therefore like to keep the discussion focused on whether the code, documentation, and testing is of sufficient quality. We think our job here is to clearly explain our model in the documentation.
All modelling software is incomplete in terms of the physics and one can always find systems and experiments that cannot be explained/fitted. However, that does not mean that the software itself is meaningless. As we understand it, JOSS publishes articles to guarantee that the software does what it is supposed to do, there is adequate documentation and testing. Our software, unless we are missing something, does indeed function as specified in the manual, it is documented, and we have automated tests in place. Previously (when using the quasi-static trapping/detrapping), the software did indeed not fully function as suggested in the manual. Now, however, this is no longer the case.
Mkoopm
commented
2 years ago @whedon https://github.com/whedon generate pdf
On Thu, 9 Dec 2021 at 15:54, kostergroup @.***> wrote:
*So in the manual I think the section on trapping should be separated from the potential section (2.1.1) and given its own heading. I think in the trapping section you should explicitly call it SRH trapping/recombination – at the moment you cite the SR paper but don’t call it SRH. And possibly move the steady state SRH equation up into this section and explain the relationship between these two approaches. At the moment the casual reader may not make the connection.
ANS We, as per your request, specified explicitly which terms enter C(x) (in the Poisson equation, eq 2.1) and how this term (C(x)) is computed. Indeed, this part of the manual was not very clear. So, we have renamed section 2.5 ‘Recombination and Trapping’. In this section, we specify how the occupancy of the trap level and the capture/emission rates are computed in S-S and in the transient case.
*I think you need to write how Cn/Cp are calculated from SRH theory.
ANS Our Cn and Cp are simply the capture coefficients as related to the capture cross section (sigma) and the carrier velocity. So Cn/p are not calculated, but are input parameters and their unit is volume/time, as used in for example doi: 10.1038/srep37511 or in textbooks like eqs (7-155) and (7-156) in K.C. Kao, Dielectric phenomena in Solids. *Now, I don’t want to be overly critical and I appreciate the effort you went to, to put in traps. And a model with traps is infinitely better than a model with no traps. But I still don’t think you can simulate a TPC transient. But, I would be interested to see if you can reverse bias your device to say -2V then apply a laser pulse and then from the transient extract say a 100meV Urbach energy as done here https://doi.org/10.1021/jp4010828. This is the acid test of a transient model.
ANS: I think there is some misunderstanding about what we did in response to your previous comments: Trapping was included from the start. However, as you pointed out correctly, the transient code (ZimT) did use a quasi-static approach to trapping rather than a fully transient one. So, we changed the way we calculate the trap occupancy. Instead of relying on an (artificial) equilibrium between trapped and free charges (quasi-S-S), we now use capture and emission rates to explicitly solve for the trap occupancy. We did not, however, introduce elaborate distributions of trapping levels in energy.
The reason I don’t think you can do this is because my reading of the manual is that you have a single trap level with one capture/escape cross section. In reality the escape coefficients will change depending on the energetic depth of the trap. (See eqn. 2.9 in the original SR paper) This is the reason TPC transients look as they do. Early current comes from shallow traps deep current comes from deep traps. Also my reading of your manual is that you have a single trap density Ntb, rather than a distribution of traps over energy space which is another reason you won’t be able to model TPC transients. Furthermore, you are assuming that all traps will have the same occupational probability ftb which is true as you only have one trap but in reality there is no reason why shallow traps should have the same occupation as deep traps.
ANS: No, we are not assuming that ftb is static. We solve for ftb explicitly for every step and grid point. (Just as an : ftb is indeed not a constant and this becomes obvious by simulating TPC with a single trap level and enough traps to cause significant build-up of space charge. The resulting TPC transient is pretty much like a power-law and thus shows a multitude of lifetimes despite the single trap level:
[image: tpc] https://user-images.githubusercontent.com/64084163/145418974-284f1d99-70fb-4b2a-bb0f-ac9f8292c858.png
<\aside>) Furthermore, for a given trap energy range dE your occupation probability ftb, will not be a single number but a range of numbers dictated by fermi-dirrac statistics. So all trap information such as density of carriers/escape rates etc.. have to be calculated by integrating the fermi-dirrac occupation function multipled by a density of states which also changes over energy space. (say Nexp(-E/Eu)). Thus you should really be solving for Fermi-level rather than ftb directly. I suspect you need to do this last step to get smooth TPC transients.
ANS f_tb is indeed obtained from F-D statistics (in steady-state of course). However, we only have a single trap level as pointed out in the manual. Extending the code to more elaborate trap distributions (in energy and / or space) is not difficult, yet beyond the scope of the present work.
If this were an APL letter, I would probably not bother pushing this point. However, as I mentioned before my concern with publishing models, is they tend to be used by other people who don’t understand the bounds of validity of the model. So either I would I would like you to simulate a TPC transient and extract the Urbach energy out of it and demonstrate this in the manual as a test case. Or very clearly say where you think your model is valid and where it is not.
ANS Yes, we agree. This is crucial, as we have stated before, and one of the motivations for making this open-source rather than freeware. The assumptions underlying the codes are outlined in the part of the manual that lists the basic equations. However, some users might not be so keen on looking at these equations so we have summarized what is in the model in the beginning of chapter 2 (“What is currently included?”). Here, among other things, we explicitly state that we have one 1 trap level. The responsibility for assessing whether SIMsalabim is suited to describe experiments on some materials system lies squarely with the user (we also point this out in the manual and paper). We are not claiming to have the perfect physical model (drift-diffusion has plenty of assumptions, no matter how sophisticated). Rather, we are trying to get a software package out there including a description of the underlying assumptions. It is up to the users (if any:)) to verify whether the model is applicable or not. If the worst comes to the worst and a user tries to describe the experiments you’re referring to, they will find that the model does not fit the data.
We would like to point out that we are not advocating a model. We are publishing a software package that is capable of simulating the model described in the manual, but this model is constantly evolving and has been for a long time. Publishing physical models is not the scope of the Journal of Open Source Software. We would therefore like to keep the discussion focused on whether the code, documentation, and testing is of sufficient quality. We think our job here is to clearly explain our model in the documentation.
All modelling software is incomplete in terms of the physics and one can always find systems and experiments that cannot be explained/fitted. However, that does not mean that the software itself is meaningless. As we understand it, JOSS publishes articles to guarantee that the software does what it is supposed to do, there is adequate documentation and testing. Our software, unless we are missing something, does indeed function as specified in the manual, it is documented, and we have automated tests in place. Previously (when using the quasi-static trapping/detrapping), the software did indeed not fully function as suggested in the manual. Now, however, this is no longer the case.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openjournals/joss-reviews/issues/3727#issuecomment-989925972, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIVWZUMJPLB5AC55YREVPUTUQC7I5ANCNFSM5EAXX2FQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
-- Marten Koopmans (PhD student) Zernike Institute for Advanced Materials University of Groningen Website https://www.rug.nl/staff/marten.koopmans/research
whedon
commented
2 years ago I'm sorry human, I don't understand that. You can see what commands I support by typing:
@whedon commands@whedon generate pdf
whedon
commented
2 years ago :point_right::page_facing_up: Download article proof :page_facing_up: View article proof on GitHub :page_facing_up: :point_left:
rkurchin
commented
2 years ago @UTH-Tuan: what's the status of your last couple checklist items?
@Mkoopm: how about the updated testing in response to @shahmoradi's concern? (I see some changes have been made in the tests directory, but at least run_tests.py appears not to have been updated in several weeks)
@roderickmackenzie: What are your thoughts on @ljakoster's last message?
To add a bit of editorial perspective on this last aspect, I agree with Prof. Koster that JOSS's primary job is to review for whether the software does what it says it does, but I also agree with Prof. Mackenzie's perspective that any tool should be "clearly labeled" as to its appropriate uses. So, acknowledging the age-old Box quote, hopefully we can come to some consensus about where this model is useful, where it might be particularly wrong, and how it ought to be labeled accordingly. Thanks again to all for your detailed, thoughtful, and good-faith engagement in this process! 😄
Mkoopm
commented
2 years ago @rkurchin: the script run_tests.py was added responding to @shahmoradi's concerns, it automates the testing procedure and not been updated because it works (tests can now be automatically run).
rkurchin
commented
2 years ago Fantastic! I'll let @shahmoradi confirm that it looks okay and finish off his checklist. (Also, wow, November 15 was more than 23 days ago... 😮 )
roderickmackenzie
commented
2 years ago @rkurchin I've read the response but I've got to reread the manual/paper from top to bottom before being able to respond in a coherent way. Hope to do this early next week/over the weekend. R
shahmoradi
commented
2 years ago The test script run_tests.py works on Windows OS. It failed on MingW and Linux OS with various library errors. I assume these errors are due to version incompatibilities. While I am not going to require the authors to make this extra change in the tests, I highly recommend adding a few lines at the beginning of the script to automatically check proper library versions are installed on the user's system before running the tests. This way, it will be clear what exactly the source of test failures is, rather than getting highly obscure errors from random dependency libraries in the Python session.
I have check-marked the last remaining item in Review checklist for @shahmoradi.
Mkoopm
commented
2 years ago @shahmoradi, thank you for the thorough checking. We will include a nicer error message with an installation suggestion in the next update. Did you follow the instructions in tests.md, or did you just try to run run_tests.py? If the instructions don't work on your systems I will look into the installation method as well.
roderickmackenzie
commented
2 years ago In my last review I asked you to “...to see if you can reverse bias your device to say -2V then apply a laser pulse and then from the transient extract say a 100meV Urbach energy as done here https://doi.org/10.1021/jp4010828. This is the acid test of a transient model.” But you have not done this, so have done it for you using the graph you provided above. The results are below. The graph plots the normalized extracted density of states against energetic depth going into the band (0eV = close to band edge, 0.2 eV = deep into the band). I have included what one would expect for Urbach energies of 100 meV, 60 meV and 30 meV. One would expect a DoS descending into the bandgap. Also plotted in the data set is the DoS extracted from your transient using equation 1 and 2 in the paper mentioned above. You will notice that the line generated from your data has the wrong gradient, such a graph would indicate the trap density increases going into the bad which is clearly wrong.
The reason the extracted DoS goes the wrong way is because your model only has one trap state and you don’t discretized your Urbach tail in energy space. Urbach energy is the defining feature in many time domain transients, TPC, ToF, TPV and many others. See for example the discussions in (Seynhaeve and Main wrote a lot on this topic):
C. Main, D. Nesheva, Transient photocurrent techniques as a mean of characterising amorphous semiconductors Seynhaeve, Post-transit time-of-Aight currents as a probe of the density of states in hydrogenated amorphous silicon C. Main, Interpretation of photocurrent transients in amorphous semiconductors Street, Localized state distribution and its effect on recombination in organic solar cells C. Main, Computer Modellin gof Multi-Trapping and hopping transport in disordered semiconductors.
You say in the paper “While SIMsalabim is not restricted to the simulation of solar cells, some relevant solar cell experiments that can be simulated include: transient photovoltage, current-voltage sweeps (including hysteresis). SIMsalabim can be used to simulate many different device types, but the user should make sure that the physical model implemented in SIMsalabim fits the device and operating regime that is simulated.”
I find this problermatic (especially for someone inexperienced), because on one hand you say it’s time domain but on the other you are saying be careful as the model may not be correct. In reality people are going to use this model for disordered solar cells, such as in OPV or perovskite because that’s what the community is working on. In these systems you you need the Urbach tail discritized in energy space or you will get results as shown above.
This for me this is the fundamental sticking point. It claims to be time domain model but it’s not clear which time domain experiments it’s valid for. I would not want to be the PhD student who tries to use this model to simulate anything in time domain. It could at best result in frustration and at worst result in papers in the literature which should not be published. So in terms of JOSS criteria I can’t tick the box “Has a clear description of the high-level functionality and purpose of the software for a diverse, non-specialist audience been provided”
From my point of view there are two options:
Write a paragraph in the manual properly reflecting about where/when the model can be used and where it can not be used. For example I would not use it to simulate the post-transit regime in TPC or ToF transients. I would worry about TPV transients especially anything which was non mono-exponentiation. CELIV may be OK. Slow Perovskite JV scans would prob be OK although fast scans may not be. I think you need to reflect on this an be up front about the user about limitations esp. for an "non-specialist audience". This is not a big ask and should take about half an hour to write.
If you are going to claim it’s time domain in the way you do without caveats: Implement Urbach tails properly and demonstrate you can simulate TPC transients then extract the Urbach energy using the methods presented https://doi.org/10.1021/jp4010828, and developed by Main et al.
This reviewer will simply not let the paper pass without condition 1 or 2 being met. I don’t think 1 is a big ask...
kostergroup
commented
2 years ago @roderickmackenzie In my last review I asked you to “...to see if you can reverse bias your device to say -2V then apply a laser pulse and then from the transient extract say a 100meV Urbach energy as done here https://doi.org/10.1021/jp4010828. This is the acid test of a transient model.” But you have not done this, so have done it for you using the graph you provided above.
ANS We did not do this as this would obviously fail.
From my point of view there are two options:
This reviewer will simply not let the paper pass without condition 1 or 2 being met. I don’t think 1 is a big ask...
ANS Both options require quite a bit of thought, not in the least as I anticipate that we would not agree straight away about option 1. So, please bear with us for a bit; we will get back to you in the new year.
ProfTuan
commented
2 years ago @UTH-Tuan: what's the status of your last couple checklist items?
@Mkoopm: how about the updated testing in response to @shahmoradi's concern? (I see some changes have been made in the tests directory, but at least
run_tests.pyappears not to have been updated in several weeks)@roderickmackenzie: What are your thoughts on @ljakoster's last message?
To add a bit of editorial perspective on this last aspect, I agree with Prof. Koster that JOSS's primary job is to review for whether the software does what it says it does, but I also agree with Prof. Mackenzie's perspective that any tool should be "clearly labeled" as to its appropriate uses. So, acknowledging the age-old Box quote, hopefully we can come to some consensus about where this model is useful, where it might be particularly wrong, and how it ought to be labeled accordingly. Thanks again to all for your detailed, thoughtful, and good-faith engagement in this process! 😄
@rkurchin,
There was an earlier comment by @shahmoradi about the automation test. I want to confirm if that has been updated.
While this domain not my field of expertise, @roderickmackenzie has raised some substantive points that need to be addressed.
rkurchin
commented
2 years ago Happy New Year everyone! @kostergroup, just a friendly reminder to update on this when you've decided your next course of action. I recognize some folks are still on holiday this week, and that as you said, it may require substantial thought. Depending on how long you want, I can also "pause" this review for a few weeks if you like.
kostergroup
commented
2 years ago Happy 2022 everyone!
@rkurchin I've just returned to the office and I think we'll get back to this in a week or 2. Not sure that qualifies as a 'pause'? probably.
jan anton
-- Prof. Dr. L.J.A. (Jan Anton) Koster Zernike Institute for Advanced Materials University of Groningen open-source simulator for perovskite and organic PV https://github.com/kostergroup/SIMsalabim group website http://www.koster-group.nl
On Mon, 3 Jan 2022 at 22:52, Rachel Kurchin @.***> wrote:
Happy New Year everyone! @kostergroup https://github.com/kostergroup, just a friendly reminder to update on this when you've decided your next course of action. I recognize some folks are still on holiday this week, and that as you said, it may require substantial thought. Depending on how long you want, I can also "pause" this review for a few weeks if you like.
— Reply to this email directly, view it on GitHub https://github.com/openjournals/joss-reviews/issues/3727#issuecomment-1004383204, or unsubscribe https://github.com/notifications/unsubscribe-auth/API5RQ5XLW5FIRSEM6PBQ3LUUILBHANCNFSM5EAXX2FQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID: @.***>
rkurchin
commented
2 years ago For just a week or two I don't think it's necessary. Just keep us posted!
rkurchin
commented
2 years ago Hi again @kostergroup @ljakoster, just checking in on this!
ljakoster
commented
2 years ago @rkurchin: thanks. We're almost done!
-- Prof. Dr. L.J.A. (Jan Anton) Koster Zernike Institute for Advanced Materials University of Groningen open-source simulator for perovskite and organic PV https://github.com/kostergroup/SIMsalabim group website http://www.koster-group.nl
On Sun, Jan 23, 2022 at 7:54 PM Rachel Kurchin @.***> wrote:
Hi again @kostergroup https://github.com/kostergroup @ljakoster https://github.com/ljakoster, just checking in on this!
— Reply to this email directly, view it on GitHub https://github.com/openjournals/joss-reviews/issues/3727#issuecomment-1019544992, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJFMMVC7QET6R2TMEU7PONDUXRFGPANCNFSM5EAXX2FQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID: @.***>
kostergroup
commented
2 years ago @roderickmackenzie
From my point of view there are two options: 1 Write … write. 2 If you are going to claim it’s time domain in the way you do without caveats: Implement Urbach tails properly and demonstrate you can simulate TPC transients then extract the Urbach energy using the methods presented https://doi.org/10.1021/jp4010828, and developed by Main et al.
This reviewer will simply not let the paper pass without condition 1 or 2 being met.
ANS
OK, thanks for bearing with us. We have opted for option 2. So, we have implemented the possibility of defining multiple trap levels (either bulk or interfacial). To validate the approach, we have put in a distribution of bulk trap levels below the conduction band that follows an Urbach tail of 100 meV and analysed the data as per your publication. We get the following:
So below the conduction band we indeed find a very nice exponential tail with an Urbach energy of 95 meV, very close to the input. (this is test 11)
For the bulk traps, we use:
Where the conduction band sits at 3.0 eV. We trust that we have met your request.
@shahmoradi: We added a check for python dependencies to the testing code. Now, installation instructions are shown if a dependency is not met.
roderickmackenzie
commented
2 years ago Good effort! And thanks for all your work. My only final suggestion is that you put a paragraph in the manual saying that a distribution of trap states are important when simulating disordered materials. That way people won't be tempted to run simulations/publish papers with no traps. best, Rod
kostergroup
commented
2 years ago @roderickmackenzie Good effort! And thanks for all your work. My only final suggestion is that you put a paragraph in the manual saying that a distribution of trap states are important when simulating disordered materials. That way people won't be tempted to run simulations/publish papers with no traps. best, Rod
ANS
Thanks for your final suggestion; this is our final modification. You provided us with two options; we opted for the more laborious option 2 as it extends the code, which is time well spent. By asking us to specify when distributions of traps are important, you are effectively asking us to also implement option 1. In all fairness, this is asking too much.
However, we have changed the manual to warn the user of the importance of getting the trapping right. Firstly, we have renamed section ‘Recombination and Trapping’ => ‘Trapping and Recombination’ to put the emphasis on trapping. Next, we have added to the manual (section ‘Trapping and Recombination’):
By their very nature, traps capture charge carriers. It is critical to understand their effects on a device in order to judge their relevance. Trapped charge carriers contribute to the space charge (see Eq. 2.1), without contributing to charge transport. Additionally, trap levels introduce another recombination pathway. Both effects are typically bad for device performance.
In transient simulations, things get a little bit more complicated as the trapping and/or detrapping can take rather long and, therefore, it might take a long time (as compared to the simulated time) before equilibrium is reached. This is especially relevant to cases where there is a distribution of traps, giving rise to multiple trapping/detrapping times.
In sum, traps can have a large impact on the simulations, depending on what is simulated and in what regime.
rkurchin
commented
2 years ago Hi again, @roderickmackenzie, does this satisfy your review at this point?
roderickmackenzie
commented
2 years ago Hi All, Yes I'm happy for this to be published now. best, Rod
rkurchin
commented
2 years ago Great, thanks – could you finish up your checklist in that case?
And @UTH-Tuan and @shahmoradi, can you also confirm you're happy to accept?
roderickmackenzie
commented
2 years ago done. R
rkurchin
commented
2 years ago @whedon generate pdf
whedon
commented
2 years ago :point_right::page_facing_up: Download article proof :page_facing_up: View article proof on GitHub :page_facing_up: :point_left:
ljakoster
commented
2 years ago @rkurchin We've received a proof from whedon; does that mean the manuscript has been accepted for publication?
Prof. Dr. L.J.A. (Jan Anton) Koster Zernike Institute for Advanced Materials University of Groningen open-source simulator for perovskite and organic PV https://github.com/kostergroup/SIMsalabim group website http://www.koster-group.nl
On Fri, Feb 4, 2022 at 12:57 AM whedon @.***> wrote:
👉📄 Download article proof https://raw.githubusercontent.com/openjournals/joss-papers/joss.03727/joss.03727/10.21105.joss.03727.pdf 📄 View article proof on GitHub https://github.com/openjournals/joss-papers/blob/joss.03727/joss.03727/10.21105.joss.03727.pdf 📄 👈
— Reply to this email directly, view it on GitHub https://github.com/openjournals/joss-reviews/issues/3727#issuecomment-1029511864, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJFMMVE4J5CFPMZXNMYSBU3UZMJABANCNFSM5EAXX2FQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID: @.***>
rkurchin
commented
2 years ago Jan Anton,
I generated the latest proof so I can do the last few editorial checks while I wait to hear from the other two reviewers that they're happy to accept. The other things you'll need to do before we finalize this submission are (assuming no other changes are needed):
rkurchin
commented
2 years ago Here are some small editorial comments on the manuscript itself:
rkurchin
commented
2 years ago @whedon check references
whedon
commented
2 years ago Reference check summary (note 'MISSING' DOIs are suggestions that need verification):
OK DOIs
- 10.1016/j.xcrp.2021.100346 is OK
- 10.1021/acsenergylett.0c02599 is OK
- 10.1039/D0EE00714E is OK
- 10.1021/acsami.0c16411 is OK
- 10.1103/PhysRevApplied.15.014006 is OK
- 10.1021/acsenergylett.9b02720 is OK
- 10.1021/acsami.8b20493 is OK
- 10.1021/acsaem.9b00856 is OK
- 10.1007/s10825-019-01396-2 is OK
MISSING DOIs
- None
INVALID DOIs
- https://doi.org/10.1016/S0040-6090(99)00825-1 is INVALID because of 'https://doi.org/' prefix@ljakoster please also fix that one invalid DOI ;)
ProfTuan
commented
2 years ago Great, thanks – could you finish up your checklist in that case?
And @UTH-Tuan and @shahmoradi, can you also confirm you're happy to accept?
accept
rkurchin
commented
2 years ago @shahmoradi, are you okay to accept this?
shahmoradi
commented
2 years ago Looks good to me. Thank you.
rkurchin
commented
2 years ago Great, so @ljakoster, once the couple last things above are addressed, this is ready to rock! 🚀
ljakoster
commented
2 years ago Dear All,
great! I would like to thank the reviewers for their patience and input; the project has greatly improved as a result of it.
@rkurchin: Marten and I are working on this.
Prof. Dr. L.J.A. (Jan Anton) Koster Zernike Institute for Advanced Materials University of Groningen open-source simulator for perovskite and organic PV https://github.com/kostergroup/SIMsalabim group website http://www.koster-group.nl
On Mon, Feb 7, 2022 at 10:26 PM Rachel Kurchin @.***> wrote:
Great, so @ljakoster https://github.com/ljakoster, once the couple last things above are addressed, this is ready to rock! 🚀
— Reply to this email directly, view it on GitHub https://github.com/openjournals/joss-reviews/issues/3727#issuecomment-1031942014, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJFMMVGRIL5DFWLGHGTRSRTU2A2IFANCNFSM5EAXX2FQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID: @.***>
ljakoster
commented
2 years ago @rkurchin:
I think we have done all the things you requested. We have a doi: https://doi.org/10.5281/zenodo.6010442 All the changes already were in the latest version (4.29) and we have created a new version tag: v4.29-JOSS https://github.com/kostergroup/SIMsalabim/releases/tag/v4.29-JOSS.
Thanks for editing the paper; we've modified the text. Please let me know if we've missed something.
best wishes, Jan Anton
-- Prof. Dr. L.J.A. (Jan Anton) Koster Zernike Institute for Advanced Materials University of Groningen open-source simulator for perovskite and organic PV https://github.com/kostergroup/SIMsalabim group website http://www.koster-group.nl
On Fri, Feb 4, 2022 at 12:42 PM Rachel Kurchin @.***> wrote:
Jan Anton,
I generated the latest proof so I can do the last few editorial checks while I wait to hear from the other two reviewers that they're happy to accept. The other things you'll need to do before we finalize this submission are (assuming no other changes are needed):
- Merge any and all changes from this review into your main branch and issue a new version tag. (If you want to merge in the paper, you may, but it is not required that the actual manuscript live into the repo in perpetuity since JOSS will host it and you can simply add a badge link or whatever you like. But the actual changes to software and docs do need to be merged!)
- Create a DOI for the contents of the repo at the same commit corresponding to that version tag, e.g. using figshare or Zenodo. Please make sure that the metadata (version number, title, author list, etc.) match those of your manuscript.
- Post a comment here with the version number and DOI.
— Reply to this email directly, view it on GitHub https://github.com/openjournals/joss-reviews/issues/3727#issuecomment-1029912030, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJFMMVFRRC2GGFECW62AFZDUZO3SHANCNFSM5EAXX2FQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID: @.***>
rkurchin
commented
2 years ago @whedon set v4.29-JOSS as version
Submitting author: @ljakoster (Lambert Jan Anton Koster) Repository: https://github.com/kostergroup/SIMsalabim Version: v4.29-JOSS Editor: @rkurchin Reviewer: @UTH-Tuan, @shahmoradi, @roderickmackenzie Archive: 10.5281/zenodo.6010442
:warning: JOSS reduced service mode :warning:
Due to the challenges of the COVID-19 pandemic, JOSS is currently operating in a "reduced service mode". You can read more about what that means in our blog post.
Status
Status badge code:
Reviewers and authors:
Please avoid lengthy details of difficulties in the review thread. Instead, please create a new issue in the target repository and link to those issues (especially acceptance-blockers) by leaving comments in the review thread below. (For completists: if the target issue tracker is also on GitHub, linking the review thread in the issue or vice versa will create corresponding breadcrumb trails in the link target.)
Reviewer instructions & questions
@UTH-Tuan & @shahmoradi & @roderickmackenzie, please carry out your review in this issue by updating the checklist below. If you cannot edit the checklist please:
The reviewer guidelines are available here: https://joss.readthedocs.io/en/latest/reviewer_guidelines.html. Any questions/concerns please let @rkurchin know.
✨ Please start on your review when you are able, and be sure to complete your review in the next six weeks, at the very latest ✨
Review checklist for @UTH-Tuan
✨ Important: Please do not use the Convert to issue functionality when working through this checklist, instead, please open any new issues associated with your review in the software repository associated with the submission. ✨
Conflict of interest
Code of Conduct
General checks
Functionality
Documentation
Software paper
Review checklist for @shahmoradi
✨ Important: Please do not use the Convert to issue functionality when working through this checklist, instead, please open any new issues associated with your review in the software repository associated with the submission. ✨
Conflict of interest
Code of Conduct
General checks
Functionality
Documentation
Software paper
Review checklist for @roderickmackenzie
✨ Important: Please do not use the Convert to issue functionality when working through this checklist, instead, please open any new issues associated with your review in the software repository associated with the submission. ✨
Conflict of interest
Code of Conduct
General checks
Functionality
Documentation
Software paper