Daniel Wheeler

FiPy Docker Instance using Ansible

2016-02-22T00:00:00+00:00

I created a repository that uses both Ansible and Docker to generate a Docker instance of FiPy. The main benefit of using Ansible in this situation is that it makes the developer generate a very clearly formatted file for the installation procedure. See, the Ansible YAML file. This file could be reused outside of a Docker instance for installation as well. A setup.bash is still required to bootstrap the Ansible installation in the event that Ansible isn’t installed. The installation procedure that’s in the Ansible YAML file could either be buried in the setup.bash or the Dockerfile. Ansible seems to do a nice job of creating a clean set of declarative statements for the installation procedure.

CHiMaD - Phase Field User Site

2015-01-16T00:00:00+00:00

Workshop 01/09/2015

Last week I attended the Phase Field Methods Workshop at Northwestern University, see the PDF document about the meeting. The meeting was really aimed at finding ways to unify the effort in developing computational tools for phase field simulations and especially to reduce replicated effort. The main actionable item that came out of the meeting was a requirement for a focused web presence for meta analysis and discussion of the various phase field codes available. The general consensus was that a GitHub presence for the community could serve this purpose. It was suggested that the NIST contingent take charge of this item along with the some of the initial contributions.

Aims

What are the aims of a GitHub site for the phase field community:

location to create and collate data comparing code capabilities
location to finalize a set of canonical phase field examples
location to push scripts, recipes (IPython notebooks for example) for building and running phase field codes that solve the canonical examples (or any other phase field examples)
location for links to virtual machines for phase field codes
location to store phase field meta analysis on such things as efficiency (memory use), convergence, capabilities or ease of use
location for any phase field code that has no home elsewhere including student’s phase field codes or phase field analysis
eventual location of meta analysis tools for automated testing of multiple phase field codes
eventual location of a generic high level API to describe phase field problems with hooks into multiple codes

I should add the caveat that the above is probably biased in favor of some of my own ideas rather than ideas from all suggestions at the meeting.

Setting up the GitHub site

Of course we could just create a GitHub organization with the name “chimad_phase_field” and have unlimited public repositories. It’s free. However, my NIST based colleagues were fairly sure that we should create this organization within the “usnistgov” organization. This raises the question of whether sub-organizations can be created in GitHub. I’m unsure about this currently.

A second point of discussion was whether we needed an organization at all or just a repository. From my perspective a single repository is really not going to handle the kind of contributions that we are interested in (multiple codes maybe, different disconnected meta-analyses). The alternative is to just have a team and have multiple repositories connected with the team as a poor man’s organization. This may work failing all else.

Before setting this up, I’m awaiting the input of several NIST colleagues in order to see what direction we should go in and whether I’m officially allowed to set up a GitHub organization external to NIST.

Mailing List

One item that we should deal with in short order is the creation of a mailing list. The choices are:

NIST based mailing list (colleagues like this idea, I’m not enthusiastic)
Google Group (I’m more in favor, it’s easier to setup and archive easily)

A mailing list for the community is really important.

Some other links along similar lines

Rosetta Code

Automated Simulation Management and Reproducible Research

2014-06-25T00:00:00+00:00

My wife was delighted when I gave her a Fitbit as a holiday gift. An unfortunate consequence of her continued enthusiasm is that we often end up heading out on a cold winter’s night to the local grocery store, where we power walk up and down the aisles until she reaches the magic 10,000 steps – indicating that she has exercised enough to satisfy the Fitbit gods. Aside from the small inconvenience of having to rush around Wegman’s late at night as the staff there give us perplexed looks, the Fitbit is a wonderful device. It records the number of steps taken each day, one’s weight (with the purchase of the accessory, somewhat pricey, scales), sleep, vertical steps and more. The results are stored in the cloud and presented on a website with upbeat graphics that render the data easily digestible.

Considering the technology available for data capture in our daily lives, the scientific process seems increasingly moribund in comparison. My everyday workflow often consists of running multiple numerical simulations across different research projects. Up until recently, I kept records of these simulations using mostly manual and entirely ad hoc schemes. Intuitively, one would imagine that maintaining simulation records for computational processes would be a relatively straightforward problem. After all, this is a deterministic process existing entirely in silico and is seemingly much simpler than capturing in vivo/vitro data as with the Fitbit or an experimental apparatus. In practice, I find that managing numerical simulations and the associated output data is a maintenance nightmare mainly because I tend to alter the ad hoc management schemes frequently. This results in rapid degradation of data, especially after the conclusion of a research project.

I am mystified as to why there are not at least a half-dozen well supported, open source projects that address the issues surrounding simulation management. Web frameworks that support cloud storage, sharing and versioning of simulation metadata should be commonplace. I can say with some conviction that scientists have sleepwalked through the last 10 years of web technology development. It is high time that we step away from the research and concentrate on building the tools and web infrastructure needed to improve the scientific process, especially in the realm of scientific computing.

Workflow, Version Control and Event Control

I think it is important to be clear at this point that I do not advocate for an all encompassing workflow tool that presumes to manage every aspect of one’s scientific life, but really just a tool to deal with event control. Event control is very different from version control or workflow. Event control is the versioning and capture of metadata associated with the execution of a workflow (or just a script or computer program) while version control records the changes in a workflow. Event control shares many similarities with version control, but records different types of metadata at each commit (or execution). Git is a simple, robust command line tool for version control. It forms a platform for many other high level tools and web services (e.g. Github). In my mind, to implement web infrastructure and fancy cloud services for data provenance, a tool along the same lines as Git is required for event control.

Data and Metadata

An important issue to be aware of is the distinction between output data produced by simulations and metadata about simulations. The arguments in this blog post are mostly related to the latter. The provenance of metadata is, in principle, a much easier problem to deal with than the provenance issues surrounding the vast quantities of data produced by simulations. The size of the metadata is almost inconsequential in comparison to the simulation output data and it is also much easier to develop simple protocols and standards for metadata capture. I acknowledge that provenance issues surrounding simulation output data are hugely important, but the output data issue can not be tackled effectively until the metadata issue is adequately resolved.

Reproducible Research

The following figure is an idealized schematic showing the five stages of progress during a computational research project.

As a general rule, it is easier to reproduce the final two stages of this process than the first three assuming the simulation output data is readily available. The use of version control may help with general workflow and aid reproduction during all of these stages, but it is most useful during the development stage. Presumably it is difficult to capture much provenance data at all during the prototyping and development stages. Moreover, there is no real need for these stages to be formally reproducible. In my opinion, the simulation stage is where current practices really need to be improved. This after all is the most important part of any project with respect to reproducible research. It forms the backbone of a research project, it is analogous to the execution of an experiment as opposed to the assembling of the apparatus or rendering of a figure in a laboratory notebook. Ideally, the simulation stage of a project is a mode of working that has a well defined workflow. It uses a well developed code base and mostly involves changing input parameters (and maybe only tweaking the code slightly). Such a well defined mode of working is highly tractable to event control and metadata capture.

Sumatra

Over the last year or so I have been using Sumatra to record simulation metadata. From my perspective, Sumatra’s most advantageous feature is it’s simple implementation as a command line tool. It consequently doesn’t make deep changes to my mode of working. In particular, launching a script requires one simple change at the command line from

$ python script.py param_file.json

$ smt run param_file.json

Please do take a look at this project and see if it fits with your own workflow, especially if you are an avid Python user. There is plenty of documentation and I have an IPython notebook demonstrating the use of Sumatra for a simple parallel problem. The notebook shows how to load the Sumatra records into a Pandas dataframe and then create custom dataframes mixing metadata and simulation output data. For Sumatra to remain (or become) a healthy open source project, it must reach a critical mass of users. In particular there are many issues on the tracker which will only be addressed with more users and contributors. I currently use Sumatra for all my simulation management and try to fix bugs and contribute back to the project whenever I can.

Cloud Service

I noticed recently that the main developer of Sumatra is now working on Sumatra-server. I am excited that this might form the basis for a client-server model for Sumatra and an eventual cloud service for simulation management. Such a service would lead to improved sharing of data, improved reproducible simulation results and then the eventual promised land of aggregation and analytics on metadata (and possibly output data) across disparate research projects.

To elucidate the value a cloud service for simulation management could provide, I would like to raise two of the ideas mentioned in C. Titus Brown’s blog post about reproducible research. These are:

“a declarative metadata standard that you can use to tell a Linux VM how to download your data”
“automated integration tests for papers”

