Jan Domanski

This blog post is a idea for a force-field parametrization strategy, which takes advantage of replica exchanges between different parametrizations of the same system. One of the problems with force-field parametrization is that a large number of parameter space has to be searched. A series of parameter values is often evaluated to try and match an experimental observable. This evaluation is usually done sequentially, slowing down the process. Additionally, if the parameter choice introduces an energy barrier, it may not be possible to sample efficiently and obtain convergence of a numerical quantity, to be compared with experiment. To enhance sampling, temperature replica exchange can be employed. Replicas of the same hamiltonian are run at different temperatures end exchanges are attempted according to the boltzman criterion. Importantly, the energies of the neighboring replicas are compared. It should be advantageous, in the force-field parametrization to take advantage of this...

The aim here was getting simulations of the DUDE receptor proteins up and running. The main challenge is a large number of missing sidechains and loops in these structures - this is not a problem for docking codes perhaps, but certainly is for MD simulation codes. Modeller from the Sali lab seemed like the tool for the job, so let's grab that wget https://salilab.org/modeller/9.16/modeller_9.16-1_amd64.deb sudo env KEY_MODELLER=MODELIRANJE dpkg -i modeller_9.16-1_amd64.deb   The only useful reference I was able to find on filling loops and missing sidechains was: https://salilab.org/modeller/wiki/Missing%20residues However, it assumes the aligment.ali file is constructed by hand. Maybe that's pleasurable to some but when I have ~20 receptor structures to complete, there is no time for this. Let's automate how alignment.ali file is generated: # alignment.py file from MDAnalysis import Universe from MDAnalysis.lib.util import convert_aa_code import textwrap, glo...

It's my first encounter with Redux (which is an implementation of Flux). Coming from a PHP/Symfony2 background, things appear pretty different at first. The core ideas of Redux are Actions, ActionCreator and the Store - all very different vocab from what the PHP-folks are used to. However, things are not as different as they appear to be. Inspired by this video here is a pocket translator for what these things are in PHP-speak. Actions The closest match are Requests, they carry an action type (equivalent of a URI) and possibly some payload (Request post/get params) ActionTypes One-to-one match with 'Routes' Store Only one per application, it's a bit like a Routing component that gets requests, and basing on their URI types, assigns which Controller to send it to. Reducers Sort of like controllers, they recieve Actions from the Store and perform the following function newState = reducer(oldState, action) So it's all quite simple really!