Support Options

Submit a Support Ticket

  • Discoverability Visible
  • Join Policy Invite Only
  • Created 29 Jun 2010

Problems reproducing bulk TB results for new parameters

  1. James Jehiel Ramsey

    I’ve been trying to test the parameters from Jancu et al., PRB 57, 6493 (1998) for use in NEMO5, and I’m running into a problem. The results are not agreeing with results of previously written Matlab/Octave scripts that determine band edges in bulk GaAs as a function of strain, and the Matlab/Octave results agree with published results. (Compare the Octave results in comp_NEMO_octave-Jancu-biax.eps in the attached archive with the dotted lines in Fig. 1 of the paper by Boykin et al. in PRB 66, 125207 (2002).) With the GaAs parameters from Boykin et al., however, I do get agreement between NEMO5 and the scripts.

    I’ve checked the obvious stuff like typos in the parameters, and so far, the problem doesn’t seem to be that simple. Another possible issue is that parameters from Jancu et al. aren’t meant to be used with the scheme from Boykin et al. for strain-dependent shifts of diagonal parameters, but I thought that simply having zero values for the strain_constant_C_* parameters should make these shifts equal to zero. The strain_exponent_V_* parameters are of course set to the values from Jancu et al.

    Obviously, I’m missing something, but I’m not sure what.

    Report abuse

  2. Tillmann Christoph Kubis

    Just as a comment, when you insert parameters in the inputdeck, NEMO5 will use these parameters with higher priority than the material database. Thus, there is no need to produce extra database files. Regarding your question: Indeed, you can set the strain_constant_C values to zero and the strain result of the Boykin 2002 model is set to zero. The strain exponent is used to scale the interatomic coupling elements: result = unstrained_result*distance_ratiostrain_exponent In so far, I do not see a mistake in the NEMO5 usage.

    Report abuse

  3. James Jehiel Ramsey

    I figured it would be more convenient to make a separate database, but adding the parameters directly to the input deck ended up getting me sane results. I’m not sure why that made a difference, though I’d gather that it probably means that there is some error in my database file.

    Thanks for the tip.

    Report abuse, a resource for nanoscience and nanotechnology, is supported by the National Science Foundation and other funding agencies. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.