These ideas are at the heart of making simulations truly reproducible. I believe that the client-server model of Sumatra can meet these two requirements. Regarding the first point: the tool that automatically captures the metadata and has the ability to rebuild an environment based on that metadata will become the de facto metadata standard. Regarding the second point: Sumatra already records the hash for output data files and has the functionality to rerun simulations and check that the hash matches thereby forming a coarse level regression test. Furthermore, integration of Sumatra with a continuous integration framework such as Buildbot would allow the testing process to be entirely automated whenever a code repository is updated.

What can NIST do to help?

I am part of the Data Storm Focus Group in the Materials Measurement Laboratory at the National Institute of Standards and Technology (NIST). The group aims to provide recommendations to upper management on the direction NIST needs to take in weathering the future data storm. In particular, the group will make recommendations on issues such as workflow management, reproducible research and data provenance issues. The group has also discussed physical infrastructure for scientific data though I have less interest in that area. From my perspective, some important actions NIST can take to improve scientific data management practices at NIST and in the wider scientific community include:

More active engagement with open source projects that are already answering the issues surrounding data capture and provenance.
Encourage NIST staff members to actively support the open source community, especially widely used projects that have primary developers external to NIST.
Take a less NIST-centered viewpoint about cloud services and open source projects. Acknowledge that open source projects are no longer associated with any particular academic institution.
Start thinking seriously about hosting cloud services for the general community including automated data provenance (this is low hanging fruit in a number of ways and the next frontier in scientific data management). In my opinion, the government (and by extension NIST) should host services for academic data management and workflow along the lines of Figshare, Wakari or Authorea.
Seek out open source projects addressing workflow and data provenance that are currently being used widely at NIST (such as IPython) and give grant money to the developers. There are multiple benefits to NIST in this approach including the possibility to influence these projects to meet NIST and the wider community’s needs without any large investment.

Conclusion

From my standpoint, we are on the cusp of a revolution in scientific data management, which will greatly improve scientific research and reproducible science and lead to analytics across disparate research projects. In particular to my own workflow, an important first step in this revolution is the development of effective cloud-based simulation record keeping and management. For me, it is great fun to be part of this revolution in some way by making contributions to projects such as Sumatra. Looking at the big picture, NIST really needs to be at the heart of supporting and providing cloud services and software tools for varying scientific communities in order to play a relevant part in the scientific data revolution.

Please see the slides from a talk I gave on Managing Numerical Simulations at the NIST Diffusion Workshop.

Parallel FiPy in IPython

2014-02-20T00:00:00+00:00

I recently created two notebooks showing the performance of FiPy in parallel. The aims of the notebooks are

to clearly demonstrate that FiPy scales reasonably well in parallel at least up to 48 nodes,
to demonstrate that the differences between PySparse and Trilinos are not that important for larger problems,
to have some publicly available data for FiPy’s performance in parallel and
to demonstrate the use of FiPy with IPython’s native parallel infrastructure (still MPI based).

The first notebook demonstrates how to use IPython’s native parallel infrastructure with FiPy and presents parallel results on a laptop. The second notebook presents results for up to 48 parallel processes running on a cluster.

FiPy, Trilinos and Anaconda

2014-01-30T00:00:00+00:00

There was a recent question on the FiPy mailing list regarding running FiPy in parallel.

My desired use case uses a nonuniform 3D grid (from fipy.meshes.nonUniformGrid3D import NonUniformGrid3D). Running this in parallel, it takes about the same amount of time or longer. If I switch the same case to a uniform 3D grid (Grid3D), parallel execution is faster than serial, as I expected (although not exactly optimal – see attached plot).

I decided to look into this as I haven’t been using FiPy in parallel for awhile and haven’t tested it for efficiency in even longer. I used a simple test case, called kris.py, to test FiPy in parallel. The test case is just a diffusion problem on a 3D grid. It uses Gmsh to partition the grid sensibly as the non-Gmsh grids in FiPy only use suboptimally sliced partitions. In serial the test case ran without issues:

$ python kris.py
27900
0.185834884644

(with PySparse) and with Trilinos:

$ python kris.py --trilinos
27900
0.387823104858

The script, kris.py, uses time to measure the duration of one time step. In general, it’s better to use timeit, but a bit more fiddly to set up. Anyway, Trilinos is quite a bit slower than PySparse, but I know that the default solver selection along with the default tolerance and number of iterations is not consistent between PySparse and Trilinos. This accounts for some of the run time duration discrepency, though not all. At this stage I just want to check that it’s actually working in parallel so I tried running it with MPI:

$ mpirun -np 1 python kris.py --trilinos
[loki:18539] [[55252,1],0] routed:binomial: Connection to lifeline [[55252,0],0] lost
Traceback (most recent call last):
  File "kris.py", line 8, in <module>
    m = fp.GmshGrid3D(nx=N, ny=N, nz=N, dx=L / N, dy=L / N, dz=L / N)
  File "/home/wd15/git/fipy/fipy/meshes/gmshMesh.py", line 2239, in __init__
    Gmsh3D.__init__(self, arg, communicator=communicator, order=order)
  File "/home/wd15/git/fipy/fipy/meshes/gmshMesh.py", line 1937, in __init__
    background=background)
  File "/home/wd15/git/fipy/fipy/meshes/gmshMesh.py", line 151, in openMSHFile
    raise EnvironmentError("Gmsh version must be >= 2.0.")
EnvironmentError: Gmsh version must be >= 2.0.

The system version of Gmsh (installed with the package manager in Ubuntu) is 2.8.2 so FiPy’s Python error message is clearly inaccurate. I searched with the routed:binomial error message and found a ticket that I’d filed ages ago and never really resolved. Looking at the ticket, it became clear that the real issue above is that MPI is messing with Python’s ability to communicate with a subprocess. FiPy calls out to Gmsh as a subprocess to gather its version number. This prompted me to reinstall Trilinos again. Sometimes this has helped resolve issues in the past when I’ve had an old version of Trilinos knocking around (maybe the system libraries get out of sync with Trilinos). Predictably, this resolved the issue as far as Trilinos was concerned. However, mpi4py generated exactly the the same subprocess communication issue (FiPy requires mpi4py for parallel operation) and subsequent reinstallation of mpi4py didn’t help.

Anaconda

I’ve been interested in switching from Virtualenv to Anaconda for some time. I had a hunch that Anaconda might handle some of the issues with library incompatibilities more seamlessly than using the system installation along with Virtualenv. My understanding is that Anaconda inherits none of the system installation (unlike Virtualenv). First, I made sure that FiPy worked in serial with Anaconda. This step consisted of installing PySparse and maybe a few other packages (can’t remember exactly), but there were no issues getting FiPy set up in serial.

Of course, to get FiPy working in parallel I needed to install Trilinos. At first I installed Trilinos without realizing that Anaconda comes with all the MPI compilers and libraries. I’d compiled Trilinos against the system MPI libraries rather than Anaconda’s, so when running:

$ /usr/bin/mpirun -np 1 python kris.py --trilinos

it gave errors (which I unfortunately didn’t record anywhere). The Trilinos build recipe that was eventually used, after a few more missteps, points at Anaconda’s MPI:

EXTRA_ARGS=$@
TRILINOS_HOME=/home/wd15/pkg/trilinos-11.4.3-Source
CMAKE=cmake

${CMAKE} \
  -D CMAKE_BUILD_TYPE:STRING=RELEASE \
  -D Trilinos_ENABLE_PyTrilinos:BOOL=ON \
  -D BUILD_SHARED_LIBS:BOOL=ON \
  -D Trilinos_ENABLE_ALL_OPTIONAL_PACKAGES:BOOL=ON \
  -D TPL_ENABLE_MPI:BOOL=ON \
  -D MPI_BASE_DIR:PATH=${ANACONDA} \
  -D Trilinos_ENABLE_TESTS:BOOL=ON \
  -D DART_TESTING_TIMEOUT:STRING=600 \
  -D CMAKE_INSTALL_PREFIX:PATH=${ANACONDA} \
  -D PyTrilinos_INSTALL_PREFIX:PATH=${ANACONDA} \
  ${EXTRA_ARGS} \
  ${TRILINOS_HOME}

where the ANACONDA variable is just the base Anaconda directory. After installing Trilinos correctly, the Gmsh subprocess gave the following error with 2 processors:

$ mpirun -np 2 python kris.py --trilinos
*** Error in `gmsh': double free or corruption (out): 0x0000000003416ec0 ***
...
7f96602a0000 ... /usr/lib/openmpi/lib/openmpi/mca_osc_rdma.so
...
[loki:07916] *** End of error message ***
Traceback (most recent call last):
...
EOFError: No `MeshFormat' header found!

