From MAILER-DAEMON Sat May 05 14:59:47 2012 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1SQkCp-0002dB-I9 for mharc-espressomd-devel@gnu.org; Sat, 05 May 2012 14:59:47 -0400 Received: from eggs.gnu.org ([208.118.235.92]:47057) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SQkCn-0002d3-9v for espressomd-devel@nongnu.org; Sat, 05 May 2012 14:59:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SQkCl-0001pM-4n for espressomd-devel@nongnu.org; Sat, 05 May 2012 14:59:44 -0400 Received: from smtp.fhstp.ac.at ([195.202.144.2]:41904 helo=mailgw.fhstp.ac.at) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SQkCk-0001mN-QY for espressomd-devel@nongnu.org; Sat, 05 May 2012 14:59:43 -0400 Received: from localhost (unknown [127.0.0.1]) by mailgw.fhstp.ac.at (Mailservice FH St. Poelten) with ESMTP id CD6EA6F810F for ; Sat, 5 May 2012 18:59:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at fhstp.ac.at Received: from mailgw.fhstp.ac.at ([127.0.0.1]) by localhost (mailgw.fhstp.ac.at [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBUquWkpheVs for ; Sat, 5 May 2012 20:59:27 +0200 (CEST) Received: from [127.0.0.1] (089144206167.atnat0015.highway.a1.net [89.144.206.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgw.fhstp.ac.at (Mailservice FH St. Poelten) with ESMTP id B73EE6F80F4 for ; Sat, 5 May 2012 20:59:26 +0200 (CEST) Message-ID: <4FA5788D.6000905@fhstp.ac.at> Date: Sat, 05 May 2012 20:59:25 +0200 From: Peter Toson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: espressomd-devel@nongnu.org References: <927557623.420981335276158662.JavaMail.root@sxalumni.fhstp.ac.at> <201204271951.05337.arnolda@icp.uni-stuttgart.de> <4F9B1923.3020404@fhstp.ac.at> <201204282108.10799.arnolda@icp.uni-stuttgart.de> In-Reply-To: <201204282108.10799.arnolda@icp.uni-stuttgart.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 195.202.144.2 Subject: Re: [ESPResSo-devel] Porting Interaction Calculations to CUDA X-BeenThere: espressomd-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ESPResSo developers' discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 18:59:46 -0000 Hi! Thanks for pointing to on_integration_start(). It was indeed my idea to collect the interaction data only once and store it in the constant memory on the GPU. What is the best way to clean up memory allocated in on_integration_start()? Is there any event called after integration end or before ESPResSo shutdown? -- Peter Am 28.04.2012 21:08, schrieb Axel Arnold: > On Saturday 28 April 2012, Peter Toson wrote: >> Yes, i ment the bonded interactions. Looks like I have to gather them >> from the particles to transfer the bonded interactions to the GPU... > If you also use other interactions, you could collect them during the regular > bonded calculations, in add_bonded_force, forces.h. Or once in > on_integration_start() in initialize.c, which is called when you enter the > integration loop. After that, bonds only change if you use dynamic bonding. On > the other hand, it might be easier to collect the positions only for the > interaction every time step, and by that send them presorted to the GPU. > > Many regards, > Axel > >> Thanks, Peter >> >> Am 27.04.2012 19:51, schrieb Axel Arnold: >>> Sorry, but what do you mean by interactions? If you mean the bonded >>> interactions, they are indeed only stored with the particles, more >>> precisely, with one of the particles involved in the bond (so, for a >>> bond, only one partner knows about this bond!). There is no local or >>> global list of these, since we don't need it. We anyways loop the >>> particles once to calculate the nonbonded interactions, and during that >>> course, we also add the bonded interactions. >>> >>> For the nonbonded short ranged interactions a local Verlet list is kept >>> with all the interacting pairs per pair of cells, but that does not >>> include the pairs you probably need. >>> >>> Many regards, >>> Axel >>> >>> On Friday 27 April 2012, Peter Toson wrote: >>>> Hallo! >>>> >>>> Thanks for the quick reply and pointing me to that code - you've saved >>>> me a lot >>>> of work. >>>> >>>> Now I have a follow-up question: is there an array for all (local) >>>> interactions as well? >>>> Or can I get the interaction information only from particles? >>>> >>>> -- Peter >>>> >>>> Am 24.04.2012 16:38, schrieb Axel Arnold: >>>>> Hi! >>>>> >>>>> If I didn't missunderstand you, you basically want to do the same as >>>>> the LB- GPU code. That code also copies the positions and velocities >>>>> to the GPU and gets the forces back. The interesting parts for you are >>>>> lbgpu_cfile.c, lb_calc_particle_lattice_ia_gpu and lb_send_forces_gpu. >>>>> These also handle the gathering of the parallely distributed particle >>>>> data. >>>>> >>>>> There are some minor issues with the C++/C interfacing since CUDA is >>>>> inherently C++, but that can be solved using "extern "C" {}" >>>>> constructs. In any case, you don't need to recompile the whole code, >>>>> just your GPU code and of course linking. >>>>> >>>>> Axel >>>>> >>>>> On Tuesday 24 April 2012, Toson Peter wrote: >>>>>> Hallo! >>>>>> >>>>>> I am trying to port the force calculation of some self-implemented >>>>>> bonded interactions to CUDA. For a beginning, I would like to write >>>>>> isolated tests (for performance and correctness) comparing >>>>>> the CPU and GPU calculations. >>>>>> >>>>>> The tests should look something like this: >>>>>> >>>>>> ================================================================ >>>>>> build Particles >>>>>> build Interactions >>>>>> >>>>>> for each Particle P { >>>>>> >>>>>> for each Interaction I of P { >>>>>> >>>>>> add force cause by I to P >>>>>> >>>>>> } >>>>>> >>>>>> } >>>>>> >>>>>> convert Particle and Interaction data to a GPU-friendly format >>>>>> do force calculation on GPU >>>>>> >>>>>> compare results and times >>>>>> ================================================================ >>>>>> >>>>>> What would be the best way to do it, without compiling whole ESPResSo >>>>>> after any change to the GPU-Implementation? >>>>>> >>>>>> >>>>>> "Only" using the Particle and Interaction structs from ESPResSo? Is >>>>>> that even possible considering the many includes in particle_data.h/c? >>>>>> >>>>>> Implementing fake Particle and Interaction structs containing only the >>>>>> members needed for the force calculation? >>>>>> >>>>>> Some other way I did not think of? >>>>>> >>>>>> >>>>>> -- >>>>>> Peter Toson >>>>>> Industrial Simulation >>>>>> St. Poelten University of Applied Sciences > From MAILER-DAEMON Sat May 05 16:51:50 2012 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1SQlxG-0006bC-Kk for mharc-espressomd-devel@gnu.org; Sat, 05 May 2012 16:51:50 -0400 Received: from eggs.gnu.org ([208.118.235.92]:35496) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SQlxD-0006b5-V8 for espressomd-devel@nongnu.org; Sat, 05 May 2012 16:51:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SQlxB-0004ri-Lm for espressomd-devel@nongnu.org; Sat, 05 May 2012 16:51:47 -0400 Received: from anoa.ica1.uni-stuttgart.de ([129.69.120.76]:46421) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SQlxB-0004rI-Bv for espressomd-devel@nongnu.org; Sat, 05 May 2012 16:51:45 -0400 Received: from janeway.localnet (localhost [127.0.0.1]) by anoa.ica1.uni-stuttgart.de (Postfix) with ESMTPS id AC0AFA4239 for ; Sat, 5 May 2012 22:51:42 +0200 (CEST) From: Axel Arnold To: espressomd-devel@nongnu.org Date: Sat, 5 May 2012 22:51:28 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.38-14-generic; KDE/4.6.5; x86_64; ; ) References: <927557623.420981335276158662.JavaMail.root@sxalumni.fhstp.ac.at> <201204282108.10799.arnolda@icp.uni-stuttgart.de> <4FA5788D.6000905@fhstp.ac.at> In-Reply-To: <4FA5788D.6000905@fhstp.ac.at> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201205052251.28769.arnolda@icp.uni-stuttgart.de> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 129.69.120.76 Subject: Re: [ESPResSo-devel] Porting Interaction Calculations to CUDA X-BeenThere: espressomd-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: arnolda@icp.uni-stuttgart.de List-Id: ESPResSo developers' discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 20:51:49 -0000 On Saturday 05 May 2012, Peter Toson wrote: > Hi! >=20 > Thanks for pointing to on_integration_start(). It was indeed my idea > to collect the interaction data only once and store it in the constant > memory on the GPU. >=20 > What is the best way to clean up memory allocated in > on_integration_start()? Is there any event called after integration end or > before ESPResSo shutdown? Hi! There is nothing that is called at the of integration, simply because in=20 general that might be just before the next integration start. Therefore, we= =20 never deallocate there, but simply, if necessary, reallocate on integration= =20 start. There was for long a routine on_program_end, but since never anyone= =20 freed something there, we dropped that - the memory is anyways freed when t= he=20 program terminates. Axel > Am 28.04.2012 21:08, schrieb Axel Arnold: > > On Saturday 28 April 2012, Peter Toson wrote: > >> Yes, i ment the bonded interactions. Looks like I have to gather them > >> from the particles to transfer the bonded interactions to the GPU... > >=20 > > If you also use other interactions, you could collect them during the > > regular bonded calculations, in add_bonded_force, forces.h. Or once in > > on_integration_start() in initialize.c, which is called when you enter > > the integration loop. After that, bonds only change if you use dynamic > > bonding. On the other hand, it might be easier to collect the positions > > only for the interaction every time step, and by that send them > > presorted to the GPU. > >=20 > > Many regards, > > Axel > >=20 > >> Thanks, Peter > >>=20 > >> Am 27.04.2012 19:51, schrieb Axel Arnold: > >>> Sorry, but what do you mean by interactions? If you mean the bonded > >>> interactions, they are indeed only stored with the particles, more > >>> precisely, with one of the particles involved in the bond (so, for a > >>> bond, only one partner knows about this bond!). There is no local or > >>> global list of these, since we don't need it. We anyways loop the > >>> particles once to calculate the nonbonded interactions, and during th= at > >>> course, we also add the bonded interactions. > >>>=20 > >>> For the nonbonded short ranged interactions a local Verlet list is ke= pt > >>> with all the interacting pairs per pair of cells, but that does not > >>> include the pairs you probably need. > >>>=20 > >>> Many regards, > >>> Axel > >>>=20 > >>> On Friday 27 April 2012, Peter Toson wrote: > >>>> Hallo! > >>>>=20 > >>>> Thanks for the quick reply and pointing me to that code - you've sav= ed > >>>> me a lot > >>>> of work. > >>>>=20 > >>>> Now I have a follow-up question: is there an array for all (local) > >>>> interactions as well? > >>>> Or can I get the interaction information only from particles? > >>>>=20 > >>>> -- Peter > >>>>=20 > >>>> Am 24.04.2012 16:38, schrieb Axel Arnold: > >>>>> Hi! > >>>>>=20 > >>>>> If I didn't missunderstand you, you basically want to do the same as > >>>>> the LB- GPU code. That code also copies the positions and velocities > >>>>> to the GPU and gets the forces back. The interesting parts for you > >>>>> are lbgpu_cfile.c, lb_calc_particle_lattice_ia_gpu and > >>>>> lb_send_forces_gpu. These also handle the gathering of the parallely > >>>>> distributed particle data. > >>>>>=20 > >>>>> There are some minor issues with the C++/C interfacing since CUDA is > >>>>> inherently C++, but that can be solved using "extern "C" {}" > >>>>> constructs. In any case, you don't need to recompile the whole code, > >>>>> just your GPU code and of course linking. > >>>>>=20 > >>>>> Axel > >>>>>=20 > >>>>> On Tuesday 24 April 2012, Toson Peter wrote: > >>>>>> Hallo! > >>>>>>=20 > >>>>>> I am trying to port the force calculation of some self-implemented > >>>>>> bonded interactions to CUDA. For a beginning, I would like to write > >>>>>> isolated tests (for performance and correctness) comparing > >>>>>> the CPU and GPU calculations. > >>>>>>=20 > >>>>>> The tests should look something like this: > >>>>>>=20 > >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>> build Particles > >>>>>> build Interactions > >>>>>>=20 > >>>>>> for each Particle P { > >>>>>>=20 > >>>>>> for each Interaction I of P { > >>>>>> =20 > >>>>>> add force cause by I to P > >>>>>> =20 > >>>>>> } > >>>>>>=20 > >>>>>> } > >>>>>>=20 > >>>>>> convert Particle and Interaction data to a GPU-friendly format > >>>>>> do force calculation on GPU > >>>>>>=20 > >>>>>> compare results and times > >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>>=20 > >>>>>> What would be the best way to do it, without compiling whole > >>>>>> ESPResSo after any change to the GPU-Implementation? > >>>>>>=20 > >>>>>>=20 > >>>>>> "Only" using the Particle and Interaction structs from ESPResSo? Is > >>>>>> that even possible considering the many includes in > >>>>>> particle_data.h/c? > >>>>>>=20 > >>>>>> Implementing fake Particle and Interaction structs containing only > >>>>>> the members needed for the force calculation? > >>>>>>=20 > >>>>>> Some other way I did not think of? > >>>>>>=20 > >>>>>>=20 > >>>>>> -- > >>>>>> Peter Toson > >>>>>> Industrial Simulation > >>>>>> St. Poelten University of Applied Sciences =2D-=20 JP Dr. Axel Arnold Tel: +49 711 685 67609 ICP, Universit=E4t Stuttgart Email: arnolda@icp.uni-stuttgart.de Pfaffenwaldring 27 70569 Stuttgart, Germany From MAILER-DAEMON Mon May 07 23:24:32 2012 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1SRb2O-0003QN-Fg for mharc-espressomd-devel@gnu.org; Mon, 07 May 2012 23:24:32 -0400 Received: from eggs.gnu.org ([208.118.235.92]:42246) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SRb2L-0003QH-Hz for espressomd-devel@nongnu.org; Mon, 07 May 2012 23:24:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SRb2J-0007Mu-S5 for espressomd-devel@nongnu.org; Mon, 07 May 2012 23:24:29 -0400 Received: from savannah.gnu.org ([140.186.70.70]:54851 helo=frontend.savannah.gnu.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SRb2J-0007MH-Or for espressomd-devel@nongnu.org; Mon, 07 May 2012 23:24:27 -0400 Received: from www-data by frontend.savannah.gnu.org with local (Exim 4.72) (envelope-from ) id 1SRb2F-0000Bc-Pl; Tue, 08 May 2012 03:24:23 +0000 Date: Tue, 08 May 2012 03:24:23 +0000 To: Olaf Lenz , Christoph Junghans , espressomd-devel@nongnu.org X-PHP-Originating-Script: 0:sendmail.php From: Christoph Junghans X-Savane-Server: savannah.nongnu.org:443 [140.186.70.71] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: espressomd X-Savane-Tracker: bugs X-Savane-Item-ID: 36431 User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.41 Safari/536.5 X-Apparently-From: 174.56.101.78 (Savane authenticated user junghans) Message-Id: <20120508-032423.sv80943.68416@savannah.nongnu.org> References: In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.70 Subject: [ESPResSo-devel] [bug #36431] myconfig-final.h in tarball break out-source build X-BeenThere: espressomd-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ESPResSo developers' discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 03:24:31 -0000 URL: Summary: myconfig-final.h in tarball break out-source build Project: ESPResSo Submitted by: junghans Submitted on: Tue 08 May 2012 03:24:23 AM GMT Category: Build system Severity: 4 - Important Status: Confirmed Assigned to: olenz Open/Closed: Open Discussion Lock: Any Release: 3.1.0 Fixed Release: None _______________________________________________________ Details: $ tar -xvzf espresso-3.1.0.tar.gz $ cd espresso-3.1.0.tar.gz $ echo "#error" > myconfig.h $ mkdir build $ cd build $ ../configure $ make No error as myconfig-final.h from src is used. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ From MAILER-DAEMON Mon May 07 23:31:51 2012 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1SRb9T-0003xU-HR for mharc-espressomd-devel@gnu.org; Mon, 07 May 2012 23:31:51 -0400 Received: from eggs.gnu.org ([208.118.235.92]:46544) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SRb9R-0003x6-Af for espressomd-devel@nongnu.org; Mon, 07 May 2012 23:31:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SRb9P-0001MV-Ad for espressomd-devel@nongnu.org; Mon, 07 May 2012 23:31:48 -0400 Received: from savannah.gnu.org ([140.186.70.70]:40881 helo=frontend.savannah.gnu.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SRb9P-0001MQ-7U for espressomd-devel@nongnu.org; Mon, 07 May 2012 23:31:47 -0400 Received: from www-data by frontend.savannah.gnu.org with local (Exim 4.72) (envelope-from ) id 1SRb9K-0000FF-CB; Tue, 08 May 2012 03:31:42 +0000 Date: Tue, 08 May 2012 03:31:42 +0000 To: Stefan Kesselheim , Christoph Junghans , Olaf Lenz , espressomd-devel@nongnu.org X-PHP-Originating-Script: 0:sendmail.php From: Christoph Junghans X-Savane-Server: savannah.nongnu.org:443 [140.186.70.71] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: espressomd X-Savane-Tracker: bugs X-Savane-Item-ID: 36432 User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.41 Safari/536.5 X-Apparently-From: 174.56.101.78 (Savane authenticated user junghans) Message-Id: <20120508-033141.sv80943.16011@savannah.nongnu.org> References: In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.70 Subject: [ESPResSo-devel] [bug #36432] tclline is broken on Mac OS X-BeenThere: espressomd-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ESPResSo developers' discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 03:31:50 -0000 URL: Summary: tclline is broken on Mac OS Project: ESPResSo Submitted by: junghans Submitted on: Tue 08 May 2012 03:31:41 AM GMT Category: Simulation core Severity: 2 - Minor Status: Confirmed Assigned to: kessel Open/Closed: Open Discussion Lock: Any Release: 3.1.0 Fixed Release: None _______________________________________________________ Details: $ Espresso > code_info stty: standard input: unable to perform all requested operations while executing "exec stty -raw echo" (procedure "lineInput" line 4) invoked from within "lineInput" (procedure "tclline" line 31) invoked from within "tclline" I would vote for disabling tclline by default and add a start-up message on how to enable readline support. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ From MAILER-DAEMON Tue May 08 06:56:28 2012 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1SRi5k-0004rs-JO for mharc-espressomd-devel@gnu.org; Tue, 08 May 2012 06:56:28 -0400 Received: from eggs.gnu.org ([208.118.235.92]:56855) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SRi5i-0004r3-1g for espressomd-devel@nongnu.org; Tue, 08 May 2012 06:56:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SRi5g-0000vH-9Y for espressomd-devel@nongnu.org; Tue, 08 May 2012 06:56:25 -0400 Received: from savannah.gnu.org ([140.186.70.70]:42205 helo=frontend.savannah.gnu.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SRi5g-0000vA-5N for espressomd-devel@nongnu.org; Tue, 08 May 2012 06:56:24 -0400 Received: from www-data by frontend.savannah.gnu.org with local (Exim 4.72) (envelope-from ) id 1SRi5e-000318-U3; Tue, 08 May 2012 10:56:22 +0000 Date: Tue, 08 May 2012 10:56:22 +0000 To: Rudolf Weeber , minina@icp.uni-stuttgart.de, espressomd-devel@nongnu.org X-PHP-Originating-Script: 0:sendmail.php From: Rudolf Weeber X-Savane-Server: savannah.nongnu.org:443 [140.186.70.71] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: espressomd X-Savane-Tracker: bugs X-Savane-Item-ID: 36434 User-Agent: ELinks/0.12~pre5-2ubuntu2 (textmode; Ubuntu; Linux 2.6.38-rc8-vaioz+ x86_64; 114x32-2) X-Apparently-From: 129.69.120.212 (Savane authenticated user rudolfweeber) Message-Id: <20120508-125622.sv80910.11180@savannah.nongnu.org> References: In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.70 Subject: [ESPResSo-devel] [bug #36434] Pressure calculation -- The user's guide does not reflect the code X-BeenThere: espressomd-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ESPResSo developers' discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 10:56:27 -0000 URL: Summary: Pressure calculation -- The user's guide does not reflect the code Project: ESPResSo Submitted by: rudolfweeber Submitted on: Tue 08 May 2012 12:56:22 PM CEST Category: User's Guide Severity: 3 - Normal Status: None Assigned to: None Open/Closed: Open Discussion Lock: Any Release: None Fixed Release: None _______________________________________________________ Details: In the manual it states regarding the ideal gas term for the pressure that the number of degrees of freedom per particle is 3 if rotation is off and 6 if rotation is on. However, this does not reflect the code. In the code, the ideal gas pressure contribution is only calculted from translational degrees of freedom and the degrees of freedom per particle is set to three. The code, in my opinion, is correct, because for non-interacting particles, the amount of momentum they transfer, when they slam into the wall does not depend on their rotational velocity. Hence, we probably have to change the manual (and some comments in the code). _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ From MAILER-DAEMON Thu May 17 07:46:34 2012 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1SUzAA-00079Y-Lj for mharc-espressomd-devel@gnu.org; Thu, 17 May 2012 07:46:34 -0400 Received: from eggs.gnu.org ([208.118.235.92]:51907) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUzA3-00078W-Qx for espressomd-devel@nongnu.org; Thu, 17 May 2012 07:46:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SUzA1-0006eG-KB for espressomd-devel@nongnu.org; Thu, 17 May 2012 07:46:27 -0400 Received: from ns2.iasbs.ac.ir ([85.185.211.19]:44350 helo=mail.iasbs.ac.ir) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUzA1-0006cu-1D for espressomd-devel@nongnu.org; Thu, 17 May 2012 07:46:25 -0400 Received: from mail.iasbs.ac.ir (localhost.localdomain [127.0.0.1]) by mail.iasbs.ac.ir (Postfix) with ESMTP id 5E9311F4EF6; Thu, 17 May 2012 16:16:17 +0430 (IRDT) Received: from 85.185.211.121 (SquirrelMail authenticated user emamyari) by mail.iasbs.ac.ir with HTTP; Thu, 17 May 2012 16:16:17 +0430 Message-ID: <6471dae0f7ead39ff61be07ed339a9a6.squirrel@mail.iasbs.ac.ir> Date: Thu, 17 May 2012 16:16:17 +0430 From: emamyari@iasbs.ac.ir To: espressomd-devel@nongnu.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: multipart/alternative;boundary="----=_20120517161617_26560" X-Priority: 3 (Normal) Importance: Normal X-IASBS-MailScanner-Information: Please contact the ISP for more information X-IASBS-MailScanner-ID: 5E9311F4EF6.A27DF X-IASBS-MailScanner: Found to be clean X-IASBS-MailScanner-From: emamyari@iasbs.ac.ir X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 85.185.211.19 Subject: [ESPResSo-devel] costraint X-BeenThere: espressomd-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ESPResSo developers' discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 11:46:33 -0000 ------=_20120517161617_26560 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 Hi, I am trying to simulate a system of several polymers by using Espresso package. I have two constraints in my system which I have constructed them by the following commands (with box_l=3D100): =C2=A0 1:=C2=A0=C2=A0=C2=A0 constraint wall normal 0 0 1 dist 5 type 5 penetrable 0=C2=A0=20 2:=C2=A0=C2=A0=C2=A0 constraint wall normal 0 0 -1 dist -80 type 6 penetrable 0 =C2=A0 I know that all of the polymers are in Z>5 and Z<80 at the beginning of the simulation. When I start the simulation, all poly= mers aggregate on the first (type=3D5) constraint (Lj-Epsilon of that is 3) af= ter about 5000 time steps.=20 The simulation stops with a background error (below) after about 10000-20000 time steps. =C2=A0 Background error :{061: wall constraint 0 violated by particle =E2=80=A6} =C2=A0 I have performed this simulation many times with different parameters, but I have not got any good result. I must consider= a special point (about constraints) in my simulation? I would be thankful if you guide me. =C2=A0 Best Wishes, --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------=_20120517161617_26560 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi,

I am trying to simulate a system of several polymers by using Espresso package. I have two constraints in my system which I have constructed them by the following commands (with box_l=3D100):

=C2=A0

1:=C2=A0= =C2=A0=C2=A0 constraint wall normal 0 0 1 dist 5 type 5 penetrable 0=C2=A0

2:=C2=A0= =C2=A0=C2=A0 constraint wall normal 0 0 -1 dist -80 type 6 penetrable 0

=C2=A0

I know that al= l of the polymers are in Z>5 and Z<80 at the beginning of the simulation. When I start the simulation, all poly= mers aggregate on the first (type=3D5) constraint (Lj-Epsilon of that is 3) af= ter about 5000 time steps.

The simulation stops with a background error (below) after about 10000-20000 time steps.

=C2=A0

Background error :{061: wall constraint 0 violated by particle =E2=80=A6}

=C2=A0

I have performed this simulation many times with different parameters, but I have not got any good result. I must consider= a special point (about constraints) in my simulation?

I would be thankful if you guide me.

=C2=A0

Best Wishes,


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. ------=_20120517161617_26560--