"https://breakingbytes.github.io/".For the how and why I am making this move from Google Blogger to Pelican and GitHub Pages, please read my first post.
Moving to Pelican at GitHub PagesGood bye Google Blogger, you've served me well. And for anyone following Poquito Picante, I hope to see you soon at Breaking Bytes.
Please read my disclaimer.
SunPower Corp., my employer, has open sourced a solar panel mismatch estimation tool called PVMismatch at the Python Package Index with a standard 3-clause BSD license. The documentation, source code and releases are also available at the SunPower Organization GitHub page.
PVMismatch can be used to simulate mismatch between cells, modules and strings in a PV system. Mismatch can be caused be differences in irradiance, say by shading or by changes to the electrical characteristics of the cells such as series resistance or dark current, and these changes can lead to a difference in the current-voltage relation of the cell (aka its I-V curve). For a module made from solar cells in series, the cells must carry the same current, leading to different voltages in each cell, and so the effective I-V curve of the panel will differ from an individual cell. In some cases a cell may be forced to operate in reverse bias in order to pass the current imposed on it.
There is a detailed example in the Quickstart section of the documentation, but here's a shorter demonstration of the basic features and usage:
from pvmismatch import * # this imports pvcell, pvmodule, pvstring and pvsystem # create a default PV system from 10 strings of 10 300[W] panels each pvsys = pvsystem.PVsystem() f = pvsys.plotSys() # plot the system f.show()
If you find any issues, please report them on GitHub. Also, if you want to contribute, there's lots to do, so please fork the repo.
Box offers 10gb of online storage for free, double what anyone else offers, with an individual max size of 2gb, but you can only upload 250mb files. So how do you upload that 2gb file? The Box API that's how, either with regular ol' requests or their fancy smancy sdk. First follow the Getting Started instructions, sign up for a developer account and create a temporary key. Then in Python, try this out:
# import the requests package
import requests
# copy your token here
TOKEN = "<your developer token>"
# try to get the top level folder, id: "0", using this command exactly as below:
r = requests.get(url='https://api.box.com/2.0/folders/0',
headers={'Authorization': 'Bearer %s' % TOKEN})
# check the response
r
# <Response [200]>
# success!
# get the output
r.json()
# lots of stuff
# upload a file, using the commands exactly as below, except put the actual id number
# of the desired folder
FILES = {'file': open('path/to/myfile','rb')}
PAYLOAD = {'attributes': '{"name":"myfile", "parent":{"id":"<id # of desired folder>"}}'}
r = requests.post(url='https://upload.box.com/api/2.0/files/content',
headers={'Authorization': 'Bearer %s' % TOKEN},
files=FILES,
data=PAYLOAD)
# check the response
r
# <Response [201]>
# success!
Check the online Content API reference for full documentation.
Memorize this table - or just bookmark this link: Pandas Offset Aliases
A number of string aliases are given to useful common time series frequencies. We will refer to these aliases as offset aliases (referred to as time rules prior to v0.8.0).
| Alias | Description |
|---|---|
| B | business day frequency |
| C | custom business day frequency (experimental) |
| D | calendar day frequency |
| W | weekly frequency |
| M | month end frequency |
| SM | semi-month end frequency (15th and end of month) |
| BM | business month end frequency |
| CBM | custom business month end frequency |
| MS | month start frequency |
| SMS | semi-month start frequency (1st and 15th) |
| BMS | business month start frequency |
| CBMS | custom business month start frequency |
| Q | quarter end frequency |
| BQ | business quarter endfrequency |
| QS | quarter start frequency |
| BQS | business quarter start frequency |
| A | year end frequency |
| BA | business year end frequency |
| AS | year start frequency |
| BAS | business year start frequency |
| BH | business hour frequency |
| H | hourly frequency |
| T, min | minutely frequency |
| S | secondly frequency |
| L, ms | milliseconds |
| U, us | microseconds |
| N | nanoseconds |
If you're using the winning workflow and the recommended Python project layout then you've set up a CI server to build releases when you tag them in Git, and you set your version in the __init__.py file of your package. But, "Oh, No!" you did it again. You created the Git tag, but forgot to update your code's __version__ string.
Okay, there is a Python package called Versioneer that handles this for you, and it's pretty awesome. But it turns out it's also pretty easy to roll your own, especially if you're just using Git, because Python has a Git implementation called Dulwich that can do this in just a few lines. Maybe it will get integrated into a future version of Dulwich - I've submitted a PR (#462) which was merged into v0.16.3 and an update (#489) which was also merged into v0.17 to also list tags that are not objects. Anyway, for now, the easiest way to use this is to copy this file into your package at the top level, Install the latest version of dulwich (>=0.17.1), import it and then add something like this to your package dunder init module so it works both in your repo during dev and then later when deployed to users.
"""
Example package dunder init module implementing
``dulwich.contrib.release_robot`` to get current version.
"""
import os
import importlib
# try to import Dulwich or create dummies
try:
from dulwich.contrib.release_robot import get_current_version
from dulwich.repo import NotGitRepository
except ImportError:
NotGitRepository = NotImplementedError
def get_current_version():
raise NotGitRepository
BASEDIR = os.path.dirname(__file__) # this directory
VER_FILE = 'version' # name of file to store version
# use release robot to try to get current Git tag
try:
GIT_TAG = get_current_version()
except NotGitRepository:
GIT_TAG = None
# check version file
try:
version = importlib.import_module('%s.%s' % (__name__, VER_FILE))
except ImportError:
VERSION = None
else:
VERSION = version.VERSION
# update version file if it differs from Git tag
if GIT_TAG is not None and VERSION != GIT_TAG:
with open(os.path.join(BASEDIR, VER_FILE + '.py'), 'w') as vf:
vf.write('VERSION = "%s"\n' % GIT_TAG)
else:
GIT_TAG = VERSION # if Git tag is none use version file
VERSION = GIT_TAG # version
__author__ = u'your name'
__email__ = u'your.email@your.company.com'
__url__ = u'https://github.com/your-org/your-project'
__version__ = VERSION
__release__ = u'your release name'
Or you can also use it to get all recent tags.
get_recent_tags()[0][0]
assuming your tags all use semantic versions like "v0.3". Enjoy!
I'm super excited to announce the Cotton Candy release of Carousel, version 0.3 on PyPI and GitHub. There were a few more issues I really wanted to close with this release, but I decided to push it forward anyway. So the remaining milestones for v0.3 will get pushed to v0.3.1.
Meta class for all layers - currently usage is spotty and inconsistent. I wanted to keep the number of commits to close PR #68 to a minimum (following the winning workflow) so I only implemented Meta classes where I had to. In fact it's not even implemented in the DataSource example below.dependencies to an attribute of each parameter, the DAG shows which calculations are orthogonal, so we can run them simultaneously. According to issue #22, I had this idea already, but when I saw this presentation at PyData SF 2016 on Airflow by Matt Davis I was even more motivated to make it happen.Calculator class whose job it is to crunch through the calculations, somewhat similar to what DataReaders and FormulaImporter do for their layers. Then the boiler plate uncertainty propagation code in the static class could be applied to any calculator such as a dynamic calculator, a linear system solver for an acyclic DAG of linear equations or a non-linear system solver for an acyclic DAG of non-linear equations.Parameter classWhat's new in Carousel-0.3 (Cotton Candy)? The biggest difference is the introduction of the Parameter class which is now used to specify parameters for data, formulas, outputs, calculations and simulation settings. For example, previously data parameters would be entered as a dictionary of attributes.
class PVPowerData(DataSource):
"""
Data sources for PV Power demo.
"""
data_reader = ArgumentReader
latitude = {"units": "degrees", "uncertainty": 1.0}
longitude = {"units": "degrees", "uncertainty": 1.0}
elevation = {"units": "meters", "uncertainty": 1.0}
class PVPowerData(DataSource):
"""
Data sources for PV Power demo.
"""
latitude = DataParameter(units="degrees", uncertainty=1.0)
longitude = DataParameter(units="degrees", uncertainty=1.0)
elevation = DataParameter(units="meters", uncertainty=1.0)
class Meta:
data_reader = ArgumentReader
Why the change? The Bicycle Bear version did not have any way to distinguish parameters, like latitude from attributes of the DataSource like data_reader. This had two unfortunate side-effects:
The Cotton Candy version makes it easy for the metaclass to determine which class attributes are parameters, which are attributes of the layer and then leaves everything else alone. Every layer now has a corresponding Parameter subclass which also defines some base attributes corresponding to that layer. Any extra parameter attributes are saved in extras. Attributes that apply to the entire layer are now specified in the `Meta` class attribute, similar to Django, Marshmallow and DRF. The similarities are completely intentional as I have been strongly inspired by those project code bases. Unfortunately, the Meta class is only partially implemented, but will be the major focus of v0.3.1.
The Formula class is also improved. Now each formulas is a Parameter with attributes, rather than a giant dictionary. This improvement is still on the roadmap for the Calculation class. As I said above, it was a stretch goal for this release.
There are many blog posts on the topic of effective Git workflows, SO questions and answers, BitBucket tutorials and GitHub guides and an article that has been archived by former BBC Mark McDonnell. So why another post on git workflow? None of these workflows seemed right for us, but recently it's just clicked, and I feel like we've finally found the process that works for us. The key was finding the simplest workflow that included the most valuable best practices. In particular, we found that complicated multi-branch strategies were unnecessary, but test driven development (TDD) and continuous integration (CI) were a must.
We start with the assumption that all of collaborators fork the upstream repository to their personal profile. Then each person clones their profile to their laptop as origin and adds another remote pointing to the upstream repository. For convenience, they may also create remotes to the forks of their most frequent collaborators.
[myusername@mycomputer ~/Projects] $ git clone git@github.com:myusername/myrepo.git [myusername@mycomputer ~/Projects] $ cd myrepo [myusername@mycomputer ~/Projects/myrepo] $ git remote add upstream git@github.com:mycompany/myrepo.git [myusername@mycomputer ~/Projects/myrepo] $ git remote add mycollaborator git@github.com:mycollaborator/myrepo.git [myusername@mycomputer ~/Projects/myrepo] $ git remote show origin upstream mycollaborator
The next assumption is that we all keep our version of master synchronized with upstream master. And we never work out of our own master branch! Basically this means at the start of any new work we do the following:
git fetch --all to get the lay of the land. This combined with git log --all --graph --date=short --pretty=format:"%ad %h %s%d [%an]"
I'm also going to assume that everyone is following the recommended project layout. This means that their project has all dependencies listed in requirements.txt, is developed and deployed in its own virtual environment, includes testing and documentation that aims for >80% coverage, has a boilerplate design that allows testing, documentation and package data to be bundled into a distribution and enables use with a test runner with self discovery, and is written with docstrings for autodocumentation. Nothing is ever perfect, so being diligent of path clashes, aware of the arcana of Mac OS X1 or Windows2 and able to use Stack Overflow to find answers is still important.
This is key. Set up Travis, Circle, AppVeyor or Jenkins on upstream master to test and build every commit, every commit to an open PR and to deploy on every tag. Easy!
There are some features of this style that stand out:
PYTHONHOME=/home/you/path/to/project/venv/ python instead of using source venv/bin/activate.nosetests script will use your system Python and therefore the Python path will not include your virtual environment. The solution is to never use system site packages and install all dependencies directly in your virtual environment.The trick to this is creating a custom field and overloading pre_save. Pay special attention to the self.attname member that is set to the value. The source for DateField is a good example. Make sure that if you add any new attributes to the field in it's __init__ method you also add a corresponding deconstruct method.
I'm sure this is completely wrong. I needed a Django model for testing, but I don't have a Django app or even a Django project. I'm developing a Django model reader for Carousel, and so I needed a model to test it out with. Sure I could have created a quick django project, but that seemed silly, and my first instinct was to import django.db.models, make a model and use it, but this raised:
ImproperlyConfigured: Requested setting DEFAULT_INDEX_TABLESPACE, but settings are not
configured. You must either define the environment variable
DJANGO_SETTINGS_MODULE or call settings.configure() before accessing
settings.
Most normal people would turn back now, but instead I imported django.conf.settings and called settings.configure() just like it said to do. Now I got this error:
AppRegistryNotReady: Apps aren't loaded yet.
So now I felt like I was getting somewhere. But where? Googling told me to import django and run setup which I did and that raised:
RuntimeError: Model class __main__.MyModel doesn't declare an explicit app_label and isn't
in an application in INSTALLED_APPS.
Wow! Normally RuntimeError is a scary warning, like you dumped your core, but this just said I needed to add the app to settings.INSTALLED_APPS, which makes perfect sense, and it also complained that my model wasn't actually part of an app and even explained how to explicitly declare it. Some more Googling and I discovered that app_label is a model option that can be set in class Meta. So I did as told, and it worked!
from django.db import models
from django.conf import settings
import django
MYAPP = 'myapp.MyApp'
settings.configure()
django.setup()
settings.INSTALLED_APPS.append(MYAPP)
class MyModel(models.Model):
air_temp = models.FloatField()
latitude = models.FloatField()
longitude = models.FloatField()
timezone = models.FloatField()
pvmodule = models.CharField(max_length=20)
class Meta:
app_label = MYAPP
mymodel = MyModel(air_temp=25.0, latitude=38.0, longitude=-122.0,
timezone=-8.0, pvmodule='SPR E20-327')
mymodel.__dict__
#{'_state': <django.db.models.base.ModelState at 0x496b2b0>,
# 'air_temp': 25.0,
# 'id': None,
# 'latitude': 38.0,
# 'longitude': -122.0,
# 'pvmodule': 'SPR E20-327',
# 'timezone': -8.0}
So I should stop here and point out that that evidently the order of these commands matters, because if I add the fake app to INSTALLED_APPS before calling django.setup() then I get this:
ImportError: No module named myapp
And unfortunately, I just figured this out now, in this post. But this isn't what I originally did. Yes, I'm completely crazy. First I added a fake module called 'myapp' to sys.modules setting it to a mock object, but that didn't work. I got back TypeError: 'Mock' object is not iterable because, as I found out later, there has to be an AppConfig subclass in the app module. But since I didn't know that yet, I did the only logical thing and put the module in a list. What? Yes, did I mention I'm an idiot? This nonsense yielded the following stern warning:
ImproperlyConfigured: The app module [] has no filesystem location, you must configure this app with an AppConfig subclass with a 'path' class attribute.
But this is where I found out about AppConfig in the Django docs which is covered quite nicely. Following the nice directions, I did as told and subclassed AppConfig, added path and also name which I learned from the docs, monkeypatched my mock module with it, and used the dotted name of the app myapp.MyApp now. I felt like I was getting closer, since I only got: AttributeError: __name__ which seemed like a problem with my pretend module. Another monkeypatch and we have my final ludicrously ridiculous hack.
from django.db import models
from django.conf import settings
import django
from django.apps import AppConfig
import sys
import mock
class MyApp(AppConfig):
"""
Apps subclass ``AppConfig`` and define ``name`` and ``path``
"""
path = '.' # path to app
name = 'myapp' # name of app
# make a mock module with ``__name__`` and ``MyApp`` member
myapp_module = mock.Mock(__name__='myapp', MyApp=MyApp)
MYAPP = 'myapp.MyApp' # full path to app
sys.modules['myapp'] = myapp_module # register module
settings.configure()
settings.INSTALLED_APPS.append(MYAPP)
django.setup()
class MyModel(models.Model):
air_temp = models.FloatField()
latitude = models.FloatField()
longitude = models.FloatField()
timezone = models.FloatField()
pvmodule = models.CharField(max_length=20)
class Meta:
app_label = MYAPP
mymodel = MyModel(air_temp=25.0, latitude=38.0, longitude=-122.0,
timezone=-8.0, pvmodule='SPR E20-327')
mymodel.__dict__
#{'_state': <django.db.models.base.ModelState at 0x496b2b0>,
# 'air_temp': 25.0,
# 'id': None,
# 'latitude': 38.0,
# 'longitude': -122.0,
# 'pvmodule': 'SPR E20-327',
# 'timezone': -8.0}
Yay?
I want to introduce Carousel, a project that my employer, SunPower has been supporting for use in prediction models. Carousel is an extensible framework for mathematical models that handles generic routines such as loading and saving data, generating reports, converting units, propagating uncertainty and running simulations so developers can focus on creating complex algorithms that are easy to share and maintain.
Mathematical models consist of algorithms glued together with generic routines. While the algorithms may sometimes be unique and complex, the rest of the code is often simple and routine. Sometimes mathematical models developed by teams of developers over time become difficult to update because there is no framework for how new data, calculations and outputs are integrated into the existing models. Carousel allows developers to focus on creating complex mathematical models that are robust and easy to maintain by abstracting generic routines and establishing a simple but extensible framework.
A Carousel basic model consists of 5 built in layers:
Carousel is extensible by creating more advanced models and layers. A Carousel model is a collection of layers. Carousel layers share a common base class. Each layer also has a corresponding object and a registry where objects are stored. All layers have a load method that loads all of the layer objects specified into the model. When a model is loaded it loads the objects specified for each layer.
Consider a load shifting algorithm for residential or commercial rooftop solar power. The model might have a performance calculation, a load calculation, a cost calculation and an optimization algorithm that determines how home or business appliances are operated to minimize overall yearly cost of the system.
The performance calculation contains several formulas which require input data from an internal database of solar panel parameters and an online API of weather conditions, so the user creates a data source and reader for each of these. There are some data readers already included in Carousel and once a data reader is created it can be reused in many different projects. Maybe the user submits a pull request to Carousel to add the new API and database reader. The load calculation contains formulas for how the appliances are used. The input data for the appliances are entered into a generic worksheet so the user creates a data source for appliances and uses the XLRDReader to collect the data for each appliance from their worksheets.
The user organizes the formulas into 4 modules, that correspond to each of the calculations, but some formulas are reused since they are generic. For example, data frame summation formulas are used with different time series to create daily, monthly and annual outputs. The user maps out the calculations and specifies their interdependence to other formulas. For example, the cost calculation depends on the load and performance calculations and the optimization algorithm depends on the cost.
The user specifies each output name, initial value and other attributes. Specifications for each layer can be in a JSON parameter file or directly in the code as class attributes; Carousel will interpret either at runtime when it creates the model. Finally the user creates a simulation which in this case is unique because instead of marching through time or space, the simulation iterates over potential load shifting solutions from the algorithm. The user decides which data or outputs to log during the simulation and which to save in reports. Now that the model is created, the user loads the model and sends it the "start" command. After the simulation is complete, the user can examine the outputs and their variances. The outputs will have been automatically converted to the units specified in the model.
The data layer handles all inputs to the models. The data layer object is a data source. Each data source has a data reader. A data source is a document, API, database or other place from which input data for the model can be obtained. The data source and reader provide a framework for specifying how data is acquired. For example a data source for stock market prices might be a public API. An implementation of the stock market API data source specifies the names and attributes of each input data that will be read from the API and how the data reader should read them. The data source is similar to a deserializer because it describes how the data from the source should be interpreted by the model and creates an object in the data registry.
The formula layer handles operations on input data that generate new outputs. It differs from the calculation layer which handles how formulas are combined together. The formula layer object is a formula, and each formula has a formula importer. For example the Python formula importer can import formulas that are written as Python functions.
Calculations are combinations of formulas. Each calculation also has a map of what data and output are used as arguments and what outputs the return values will be. Calculations also implement calculators. Currently there is a static calculator and a dynamic calculator, but new calculators can be implemented that can be reused in other models. The calculation also implements indexing into data and output registries in order retrieve items by index or at a specific time.
Outputs are just like data except they don't need a reader because they are only generated from calculations. Each output is like a serializer because it determines how output objects will be reported or displayed to the user.
The simulation layer determines the order of calculations based on the calculation dependencies. It first executes all of the static calculations and then loops over dynamic calculations, displaying logs and saving periodic reports as specified.
The model is a low level class that can be extended to add new layers or implement new simulation commands. Currently only the basic model is implemented. A new model might contain a post processing layer that generates plots and reports from outputs.
Every layer has a dictionary called a registry that contains all of the layer objects and metadata corresponding to the layer attributes. The registry implements a register method that doesn't allow an item to registered more than once. Each layer registry is subclassed from the base registry so that specific layer attributes can be associated to each key. For example, data sources and outputs have a variance attribute while formulas have an args attribute.
After a model has been described using the framework, it can be loaded. Then any or all of the model simulations can be executed from the model. The simulation specifies commands to the model that user sends using the models command method. Currently the basic model can execute the simulation start command.
Carousel uses the Pint units wrapper to convert units as specified. Uncertainty is propagated using the UncertaintyWrapper package which was developed for Carousel. It can wrap Python extensions and non-linear algorithms without changing any code. It propagates covariance and sensitivity across all formulas.
A basic version of Carousel is ready now. There is an example of a photovoltaic module performance model in the documentation online at GitHub. Some ideas for new features are listed in the Carousel wiki on GitHub.
Carousel was presented at the 5th Sandia PVPMC Workshop hosted by EPRI in Santa Clara in May 2016
Carousel and UncertaintyWrapper were developed with the support of SunPower Corp. They are distributed with a BSD 3-clause license.
Please read my disclaimer.
I'm proud to announce UncertaintyWrapper at the Cheese Shop. This work was supported by my employer, SunPower Corp. and is currently offered with a standard 3-clause BSD license. The documentation, source code and releases are also available our SunPower org GitHub page.
So what does uncertainty_wrapper do? Let's say you have a Python function, to calculate solar position, and the function uses a C/C++ library via the Python ctypes library. Or maybe you just have a really complicated set of calculations that you repeat 8760 times, and you want it to run super fast, so you don't want it to calculate derivatives and uncertainty at every internal step, just the final output. Oh and by the way, you want all 8760 calculations vectorized, _ie_: done concurrently as much as possible.
Heres an example using PVLIB of just the first 24 hours.
#
import numpy as np # v1.11.0
import pandas as pd # v0.18.0
import pytz # v2016.1
import pvlib # v0.3.2
from uncertainty_wrapper import unc_wrapper_args # v0.4.1
PST = pytz.timezone('US/Pacific') # Pacific Standard Time
times = pd.DatetimeIndex(start='2015/1/1', end='2015/1/2', freq='1h', tz=PST) # date range
# arguments for the number of observations
# new in UncertaintyWrapper==0.4.1, jagged arrays are okay
latitude, longitude, pressure, altitude, temperature = 37., -122., 101325., 0., 22.
# standard deviation of 1% assuming normal distribution
covariance = np.tile(np.diag([0.0001] * 5), (times.size, 1, 1)) # tile this for the number of observations
@unc_wrapper_args(1, 2, 3, 4, 5)
# indices specify positions of independent variables:
# 1: latitude, 2: longitude, 3: pressure, 4: altitude, 5: temperature
def spa(times, latitude, longitude, pressure, altitude, temperature):
# location class only used prior to pvlib-0.3
dataframe = pvlib.solarposition.spa_c(times, latitude, longitude, pressure, altitude, temperature)
retvals = dataframe.to_records()
zenith = retvals['apparent_zenith']
zenith = np.where(zenith<90, zenith, np.nan)
azimuth = retvals['azimuth']
return zenith, azimuth
ze, az, cov, jac = spa(times, latitude, longitude, pressure, altitude, temperature, __covariance__=covariance)
df = pd.DataFrame({'zenith': ze, 'az': az}, index=times) # easier to view as dataframe
print df
# az zenith
# 2015-01-01 00:00:00-08:00 349.297715 NaN
# 2015-01-01 01:00:00-08:00 40.210628 NaN
# 2015-01-01 02:00:00-08:00 66.719304 NaN
# 2015-01-01 03:00:00-08:00 80.930185 NaN
# 2015-01-01 04:00:00-08:00 90.852887 NaN
# 2015-01-01 05:00:00-08:00 99.212426 NaN
# 2015-01-01 06:00:00-08:00 107.181217 NaN
# 2015-01-01 07:00:00-08:00 115.450451 NaN
# 2015-01-01 08:00:00-08:00 124.564183 84.113440
# 2015-01-01 09:00:00-08:00 135.023137 74.984664
# 2015-01-01 10:00:00-08:00 147.247403 67.475783
# 2015-01-01 11:00:00-08:00 161.371578 62.273878
# 2015-01-01 12:00:00-08:00 176.922804 60.008978
# 2015-01-01 13:00:00-08:00 192.742327 61.017538
# 2015-01-01 14:00:00-08:00 207.519768 65.144340
# 2015-01-01 15:00:00-08:00 220.494108 71.839001
# 2015-01-01 16:00:00-08:00 231.600910 80.422988
# 2015-01-01 17:00:00-08:00 241.184075 89.948123
# 2015-01-01 18:00:00-08:00 249.726361 NaN
# 2015-01-01 19:00:00-08:00 257.751550 NaN
# 2015-01-01 20:00:00-08:00 265.873170 NaN
# 2015-01-01 21:00:00-08:00 275.014534 NaN
# 2015-01-01 22:00:00-08:00 287.078877 NaN
# 2015-01-01 23:00:00-08:00 307.283646 NaN
# 2015-01-02 00:00:00-08:00 348.921385 NaN
# covariance at 8AM
idx = 8
print times[idx]
# Timestamp('2015-01-01 08:00:00-0800', tz='US/Pacific', offset='H')
nf = 2 # number of dependent variables: [ze, az]
print cov[idx]
# [[ 0.6617299 -0.6152971 ]
# [-0.6152971 0.62483904]]
# standard deviation
print np.sqrt(cov[8].diagonal())
# [ 0.81346782, 0.79046761]
# Jacobian at 8AM
nargs = 5 # number of independent args
print jac[idx]
# [[ 5.56456716e-01 -6.45065654e-01 -1.37538277e-06 0.00000000e+00 4.72409055e-04]
# [ 8.29163154e-02 6.47436098e-01 0.00000000e+00 0.00000000e+00 0.00000000e+00]]
#
First this tells us that the standard deviation of the zenith is 1% if the input has a standard deviation of 1%. That's reasonable. This also tells that zenith is more sensitive to latitude and longitude than pressure or temperature and more sensitive to latitude than azimuth is.
Unfortunately you can't depend on makemigrations to generate the correct SQL to migrate and cast data from a scalar field to a PostgreSQL ARRAY. But Django provides a nifty RunSQL that's also described in this post, "Down and Dirty - 9/25/2013" by Aeracode, the original creator of South predecessor of Django migrations. That post even mentions using RunSQL to alter a column using CAST.
The issue and trick to migrating a column to an ArrayField is given by PostgreSQL in the traceback, which says:
Further hints can be found by rtfm and searching the internet, such this stackoverflow Q&A. My procedure was to usecolumn "my_field " cannot be cast automatically to type double precision[] HINT: Specify a USING expression to perform the conversion.
makemigrations to get the state_operations and then wrap each one into a RunSQL migration operation.
# -*- coding: utf-8 -*-
from __future__ import unicode_literals
from django.db import migrations, models
import datetime
from django.utils.timezone import utc
import django.contrib.postgres.fields
import simengapi_app.models
import django.core.validators
class Migration(migrations.Migration):
dependencies = [
('my_app', '0XYZ_auto_YYYYMMDD_hhmm'),
]
operations = [
migrations.RunSQL(
"""
ALTER TABLE my_app_mymodel
ALTER COLUMN "my_field"
TYPE double precision[]
USING array["my_field"]::double precision[];
""",
state_operations=[
migrations.AlterField(
model_name='mymodel',
name='my_field',
field=django.contrib.postgres.fields.ArrayField(
base_field=models.FloatField(), default=list,
verbose_name=b'my field', size=None
),
)
],
),
]
I've started using Django REST Framework, and it is simply magic!
Here is a technique I've used to input lists of primitive types and serializers with many=True
from functools import partial
from rest_framework import viewsets
from rest_framework.response import Response
from rest_framework import status
from my_app.serializers import MyNestedModelSerializer
...
class MyNestedModelViewSet(viewsets.ViewSet):
serializer_class = MyNestedModelSerializer
def create(self, request):
serializer = self.serializer_class(data=request.data)
# get the submodel list serializer since it can't render/parse html
submodel_list_serializer = serializer.fields['submodels']
# make a partial function by setting the submodel list serializer
partial_get_value = partial(custom_get_value, submodel_list_serializer)
# monkey patch submodel_list_serializer.get_value() with partial function
submodel_list_serializer.get_value = partial_get_value
if serializer.is_valid():
simulate_data = serializer.save()
# do stuff ...
return Response(serializer.data, status=status.HTTP_201_CREATED)
return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)
The function `custom_get_value()` uses JSON to parse the input:
def custom_get_value(serializer, dictionary):
if serializer.field_name not in dictionary:
if getattr(serializer.root, 'partial', False):
return empty
# We override the default field access in order to support
# lists in HTML forms.
if html.is_html_input(dictionary):
listval = dictionary.getlist(serializer.field_name)
if len(listval) == 1 and isinstance(listval[0], basestring):
# get only item in value list, strip leading/trailing whitespace
listval = listval[0].strip()
# add brackets if missing so that it's a JSON list
if not (listval.startswith('[') and listval.endswith(']')):
listval = '[' + listval + ']'
# try to deserialize JSON string
try:
listval = json.loads(listval)
except ValueError as err:
# return original string and log error
pass
# set the field with the new value list
dictionary.setlist(serializer.field_name, listval)
val = dictionary.getlist(serializer.field_name, [])
if len(val) > 0:
# Support QueryDict lists in HTML input.
return val
return html.parse_html_list(dictionary, prefix=serializer.field_name)
return dictionary.get(serializer.field_name, empty)
If you enjoyed Dr. Horrible's Sing Along Blog then you may also like Felicia Day's The Guild from her Geek & Sundry YouTube channel. Irresistible, and pretty amazing production values for a web series.
In fact as soon as you assign a value to any element in the object array it grows the array to that size, which allocates (or reallocates) RAM for the new object array, therefore defeating the point of preallocating space.
From Empty Arrays section of OOP documentation:
“If you make an assignment to a property value, MATLAB calls the SimpleClass constructor to grow the array to the require size:”
Instead if you want to preallocate space for an object array, grow the array once by assigning the last object first. This requires the class to have a no-arg constructor. Each time you grow your array you will reallocate RAM for it, wasting time and space, so do it once with the max expected size of the array. See Initialize Object Arrays and Initializing Arrays of Handle Objects in the OOP documentation.
>> S(max_size) = MyClass(args)
Another option is to preallocate any other container like a cell array (best IMHO), structure or containers.Map and then fill in the class objects as they are created. An advantage to this is you don’t have to subclass matlab.mixin.Heterogeneous to group different classes together.
>> S = cell(max_size); args = {1,2,3;4,5,6;7,8,9};
>> for x = 1:size(args,1), S(x) = MyClass(args{x,:});end
The only time to use an empty object is if you want it as a default for the situation where nothing gets instantiated, and you need the it be an instance of the class. Of course any empty array will do this, IE: '', [] and {} are also empty.
>> S = MyClass.empty >> if blah,S = MyClass(args);end >> if isa(S, 'MyClass') && isempty(S),do stuff; end
I hope this helps someone; it definitely helped me understand the odd nature of MATLAB. This behavior is because everything in MATLAB is an array, even a scalar is a <1x1 double> read the C-API mxArray for external references and mwArray for compiled/deployed MATLAB for more info.
MATLAB = Matrix LaboratoryClass definitions didn’t appear until 2008. Other languages like C++, Java, Python and Ruby are object first. So the empty method is meant to duplicate the ability to be empty similar to other MATLAB datatypes such as double, cell, struct, etc. IMO outside of MATLAB it's a very artificial and somewhat meaningless construct.
[UPDATE 2015-06-09] I have switched to git-fat-0.5.0 [2015-05-06]; the fork on PyPI maintained on GitHub by Alan Braithwaite of Cyan Inc. Unfortunately, I could not figure out how to clone a git-media repo, therefore git-media sucks.
Basically this comes with everything you need to work on Windows, Mac or Linux. It uses rsync for transport, and the rest is mostly written in Python but does depend on some libraries that are standard in Linux and have mature ports in Windows and Mac. One of the major benefits of git-fat over git-media is that it uses a .gitfat config file which updates your .git/config when git fat init is run. This is similar to git submodules and makes repos portable. In general there's more functionality and features than git-media. For example, you can list the files managed by git-fat, check for orphans and pull data from or push data to your remote storage. The only catch is that the wheel file at PyPI has metatags for win32 not amd64. This is easy to fix, but I think there are a couple of use cases that might differ from how the distribution was implemented.
If you look at a Linux install, the repository has a symlink to git_fat.py in bin called git-fat. Why not just bootstrap git-fat if we only really need one file. Just dump everything in a single folder, change the file name to git-fat and make sure there's a shebang that uses #! /usr/bin/env python which git seems to prefer, then stick it on your path. This works for both msys-git and Windows cmd.
msysgit comes with Git Bash, a posix shell which includes many Linux libraries ported to Windows, such as gawk and ssh. Unfortunately it does not come with rsync, however you can get rsync from the msys source either from mingw-w64 (that's where I got it), from msys2, from the original mingw project, from mingw builds and from lots of places. You could even get it from cygwin. I usually stick files like this in my local bin folder which is always first on my path in git bash. You'll need to also grab the iconv, intl, lzma and popt msys libraries which rsync depends on. Anyway, since you have these libraries, you don't need the ones bundled in the wheel, however, git-fat is written to look for those bundled files if it detects that your platform is Windows, so just comment out those lines. You will need to change awk to gawk, since awk is a shell script that calls gawk. Again you can bootstrap this file, ie: put it in your local bin folder or install it into your Python site-packages and/or scripts folder.
This is the way I ended up using it. You can download my version here and install it with pip. I put the windows libraries into the site-packages git-fat folder instead of in scripts and then in the git-fat script, added the site-packages git-fat folder to the shell's path. Then I called the git-fat module as a script by adding a __main__.py file to it which basically imports git_fat.py and calls it using Python with the -m option, but you could just as easily call the module as a script. This just keeps these extra libraries bundled together rather than dumping them into the scripts folder with everything else. Also since I mostly use git bash it doesn't put git-fat's libraries ahead of git's since they both use gawk and ssh.
Usage is extremely easy compared to git-media, which is a plus! Note these instructions are for msysgit git bash. For Windows cmd window replace git fat with git-fat everywhere. Both methods should work fine.
git clone my://remote/repo.git
git fat init which sets up the filters and smudges that tell your local repo how to use git-fat with the .gitattributes file which is part of the repo already.
git fat pull which downloads your files from the remote storage specified in the .gitfat, which is also already in the repo
git fat list to see a list of managed files
git fat status to see a list of orphans waiting to be pulled/pushed?
Creating a repo and setting it up to use git-fat is also easy. There is great help in the readme at PyPI and the readme at GitHub.
[rsync] remote = //server/share/repo/fat
git fat init to set up your local .git/config
git fat push to send stuff to your remote
Finally time to install Ruby. You're going to need it if you want to use git-media which let's you mix big biinary files within your git repo, but store them in some remote host, which could be google-drive, amazon s3, another server via ssh/scp or a network share. Why don't you want to store big binary files in your git repo? Since Git stores each revision instead of deltas, that means that it will quickly blow up as you make new commits.
Super easy, they recommend 2.1, no admin rights required, unzips into c:\
just like python, I checked all of the options: tk/tcl, add ruby to path
and what was the last option? Then I ran gem update.
gem install git-media trollup right_aws
There is a tiny issue with right_aws where it outputs the message:
Digest::Digest is deprecated; use DigestThe readme on the github overview page has everything you need to know.
[UPDATE 2018-09-04] Links to Cookiecutter and Bootstrap a Scientific Python Library from the National Synchrotron Light Source II (NLSL-II).
[UPDATE 2016-07-19] Lately I've preferred using core instead of lib for the main package modules.
[UPDATE 2015-06-04] Create top level package to bundle all sub-packages and package-data together for install.
Been looking for a good, comprehensive, credible guide:
This is a tutorial with a template for packaging, testing, documenting, and publishing scientific Python code.
A command-line utility that creates projects from cookiecutters (project templates), e.g. creating a Python package project from a Python package project template.
It's hard to pin a standard style down. Here’s mine:
MyProject/ <- git repository
|
+- .gitignore <- *.pyc, IDE files, venv/, build/, dist/, doc/_build, etc.
|
+- requirements.txt <- to install into a virtualenv
|
+- setup.py <- use setuptools, include packages, extensions, scripts and data
|
+- MANIFEST.in <- files to include in or exclude from sdist
|
+- readme.rst <- incorporate into setup.py and docs
|
+- changes.rst <- release notes, incorporate into setup.py and docs
|
+- myproject_script.py <- script to run myproject from command line, use Python
| argparse for command line arguments put shebang
| `#! /usr/bin/env python` on 1st line and end with a
| `if __name__ == "__main__":` section, include in
| setup.py scripts section for install
|
+- any_other_scripts.py <- scripts for configuration, documentation generation
| or downloading assets, etc., include in setup.py
|
+- venv/ <- virtual environment to run tests, validate setup.py, development
|
+- myproject/ <- top level package keeps sub-packages and package-data together
| for install
|
+- __init__.py <- contains __version__, an API by importing key modules,
| classes, functions and constants, __all__ for easy import
|
+- docs/ <- use Sphinx to auto-generate documentation
|
+- tests/ <- use nose to perform unit tests
|
+- other_package_data/ <- images, data files, include in setup.py
|
+- core/ <- main source code for myproject, sometimes called `lib`
| |
| +- __init__.py <- necessary to make mypoject_lib a sub-package
| |
| +- … <- the rest of the folders and files in myproject
|
+- related_project/ <- a GUI library that uses myproject_lib or tools that
| myproject_lib depends on that's bundled together, etc.
|
+- __init__.py <- necessary to make related_project a sub-package
|
+- … <- the rest of the folders and files in your the related project
[UPDATE 2015-07-02] Check out Python Bootstrap a continuously integrated build of Python-2.7 for Windows that can be installed without admin rights.
I know I was just ranting about the inability to distribute Python27 w/o admin rights, but surprise! This is a piece of cake, thanks to the whoever the amazing Python developers are who maintain the PCbuild and external buildbot tools for Windows. There are also a few sites out there that have similar information on building Python for windows, but honestly everything you need is in PCbuild/readme.txt. Read it, then read it again. Seriously. Also check out the Python docs developer's guide. Hmm, thinking of setting up an AppVeyor buildbot for this.
svn binary for windows and put it on your path. I use CollabNet SubVersion commandline binaries. The easiest way to get and build all of the external libraries (bzip2, sqlite3, tk/tcl, etc.) is to use the Tools/buildbot batch scripts which call svn.exe.C:\Program Files\Microsoft SDKs\Windows\v7.0>setenv /Release /x86
Tools/buildbot/externals batch script exactly as described in the PCbuild readme. I added the release build immediately after the debug fields.
if not exist tcltk\bin\tcl85.dll (
@rem all and install need to be separate invocations, otherwise nmakehlp is not found on install
cd tcl-8.5.15.0\win
nmake -f makefile.vc INSTALLDIR=..\..\tcltk clean all
nmake -f makefile.vc INSTALLDIR=..\..\tcltk install
cd ..\..
)
if not exist tcltk\bin\tk85.dll (
cd tk-8.5.15.0\win
nmake -f makefile.vc INSTALLDIR=..\..\tcltk TCLDIR=..\..\tcl-8.5.15.0 clean
nmake -f makefile.vc INSTALLDIR=..\..\tcltk TCLDIR=..\..\tcl-8.5.15.0 all
nmake -f makefile.vc INSTALLDIR=..\..\tcltk TCLDIR=..\..\tcl-8.5.15.0 install
cd ..\..
)
if not exist tcltk\lib\tix8.4.3\tix84.dll (
cd tix-8.4.3.5\win
nmake -f python.mak DEBUG=0 MACHINE=IX86 TCL_DIR=..\..\tcl-8.5.15.0 TK_DIR=..\..\tk-8.5.15.0 INSTALL_DIR=..\..\tcltk clean
nmake -f python.mak DEBUG=0 MACHINE=IX86 TCL_DIR=..\..\tcl-8.5.15.0 TK_DIR=..\..\tk-8.5.15.0 INSTALL_DIR=..\..\tcltk all
nmake -f python.mak DEBUG=0 MACHINE=IX86 TCL_DIR=..\..\tcl-8.5.15.0 TK_DIR=..\..\tk-8.5.15.0 INSTALL_DIR=..\..\tcltk install
cd ..\..
)
Python-2.7.9) call the externals batch script. It will copy and build all of the externals from svn.python.org in a folder called externals/.build.bat. Voila, python.exe for x86.C:\Users\myname\downloads\Python-2.7.9>setenv /Release /x64
HOST_PYTHON=C:\Python27\python.exe. You may not need this at all or you might be able to use the 32-bit version just built.
if not exist tcltk64\bin\tcl85.dll (
cd tcl-8.5.15.0\win
nmake -f makefile.vc MACHINE=AMD64 INSTALLDIR=..\..\tcltk64 clean all
nmake -f makefile.vc MACHINE=AMD64 INSTALLDIR=..\..\tcltk64 install
cd ..\..
)
if not exist tcltk64\bin\tk85.dll (
cd tk-8.5.15.0\win
nmake -f makefile.vc MACHINE=AMD64 INSTALLDIR=..\..\tcltk64 TCLDIR=..\..\tcl-8.5.15.0 clean
nmake -f makefile.vc MACHINE=AMD64 INSTALLDIR=..\..\tcltk64 TCLDIR=..\..\tcl-8.5.15.0 all
nmake -f makefile.vc MACHINE=AMD64 INSTALLDIR=..\..\tcltk64 TCLDIR=..\..\tcl-8.5.15.0 install
cd ..\..
)
if not exist tcltk64\lib\tix8.4.3\tix84.dll (
cd tix-8.4.3.5\win
nmake -f python.mak DEBUG=0 MACHINE=AMD64 TCL_DIR=..\..\tcl-8.5.15.0 TK_DIR=..\..\tk-8.5.15.0 INSTALL_DIR=..\..\tcltk64 clean
nmake -f python.mak DEBUG=0 MACHINE=AMD64 TCL_DIR=..\..\tcl-8.5.15.0 TK_DIR=..\..\tk-8.5.15.0 INSTALL_DIR=..\..\tcltk64 all
nmake -f python.mak DEBUG=0 MACHINE=AMD64 TCL_DIR=..\..\tcl-8.5.15.0 TK_DIR=..\..\tk-8.5.15.0 INSTALL_DIR=..\..\tcltk64 install
cd ..\..
)
Python-2.7.9) call the externals-amd64 batch scriptbuild.bat -p x64. Voila, python.exe for x64.externals/tcltk to your path and run the testsC:\Users\myname\downloads\Python-2.7.9\PCbuild>set PATH=C:\Users\myname\downloads\Python-2.7.9\externals;%PATH% C:\Users\myname\downloads\Python-2.7.9\PCbuild>rt
Program Files (x86)\Microsoft Visual Studio 9.0\VC\redist\x86\Microsoft.VC90.CRT\to PCbuild folder, and
Program Files (x86)\Microsoft Visual Studio 9.0\VC\redist\amd64\Microsoft.VC90.CRT\to PCbuild\amd64 folder.Python27 | +-python.exe | +-pythonw.exe | +-python27.dll | +-msvcr90.dll <- from VC/redist/MICROSOFT.VC90.CRT | +-msvcp90.dll <- from VC/redist/MICROSOFT.VC90.CRT | +-msvcm90.dll <- from VC/redist/MICROSOFT.VC90.CRT | +-MICROSOFT.VC90.CRT.manifest <- from VC/redist/MICROSOFT.VC90.CRT | +-DLLs <- all externals/tcltk/bin, PCbuild/*.dll & PCbuild/*.pyd files | & PC/py.ico, PC/pyc.ico & PC/pycon.ico. | +-Lib <- same as source archive except all *.pyc files, all plat-* folders | & ensurepip folder | +-libs <- all PCbuild/*.lib files | +-include <- same as source archive + PC/pyconfig.h | +-tcl <- everything in tcltk/lib | +-Scripts <- PCbuild/idle.bat | +-Doc <- set %PYTHON%=python.exe and build Sphinx docs with Sphinx if you have it
Note: wish85.exe and tclsh85.exe won't work with this Python installed file structure although it will work in the externals bin folder because they look for the tcl85.dll in ../lib. Also note that idle.bat needs some fixin. And also it's very important to know that most executables in Scripts created by installer packages have the path to python.exe hardwired, IE: they are initially not portable, however check out this blog for a few quick tricks to fix them.
You can download my x64 build and x86 build from dropbox. Congratulations!
[UPDATE 2015-07-02] Check out Python Bootstrap a continuously integrated build of Python-2.7 for Windows that can be installed without admin rights.
This issue starts simple enough, but then unravels to reveal some very interesting insights. Evidently creating a Python for Windows installer that does not depend on administrator rights is not as easy as it seems. The question comes down to what we really need. Steve Dover from Microsoft breaks it down like this:
Let me say 1st off that I think that #3 is absurd. I can't imagine Windows system admins ever using Python in this way. Most of them have never even heard of Python. And there is an entire .NET infrastructure to do exactly this. Why would you use Python instead of C#? Windows will never, ever be like Linux. It is not a POSIX environment, it does not use GNU tools and it does not need Python.
I think that #1 and #2 could serve the same purpose and should really be the only option available. Users who want to use Python on Windows should unzip the Python Windows distro to their System Root (ie: C:\Python27) and use it. No admin rights required. End of story. It should contain the msvcrt90 redistributable and all libraries it needs. There should be no other dependencies.
There is also a 0th option - do not distribute a binary for Windows at all. Let Windows users build from source themselves, or recommend alternate distribution, which Python.org already does on its alternative distribution page.. This is what Ruby does, and perhaps it's the best way to satisfy everyone. But the fact that official Python is available for windows is a very nice thing. Althoght Enthought and ActiveState have been around for a long time, they are private and could go out of business. Nevertheless, this does seem to be the path people are taking.
Anaconda, from Continuum Analytics, a relative newcomer, founded by Peter Wang and Travis Oliphant formerly from Enthought, seems to have become, almost overnight, the most popular source of Python on windows. It's baby sister, Miniconda, is less know but merely installs the conda package/environment manager and Python-2.7 which can be used to install more Python version and packages, whereas Anaconda preinstalls most sci-data packages. The only major concern for me with Anaconda is that it is closed source. Is it the python.org version built out of the box?WinPython on the other hand is open source on github and offers both 32 and 64 bit versions that do not require admin rights to instal. Enthought is also closed source and PortablePython only offers an older out of date 32bit version. There is also PythonXY but for me it seemed buggy.
Not sure what the future of Python on Windows will look like. If you are interested in shaping that future, I suggest you contact one of the Python devs and let them know what your use case is.