The Python error is just due to Gmsh falling over. The fact that the error message is pointing at the system MPI is confusing and suggests the system version of Gmsh is somehow compiled with MPI support. However, ENABLE_MPI=OFF is the default setting for Gmsh which seems inconsistent. Anyway, I didn’t try to really resolve this problem, but just updated the version of Gmsh without using the system version. I downloaded the latest binary version of Gmsh and placed it in Anaconda’s bin directly and then everything seemed to work:

$ mpirun -np 1 python kris.py --trilinos
27900
0.372065067291
$ mpirun -np 2 python kris.py --trilinos
14973
14973
0.230810165405
0.230820894241
$ mpirun -np 4 python kris.py --trilinos
7971
7955
8106
7958
0.157829046249
0.157819032669
0.157863140106
0.157871007919

Of course, the above doesn’t answer any of the original questions on the mailing list, but at least I have a working version of FiPy in parallel.

MKS Workshop

2014-01-17T00:00:00+00:00

On January 13th and 14th we held a small workshop in the Center for Theoretical and Computational Materials Science (CTCMS) at NIST to discuss and work on materials informatics code examples. We focused on the materials knowledge system (MKS) and the more general topic of spatial statistics. The MKS is a regression technique that matches a microstructure with a response and is a nice introduction to materials informatics and smoothly leads into other topics such as spatial statistics and machine learning. The workshop included lightning talks and tutorials given by me and Tony Fast. There were also talks by Jim Warren and Surya Kalidindi. While the focus of the workshop was on materials informatics, the aim was really to work on some of the scientific computing aspects of materials informatics rather than the theoretical or experimental aspects.

Overall I enjoyed the two days. I learned a lot about structuring this type of “hands on” workshop (more on that below). I have a better idea of the global picture of materials informatics, specifically the relationship to spatial statistics and signal-response theory and the importance of varying forms of discretization for the state space rather than a simple linear interpolation. I have had positive feedback from a number of the participants. In particular, it has increased the understanding of how the MKS can augment existing modeling techniques. Also, I think there is some future collaboration with Tony that seems to be within reach, for example,

port the spatial statistics functions from Matlab to Python and then package and document,
create a nice set of examples that work as both demonstrations and regression tests.

Criticism

I’ll stick to my own experiences during my tutorial. I really enjoyed doing it and especially preparing the materials. The tutorial was prepared as a set of IPython notebooks with optional exercise problems. From a Python perspective, addressing the audience was quite difficult as it was made up of both very experienced Python users and complete beginners. This is an almost impossible gap to bridge. On top of this, I am new to the subject matter and haven’t presented it before.

The main issue with the tutorial was that no one really participated in actually running the code and attempting the exercise problems. This wasn’t a show stopper and participants still got a lot out of it. It just makes it more difficult to follow along and understand each step in the coding process. With this in mind, here are some ideas that would substantially improve similar “hands on” tutorials.

Don’t do it alone. Two people should really tutor for a 3 hour tutorial.
The first few exercise problems need to be really easy so that the material doesn’t seem overwhelming.
In this tutorial there were quite a few issues with the computational environment. These issues are completely negated with a cloud-based environment using either Wakari or a custom AMI.
Participants need to be able to see their screens and see the main screen without turning around.
Any tricky packages should have imports only in the cells or functions where they are used. This prevents pointless import errors that don’t matter for most of the notebooks. This problem threw a few people right at the beginning.

Specifically, when presenting the MKS:

Make the introduction far less dense and introduce the equations slowly defining each term and show lots of examples.
No need to have a Python intro. Any Python material can be embedded in the other tutorials.
Demonstrate why we are using the MKS at the beginning. In this case to speed up solving an equation in a non-traditional way.

Materials for MKS Tutorial

The materials for the MKS tutorial are available on Github:

https://github.com/wd15/pymks/tree/workshop

The IPython notebooks are viewable straight from the browser (without Python or IPython installed on your computer):

http://nbviewer.ipython.org/github/wd15/pymks/tree/workshop/notebooks/

Materials for Spatial Statistics Tutorials

All of Tony’s Matlab materials are also available at both:

https://github.com/tonyfast/SpatialStatisticsFFT

and

https://github.com/tonyfast/NIST_MS_Workshop

as well as some slides

http://www.slideshare.net/tonyfast1

More Extreme Fill Simulations

2013-07-19T00:00:00+00:00

The simulations below try to determine if total fill can be achieved without the deposition completely shutting down and with an absence of voids. There are also some concerns regarding the veracity of the consistent v-notch that forms on the depositing surface in the center of the feature during filling. To check this, simulations with no symmetry condition are plotted.

Varying $k^-$

If we observe the $k^-$ simulations in Extremefill 2D - Comparison with 1D, it seems that going to higher values of $k^-$ provides the possibility of full fill without shutting down and with no voids. The simulations here are with a slightly reduced value of $k^+=78.5$ . Shifting from $k^-=1.83 \times 10^7$ to $2.64 \times 10^7$ moves from a “shut down” regime to a “void” regime. Intermediate values may demonstrate void free fill, but have not yet been run.

from multiViewer import MultiViewer
from smtext import getSMTRecords, smt_ipy_table
records = getSMTRecords()
records = getSMTRecords(records=records, tags=['serialnumber24'])
records = getSMTRecords(records=records, parameters={'kPlus' : 78.4759970351})
records = [getSMTRecords(records=records, parameters={'kMinus' : value})[0] for value in 10**np.linspace(6, 9, 20)[6:14]]
title = [r'$k^-$={0:1.2e}'.format(r.parameters['kMinus']) for r in records]
viewer = MultiViewer(records, title=title, figsize=(16, 9))
viewer.plot(times=(0., 1000., 2000., 3000., 4000.))
smt_ipy_table(records, fields=['label', 'timestamp', 'parameters', 'duration', 'version'], parameters=['Nx', 'kPlus', 'kMinus'])

Created Django record store using PostgreSQL

/users/wd15/hg/sumatra/sumatra/programs.py:57: Warning: Python could not be found. Please supply the path to the /users/wd15/.virtualenvs/fipy/bin/python executable.
  warnings.warn(errmsg)

Label	Timestamp	Parameters	Duration	Version
`ec74004eb72b`	2013-06-07 21:08	`Nx: 300, kPlus: 78.4759970351, kMinus: 8858667.9041`	5h 24m 52.39s	`b467f01d4abd`
`adfeb4503513`	2013-06-07 21:08	`Nx: 300, kPlus: 78.4759970351, kMinus: 12742749.857`	5h 23m 21.70s	`b467f01d4abd`
`c3a221795022`	2013-06-07 21:08	`Nx: 300, kPlus: 78.4759970351, kMinus: 18329807.1083`	5h 52m 46.03s	`b467f01d4abd`
`d0801179015f`	2013-06-07 21:08	`Nx: 300, kPlus: 78.4759970351, kMinus: 26366508.9873`	6h 57m 6.35s	`b467f01d4abd`
`9fce57507937`	2013-06-07 21:09	`Nx: 300, kPlus: 78.4759970351, kMinus: 37926901.9073`	7h 3m 22.95s	`b467f01d4abd`
`d74cd7d41d6d`	2013-06-07 21:10	`Nx: 300, kPlus: 78.4759970351, kMinus: 54555947.8117`	7h 1m 46.10s	`b467f01d4abd`
`f4811b0c57d4`	2013-06-07 21:10	`Nx: 300, kPlus: 78.4759970351, kMinus: 78475997.0351`	7h 22m 36.94s	`b467f01d4abd`
`dfb708221425`	2013-06-07 21:11	`Nx: 300, kPlus: 78.4759970351, kMinus: 112883789.168`	6h 11m 23.61s	`b467f01d4abd`

Varying $k^+$

Observing the $k^+$ simulations from Extremefill 2D - Comparison with 1D, it seems that void free fill between $k^+=50$ and $k^+=100$ is possilbe. The plots below demonstrate that $k^+=80$ is in fact void free.

from multiViewer import MultiViewer
from smtext import getSMTRecords, smt_ipy_table
records = getSMTRecords()
records = getSMTRecords(records=records, tags=['serialnumber25'])
records = [getSMTRecords(records=records, parameters={'kPlus' : value})[0] for value in (60., 70., 80., 90.)]
title = [r'$k^+$={0:1.2e}'.format(r.parameters['kPlus']) for r in records]
viewer = MultiViewer(records, title=title, figsize=(8, 9))
viewer.plot(times=(0., 1000., 2000., 3000., 4000., 5000., 6000., 6900.))
smt_ipy_table(records, fields=['label', 'timestamp', 'parameters', 'duration', 'version'], parameters=['kPlus'])

