Overview

This issue is a seed for a new milestone.

Currently this module uses conda for building a package and has no continuous integration enabled. The python build ecosystem has evolved to cover most of conda's use-cases, and continuous integration will provide automation for tedious and error-prone tasks.

In no particular order, I want to achieve the following outcomes.

1. Replace conda with hatch for building.
2. Automate build and test with tox.
3. Automate build and test when commits are pushed to a PR, or a tag is pushed. Block PR merge if all tests are not passed.
4. Automatically cut a release when a version tag is pushed. Push new final release to pypi (but not prereleases or post-releases).
5. Embed version metadata in module (e.g. ibei.__version__), properly updated at build time.

When calling ibei.devos_efficiency, a TypeError exception is raised. This issue can be repeated with the following code

import ibei
bandgap = 1.15
temp_earth = 288
temp_sun = 5762
ibei.devos_efficiency(bandgap, temp_sun, temp_earth, 1.09)

The following exception is raised:

TypeError: Constant u'e' does not have physically compatible units across all systems of units and cannot be combined with other values without specifying a system (eg. e.emu)

Essentially the same as issue 12 of physicalproperty.

There seems to be an intermediate 'main' level when I import this module. I want to have the classes and methods directly below the ibei module. For example, I don't want

ibei.main.uibei

I want

ibei.uibei

This problem is most apparent when building the API documentation.

Since this module depends on numpy, it makes sense to package and distribute it using conda and binstar.org in order to ease the difficulty of installing the dependencies.

This issue pretty much obviates #19 and depends on #26.

The following commands should replicate this issue

import ibei
bandgap = 1.15
temp_earth = 288
temp_sun = 5762
ibei.devos_efficiency(bandgap, temp_sun, temp_earth, 1.2)

The traceback for the exception is as follows:

ERROR: TypeError: float() argument must be a string or a number [ibei.main]
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-2-9aa0a5faf55e> in <module>()
----> 1 ibei.devos_efficiency(bandgap, temp_sun, temp_earth, 1.2)

