http://antrg.com/Antoine Roy-Gobeil's blog2020-04-30T00:00:00ZAntoine Roy-Gobeilhttp://antrg.comtag:antrg.com,2020-04-30:/blog/2020/4/30/dash-plotly-nixos-20.03/Dash lands in NixOS 20.032020-04-30T00:00:00Z2020-04-30T00:00:00Z<p>
Starting with the release of <a href="https://nixos.org/">NixOS</a> 20.03,
<a href="https://plotly.com/dash/">Dash</a> from <a href="https://plotly.com/">Plotly</a>
(<a href="https://github.com/plotly/dash">Github project</a>)
is now part of the system's Python packages.
See my <a href="https://github.com/NixOS/nixpkgs/pull/77837">pull request</a> for details.
</p>
<div id="splash-logo" style="display: flex; align-items: center">
<div><img alt="Plotly logo" src="img/plotly-fit.png"></div>
<div><img alt="NixOS 20.03 logo" src="img/markhor-fit.png"></div>
</div>
<h2>Getting started</h2>
<h3><code>nix-shell</code></h3>
<p>
You can hop into a reproducible development
environment with <code>nix-shell</code>:
</p>
<pre><code>
[:~]$ nix-shell -p 'python37.withPackages(ps: with ps; [ pandas dash ])'
[nix-shell:~]$ python app.py
</code></pre>
<h3><code>nix-build</code></h3>
<p>
One can build a Dash app server in a reproducible manner using Nix.
Every dependency is cryptographically pinned
down to the Python interpreter, <code>glibc</code> and <code>openblas</code>.
</p>
<p>
Here's an example build file `default.nix` that
take a single file Dash app in file `app.py`
and produce an executable:
</p>
<pre><code>let
nixpkgs = builtins.fetchGit {
name = "nixos-20.03";
url = "https://github.com/nixos/nixpkgs-channels/";
# `git ls-remote https://github.com/nixos/nixpkgs-channels nixos-20.03`
ref = "refs/heads/nixos-20.03";
rev = "ab3adfe1c769c22b6629e59ea0ef88ec8ee4563f";
};
pkgs = import nixpkgs {};
python = pkgs.python37.withPackages(ps: with ps; [ pandas dash ]);
in
pkgs.stdenv.mkDerivation {
name = "dash";
src = ./.;
buildInputs = [python];
installPhase = ''
mkdir -p $out/bin
echo -e "#!/bin/sh\n\n${python.interpreter} $src/app.py" > $out/bin/server
chmod +x $out/bin/server
'';
}</code></pre>
<p>you can then run the server:</p>
<pre><code>$ result/bin/server</code></pre>
<p>
Using Nix tools, we can easily inspect all the dependencies (ie. the closure)
of the `server` executable derived above:
</p>
<div id="gd"></div>
<script src="https://cdn.plot.ly/plotly-latest.min.js"></script>
<script>
Plotly.d3.json('static/figure.json', function(figure) {
Plotly.newPlot('gd', figure)
})
</script>
tag:antrg.com,2020-02-10:/blog/2020/2/10/epj-afm-optical-excitation/Optical excitation of atomic force microscopy cantilever for accurate spectroscopic measurements2020-02-10T00:00:00Z2020-02-10T00:00:00Z<p>
<b>Yoichi Miyahara, Harrisonn Griffin, Antoine Roy-Gobeil, Ron Belyansky, Hadallia Bergeron, José Bustamante & Peter Grutter</b><br>
<i>EPJ Techniques and Instrumentation volume</i>, <b>7</b> 2 (2020)<br>
<b>DOI:</b> <a href="https://doi.org/10.1140/epjti/s40485-020-0053-9">epjti/s40485-020-0053-9</a><br>
</p>
<p>Three years after <a href="/blog/2016/11/1/phd_defence/">defending</a> my <a href="/blog/2016/12/15/phd_thesis/">PhD thesis</a>,
here's a follow-up paper to its instrumentation chapter.
It presents the optical excitation system used
to perform accurate spectroscopic measurements.
It contains new contributions
from several co-authors I had the pleasure to work with during my time at McGill.
I want to give special thanks to <a href="https://harrisonngriffin.com/">Harrisonn Griffin</a>
and Yoichi Miyahara for bringing this one to the finish line while I'm busy
working on <a href="http://github.com/plotly/">plotly</a>!
</p>
<p>Here's a link to the full article in PDF</p>
<a href="https://epjtechniquesandinstrumentation.springeropen.com/track/pdf/10.1140/epjti/s40485-020-0053-9" class="btn btn-lg"><i class="fa fa-2x fa-file-pdf-o"></i></a>
<div style="border-top:1px solid #EEE;margin-top:50px">
<h2>Some highlights</h2>
<div>
<img style="width: 75%" src="https://media.springernature.com/full/springer-static/image/art%3A10.1140%2Fepjti%2Fs40485-020-0053-9/MediaObjects/40485_2020_53_Fig1_HTML.png?as=webp" alt="Schematic diagram of the experimental setup">
<p><b>Figure 1. </b> Schematic diagram of the experimental setup. Two laser lights from Laser diode 1 (1550 nm) and Laser diode 2 (1310 nm) are combined with a filter Wavelength Division Multiplexer (FWDM). The combined light is launched into a single-mode optical fiber. While a fraction of the light is reflected at the fiber-vacuum interface, the rest of the light which comes out of the fiber is reflected on the back side of the cantilever and goes back into the fiber. Only the 1550 nm laser can pass through the filter WDM and reach the photo diode</p>
</div>
<div style="margin-top:50px">
<img style="width: 75%" src="https://media.springernature.com/full/springer-static/image/art%3A10.1140%2Fepjti%2Fs40485-020-0053-9/MediaObjects/40485_2020_53_Fig4_HTML.png?as=webp" alt="Amplitude and phase frequency responses of the AFM cantilever excited by optical excitation (red) and piezo excitation (blue) measured at 4.5 K.">
<p><b>Figure 4.</b> Amplitude and phase frequency responses of the AFM cantilever excited by optical excitation (red)
and piezo excitation (blue) measured at 4.5 K. Note the spurious mechanical resonances in the piezo
excitation which arise from vibrations in the microscope body</p>
</div>
</div>
tag:antrg.com,2019-09-09:/blog/2019/9/9/nanoletters/Fully Quantized Electron Transfer Observed in a Single Redox Molecule at a Metal Interface2019-09-09T00:00:00Z2019-09-09T00:00:00Z<p>
<b>Antoine Roy-Gobeil Yoichi Miyahara, Kirk H. Bevan and Peter Grutter</b><br>
<i>Nano Lett.</i>, <b>2019</b> 19, 9, 6104-6108<br>
<b>DOI:</b> <a href="https://doi.org/10.1021/acs.nanolett.9b02032">10.1021/acs.nanolett.9b02032</a><br>
</p>
<p><b>My latest work is finally published in Nano Letters.</b>
This is the result of a long research journey, lots of efforts and several reviews by scientific peers.
<b>I would like to thank everybody that supported me in my work</b>.</p>
<p>You can find a link to the PDF below in case you are outside of the paywall.</p>
<a href="static/acs.nanolett.9b02032.pdf" class="btn btn-lg"><i class="fa fa-2x fa-file-pdf-o"></i></a>
<div style="border-top:1px solid #EEE;margin-top:50px">
<h3>
<a href="static/nl9b02032_si_001.pdf"><i class="fa fa-file-pdf-o"></i> Supplementary information</a>
</h3>
<h3>Movie S1</h3>
<video controls>
<source src="static/small.mp4" type="video/mp4">
</source></video>
<h3>Movie S2</h3>
<video controls>
<source src="static/large.mp4" type="video/mp4">
</source></video>
</div>
tag:antrg.com,2018-11-28:/blog/2018/11/28/reproducible-opengl/Reproducible OpenGL2018-11-28T00:00:00Z2018-11-28T00:00:00Z<style>
article figure {
display: block;
text-align: center;
}
figcaption {
font-size: 0.8em;
font-style: italic;
margin: 0 0 .8em;
}
</style>
<p>I recently learned the hard way that OpenGL is not a “pixel exact” specification. This is coming straight from the horse’s mouth (Appendix A of the <a href="https://www.khronos.org/registry/OpenGL/specs/gl/glspec44.core.pdf">OpenGLR Graphics System: A Specification (Version 4.4 (Core Profile) - March 19, 2014))</a></p>
<blockquote>
<p>The OpenGL specification is not pixel exact. It therefore does not guarantee an exact match between images produced by different GL implementations.</p>
</blockquote>
<p>Although the result is deterministic (a given machine always returns the same result), it usually isn’t reproducible on different hardware and/or driver. This means that your colleagues who use the exact same data and the exact same code to produce a figure will get a slightly different image. Of course, in many cases it doesn’t matter because monitors and printers are usually not properly calibrated anyway.</p>
<p>However, it makes reliable testing of visualization libraries harder. For example, the <a href="https://github.com/plotly/plotly.js">plotly.js</a> library renders hundreds of figures which are compared pixel by pixel to baseline images in order to guarantee consistency and correctness across releases. This ensures that those figures will always look the same or at least won’t be altered without developers noticing.</p>
<figure>
<div id="graph" style="width:800px;height:500px; margin: 0 auto; ">
</div>
<figcaption>
Figure 1. Example plotly.js 3D figure generated from <a href="https://raw.githubusercontent.com/plotly/plotly.js/master/test/image/mocks/gl3d_ibm-plot.json">gl3d_ibm-plot.json</a>
</figcaption>
</figure>
<script src="https://cdn.plot.ly/plotly-latest.min.js"></script>
<script>
Plotly.d3.json('https://raw.githubusercontent.com/plotly/plotly.js/master/test/image/mocks/gl3d_ibm-plot.json', function(mock) {
Plotly.plot('graph', mock)
})
</script>
<h2 id="software-rendering">Software rendering</h2>
<p>One solution is to not rely on the black-box magic that is hardware acceleration and perform the rendering in software. <a href="http://sdvis.org/">Software defined visualization</a> as Intel puts it allows working with datasets when GPU hardware isn’t available or is limiting. It runs on anything from laptops to workstations to compute nodes in supercomputers.</p>
<p>But is it reproducible? In my tests, the newer more performing <code>llvmpipe</code> and <code>openswr</code> were not but <code>softpipe</code> was reproducible! 🎉🎉🎉</p>
<h3 id="docker-container">Docker container</h3>
<p>Setting up MESA on Ubuntu 18.04 (Bionic Beaver) under Docker:</p>
<pre><code>FROM ubuntu:bionic
RUN apt-get update && apt-get install -y libtool-bin autoconf python-pip libx11-dev libxext-dev x11proto-core-dev x11proto-gl-dev libglew-dev freeglut3-dev bison flex
# Build Mesa
RUN apt-get install -y wget pkg-config zlib1g-dev llvm-dev
RUN wget https://mesa.freedesktop.org/archive/mesa-18.2.4.tar.xz
RUN tar xf mesa-18.2.4.tar.xz
RUN mkdir mesa-18.2.4/build
WORKDIR mesa-18.2.4/build
RUN ../configure --disable-dri \
--disable-egl \
--disable-gbm \
--with-gallium-drivers=swrast,swr \
--with-platforms=x11 \
--prefix=/usr/local/ \
--enable-gallium-osmesa \
--disable-xvmc --disable-vdpau --disable-va \
--with-swr-archs=avx
RUN make -j `numprocs` && make install
# Setup our environment variables.
ENV XVFB_WHD="1920x1080x24"\
DISPLAY=":99" \
LIBGL_ALWAYS_SOFTWARE="1" \
GALLIUM_DRIVER="softpipe"</code></pre>
<h3 id="creating-a-baseline-image">Creating a baseline image</h3>
<p>Using this Docker container running <a href="https://github.com/plotly/orca">Orca</a>, we can now render reproducibly any plotly.js figure on different machines! The result is pixel perfect but be patient: everything is rendered on the CPU!</p>
<div class="sourceCode" id="cb2"><pre class="sourceCode bash"><code class="sourceCode bash"><a class="sourceLine" id="cb2-1" data-line-number="1">$ <span class="ex">docker</span> pull antoinerg/orca-reproducible</a>
<a class="sourceLine" id="cb2-2" data-line-number="2">$ <span class="va">MOCK=</span>gl3d_ibm-plot; <span class="kw">\</span></a>
<a class="sourceLine" id="cb2-3" data-line-number="3"> <span class="ex">curl</span> https://raw.githubusercontent.com/plotly/plotly.js/master/test/image/mocks/<span class="va">$MOCK</span>.json <span class="kw">|</span> <span class="kw">\</span></a>
<a class="sourceLine" id="cb2-4" data-line-number="4"> <span class="ex">docker</span> run -i antoinerg/orca-reproducible graph --verbose <span class="op">></span> <span class="va">$MOCK</span>.png</a></code></pre></div>
<figure>
<img src="img/gl3d_ibm-plot.png" alt="plotly.js mock 14.json">
<figcaption>
Figure 2. Example plotly.js baseline image generated from <a href="https://raw.githubusercontent.com/plotly/plotly.js/master/test/image/mocks/gl3d_ibm-plot.json">gl3d_ibm-plot.json</a> using reproducible Orca
</figcaption>
</figure>
<h3 id="references">References:</h3>
<ul>
<li><a href="https://www.khronos.org/registry/OpenGL/specs/gl/glspec44.core.pdf">The OpenGLR Graphics System: A Specification (Version 4.4 (Core Profile) - March 19, 2014)</a></li>
<li><a href="https://stackoverflow.com/a/7922752">OpenGL deterministic rendering between GPU vendor - Stack Overflow</a></li>
<li><a href="http://arek.bdmonkeys.net/bugs/invariance/index.html">OpenGL Invariance</a></li>
<li><a href="https://media.readthedocs.org/pdf/gallium/latest/gallium.pdf">Gallium Documentation</a></li>
</ul>
tag:antrg.com,2018-09-14:/blog/2018/9/14/jcp-franck-condon-blockade-redox-chemistry/Relating Franck-Condon blockade to redox chemistry in the single-particle picture2018-09-14T00:00:00Z2018-09-14T00:00:00Z<p>
<b>Kirk H. Bevan, Antoine Roy-Gobeil, Yoichi Miyahara and Peter Grutter</b><br>
<i>The Journal of Chemical Physics</i>, <b>149<b>, 104109</b><br>
<b>DOI:</b> <a href="https://doi.org/10.1063/1.5043480%20">10.1063/1.5043480</a><br>
Publication Date: 14 September 2018<br>
</b></p>
<p><b>I am the proud co-author of a <a href="https://doi.org/10.1063/1.5043480%20">a cool theory paper</a> which got published today in The Journal of Chemical Physics!</b></p>
<a href="static/article.pdf" class="btn btn-lg"><i class="fa fa-2x fa-file-pdf-o"></i></a>
<div style="border-top:1px solid #EEE;margin-top:50px">
<h3>Abstract</h3>
<blockquote>
<p>In this work, we explore Franck-Condon blockade in the “redox limit,” where nuclear relaxation processes occur much faster than the rate of electron transfer.
To this end, the quantized rate expressions for electron transfer are recast in terms of a quantized redox density of states (DOS) within a single phonon mode model.
In the high temperature regime, this single-particle picture formulation of electron transfer is shown to agree well with the semi-classical rate and DOS expressions developed by Gerischer and Hopfield. Upon incorporation into a two electrode formulation, utilizing the master equation approach, the low temperature quantized conductance features of Franck-Condon blockade are reproduced.
Moreover, at sufficiently large reorganization energies, it is argued that Franck-Condon blockade should also be observable in room temperature systems.
In general, this work aims to further bridge descriptions of electron transfer and transport in the single-particle picture.
</p>
</blockquote>
</div>