Created Django record store using PostgreSQL

/users/wd15/hg/sumatra/sumatra/programs.py:57: Warning: Python could not be found. Please supply the path to the /users/wd15/.virtualenvs/fipy/bin/python executable.
  warnings.warn(errmsg)

Label	Timestamp	Parameters	Duration	Version
`552885d5576c`	2013-07-08 15:18	`kPlus: 60.0`	3h 9m 43.21s	`b467f01d4abd`
`962f4b9b576e`	2013-07-08 15:18	`kPlus: 70.0`	3h 20m 35.14s	`b467f01d4abd`
`1c7e585c9ae2`	2013-07-08 15:18	`kPlus: 80.0`	3h 3m 0.48s	`b467f01d4abd`
`95f755f659cc`	2013-07-08 15:18	`kPlus: 90.0`	6h 51m 35.48s	`b467f01d4abd`

Simulation with no symmetry condition

Simulations with no symmetry condition are indeed similar to the simulations with symmetry. One major difference is the asymmetric instability that occurs when the filling exits the feature. The second difference is that the void near the top of $k^+=70$ simulation is absent. The reason for this is unclear.

%load_ext autoreload
%autoreload 2
from multiViewer import MultiViewer
from smtext import getSMTRecords, smt_ipy_table
records = getSMTRecords()
records = getSMTRecords(records=records, tags=['serialnumber27'])
records = [getSMTRecords(records=records, parameters={'kPlus' : v})[0] for v in (60., 70., 80., 90.)]
title = [r'$k^+$={0:1.2e}'.format(r.parameters['kPlus']) for r in records]
viewer = MultiViewer(records, title=title, figsize=(8, 9))
viewer.plot(times=(0., 1000., 2000., 3000., 4000., 5000., 6000., 7000.))
smt_ipy_table(records, fields=['label', 'timestamp', 'parameters', 'duration', 'version'], parameters=['symmetry', 'kPlus'])

Created Django record store using PostgreSQL

/users/wd15/hg/sumatra/sumatra/programs.py:57: Warning: Python could not be found. Please supply the path to the /users/wd15/.virtualenvs/fipy/bin/python executable.
  warnings.warn(errmsg)

Label	Timestamp	Parameters	Duration	Version
`b79945f365b8`	2013-07-17 18:06	`symmetry: 0, kPlus: 60.0`	6h 43m 48.49s	`6749083f8baa`
`a8c88dee2c0c`	2013-07-17 18:06	`symmetry: 0, kPlus: 70.0`	6h 45m 14.60s	`6749083f8baa`
`e0a2e96b782a`	2013-07-17 18:06	`symmetry: 0, kPlus: 80.0`	6h 25m 12.13s	`6749083f8baa`
`f5424a88c7dc`	2013-07-17 18:06	`symmetry: 0, kPlus: 90.0`	6h 10m 21.66s	`6749083f8baa`

Scipy 2013 Talk

2013-07-19T00:00:00+00:00

I really enjoyed the Scipy 2013 conference. The talk seemed to go quite well and there were a few interesting questions. One of the questions involved the accessibility of Sumatra provenance data from within a Python session and whether users need to use the web interface. Using the web interface is not necessary and due to time management issues, I had to rush through the IPython notebooks that highlighted extracting simulation provenance data during a Python session so this may not have been entirely clear from the talk.

The following movie shows “Using Sumatra to Manage Numerical Simulations”, Scipy 2013, June 25th, 2013.

The HTML slides. Some of the embedded pages in the talk were running from a local server when this was presented so won’t be available in the slides. Use the arrow keys to shift between the slides.

Intel Presentation

2013-06-20T00:00:00+00:00

The HTML slides from a talk I gave for Intel representatives (Scott List and Stephen Cea) that visited NIST on June 20th, 2013.

Use the left and right arrows to scroll through the slides. The html may require loading a few times before the equations render correctly. You may also need to use Chrome to view the slides.

Git repository for the slides at the commit when the talk was given (c0944d).

Extremefill2D - Comparison with 1D

2013-06-07T00:00:00+00:00

This blog post compares the new 2D model as described in the previous blog post with the older 1D model (already published). Firstly, the single parameter studies are compared. These include the adsorption coefficient $k^+$ , the consumption coefficient $k^-$ , the depth of the trench $h$ and the distance between the counter electrode and the reference electrode $L$ , the suppressor concentration $C_{\text{SUPP}}^{\infty}$ and the applied potential $E_{\text{APPLIED}}^{\infty}$ . I was planning on including the contour plots (figures 5 and 10 from the 1D paper) as well, but I had issues with the cluster and those simulations are not finished at the time that I wrote this blog post. To get a better feel for how these parameters influence the filling see the equations for the extreme fill system.

Helper Functions

The functions plot1DFigure and plotFeatures can be found at Github. The function plot1DFigure plots figures from the 1D Extreme Fill paper in an IPython friendly manner and plotFeatures shows an array of features along with a corresponding table of Sumatra records.

from multiViewer import plot1DFigure
from multiViewer import plotFeatures

Comparing $k^+$

The following cells show a comparison between the 1D steady and 2D extreme fill simulations. The first image is a plot of the deposition rate, $v$ , versus the feature depth, $z$ , with $z=0$ at the top of the feature for the 1D code. If the curve is not monotonically decreasing it represents a failure (or chance of a failure) in the 1D model.

Comparing the 1D and 2D models it seems like the results do not show any real discrepancies. Obviously, the 1D model does not predict a shutdown of deposition in the $k^+=1000$ , just that there will be extreme fill initially. In the $k^+=50$ case, the 1D model shows a fairly flat profile at the bottom of the feature, hence, it is not surprising to see the void in the 2D case.

plot1DFigure(3)

plotFeatures(parameter='kPlus',
             parameterValues=(0.01, 5.0, 25.0, 50.0, 100.0, 1000.0),
             Nxs=(300, 600, 1200),
             tags=['serialnumber9', 'serialnumber10'],
             title=r'$k^+$={0:1.1e}')

Label	Timestamp	Parameters	Repository	Version	Duration
`18631864eaa6`	2013-04-02 16:37	`kPlus: 0.01, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`87a88d0af002`	12m 6.34s
`b805c8879d80`	2013-04-02 16:37	`kPlus: 5.0, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`87a88d0af002`	11m 58.11s
`aa4c8047157f`	2013-04-02 16:37	`kPlus: 25.0, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`87a88d0af002`	19m 20.55s
`00b17f707ea4`	2013-04-02 16:37	`kPlus: 50.0, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`87a88d0af002`	25m 42.70s
`e673de98c2dc`	2013-04-02 16:37	`kPlus: 100.0, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`87a88d0af002`	28m 20.58s
`31eec11df111`	2013-04-02 16:37	`kPlus: 1000.0, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`87a88d0af002`	20m 32.31s
`c1d4f26fd54c`	2013-04-03 15:51	`kPlus: 0.01, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`87a88d0af002`	1h 44m 37.04s
`00cbe85817e9`	2013-04-03 15:51	`kPlus: 5.0, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`87a88d0af002`	1h 49m 59.28s
`27e40bd4444c`	2013-04-03 15:51	`kPlus: 25.0, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`87a88d0af002`	3h 19m 52.71s
`1d3b25691b7b`	2013-04-03 15:50	`kPlus: 50.0, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`87a88d0af002`	4h 48m 47.09s
`3fbe42d086c8`	2013-04-03 15:51	`kPlus: 100.0, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`87a88d0af002`	5h 8m 19.00s
`e008611c183f`	2013-04-03 15:51	`kPlus: 1000.0, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`87a88d0af002`	48m 45.33s
`0c5cd52d2f54`	2013-04-03 15:51	`kPlus: 0.01, Nx: 1200`	`git@github.com:wd15/extremefill-data.git`	`87a88d0af002`	16h 36m 39.61s
`f735fdfe0d4e`	2013-04-03 15:51	`kPlus: 5.0, Nx: 1200`	`git@github.com:wd15/extremefill-data.git`	`87a88d0af002`	22h 33m 1.57s
`08a3dab5669e`	2013-04-03 15:51	`kPlus: 25.0, Nx: 1200`	`git@github.com:wd15/extremefill-data.git`	`87a88d0af002`	2d 8h 43m 53.23s
`305609d74a69`	2013-04-03 15:51	`kPlus: 50.0, Nx: 1200`	`git@github.com:wd15/extremefill-data.git`	`87a88d0af002`	3d 13h 48m 20.33s
`96dfe15ab005`	2013-04-03 15:51	`kPlus: 100.0, Nx: 1200`	`git@github.com:wd15/extremefill-data.git`	`87a88d0af002`	3d 10h 2m 18.18s
`bf11529241b5`	2013-04-03 15:51	`kPlus: 1000.0, Nx: 1200`	`git@github.com:wd15/extremefill-data.git`	`87a88d0af002`	2d 15h 24m 7.94s