/Users/jrsmith3/Documents/work/ibei/ibei/main.py in devos_efficiency(bandgap, temp_sun, temp_planet, voltage)
     71     Efficiency calculated according to DeVos Eqs. 6.4 and prior.
     72     """
---> 73     cell_power = devos_power(bandgap, temp_sun, temp_planet, voltage)
     74     solar_power = bb_rad_power(temp_sun)
     75 

/Users/jrsmith3/Documents/work/ibei/ibei/main.py in devos_power(bandgap, temp_sun, temp_planet, voltage)
     63 
     64     solar_flux = uibei(2, bandgap, temp_sun, 0)
---> 65     solar_cell_flux = uibei(2, bandgap, temp_planet, electron_energy)
     66 
     67     return electron_energy * (solar_flux - solar_cell_flux)

/Users/jrsmith3/Documents/work/ibei/ibei/main.py in uibei(order, energy_lo, temp, chem_potential)
     37         real_arg = np.exp(expt.value)
     38 
---> 39         term = reduced_energy_lo**index * float(polylog(indx, real_arg)) / np.math.factorial(index)
     40 
     41         summand += term

TypeError: float() argument must be a string or a number

Release version 1.0.6. This issue closes when milestone 1.0.6 is reached.

The gh-pages branch is unnecessary as soon as the documentation successfully gets posted to ReadTheDocs.

Disclaimer: Its been awhile since I wrote the original code examples for this issue.

Problem

There's a non-continuous kink in the photon energy flux calculation vs. temperature (cf. this ipython notebook). The problem is that the photon energy flux is calculated via a finite sum of polylogarithm functions and the first order polylogarithm function returns values of zero for sufficiently small arguments. At some value of argument, the return value suddenly jumps to a nonzero value and yields the kink seen in the ipython notebook.

In ibei, the polylogarithm is implemented by the mpmath package via sympy. The first order polylogarithm can be expressed as a natural log.

Li_{1}(z) = -log(1 - z)

mpmath's implementation of the first order polylogarithm tests for the case of order unity and calls the natural log function in this case. The problem is that the argument to the natural log function is unity minus the polylogarithm argument. If the original polylogarithm argument is very small, 1 - z will be rounded to unity yielding zero for the final result (log(1) = 0).

>>> import mpmath
>>> z = 5e-20
>>> mpmath.polylog(1, z)
0

Solution

The solution is simply to increase the precision of the mpmath calculation to the order of the polylogarithm argument.

>>> import mpmath
>>> z = 5e-20
>>> mpmath.mp.dps = 22
>>> mpmath.polylog(1, z)
mpf('5.000000487562466251661797e-20')

This modification can be done within the uibei method by evaluating the size of the real_arg value.

Trigger

The following code will raise the exception:

import ibei
input_params = {"temp_sun": 5762.,
                "temp_planet": 288.,
                "bandgap": 0.1,
                "voltage": 0.5,}
sc = ibei.DeVosSolarcell(input_params)
sc.calc_power_density()

Proposed solution

I am pretty sure this exception can be prevented by fixing the units that are output by ibei.uibei when energy_lo < chem_potential.

Traceback

Here's the traceback on my machine:

ERROR: UnitsError: 'C V' (energy) and 'W / m2' are not convertible [astropy.units.core]
---------------------------------------------------------------------------
UnitsError                                Traceback (most recent call last)
<ipython-input-7-11e6c0fae7a0> in <module>()
----> 1 sc.calc_power_density()

/Users/jrsmith3/Documents/work/ibei/ibei/main.py in calc_power_density(self)
    191         power_density = electron_energy * (solar_flux - solar_cell_flux)
    192 
--> 193         return power_density.to("W/m^2")

/Users/jrsmith3/anaconda/lib/python2.7/site-packages/astropy/units/quantity.pyc in to(self, unit, equivalencies)
    479         unit = Unit(unit)
    480         new_val = np.asarray(
--> 481             self.unit.to(unit, self.value, equivalencies=equivalencies))
    482         result = self.__quantity_view__(new_val, unit)
    483         result._unit = unit

/Users/jrsmith3/anaconda/lib/python2.7/site-packages/astropy/units/core.pyc in to(self, other, value, equivalencies)
    909             If units are inconsistent
    910         """
--> 911         return self.get_converter(other, equivalencies=equivalencies)(value)
    912 
    913     def in_units(self, other, value=1.0, equivalencies=[]):

/Users/jrsmith3/anaconda/lib/python2.7/site-packages/astropy/units/core.pyc in get_converter(self, other, equivalencies)
    845         except UnitsError:
    846             return self._apply_equivalences(
--> 847                 self, other, self._normalize_equivalencies(equivalencies))
    848         return lambda val: scale * _condition_arg(val)
    849 

/Users/jrsmith3/anaconda/lib/python2.7/site-packages/astropy/units/core.pyc in _apply_equivalences(self, unit, other, equivalencies)
    808         raise UnitsError(
    809             "{0} and {1} are not convertible".format(
--> 810                 unit_str, other_str))
    811 
    812     def get_converter(self, other, equivalencies=[]):

UnitsError: 'C V' (energy) and 'W / m2' are not convertible

Overview

I want to run this code again and it needs some modifications in order to do so. At minimum, I think it needs the following modifications:

1. Relative imports of submodules.
2. Break dependence on physicalproperty.
3. Break dependence on the deVos, Shockley Queisser implementations.
4. Complete #35.

There are several other modifications that I’d like to make to automate some things, review the tests, etc., but the three items above should be enough to get this thing to run.

Once I make these changes, I can cut a new dev release (2.0.0.dev1).

The motivation for this issue is exactly the same as issue 11 of the physicalproperty package.

Overview

The scope of this ticket is to refactor the tests to use pytest instead of unittest. The end result will be up to my discretion; e.g. what kinds of fixtures I write, how I organize tests, etc.

Since this project is a python module, the versioning scheme should be PEP 440 compatible.

Currently the category is "Development Status :: 3 - Alpha". It should be "Development Status :: 5 - Production/Stable".

This project currently has conda building against whatever is in the filesystem. The meta.yaml should be changed so that conda builds against the (local checkout) of the repository.

