Request for "balance.h" and "balance.cpp"

Submitted by dianwa on Mon, 02/18/2013 - 18:19

Hi,

Although our great author told us that the "balance" command would not work with some LIGGGHTS features, I still want to have a try to check whether it works in my case.

While now I can not download previous version and can not find those files. So could anyone send them to me if convenient?

Thank you very much!!

My E-mail is li900@purdue.edu

Best

Liang

Forums:

ckloss's picture

ckloss | Mon, 02/18/2013 - 23:49

Hi Liang,

you can merge with balance.h/cpp manually from LAMMPS, 20 April 2011 version
just checkout LAMMPS from the git repo, reset to 20 April 2011 version and copy the files

Be sure not to use mesh walls - in this case LIGGGHTS will crash or behave unexpectedly without warning or error

Cheers,
Christoph

dianwa | Tue, 02/19/2013 - 16:10

WOW.....
Indeed, I have to use mesh walls. The simulation effective region is changing, the command "deform" is helpful, although it is not perfect and at risk, I think. While it is forbidden to use both "mesh wall" and "deform".

Now for a simulation region, if we use 2*2*1 partition system, we can get result even faster than 2*2*2.
For example, if we simulated 0.5 second, 2*2*2 would take 408 second, while if we simulated 1.0 second fully, the time would be 1437 seconds.

Do you have any suggestion about making advantage of parallel computing in LIGGGHTS, thank you very much!!

I am a student, who is major in visualization

xavier.tricoche | Tue, 02/19/2013 - 19:24

If I may just chime in... (Liang is my student)

We want to use LIGGGHTS to study large-scale granular tapping problems on parallel architectures. In this context, the spatial distribution of the particles can change dramatically over time and barring some form of dynamic load balancing, the scalability is poor. I am sure that you are most familiar with this problem.

Hence our interest in whatever is already implemented in LIGGGHTS (foolproof, working, or plain buggy) to support load balancing. In particular, we would very much like to understand what technical reasons lead to erratic behavior of the code if balance is used in combination with mesh walls (since our oscillating floor is a mesh wall) and whether it would be worthwhile for us to try and fix the problem, at least for the class of problems that we investigate.

Alternatively, it would be good to know if there exists a "balance-friendly" alternative to moving meshes that we could use instead to model the floor. Going back to an exchange that we had a while ago, I seem to remember that moving mesh was the only way to represent a boundary with user defined motion.

Either way, we would be most thankful for any insight you can provide and we are certainly open to contributing time and code to existing balancing efforts in LIGGGHTS.

Thanks

ckloss's picture

ckloss | Mon, 02/25/2013 - 14:50

Hi Xavier,

dynamic load balancing for LIGGGHTS is developed and pretty mature but at this point we're sharing it with our collaboration partners.

We'll soon post details on our release schedule to clarify this.

>>Going back to an exchange that we had a while ago, I seem to remember that moving mesh was the
>>only way to represent a boundary with user defined motion.
Another possibility would be to implement a primitive boundary and according movement.

Cheers
Christoph

jw851602 | Tue, 12/03/2013 - 10:17

Hi Christoph,

are there any news when the "fix balance" command as shown in your benchmarks will be available in LIGGGHTS? And are there any possibilities to test it in advance?

Regards,
Jan