Comparing $k^-$

The lower values for $k^-$ for which the deposition is highly segregated tend to shutdown more quickly.

plot1DFigure(4)

plotFeatures(parameter='kMinus',
             parameterValues=(1e7, 1.5e7, 2e7, 2.5e7, 3e7),
             Nxs=(300, 600),
             tags=['serialnumber11'],
             title=r'$k^-$={0:1.1e}')

Label	Timestamp	Parameters	Repository	Version	Duration
`6b96133ad973`	2013-04-03 16:36	`kMinus: 10000000.0, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`87a88d0af002`	6m 8.08s
`4461f3cee837`	2013-04-03 16:36	`kMinus: 15000000.0, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`87a88d0af002`	8m 25.50s
`6410734030b5`	2013-04-03 16:36	`kMinus: 20000000.0, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`87a88d0af002`	20m 32.71s
`b930f922774f`	2013-04-03 16:36	`kMinus: 25000000.0, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`87a88d0af002`	33m 39.78s
`ef1fa12f21cf`	2013-04-03 16:36	`kMinus: 30000000.0, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`87a88d0af002`	33m 41.86s
`55783e471a66`	2013-04-03 16:36	`kMinus: 10000000.0, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`87a88d0af002`	34m 37.67s
`f65a33fd5c41`	2013-04-03 16:36	`kMinus: 15000000.0, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`87a88d0af002`	46m 56.16s
`b8c1323115fd`	2013-04-03 16:36	`kMinus: 20000000.0, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`87a88d0af002`	4h 3m 21.07s
`90fa89140aac`	2013-04-03 16:36	`kMinus: 25000000.0, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`87a88d0af002`	4h 36m 50.07s
`522e129ef700`	2013-04-03 16:36	`kMinus: 30000000.0, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`87a88d0af002`	5h 52m 29.70s

Comparing $h$

In the deepest features, small voids appear near the bottom.

plot1DFigure(6)

plotFeatures(parameter='featureDepth',
             parameterValues=(8.5e-5, 7.5e-5, 6.5e-5, 5.5e-5, 4.5e-5, 3.5e-5, 2.5e-5, 1.5e-5),
             Nxs=(300, 600),
             tags=['serialnumber19'],
             title=r'$h$={0:1.1e}')

Label	Timestamp	Parameters	Repository	Version	Duration
`9a55126083e0`	2013-05-15 18:26	`featureDepth: 8.5e-05, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`fd277a62ec14`	2h 55m 3.03s
`8b0a677e090e`	2013-05-15 18:26	`featureDepth: 7.5e-05, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`fd277a62ec14`	4h 59m 29.97s
`68a1fc298292`	2013-05-15 18:26	`featureDepth: 6.5e-05, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`fd277a62ec14`	4h 56m 56.97s
`a7ce7488083d`	2013-05-15 18:26	`featureDepth: 5.5e-05, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`fd277a62ec14`	5h 16m 46.53s
`c515ee927819`	2013-05-15 18:26	`featureDepth: 4.5e-05, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`fd277a62ec14`	5h 19m 50.13s
`990396c700ce`	2013-05-15 18:26	`featureDepth: 3.5e-05, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`fd277a62ec14`	5h 33m 32.25s
`325ccfb86835`	2013-05-15 18:26	`featureDepth: 2.5e-05, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`fd277a62ec14`	5h 50m 58.30s
`21fa13a67dc2`	2013-05-15 18:26	`featureDepth: 1.5e-05, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`fd277a62ec14`	6h 20m 58.48s
`840446f47425`	2013-05-15 18:26	`featureDepth: 8.5e-05, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`fd277a62ec14`	22h 32m 49.35s
`b5661185346b`	2013-05-15 18:26	`featureDepth: 7.5e-05, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`fd277a62ec14`	13h 31m 1.20s
`0469b23caa5b`	2013-05-15 18:26	`featureDepth: 6.5e-05, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`fd277a62ec14`	23h 19m 51.73s
`764f0c5fc3f0`	2013-05-15 18:26	`featureDepth: 5.5e-05, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`fd277a62ec14`	23h 45m 47.20s
`3aa7c0ae8e87`	2013-05-15 18:26	`featureDepth: 4.5e-05, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`fd277a62ec14`	1d 14m 29.24s
`6de4dbecc6e7`	2013-05-15 18:26	`featureDepth: 3.5e-05, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`fd277a62ec14`	1d 49m 52.63s
`ad26778146a4`	2013-05-15 18:26	`featureDepth: 2.5e-05, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`fd277a62ec14`	1d 1h 55m 38.43s
`9cd5d06caac4`	2013-05-15 18:26	`featureDepth: 1.5e-05, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`fd277a62ec14`	1d 2h 14m 23.62s

Comparing $\delta_{\text{REF}}$

The inverted curved all fail dramatically as expected. The $L=0.02$ (cyan curve) shows small voids although is doesn’t differ substantially from the $L=0.03$ (pink) and $L=0.04$ yellow curves.

plot1DFigure(7)

from smtext import getSMTRecords, smt_ipy_table
smt_ipy_table(getSMTRecords(tags=['serialnumber20']), fields=['label', 'timestamp', 'parameters', 'repository', 'version', 'duration'], parameters=['deltaRef', 'Nx'])

Label	Timestamp	Parameters	Repository	Version	Duration
`7553c7d3b89c`	2013-05-17 15:51	`deltaRef: 0.04, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`e88050cf7683`	22h 36m 7.78s
`049a8e94a6b8`	2013-05-17 15:51	`deltaRef: 0.03, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`e88050cf7683`	5h 13m 22.98s
`431c8493b363`	2013-05-17 15:51	`deltaRef: 0.02, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`e88050cf7683`	5h 14m 14.59s
`75ab53a5bec6`	2013-05-17 15:51	`deltaRef: 0.005, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`e88050cf7683`	1d 1h 39m 47.09s
`8939f82a5cb4`	2013-05-17 15:51	`deltaRef: 0.04, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`e88050cf7683`	5h 11m 32.67s
`1a80210b206e`	2013-05-17 15:51	`deltaRef: 0.001, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`e88050cf7683`	5h 18m 59.52s
`1d6061b11d1f`	2013-05-17 15:51	`deltaRef: 0.01, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`e88050cf7683`	1d 2h 38m 38.77s
`494969027438`	2013-05-17 15:51	`deltaRef: 0.001, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`e88050cf7683`	1d 1h 19.21s
`d133c857328f`	2013-05-17 15:51	`deltaRef: 0.005, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`e88050cf7683`	5h 17m 54.08s
`e7b9378519b4`	2013-05-17 15:51	`deltaRef: 0.02, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`e88050cf7683`	23h 41m 44.97s
`85318f13cc7e`	2013-05-17 15:51	`deltaRef: 0.01, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`e88050cf7683`	5h 28m 48.48s
`8622b52a132f`	2013-05-17 15:51	`deltaRef: 0.03, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`e88050cf7683`	1d 2h 25m 16.24s

plotFeatures(parameter='deltaRef',
             parameterValues=(0.001, 0.005, 0.01, 0.02, 0.03, 0.04),
             Nxs=(300, 600),
             tags=['serialnumber20'],
             title=r'$L$={0:1.1e}')