Modification

Change the lines noted in the link above to

source:
    git_url: ..

Overview

I should update the CHANGELOG to note the PR #40.

It makes sense for the PhysicalProperty class to be separated from this module because it is independent. Once that code has been removed, I can merge it back into this repo in a similar fashion as I did with merging this repo into tec.

The classes should be in their own .py files instead of everything being in main.py.

The filename is ambiguous and should be something like "test_ibei.py" or something.

The patch version number should be bumped when this issue is closed.

Jeff Knupp's post should be useful in this regard.

Overview

Since I was actively working on this project, I've created a set of labels that work well. This new set of labels is not the same as the set of labels in this repo, so I want to migrate to the new set of labels.

The following existing labels will be deleted and will not be mapped to a new label.

• code cleanup
• documentation
• enhancement
• question
• test

Closing this issue will not require a PR.

Deliverables

Replace current labels with the new ones defined in this ticket, map the old ones to the new ones as defined above.

It looks like mpmath has been unbundled from sympy as of PR 2192. This change hasn't been released as a tag yet, but when it does, ibei functionality will break.

Overview

See title.

Overview

The scope of this ticket is to write a GitHub action to automatically run the tests when commits are pushed. Additionally, PRs should be blocked from being merged if the tests are not passing.

Related issues

• Depends on #50.

The physicalproperty module should come in via an "import" statement. The code should not be included like it is.

To close this issue, physicalproperty needs to end up on pypi so that it can be imported.

Overview

This functionality would be a good compliment to the existing functionality and #43.

I’ve done some calculations and as far as I can tell the lower-incomplete Bose-Einstein integral can only be expressed in terms of the complete integral and upper incomplete integral.

lower = complete - upper

Related issues

• Depends on #43.

Currently I'm running the tests for this package from within the repo directory using the nosetests command. Now that this package is on pypi, I would like to be able to execute the tests after a user has installed the package using pip install ibei.

Overview

The scope of this issue is to write a GitHub action that generates releases from release tags.

Deliverables

• Document what a "release tag" is.
• Document versioning strategy.
• Write GitHub action to generate releases from release tags.
• Releases should include corresponding package artifacts.

Symptom

The following is the output of the nosetests command at the command line from within the root directory of the repository.

.............E...........................
======================================================================
ERROR: Raise UnitsException when setting with Quantity of incompatible units.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/jrsmith3/Documents/work/ibei/test/test_PhysicalProperty.py", line 64, in test_set_Quantity_incompatible_units
    self.assertRaises(units.UnitsException, pp.__set__, MockClassEmpty, qty)
AttributeError: 'module' object has no attribute 'UnitsException'

----------------------------------------------------------------------
Ran 41 tests in 0.634s

FAILED (errors=1)

Resolution

Update the test_PhysicalProperty.py tests to look for a astropy.units.UnitsError instead of astropy.units.UnitsException.

It states the version is 1.0.0.

Overview

Since I stopped working on this project, the standard python build ecosystem has advanced and I think I can rely on it for what this project needs. The scope of this ticket is to remove conda as the packaging solution in favor of hatch.

Deliverables

• Remove conda as packaging solution.
• Create pyproject.toml with necessary configuration and remove setup.py.
• Leverage hatch-vcs to automatically calculate version string.
• Relocate module source under src directory.

Trigger

import ibei
ibei.uibei(2, 1., 300., 1.)

Traceback

ERROR: ValueError: zeta(1) pole [sympy.mpmath.libmp.gammazeta]
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-10-5fb2c6a8e4cd> in <module>()
----> 1 ibei.uibei(2, 1., 300., 1.)

/Users/jrsmith3/Documents/work/ibei/ibei/main.pyc in uibei(order, energy_lo, temp, chem_potential)
     56         index = order - indx + 1
     57 
---> 58         term = reduced_energy_lo**index * float(polylog(indx, real_arg)) / np.math.factorial(index)
     59 
     60         summand += term

