How can I perform a fracture simulation where a new " type" of particle appears when a potential or interaction breaks.
Is it possible to declare in the script the pair_style for this new type of particles.
Explanation : When the simulation starts, there are only some particles with the “type” equals to 1.
When an interaction or a potential is broken between two particles,I’d like the type of these 2 particles switches to 2 (I can do that by changing the code).
However, I’d want to have the possibility to declare in the script the pair_style for the interaction between particles of type 2 which does not initially exist.
How can I perform a fracture simulation where a new " type" of particle
appears when a potential or interaction breaks.
for explicit bonds, you can extend fix bond/break. for implicit bonds,
i.e. changing the type of non-bonded interactions without having bonds
present, it gets a bit trickier and you'd have to do something similar
to what is done in peridynamics. where a custom "initial neighbors"
list is maintained to have that information available without having
to loop over the entire neighborlist.
Is it possible to declare in the script the pair_style for this new type of
particles.
pair_styles cannot be changed during a run.
Explanation : When the simulation starts, there are only some particles with
the "type" equals to 1.
When an interaction or a potential is broken between two particles,I'd like
the type of these 2 particles switches to 2 (I can do that by changing the
code).
However, I'd want to have the possibility to declare in the script the
pair_style for the interaction between particles of type 2 which does not
initially exist.
Thank you for quick reply. I am already using hybrid simulation (Peridynamics/Granular).
Now, I would like to use the fracture capacity of the peridynamics (PD) method and switch on granular interaction when the PD interaction is broken.
So thank you for your advice to use “fix break/bond”, I did not know this command.
However, even with a hybrid simulation you cannot declare or write in the script file a pair_gran_style for a type of particles which does not exist at the first step !!??
Thank you for quick reply. I am already using hybrid simulation
(Peridynamics/Granular).
Now, I would like to use the fracture capacity of the peridynamics (PD)
method and switch on granular interaction when the PD interaction is broken.
i don't see how that can work at all, since a peridynamics "particle"
is not really a particle but more like a point in an adaptive mesh. so
in my limited understanding of how peridynamics works, you'd have to
reformulate the underlying equations to include the properties that
you want to import from switching to a granular formulation.
So thank you for your advice to use "fix break/bond", I did not know this
command.
it is listed in the documentation as all other available keywords. but
it is meant to be used for atomistic simulations and thus not
applicable here.
However, even with a hybrid simulation you cannot declare or write in the
script file a pair_gran_style for a type of particles which does not exist
at the first step !!??
both granular and peridynamics simulations are quite different from
each other in their approach and from atomistic/coarse grain systems,
where my main expertise lies.
the kind of particle type switching you attempt is far from trivial
and i would be surprised, if you can make this work rigorously without
significant amounts of programming. even though i cannot give any
physical or mathematical reasons, what you are attempting "feels"
conceptually wrong to me.
Axel's comments are more rigorous than mine, particularly with regard to what you are trying to do conceptually.
Your original question was simple enough; can you define interactions for particle type which do not exist at the start of your simulation? The answer is that you can define interactions for any number of 'types' at the start; particles of every type do not need to exist in the simulation. What you need to do is tell the simulation when you create your box how many types you will eventually have. Similarly, the particle interactions (pair_style) must be defined, even if particles of that type do not yet exist.
Moreover, I appreciate that you take time to discuss about the validity of these hybrid simulations. I am always open to discussion.
You are right the both method is conceptually different.
The PD is a non-local method as MD to model a solid behaviour and the discrete element method (DEM) is used to model the contact between spheres.
However the behaviour of a discontinuity within a PD body or the interaction between 2 PD bodies can be led by contact law from spheres.
I think that it is not bad to apply on a PD body external volumic forces which come from contact law !!??
Moreover, I appreciate that you take time to discuss about the validity of
these hybrid simulations. I am always open to discussion.
no problem, it is refreshing to discuss conceptual issues for a
changes instead of "why doesn't my input do what i want it to do?".
You are right the both method is conceptually different.
The PD is a non-local method as MD to model a solid behaviour and the
discrete element method (DEM) is used to model the contact between spheres.
However the behaviour of a discontinuity within a PD body or the interaction
between 2 PD bodies can be led by contact law from spheres.
I think that it is not bad to apply on a PD body external volumic forces
which come from contact law !!??
that is not the concern. the question is: can you identify DEM
particles with PD particles or even switch between them? and in my
understanding the answer to that would be a "no on both accounts"
the corollary of this is that you would have to come up with some way
to do a simulation of two systems side by side and then selectively
couple them, i.e. move the DEM particles according to the volume/shape
of the PD system and project the forces resulting from the DEM
particle interactions selectively onto your PD system.
however, at this point it is probably best to discuss with the
peridynamics author (copied) to have an authoritative answer and not
just some speculation from a guy that has looked at the code only
enough to be able to add multi-threading to it.