Label	Timestamp	Parameters	Repository	Version	Duration
`1a80210b206e`	2013-05-17 15:51	`deltaRef: 0.001, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`e88050cf7683`	5h 18m 59.52s
`d133c857328f`	2013-05-17 15:51	`deltaRef: 0.005, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`e88050cf7683`	5h 17m 54.08s
`85318f13cc7e`	2013-05-17 15:51	`deltaRef: 0.01, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`e88050cf7683`	5h 28m 48.48s
`431c8493b363`	2013-05-17 15:51	`deltaRef: 0.02, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`e88050cf7683`	5h 14m 14.59s
`049a8e94a6b8`	2013-05-17 15:51	`deltaRef: 0.03, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`e88050cf7683`	5h 13m 22.98s
`8939f82a5cb4`	2013-05-17 15:51	`deltaRef: 0.04, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`e88050cf7683`	5h 11m 32.67s
`494969027438`	2013-05-17 15:51	`deltaRef: 0.001, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`e88050cf7683`	1d 1h 19.21s
`75ab53a5bec6`	2013-05-17 15:51	`deltaRef: 0.005, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`e88050cf7683`	1d 1h 39m 47.09s
`1d6061b11d1f`	2013-05-17 15:51	`deltaRef: 0.01, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`e88050cf7683`	1d 2h 38m 38.77s
`e7b9378519b4`	2013-05-17 15:51	`deltaRef: 0.02, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`e88050cf7683`	23h 41m 44.97s
`8622b52a132f`	2013-05-17 15:51	`deltaRef: 0.03, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`e88050cf7683`	1d 2h 25m 16.24s
`7553c7d3b89c`	2013-05-17 15:51	`deltaRef: 0.04, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`e88050cf7683`	22h 36m 7.78s

Comparing $E_{\text{APPLIED}}$

The $E=-0.2$ curve shuts down early on. It is evident that there is a critical point for shut down as the deposition becomes more segregated. The $E=-0.3$ curve is flat near the bottom of the feature and, hence, a void results in the 2D case.

plot1DFigure(8)

plotFeatures(parameter='appliedPotential',
             parameterValues=(-0.3, -0.25, -0.2),
             Nxs=(300, 600),
             tags=['serialnumber21'],
             title=r'$E$={0:1.2f}')

Label	Timestamp	Parameters	Repository	Version	Duration
`2eba4677933c`	2013-05-17 16:39	`appliedPotential: -0.3, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`349d11bf2008`	5h 49m 11.64s
`00fb468033ca`	2013-05-17 16:39	`appliedPotential: -0.25, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`349d11bf2008`	5h 33m 11.88s
`ebb4986b6644`	2013-05-17 16:39	`appliedPotential: -0.2, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`349d11bf2008`	4h 50m 8.42s
`1da2dc5ddb67`	2013-05-17 16:39	`appliedPotential: -0.3, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`349d11bf2008`	1d 6h 55m 29.12s
`c67b57aec60b`	2013-05-17 16:39	`appliedPotential: -0.25, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`349d11bf2008`	22h 8m 25.47s
`791e0ec14d0f`	2013-05-17 16:39	`appliedPotential: -0.2, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`349d11bf2008`	19h 38m 25.55s

Comparing $C_{\text{SUPP}}^{\infty}$

The comparison between the 1D and 2D fits well with the previous results above.

plot1DFigure(9)

plotFeatures(parameter='bulkSuppressor',
             parameterValues=(0.005, 0.01, 0.02, 0.04),
             Nxs=(300, 600),
             tags=['serialnumber22'],
             title=r'$C_}}^$={0:1.2f}')

Label	Timestamp	Parameters	Repository	Version	Duration
`ccbab4a031a7`	2013-05-17 17:14	`bulkSuppressor: 0.005, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`398116fa9d51`	4h 53m 9.35s
`0fa2059ea8ea`	2013-05-17 17:14	`bulkSuppressor: 0.01, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`398116fa9d51`	5h 25m 28.95s
`be0513d524b7`	2013-05-17 17:14	`bulkSuppressor: 0.02, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`398116fa9d51`	5h 9m 38.68s
`fe78f7535f52`	2013-05-17 17:14	`bulkSuppressor: 0.04, Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`398116fa9d51`	4h 10m 42.71s
`97d119babd49`	2013-05-17 17:14	`bulkSuppressor: 0.005, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`398116fa9d51`	21h 57m 26.72s
`7ca156d7a1a4`	2013-05-17 17:14	`bulkSuppressor: 0.01, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`398116fa9d51`	1d 6h 16m 11.23s
`3a57ba0896f2`	2013-05-17 17:14	`bulkSuppressor: 0.02, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`398116fa9d51`	22h 24m 23.14s
`d0afd550f3d0`	2013-05-17 17:14	`bulkSuppressor: 0.04, Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`398116fa9d51`	20h 24m 11.74s

Using Sumatra to Manage Numerical Simulations

2013-05-14T00:00:00+00:00

The following movie shows a talk I gave for my group (Thermodynamics and Kinetics Group) on “Using Sumatra to Manage Numerical Simulations” (May 14, 2013).

The HTML slides. Some of the embedded pages in the talk were running from a local server when this was presented so won’t be available in the slides. Use the arrow keys to shift between the slides.

Git repository for the slides at the commit when the talk was given (28040e).

Extreme Fill 2D

2013-05-07T00:00:00+00:00

Introduction

