please always copy the mailing list on your replies.
useful discussions should be archived in the mailing
list archives, so that people in a similar situation can
later research the solutions there in case it doesn't
lead to a change of the code or the documentation.
Thanks for the reply.
This program will be generating scripts that run a few thousand timesteps,
and then reserialise all the data back into python to calculate constraints
mid simulation/work out where to add more elements - I don't want to add the
overhead of writing to a second file, which will slow things down even more.
i disagree, using all those individual
commands is usually *less* efficient.
also, the data file will be *much* more
compact than a file with all the individual
What I really want is a c++ interface to initialise and retrieve the data
myself programatically, but that approach isn't documented so this seemed
the main documentation is the source code,
which is pretty readable.
there also is the option to compile LAMMPS
as a library and use it from C or C++.
... and there is a python wrapper, too.
if you worry about i/o, why not use the python
wrapper and feed the text directly?
that would seem like an even better
approach to what you are trying to do,
based on the limited information i have.
it would require a few additions to the
library interface that are specific to
granular simulations, but that would
be fairly straightforward.
when I say bug - the documentation doesn't explicitly say you can do this,
it seems to imply that 'rot yes' is only applicable when zeroing the
rot yes. applies to the zeroing the rotational momentum
of the _entire group_ in case of initializing particles to
a distribution of random velocities. this has no relevance
to what you are doing. in general, the use for granular
media simulation, is not a very common use of LAMMPS
(the LIGGGHTS fork would probably a better place to
look at and work with), and thus support for relevant
features is - at best - spotty (which motivated the
existence of LIGGGHTS in the first place).
velocity - but that would leave no way to do it (apart from a data file)
when you can modify everything else...
nod. if you don't want to modify the sources,
a data file is all that you have left to do what
you want to do.
Attached is a script that you can see perhaps should set the angular speed
and doesn't: you can see that the angular y that we try to set up ends up in
the linear y. I also attach the output I get. (there also seems to be
something insane going on with the scaling of units, but I'll get to the
that is a common mistake. many commands
default to using coordinate data in terms of
lattice spacings rather than length units. add
"units box" and you are likely to get what you