Re: [ESPResSo-users] address@hidden: Creating polymers: Default neutral monomer type not 0?]

[David Sean]

Hello Ramon Creyghton,

Thank you for your feedback, it is a good idea to add a small warmup
section in the sample polymer script.
In the meanwhile, feel free to look at the warmup section of the
samples/constraints.py
 or consider this one:

warm_steps=10
lj_cap = 1
system.force_cap = lj_cap
act_min_dist = system.analysis.min_dist()
# warmup with zero temperature to remove overlaps
system.thermostat.set_langevin(kT=0.0, gamma=1.0)
# slowly ramp up the cap
while ( act_min_dist < 0.95):
    print("min_dist: {} \t force cap: {}".format(act_min_dist, lj_cap))
    system.integrator.run(warm_steps)
    system.part[:].v=[0,0,0]
    # Warmup criterion
    act_min_dist = system.analysis.min_dist()
    lj_cap = lj_cap*1.01
    system.force_cap = lj_cap
#remove force cap
lj_cap = 0
system.force_cap = lj_cap
system.integrator.run(warm_steps*10)
# restore simulation temperature
system.thermostat.set_langevin(kT=1.0, gamma=1.0)
system.integrator.run(warm_steps*10)
print("Finished warmup")

This should fix the bond_broken errors you are seeing.

The way in which the charged monomers are chosen along the backbone is
by setting the type to type_charge at every interval of
charge_distance. For example, let n be the monomer index (starting at
0) of a given polymer chain

    if(n % charge_distance==0)
        type = type_poly_charged
    else
        type = type_poly_neutral

So that by construction, the first monomer is ALWAYS of
type_poly_charge separated by a string of monomers having type
type_poly_neutral such that the distance along the contour is
charge_distance.

With the default value of charge_distance=1, all of them have the same
type set to type_poly_charge.
If you wish to not have them actually carry a charge, simply set the
valency to 0.0 using val_poly=0.0 (which is the default).

For your case of a polymer made up of type=0 (uncharged) monomers, you can use

polymer.create_polymer(N_P=1, bond_length=1.0, type_poly_charged=0,
MPC=50, bond=fene)

which will not actually--- despite the misleading keywords---assign a
charge to the monomers.

The sample script (and documentation) should be updated shortly to reflect this.

David Sean


> Date: Wed, 21 Feb 2018 17:06:43 +0100
> From: Ramon Creijghton <address@hidden>
> To: "address@hidden" <address@hidden>
> Subject: [ESPResSo-users] Creating polymers: Default neutral monomer type not 
> 0?
> X-Mailer: Zarafa 7.2.6.10-10
>
> Dear ESPResSo users and developers,
>
>
>
> I am trying to simulate and visualize polymers in confinement. I'm working on 
> the basis of the minimal-polymer.py sample file in the current development 
> version. This file (and some other sample files) define i.a.:
>
>
> A)  a shifted and truncated Lennard-Jones potential between all monomers, 
> defined by     system.non_bonded_inter[0, 0].lennard_jones.set_params(...)
>
> B)  one or more polymers created by     polymer.create_polymer(...)
>
>
> At B), no type_poly_neutral or type_poly_charged is given. Given the 
> documentation [ 
> http://espressomd.org/html/doc/espressomd.html#espressomd.polymer.create_polymer
>  
> <http://espressomd.org/html/doc/espressomd.html#espressomd.polymer.create_polymer>
>  ], one expects that the monomers will be of type 0 by default, as they are 
> not charged. Instead, a simple printout of the created particles shows that 
> they are of type 1. To change the type to int n, an explicit argument to 
> create_polymer of the form type_poly_charged=n works. Note that 
> type_poly_neutral=n does *not* work, even though the monomers are in fact 
> neutral. Thus, it seems as if create_polymer somehow confuses the 
> charge/neutrality of the monomers it intends to create.
>
>
>
> If one changes minimal-polymer.py by setting the particle type to 0, or the 
> interaction to non_bonded_inter[1, 1], the L-J-potential is indeed working on 
> the polymer's monomers. As far as I can tell, it *not* working in the current 
> version.
>
> However, once it is activated, many 'bond broken' errors arise. I'm not 
> entirely sure about the cause, but these errors are probably to be expected, 
> as a proper activation of such potential should start with a force-capped 
> warm-up phase. This might be necessary to add to this (and some other?) 
> sample files.
>
>
>
>
>
> As I am just starting with ESPResSo this month, I am still not quite sure 
> about its proper usage, so... I would appreciate any insights into whether 
> this is a bug, or that I am mistaken.
>
>
>
> Many thanks in advance,
>
> and best regards,
>
>
>
> Ramon Creyghton
>
>