[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ESPResSo-devel] Lees-edwards PBCs

From: Stefan Kesselheim
Subject: Re: [ESPResSo-devel] Lees-edwards PBCs
Date: Fri, 15 Feb 2013 10:52:10 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130105 Thunderbird/17.0.2

Dear Josh,
thanks for your contribution! Just yesterday I thought about implementing LEBCs for the LB, but also thought it was too annoying to implement it for particles as well. However this excuse does not count any more. Thanks!
We usually work like this: Every developer has his own github repository and whenever he or she thinks something is ready to go into the master, a pull request is sent to Olaf and he puts it into the master on github. This allows to make some last-minute quality check like "Is there a test case? Is there documentation".
A few other people can actually push to espressomd-github but only if Olaf is not available, or similar.

On 02/15/2013 10:46 AM, Josh Berryman wrote:
Hello devs, I've been obliged to run up some Lees-Edwards boundary conditions for the sake of a project that Tanja has ongoing. (Lees-Edwards: periodic shear flow generated by continuously moving the PBC wrap, so that, roughly speaking:  x_unfolded == x_folded + x_img * L  + (y_img * gamma * t), and v_x_unfolded =   v_x_folded + (y_img * gamma).

Modifications were made to the setup of the domdec cell system and (fairly obviously) to everything involving periodic imaging; the net effect is to slow down the code a bit, but of course only when LEES_EDWARDS is compiled in. 

I'd like to submit the code up to the repo, not because I think I deserve developer status for something so small, but just to avoid having to do the patch myself every time someone wants to use it.  If you are OK with this the please give me git access (public key attached) and I will pull, create a branch, and push again so that people can have a look at the branch and see if they want to merge into the trunk.

I have done only a tcl interface so far, the python one should be easy: communication with the user consists of setting a single variable.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]