Hello Everyone,

I have a system of MICELLE in water.
In order to generate MICELLE I used MATLAB script to force the monomers to take a shape close to spherical micelle and then using appropriate parameters between same species like water-water, hydrophilic-hydrophilic parts of monomer, hydrophobic-hydrophobic parts of monomer and between different species like water-hydrophilic part of monomer, hydrophilic-hydrophobic parts of monomer (all monomers together form Micelle) to have monomer assembled by running a simulation.

The micelle at the end of the simulation remains assembled with the above mentioned parameters From VMD i can see that the micelle is assembled and hydrophilic part of the micelle faces water and hydrophobic part makes the core of the micelle and I can see brownian motion of the micelle…

I wanted to be sure that I have the perfect micelle and I want to calculate the DENSITY PROFILE of the micelle, but the available compute and fix

COMPUTE id GROUP-ID chunk/atom bin/1d x 0 0.1
fix fix-id hydrophobic_part ave/chunk 1 10 1000 id density/number norm sample file densityhydrophobic.profile

will not give me what I want.
Can anyone tell me how I can calculate the density profile of MICELLE to be sure that there is no problem with the assembly of micelle?


Sheikh Salahudin
PhD Student


Before anybody can give some useful advice you have to explain how you expect the “profile” to be computed and what kind of output you want to see.

Most likely you will have to write a custom post processing tool specific for your system and the kind of analysis you need.
One problem is to cleanly define which atoms “belong” to a micelle and which not. I recall that was non-trivial in a study that I was involved in over 10 years ago that was published in: J. Chem. Theory Comput. 7(12), 4135-4145 (2011)

There are likely other publications on that topic that discuss other approaches or variants. You will have to see which one is most suitable for your system.

You can equilbrate your system using LAMMPS MD simulation, produce a data or trajectory file, and use “OVITO” (for example) to analyse the particles distribution.

Thanks for your replies.
I managed with my problem of density profile of Micelle.
I actually used bin**/sphere** to calculate the density profile of micelle.

*bin/sphere* args = xorig yorig zorig rmin rmax nsbin

Since my Micelle is moving during the simulation, I need to define arguments like xorig yorig zorigin , which is like the center of mass of micelle and these arguments (xorig yorig zorigin) will change for every timestep.
Now in order to use these updated xorig, yorig, zorigin, I used compute com command, but the problem is i get this error,

ERROR: Expected floating point parameter in input script or data file (…/compute_chunk_atom.cpp:106)
Last command: compute cc2 polymer chunk/atom bin/sphere c_comm[0] c_comm[1] c_comm[2] 0 30 20 discard yes

I almost read all the mailinglist related to this error, but did not find any solution.

Can someone help me with this?

here is my lammps script.

variable ndim equal 3
variable kBT equal 0.8
variable seed equal 2654868
variable rc equal 1.0
variable skin equal 0.3*{rc} variable s_exp equal 0.5 variable sigma equal 3 variable gamma equal {sigma}^2/(2*${kBT})

variable Lx equal 30.0
variable Ly equal 30.0
variable Lz equal 30.0

variable nden equal 3.0
variable aww equal 25.0

variable ahh equal 25.0

variable att equal 25.0
variable ahw equal 15.0

variable atw equal 80.0
variable aht equal 80.0

variable relax equal 200
variable ntime equal 50000
variable dt equal 0.01

variable dump equal 5000
variable dump_vmd equal 10000

variable thermo equal 10000

variable Nevery equal 1
variable Nrepeat equal round(1.0*{ntime}/{Nevery})
variable Nfreq equal round(1.0*${ntime})

variable start equal 0
variable freq equal 10
variable length equal 10000

there is no mention in the documentation of compute chunk/atom that the parameters you are looking at may be replaced by a variable or compute or fix reference.
if it is not mentioned, then it is not supported. if you want to change that, you will have to change the C++ source code.
The only way that you currently can have the kind of chunk definition that you are looking for would be if each atom would compute it from an atom style variable based on its own position. I would do this in post-processing. That is what we did for https://doi.org/10.1021/ct2005193 that I have mentioned before.

Thank you for the clarification Alex.

I have never tried to make changes in the source code. But I think now is the time to go for it.
Can you suggest something where I can learn how to make changes in LAMMPS source codes?

Thank you for the clarification Alex.

I have never tried to make changes in the source code. But I think now is the time to go for it.

I disagree. Doing this in post-processing will be significantly simpler.
You don’t need to “learn” how things are done “the LAMMPS way” and can use the programming language that you are most familiar with. For something that is rather complex (I think you are mistaken in how complex it can be to determine the size of a micelle and are likely tainting your results by assuming that it will be perfectly spherical).

Can you suggest something where I can learn how to make changes in LAMMPS source codes?

Some basic instructions are - of course - in the manual: https://docs.lammps.org/Modify.html

However, that is only part of it. The rest can be only learned from studying the source code, especially the comments in the header files of the core classes.
Please note that processing of data in LAMMPS can be much more complex than in post-processing, since the data of the atoms is distributed across parallel sub-domains and thus analysis of groups of atoms/molecules can be complex (check out the sources to compute cluster/atom, compute fragment/atom, and compute aggregate/atom, for example).


p.s.: your input file is an excellent example to demonstrate the abuse of variables in input files. this input file is extremely difficult to read since most parameters are not written where they are used, but first defined as variables somewhere else in the input (and very few of them are used multiple times, so there is next to no benefit from making them a variable), so when debugging the input one always has to jump around to look up and then memorize what which variable stands for. this makes it very easy to confuse things and misinterpret the input. with this you are essentially inventing another input file “language” on top of the keywords that LAMMPS is using.