/Users/jrsmith3/anaconda/lib/python2.7/site-packages/sympy/mpmath/ctx_mp_python.pyc in f_wrapped(ctx, *args, **kwargs)
   1014                 try:
   1015                     ctx.prec += 10
-> 1016                     retval = f(ctx, *args, **kwargs)
   1017                 finally:
   1018                     ctx.prec = prec

/Users/jrsmith3/anaconda/lib/python2.7/site-packages/sympy/mpmath/functions/zeta.pyc in polylog(ctx, s, z)
    466     z = ctx.convert(z)
    467     if z == 1:
--> 468         return ctx.zeta(s)
    469     if z == -1:
    470         return -ctx.altzeta(s)

/Users/jrsmith3/anaconda/lib/python2.7/site-packages/sympy/mpmath/functions/zeta.pyc in zeta(ctx, s, a, derivative, method, **kwargs)
    532     if a == 1 and not (d or method):
    533         try:
--> 534             return ctx._zeta(s, **kwargs)
    535         except NotImplementedError:
    536             pass

/Users/jrsmith3/anaconda/lib/python2.7/site-packages/sympy/mpmath/ctx_mp_python.pyc in f(x, **kwargs)
    991             if hasattr(x, '_mpf_'):
    992                 try:
--> 993                     return ctx.make_mpf(mpf_f(x._mpf_, prec, rounding))
    994                 except ComplexResult:
    995                     # Handle propagation to complex

/Users/jrsmith3/anaconda/lib/python2.7/site-packages/sympy/mpmath/libmp/gammazeta.pyc in mpf_zeta(s, prec, rnd, alt)
   1199             return mpf_mul(z, q, prec, rnd)
   1200         else:
-> 1201             return mpf_zeta_int(to_int(s), prec, rnd)
   1202     # Negative: use the reflection formula
   1203     # Borwein only proves the accuracy bound for x >= 1/2. However, based on

/Users/jrsmith3/anaconda/lib/python2.7/site-packages/sympy/mpmath/libmp/gammazeta.pyc in mpf_zeta_int(s, prec, rnd)
   1132     if s < 2:
   1133         if s == 1:
-> 1134             raise ValueError("zeta(1) pole")
   1135         if not s:
   1136             return mpf_neg(fhalf)

ValueError: zeta(1) pole

Add the following to meta.yaml:

build:
    string: {{ environ.get('GIT_BUILD_STR', '') }}

In this way the commit hash (more or less) will be set as the conda build string and therefore I will be able to identify from which commit a particular conda build was produced.

This upgrade is currently not compatible with Issue #37, or at least I can't figure out how to simultaneously specify noarch and use the git commit hash in the build string.

Overview

Functionality to complete the full Bose-Einstein integral would be a good compliment to the upper-incomplete functionality.

Related issues

• Depends on #68.

Example

>>> import ibei
>>> ibei.uibei(3, 0., 300., 0.)
<Quantity 0.0 J / (m2 s)>

Discussion

This behavior is wrong; Wurfel defines the chemical potential of radiation in terms of non-thermal photons (LEDs, lasers, etc.). Therefore, a blackbody experiencing only thermal radiation has a chemical potential of radiation of zero. Furthermore, this blackbody can have a bandgap of zero (i.e. a metal). In this case, the blackbody clearly will emit a nonzero number of thermal photons, which the ibei.uibei function should correctly model.

Solution

Test for the case where both energy_lo and chem_potential are zero. If so, return the result of the calculation.

Add the following to meta.yaml:

build:
    string: {{ environ.get('GIT_BUILD_STR', '') }}

In this way the commit hash (more or less) will be set as the conda build string and therefore I will be able to identify from which commit a particular conda build was produced.

Overview

The scope of this issue is to introduce tox as the mechanism to run tests. I don't intend to use tox only for tests, but running tests is the first use-case for tox. I envision writing tox tasks for building documentation, etc.

Related issues

• Depends on #48.

Currently, that section of the documentation doesn't say anything useful. The 1.0.6 release should be posted on http://figshare.com/ so that it receives a DOI.

This note should occur in the "installation" section of the documentation. It should mention that the easiest way to get set up with the appropriate environment is to use the anaconda distribution.