Simulation with read_data slower than without it?

Submitted by carlesbp on Wed, 05/06/2015 - 17:32

Hi all,

I am running a rotating mill with 1 atom, velocities and positions are read from a read_data file. It runs and the behaviour of the atom is as expected, but the time it takes to finish the simulation is way too long, obtaining 0.23 seconds per iteration.

If I keep all the same settings but insert the particle with the insert/stream command, the time is much smaller, such as 0.005 seconds per iteration.

Is it due to LIGGGHTS checking the read_data file at every iteration? How can I avoid that, if it is the case, to only check the read_data file at the first time step, when all the particles are inserted? I need to read 10.000 particles and I am worried about the time needed according to what I obtained.
Thanks!!

Regards,

Carles

AttachmentSize
Binary Data input_and_data.tar_.gz157.74 KB

Forums:

RobertG | Wed, 05/06/2015 - 18:11

Hello Carles,
I worked with the read_data method for quite a time. Some time It is more handy than the restart command.
From my experience, it was not that problematic. I have had 1.2 million particles and there was no significant change in time.
Can you upload your code?

Best regards
RobertG

carlesbp | Wed, 05/06/2015 - 18:22

Hi Robert,

Thanks for your answer! I am attaching the input file and the data file.

Best regards,

Carles

RobertG | Thu, 05/07/2015 - 13:04

Hello Carles,
I have tried your program and got an error. My read_data command is incompatible with your format.

Could you insert the "write_data data.test" command directly after your read_data to generate an file, which I can use?

Best regards
RobertG

carlesbp | Mon, 05/11/2015 - 17:23

Hi Robert,

Sorry I was out on vacation all these days and thanks again for your help.

I suspect the error you obtained is due to the format, as I posted the previous comment and uploaded the files from a windows machine.
Now I am uploading them again from a Ubuntu machine, together with the write_data command, which I tested and works.

Best regards,

Carles

RobertG | Wed, 05/13/2015 - 14:18

It works pretty good with the
>>read_data data.position<<
command.

>>>Loop time of 0.00269294 on 1 procs for 1 steps with 1 atoms<<<
>>>Loop time of 1.14042 on 1 procs for 199 steps with 1 atoms<<<

Maybe it is the format which causes the delay.

Best regards
RobertG

carlesbp | Wed, 05/13/2015 - 15:20

Hi Robert,

Many thanks for checking this.

What do you mean when you say the format? Do you see any possible improvements?

Thanks

RobertG | Thu, 05/14/2015 - 21:28

Hello carles,
try to replace your >>read_data positions_granular22.csv<< command with the >>read_data data.position<< command.

That's the only suggestion I can make ...

Loading the data works for me.
If you have problems, it may be caused from your liggghts compilation ...

Best regards
RobertG

carlesbp | Fri, 05/29/2015 - 11:50

Hi, I am getting a really strange behaviour in my mill:

All the particles start in the correct position but when the mill starts rotating, only the particles between the teeth move and the rest of them stay completely static. They do not even move down to the empty spaces between the teeth. I end up having a disk of particles in the middle of the mill that does not move.

Any suggestions about the cause of that?

Thanks

JoshuaP | Fri, 05/29/2015 - 12:00

what integration do you use? nve/sphere? Do you integrate all particles? or do you define a group? If so try to integrate all
fix myID all nve/sphere
What size do you use for neigh bin size? And your timestep?
regards

carlesbp | Mon, 06/08/2015 - 12:00

Hi Joshua! thanks for your help!

I use nve/sphere over all particles. My neigh bin size is 0.002 bin with neigh_modify delay 0. Timestep is 0.0001.

I will try to change the bin size and see what happens, thanks!

Carles