unfix then crash

Submitted by jwarnett on Wed, 12/14/2011 - 13:38

hey

I am sure it is something I have done wrong, but I was running a simulation where something is rotated, and then a mesh is to be removed. The fixes that were in place were:

fix cadcyl all mesh/gran 2cmcyl.stl 1 1 0 0 0 0 0 0
....
fix rotcadcyl all move/mesh/gran rotate 0 0 0 0 0 1 1.0 cadcyl

when my simulation got as far as unfixing both of these I then got the error message:
ERROR: Atom type must start from 1 in granular simulations

and I am unsure as to why this has happened as I do not see how unfixing both of these is related.

Also once the problem has been found, is there anyway to continue the simulation where it left off, unfix and then continue the simulation? It took 9 days to get as far as it did!

Below is the input script I have, which was working fine when I lifted meshes instead of unfixing.

Thanks in advance

Jay

Forums:

ckloss's picture

ckloss | Wed, 12/14/2011 - 14:17

>>ERROR: Atom type must start from 1 in granular simulations
you cant have particles of type 2 without having something of type 1 anywhere
in your case, the mesh is type 1 and the particles type 2, if you remove the mesh, material 1 is no longer used.
so it's just a matter of how the materials are numbered, however liggghts requires you to start with material 1

>>Also once the problem has been found, is there anyway to continue the simulation where it left off, unfix and then continue the simulation?
sure - have a look at write_restart, read_restart and restart and the correspronding how-to section
but this only works if you had a restart or write_restart command in your script

what I typically do is before running the real simulation is running it on smaller scale (less particles, smaller geometry) to see if there is any mistake, typo etc in the script that you would otherwise only discover after 9 days ;-)

Christoph

jwarnett | Wed, 12/14/2011 - 14:24

thanks Christoph. Yea I normally do things on a smaller scale first and then run, but I assumed that the minor change would work. Live and learn!

jwarnett | Thu, 12/15/2011 - 13:14

Hey

I double checked, ensuring all meshes were of type 2 and I still get the same problem. I then went to the extent of naming a group of atom type 2, and then ensuring the stl insertion was with this group ID and I still run into the same problems. I can't see what I am missing!

Thanks
Jay

#initialise granular system with fixed boundaries
atom_style granular
boundary f f f
newton off
communicate single vel yes
units si

#create simulation region
region reg block -0.42 0.42 -0.42 0.42 -0.01 0.4 units box
create_box 2 reg

#setup neighbor lists
neighbor 0.0005 bin
neigh_modify delay 0

#set all material properties and pair style
#using hertz model. refer to documentation
fix m1 all property/global youngsModulus peratomtype 200.e9 200.e9
fix m2 all property/global poissonsRatio peratomtype 0.3 0.3
fix m3 all property/global coefficientRestitution peratomtypepair 2 0.6 0.6 0.6 0.6
fix m4 all property/global coefficientFriction peratomtypepair 2 0.5 0.5 0.5 0.5
pair_style gran/hertz/history 1 0 #Hertz without cohesion
pair_coeff * *

#define timestep
timestep 0.0000001

#define integration type
fix 1 all nve/sphere

#apply gravity
fix 2 all gravity 9.81 vector 0 0 -1

#####IMPORTING MESHES######
#define region of insertion and put granules in
#region defined to be between 2cm-10cm of the cylinder
region incyl cylinder z 0 0 0.009 0.02 0.1 units box
group nve_group region incyl
group atom_type1 type 1
group atom_type2 type 2

#insert tank radius 40cm, depth 15cm
fix cadtank atom_type2 mesh/gran tank.stl 2 1 0 0 0 0 0 0

#insert cylinder so it sits directly on tanke: radius 1cm depth 14cm
fix cadcyl atom_type2 mesh/gran 2cmcyl.stl 2 1 0 0 0 0 0 0

#make meshes granular walls DEM for geomechanical applications
fix granwall atom_type2 wall/gran/hertz/history 1 0 mesh/gran 2 cadtank cadcyl

#N is replaced with number of atoms. alter diam and dens as reqiored
#particles are 'poured' this means that they are expected to leave the region
#of insertion due to gravity
fix ins nve_group pour 10 1 1 region incyl diam uniform 0.001 0.001 dens uniform 8000 8000

#thermo settings
compute 1 all erotate/sphere
thermo_style custom step atoms ke c_1 vol
thermo 1000
thermo_modify lost ignore norm no

compute_modify thermo_temp dynamic yes

#insert the first particles so dump isn't empty
run 1

#create dump of particles, following 'atom' style of dump
dump dmpins1 all custom 1000 ins1.dump id type x y z vx vy vz omegax omegay omegaz
run 2000
unfix ins
undump dmpins1

#rotate the tank and allow the particles to enter solid body rotation
#1.0 is the period

fix movecadtank atom_type2 move/mesh/gran rotate 0 0 0 0 0 1 1.0 cadtank
fix rotcadcyl atom_type2 move/mesh/gran rotate 0 0 0 0 0 1 1.0 cadcyl

dump dmpsbr1 all custom 1000 sbr1.dump id type x y z vx vy vz omegax omegay omegaz
run 5000
undump dmpsbr1

#remove cylinder
unfix rotcadcyl
unfix cadcyl

#dump how particles fall. note there is no reason for the cylinder to keep moving past 20cm. note this in the run
dump dmpfall1 atom_type1 custom 1000 fall1.dump id type x y z vx vy vz omegax omegay omegaz
run 5000

ckloss's picture

ckloss | Thu, 12/15/2011 - 18:11

Hi Jay,

maybe you can have a look and debug in mech_param_gran.cpp by fprintf(screen,"BLAH") commands, thats where the error is thrown.

Cheers, Christoph

jwarnett | Wed, 01/11/2012 - 15:09

Hey Christoph

I found the problem with my script and thought I should let you know. It seems the christmas break and looking at it with a fresh set of eyes has helped!

In the above script, when unfix cadcyl is invoked, it had also been defined as a granular wall:
fix granwall atom_type2 wall/gran/hertz/history 1 0 mesh/gran 2 cadtank cadcyl

so since it was reffered to in another fix it caused an issue when unfixing it. Silly mistake really. In my script it is not really necessary to have that particular mesh as a granular wall so for me there is no harm in removing that mesh from the wall/gran fix. I can cope with just the tank being a gran/wall

But the fix wall/gran of type mesh/gran can only be called once and applied to multiple meshes, correct? So if I wanted two different gran/wall fixes, this would currently be impossible. As I said, not an issue for me, but i thought something you should note.

Jay

Philippe's picture

Philippe | Thu, 01/12/2012 - 09:24

Hello Jay,

you are right, there can only be one fix wall/gran at a time. However, unfixing it, removing the mesh and creating a new fix wall/gran can be used as a workaround for your issue.

unfix granwall
unfix rotcadcyl
unfix catcyl
fix granwall atom_type2 wall/gran/hertz/history 1 0 mesh/gran 1 cadtank

should do the trick.
please give it a try and tell us if this solves your issue.

regards
Philippe

jwarnett | Wed, 02/01/2012 - 14:45

been a while since ive been on the forums, but yes this is the way around I ended up going.

Thanks

Philippe