espressomd / espresso Goto Github PK

Tue 02 Dec 2014 03:34:31 PM CET, comment #1:
The artifacts are probably caused by halo nodes not correctly marked as boundary nodes, because the rhomboids in boundaries.tcl do not cover the halo region.

Check complexity and assign to sb

If an interaction is set up after the LB fluid, the latter is brought to the initial state (see simple script below)

Is this the expected behaviour or should it be fixed?

setmd box_l 2 2 2
setmd periodic 1 1 1
setmd time_step 0.1
setmd skin 0.1
lbfluid cpu agrid 1 dens 1 visc 1.0 tau 0.1
lbnode 0 0 0 set v 0.1 0.0 0.0
integrate 0
# uncomment the line below to see the "unexpected behavior" (momentum= 0 0 0)
# inter 0 0 lennard-jones 1.0 1.0 0.1

puts "[analyze fluid momentum ]"  ; # this should yield 0.1 0 0 

Mon 04 Aug 2014 03:44:21 PM CEST, original submission:
Errors are not huge, but very noticable with single test charges. I fixed one obvious bug which at least in some cases fixes the forces, but so far, don't trust ELC with any dielectrics.

Fri 30 Jan 2015 05:08:59 PM CET, original submission:
(1) The particle temperature is too high; as determined by running a longer version of the lb_gpu.tcl test case, see figure.
(2) The lb_gpu.tcl (and by extension the lb.tcl) test case uses the instantaneous fluid temperature as its error criterion, this should be the averaged fluid temperature.
(3) The lb fluid temperature may be too high; could not confirm, different seeds gave different averages, see figure for an instance of a too high fluid temperature.
(4) The lb gpu is improperly seeded; it uses global seed plus thread index. If one uses the PID as global seed (as done in the test case) successive runs produce systems with nearly identical progression of the kinetic energy.
(5) In the extended run length version of the lb_gpu.tcl test case there is unexpected divergence of the kinetic energy (temperature) when runs are initialized with identical seeds. They evolve identically at first, but diverge suddenly somewhere between 16000 and 20000 steps (depending on the seed and possibly time step), see attached images. This could be an uninitialized memory issue.
(6) The deviation of the temperature with respect to the input value becomes smaller with smaller time step.

Wed 08 Apr 2015 07:28:51 PM CEST, original submission:
The values in the stress tensor don't make sense when used together with p3m. Stretching in different directions does reflect the symmetry of the system.
As example I have used just a cubic box with salt and stretched a polymer over the main diagonal. Simulations without p3m yielded that the normal components of the unchanged directions are the same. With p3m stretching yields completely different behavior.
A script with the sample system is attached.
Kind regards,
Tobias Richter

Thu 12 Jun 2014 04:05:58 PM CEST, original submission:
At the moment, one has to manually call "analyze set topo_part_sync" to match the topology information stored with the particles and the topology array. This was long ago decided as the synchronization involves a loop over all particles, but really should be done automatically directly after the "analyze set ..." commands.
Otherwise, we would need to check for all analysis functions that use mol_ids and clarify that "analyze set" is not sufficient for them to work, which is really non-obvious.
In addition, this probably means that the mol_id should be a read-only property, since synchronizing back from particle mol_ids will be PITA.

integrate 1
electrokinetics print lbforce vtk "lbforce.vtk"

This results in a VTK file containing only zeros.

integrate 1
electrokinetics 1 print flux vtk "flux_1.vtk"
electrokinetics 2 print flux vtk "flux_2.vtk"
electrokinetics print lbforce vtk "lbforce.vtk"

This results in a VTK file containing the correct forces.

In integrate.cpp the variable 'step' is used to check whether a ghmc_mc() step is done.
If autoupdates of observables or the correlator are activated, step is always 0, and this is never the case.
I could not find it in the user guide that this is the expected behavior.

Thu 22 Mar 2012 06:02:32 PM CET, original submission:
VIRTUAL_SITES_RELATIVE and VIRTUAL_SITES_COM are implemented in opposite ways.
VIRTUAL_SITES_RELATIVE uses particle properties, while VIRTUAL_SITES_COM uses the topology data.
The first approach seems easy to generalize, however for many molecule the second one save memory as every molecule data is only stores once.
Also the setup is very different VIRTUAL_SITES_RELATIVE uses the part command, while VIRTUAL_SITES_COM uses the "analyze set" command.
The first one is more obvious to use as there is no documentation for the second one ("analyze set chain" is documented, but this is something else).
The suggestion would be to make both accessible via the part command under a "vs" sub-command:
part ... vs relative ...
part ... vs relative_auto ...
part ... vs com ...
With this we can disallow the direct setting of the virtual property via the "part .. virtual {0|1}" command.
Additionally the "analyze set" could be reworked into a topology command:
topology create mol_id parts id id id type int excl {0|1}
topology delete mol_id
topology create mol_id chain ....
With this we can disallow the direct setting of the mol_id property via the "part .. mol_id id" command.

see src/python/espressomd/particle_data.pyx#L191

Integration loop is duplicated between integrate.cpp (velocity verlet/langevin, stepest descend) and integrate_sd.cpp (BD/SD). This will break within weeks. Needs some thoughts because one and two step integrators. Maybe new hooks (on_...).

Wed 30 Jul 2014 08:37:41 AM CEST, original submission:

Limits too tight?