The extreme fill 1D model has been extended to 2D. Although, the 1D model uses transient terms for all the equations, the electrode/electrolyte interface is held in a stationary position. This idealized system helps explain the most puzzling aspect of extreme fill, the initial formation of the “on” and “off” states of deposition (see previous blog post. While the 1D model captures the most important qualitative aspect of extreme fill, it is not particularly accurate for making fill/fail predictions. The 2D extreme fill model aims to improve the accuracy by using the level set method to model the moving interface in similar way to the old 2D superfill models, but now uses the new level set implementation recently introduced into FiPy. The extreme fill 2D model is hosted at Github.

Note on IPython and Jekyll

This is a just a note on integrating the IPython notebook into the Jekyll blog. The blog post by David Ketcheson includes a script to automate the IPython to Jekyll transition. The script has been modified for my own needs (see the script on Github). There are a number of issues that aren’t yet ironed out such as embedding Sumatra markdown tables rather than HTML and including hover text with Sumatra labels for figures.

Demonstration

As a demonstration of the model, a movie has been made from the following Sumatra record. This also demonstrates embedding a Sumatra table in IPython.

from smtext import getSMTRecords, smt_ipy_table
records = getSMTRecords(tags=['serialnumber18'],parameters={'Nx' : 600})
smt_ipy_table(records, fields=['label', 'timestamp', 'parameters', 'repository', 'version'], parameters=['Nx'])

Label	Timestamp	Parameters	Repository	Version
`58d17d49efd8`	2013-04-26 17:55	`Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`a4e17af0c25a`

Convergence

The following sections contain a rudimentary $\chi$ -by-eye convergence analysis. Further convergence testing may be done, but it is probably best to actually produce some useful results and revisit convergence when the model is closer to being finalized.

CFL Number

The figures show convergence as the CFL decreases from 0.64 to 0.01. The contours presented are for the time steps that have the closest elapsed times to the times argument (time step size is not uniform for these simulations). The red contour is for CFL=0.01 (the base case).

from multiViewer import MultiViewer
from smtext import getSMTRecords, smt_ipy_table

records = getSMTRecords(tags=['CFL', 'production'])
records = [getSMTRecords(records=records, parameters={'CFL' : CFL})[0] for CFL in (0.01, 0.02, 0.04, 0.08, 0.16, 0.32, 0.64)]
title = [r'CFL={0:1.2f}'.format(r.parameters['CFL']) for r in records[1:]]
viewer = MultiViewer(records[1:], baseRecords=records[0], title=title, figsize=(12, 9))
viewer.plot(times=(0., 1000., 2000., 3000., 4000.))
smt_ipy_table(records, fields=['label', 'timestamp', 'parameters', 'repository', 'version', 'duration'], parameters=['CFL'])

Label	Timestamp	Parameters	Repository	Version	Duration
`76cc1cca1d89`	2013-02-22 13:40	`CFL: 0.01`	`git@github.com:wd15/extremefill-data.git`	`0e0334ae83ae`	6h 9m 0.42s
`e07c8a307a1e`	2013-02-22 13:40	`CFL: 0.02`	`git@github.com:wd15/extremefill-data.git`	`0e0334ae83ae`	3h 41m 14.56s
`678975cf7009`	2013-02-22 13:40	`CFL: 0.04`	`git@github.com:wd15/extremefill-data.git`	`0e0334ae83ae`	2h 19m 31.04s
`a9431ee7da68`	2013-02-21 16:32	`CFL: 0.08`	`git@github.com:wd15/extremefill-data.git`	`0592f3835b5c`	1h 18m 11.83s
`9f933d3ae816`	2013-02-21 16:32	`CFL: 0.16`	`git@github.com:wd15/extremefill-data.git`	`0592f3835b5c`	43m 40.75s
`36f7e8fa0702`	2013-02-21 16:32	`CFL: 0.32`	`git@github.com:wd15/extremefill-data.git`	`0592f3835b5c`	24m 44.49s
`a1e3ead836eb`	2013-02-21 16:32	`CFL: 0.64`	`git@github.com:wd15/extremefill-data.git`	`0592f3835b5c`	17m 53.83s

Grid Spacing

The figures show a comparison between Nx=1200 (the red curves) and Nx=150, 300, 600. Nx is the total number of cells from the bottom to the top of the domain including the length of the feature and the boundary layer. The results do not demonstrate any clear grid convergence at present and further results with finer grids are required. These runs are all in serial at present. Some changes are required to the level set implementation in FiPy to run in parallel to allow comparison with finer grids.

from multiViewer import MultiViewer
from smtext import getSMTRecords, smt_ipy_table

records = getSMTRecords(tags=['batch2'])
records = [getSMTRecords(records=records, parameters={'Nx' : Nx})[0] for Nx in (1200, 600, 300, 150)]
title = [r'Nx={0:d}'.format(r.parameters['Nx']) for r in records[1:]]
viewer = MultiViewer(records[1:], baseRecords=records[0], title=title, figsize=(6, 9))
viewer.plot(times=(0., 1000., 2000., 3000., 4000.))
smt_ipy_table(records, fields=['label', 'timestamp', 'parameters', 'repository', 'version', 'duration'], parameters=['Nx'])

Label	Timestamp	Parameters	Repository	Version	Duration
`143dec5e7ecd`	2013-02-28 11:48	`Nx: 1200`	`git@github.com:wd15/extremefill-data.git`	`81f76189d481`	5d 21h 57m 20.14s
`4282f5340892`	2013-02-28 11:51	`Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`81f76189d481`	11h 8m 2.38s
`e66ca6267686`	2013-02-28 11:48	`Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`81f76189d481`	1h 26m 11.63s
`85626d5b2715`	2013-02-28 11:51	`Nx: 150`	`git@github.com:wd15/extremefill-data.git`	`81f76189d481`	16m 39.49s

Sweeps

from multiViewer import MultiViewer
from smtext import getSMTRecords, smt_ipy_table

records = getSMTRecords(tags=['serialnumber4'])
records = [getSMTRecords(records=records, parameters={'sweeps' : sweeps})[0] for sweeps in (32, 16, 8, 4, 2, 1)]
title = [r'sweeps={0:d}'.format(r.parameters['sweeps']) for r in records[1:]]
viewer = MultiViewer(records[1:], baseRecords=records[0], title=title, figsize=(10, 9))
viewer.plot(times=(0., 1000., 2000., 3000., 4000.))
smt_ipy_table(records, fields=['label', 'timestamp', 'parameters', 'repository', 'version', 'duration'], parameters=['sweeps'])

Label	Timestamp	Parameters	Repository	Version	Duration
`7ed71a0a1faf`	2013-03-26 17:12	`sweeps: 32`	`git@github.com:wd15/extremefill-data.git`	`26a1c53dc79c`	3h 35m 47.96s
`7a17de0b7487`	2013-03-26 17:12	`sweeps: 16`	`git@github.com:wd15/extremefill-data.git`	`26a1c53dc79c`	3h 10m 54.34s
`8307dc417ea0`	2013-03-26 17:12	`sweeps: 8`	`git@github.com:wd15/extremefill-data.git`	`26a1c53dc79c`	1h 6m 16.29s
`e16fa2b84942`	2013-03-26 17:12	`sweeps: 4`	`git@github.com:wd15/extremefill-data.git`	`26a1c53dc79c`	1h 3m 56.60s
`528f07e88fae`	2013-03-26 17:12	`sweeps: 2`	`git@github.com:wd15/extremefill-data.git`	`26a1c53dc79c`	26m 3.20s
`331ce2cd522c`	2013-03-26 17:12	`sweeps: 1`	`git@github.com:wd15/extremefill-data.git`	`26a1c53dc79c`	15m 42.37s

Linear Tolerance

from multiViewer import MultiViewer
from smtext import getSMTRecords, smt_ipy_table

records = getSMTRecords(tags=['serialnumber7'])
records = [getSMTRecords(records=records, parameters={'solver_tol' : solver_tol})[0] for solver_tol in (1e-7, 1e-6, 1e-5, 1e-4, 1e-3, 1e-2, 1e-1)]
title = [r'tol={0:1.1e}'.format(r.parameters['solver_tol']) for r in records[1:]]
viewer = MultiViewer(records[1:], baseRecords=records[0], title=title, figsize=(12, 9))
viewer.plot(times=(0., 1000., 2000., 3000., 4000.))
smt_ipy_table(records, fields=['label', 'timestamp', 'parameters', 'repository', 'version', 'duration'], parameters=['solver_tol'])

Label	Timestamp	Parameters	Repository	Version	Duration
`faa5d9f206ed`	2013-03-27 11:25	`solver_tol: 1e-07`	`git@github.com:wd15/extremefill-data.git`	`a5790e469d66`	32m 58.14s
`f59dfdbec834`	2013-03-27 11:24	`solver_tol: 1e-06`	`git@github.com:wd15/extremefill-data.git`	`a5790e469d66`	33m 43.28s
`9bc8c7395961`	2013-03-27 11:24	`solver_tol: 1e-05`	`git@github.com:wd15/extremefill-data.git`	`a5790e469d66`	31m 14.05s
`417bcf854132`	2013-03-27 11:24	`solver_tol: 0.0001`	`git@github.com:wd15/extremefill-data.git`	`a5790e469d66`	27m 41.94s
`33b8c8063ac2`	2013-03-27 11:24	`solver_tol: 0.001`	`git@github.com:wd15/extremefill-data.git`	`a5790e469d66`	25m 56.36s
`5ad7bdc1a530`	2013-03-27 11:24	`solver_tol: 0.01`	`git@github.com:wd15/extremefill-data.git`	`a5790e469d66`	31m 59.05s
`2531d84308b4`	2013-03-27 11:24	`solver_tol: 0.1`	`git@github.com:wd15/extremefill-data.git`	`a5790e469d66`	1h 6m 29.66s

Control Parameters

Using the images above, the control parameters will be adjusted from

sweeps = 30
solver_tol = 1e-6
CFL = 0.1
tol = 1e-1```

to

sweeps = 4 solver_tol = 1e-10 CFL = 0.1 tol = 1e-10```

Using these new parameters, simulations have been run with Nx=150, 300, 600 and compared with the old parameters. Simulations with the new parameters are more efficient without sacrificing accuracy.

from multiViewer import MultiViewer
from smtext import getSMTRecords, smt_ipy_table

Nxs = (600, 300)
records = getSMTRecords(tags=['serialnumber8'])
records = [getSMTRecords(records=records, parameters={'Nx' : Nx})[0] for Nx in Nxs]
baseRecords = getSMTRecords(tags=['batch2'])
baseRecords = [getSMTRecords(records=baseRecords, parameters={'Nx' : Nx})[0] for Nx in Nxs]
title = [r'Nx={0:d}'.format(r.parameters['Nx']) for r in records]
viewer = MultiViewer(records, baseRecords=baseRecords, title=title, figsize=(4, 9))
viewer.plot(times=(0., 1000., 2000., 3000., 4000.))
smt_ipy_table(records + baseRecords, fields=['label', 'timestamp', 'parameters', 'repository', 'version', 'duration'], parameters=['Nx'])

Label	Timestamp	Parameters	Repository	Version	Duration
`d83505552902`	2013-03-27 14:22	`Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`a5790e469d66`	4h 20m 30.13s
`8cdf3a35f80f`	2013-03-27 14:22	`Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`a5790e469d66`	28m 45.72s
`4282f5340892`	2013-02-28 11:51	`Nx: 600`	`git@github.com:wd15/extremefill-data.git`	`81f76189d481`	11h 8m 2.38s
`e66ca6267686`	2013-02-28 11:48	`Nx: 300`	`git@github.com:wd15/extremefill-data.git`	`81f76189d481`	1h 26m 11.63s

What is Extreme Fill?

2013-04-12T00:00:00+00:00

Extreme fill theory explains one particular mechanism of feature filling in electroplating. The mechanism that results in extreme fill is similar in a number of respects to both the curvature enhanced accelerator coverage (CEAC) and leveling mechanisms, which are both modulated by additives in the electrolyte. In contrast to the CEAC and leveling mechanisms, the defining characteristic of extreme fill is the highly segregated deposition that occurs only on the very bottom of the feature with a complete absence of deposition on the top surface and walls of the feature. The image below of deposition in a silicon via demonstrates just how segregated extreme fill can be.

The simplest explanation of extreme fill requires just two equations, an equation for the deposition rate, $v$ , given by

$v = v_0 \left(1 - \theta\right)$

and an equation for the coverage of an adsorbed additive (known as the suppressor) at the electrode/electrolyte interface, $\theta$ , given by

$\dot{\theta} = k^+ c_{\theta} \left(1 - \theta\right) - k^- \theta v$

where $\theta$ varies between 0 (no suppression) and 1 (fully suppressed). The coverage of suppressor is governed by the competition between adsorption and consumption controlled by $k^+$ and $k^-$ , respectively. The concentration of suppressor in the bulk electrolyte is given by $c_{\theta}$ .

There are two steady state solutions to these equations, $\theta=\frac{k^+ c_{\theta}}{k^- v_0}$ and $\theta=1$ . These two states corresponding to the “on” and “off” states of deposition, which manifests in the extreme fill behavior demonstrated in the image. Now, if $\frac{k^+ c_{\theta}}{k^- v_0} > 1$ then the stable solution is $\theta=1$ , but if $\frac{k^+ c_{\theta}}{k^- v_0} < 1$ , the stable solution is given by $\theta=\frac{k^+c_{\theta}}{k^-v_0}$ . The control parameter here is $c_{\theta}$ , which varies spatially and can change rapidly descending down the trench and thus enables an “off” state at the top of the trench and an “on” state at the bottom of the trench. To reach these steady “on” and “off” states, the equation for the electric potential must also be coupled into the problem (see the full set of equations on the extreme fill website).

The movie below is generated by a pseudo steady state model of extreme fill outlined in this recent paper. It shows the normalized potential (cyan), bulk suppressor concentration (green), cupric concentration (red) and suppressor coverage (blue). The region where $x < 0$ $\mu$ m corresponds to the inside of the feature. When the steady state is obtained, deposition is only occurring at the very bottom of the feature $x < 50$ $\mu$ m where the blue line is less than 1 and bulk suppressor concentration (green line) is very close to zero.

For further details about the extreme fill mechanism see the paper, which contains a complete description of the psuedo steady-state model. The extreme fill website and corresponding Github repository contain the necessary documentation and code to run the FiPy model of extreme fill as well as generate the data to completely reproduce the images in the paper.

Configuring Sumatra for Postgres

2013-04-08T00:00:00+00:00

For the last few months I’ve been using Sumatra to log the provenance data for simulations. It’s a really promising tool, and I’ve been hacking on it from time to time as I proceed with real research. Sumatra even has a web interface driven by Django and uses SQLite as the default back end database.

One of the issues with SQLite is concurrency. This issue manifests itself with Sumatra when dozens of jobs are launched simultaneously with each job having a similar life time. In this event most of the jobs are not recorded and the unrecorded jobs will sign off with the dreaded django.db.utils.DatabaseError: database is locked. For further discussion of this issue see the Sumatra mailing list thread on this topic.

Quick and Dirty Solution

In the short term, I decided to use a quick and dirty solution to work around this issue using file locks. I couldn’t face learning to configure Postgres as I have little to no experience with databases. The file lock solution allowed me to proceed with my work without having to learn the ins and outs of configuring Django and Postgres.

The solution required creating a decorator class available at Github that encapsulated the Python function to be logged. The two Sumatra commands that need to be protected from concurrency issues are project.add_record and project.save. Here the with statement is used to set and release the lock:

with SMTLock(project):
    project.add_record(record)
    project.save()

where SMTLock is defined as

class SMTLock:
    def __init__(self, project):
        self.lock = lockfile.FileLock(
            os.path.split(_get_project_file(project.path))[0])

    def __enter__(self):
        self.lock.acquire()

    def __exit__(self, type, value, tb):
        self.lock.release()

The above class requires the lockfile module. The file locking mechanism worked well enough and might be a solution for those that wish to maintain a lightweight database solution with Sumatra. However, it does require making changes to the script or program for which the provenance data is being logged. This goes against the grain of the “don’t change the existing workflow” approach of Sumatra.

Postgres

Given that the above solution is unsatisfactory, another alternative is to use a database that properly handles concurrency. To install Postgres on Ubuntu use

$ sudo apt-get install postgresql
$ sudo apt-get install python-psycopg2

and then use

$ sudo passwd postgres

to set the password. Then create a Sumatra user for Postgres using

$ sudo -u postgres createuser -P sumatra_user

To create a database do

$ su postgres
postgres$ psql template1

template1=# CREATE DATABASE sumatra_db OWNER sumatra_user ENCODING 'UTF8';

Exit the Postgres shell prompts and edit /etc/postgresql/9.1/main/pg_hba.conf by adding

local      sumatra_db   sumatra_user   trust

and relaunch Postgres

$ sudo /etc/init.d/postgresql restart

If Sumatra gives errors during configuration and the database has the wrong field sizes then you’ll need to repeat the process above to create a new database. You can delete the old database with

template1=# DROP DATABASE sumatra_db

These instructions were snatched from iiilx’s blog. Now that Postgres is working we can move on to setting up Sumatra.

Configuring Sumatra

Edit the Django database configuration in src/recordstore/django_store/__init__.py to swap SQLite for Postgres.

             self._settings['DATABASES'][label] = {
-                'ENGINE': 'django.db.backends.sqlite3',
-                'NAME': os.path.abspath(db_file)
+                'ENGINE':
+                'django.db.backends.postgresql_psycopg2',
+                'NAME': 'sumatra_db',
+                'USER': 'sumatra_user',
+                'PASSWORD': 'password',
+                'HOST': 'localhost'
             }

Ideally this would be the only change required, however, there is an issue with the field sizes in Sumatra. Using Sumatra with the above configuration will result in Postgres errors of the type DatabaseError: value too long for type character varying(100). This error is caused because the field sizes have never been checked with anything but SQLite and SQLite has no size limits in the way that Postgres does (see this stackoverflow thread for more details). Anyway, fixing the field size problem simply requires making a number of changes like this

-    type = models.CharField(max_length=20)
+    type = models.CharField(max_length=100)

in src/recordstore/django_store/models.py. There are about 10 of these altogether (see the full changeset for a complete list). The above instructions are valid as of commit d65bb4fa1f83.

Testing Sumatra for Concurrency

The following is a test to see that it works. Set up a trivial script.py,

1
2
3
4
5
6
7
8
9
10 import time
import sys

param_file = sys.argv[1]
f = open(param_file, 'r')
exec f.read()

print 'waiting for ' + str(wait) + '(s)'
time.sleep(wait)
print 'finished'

and a parameter file (default.param) with

1 wait=3

Set up a Git repository.

$ git init
$ git add script.py default.param
$ git ci -m "First commit."

Set up a Sumatra repository.

$ smt init postgres_test
$ smt configure --executable=python --main=script.py
$ smt configure --addlabel=cmdline
$ smt configure -g uuid
$ smt configure -c store-diff
$ smt run default.param wait=5

Check the repository with smtweb. There should be one record. Now to test the concurrency use

$ for i in $(seq 100); do smt run default.param wait=3 &> /dev/null & done

Check the repository. 101 records. No concurrency issues!

What next?

In the near future I hope to submit a patch for this and include some kind of command line configuration for Sumatra to allow easy set up. Something like this

$ smt configure --database=postgres --name=sumatra_db --user=sumatra_user --password=password

Switching to Jekyll

2013-04-05T00:00:00+00:00

I finally decided to move away from my old Trac blog at Matforge. Jekyll Bootstrap seems like a good alternative as most of my research has moved to Github repositories in the last year. The main benefit of the Trac blog was the close integration with the Subversion repository, which I now of course no longer use. The overriding benefit of using Jekyll is having the posts stored as plain markup in a local Git repository independently from either the blogging tool or the blog design. Also, using Jekyll presents a very low barrier to switching between blogging tools. There is also the added benefit of testing locally before publishing.

Resources

The Jekyll Bootstrap site has most of the requirements for setting up the blog. To add in maths support I found Dason Kurkiewicz’s site which had very clear instructions. So, using the Mathjax plugin

\frac{\partial \phi}{\partial t} = -\phi^2 + a^2

renders as

$\frac{\partial \phi}{\partial t} = -\phi^2 + a^2$

and the code highlighting looks good

for i in range(10):
    print i

I chose to use “the-minimum” Jekyll Bootstrap theme and tweaked only a very few things. Unfortunately, I don’t know nearly enough about the way Jekyll and css work to make the changes that I want at the moment. Hopefully, the site will improve over time.

Other resources:

A list of nice Jekyll Bootstrap sites.