Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Failed to build the program in eclipse #9

Open
ZombieWonder opened this issue Jun 26, 2019 · 12 comments
Open

Failed to build the program in eclipse #9

ZombieWonder opened this issue Jun 26, 2019 · 12 comments

Comments

@ZombieWonder
Copy link

Hello Dr. Baranov,

I am a PhD student with almost zero programming background.
A small portion of my manuscript requires me to do a packing density analysis of bimodal distributed spherical particles which led me to your program.

After following the steps for windows system and open the "packing-generation-1.0.1.28" folder as a project in eclipse, I clicked the build button but to find the build process was terminated with the following message:

"make all
"make all" terminated with exit code -1073741515. Build might be incomplete."

May I ask for your help in getting me through the initialization of the program?

Thanks!

Dixiong Wang
@VasiliBaranov
Copy link
Owner

Hi Mr. Dixiong,

could you provide more information please? Can you attach the entire log (if there was more to it)? Maybe you can try to build directly from terminal/command line (go to the _Release folder and run "make" there) and see what the output is? Thanks! Which system are you using, by the way (Windows/Linux)?

Best Regards,
Vasili

@ZombieWonder
Copy link
Author

ZombieWonder commented Jun 28, 2019 via email

@VasiliBaranov
Copy link
Owner

Hi Dixiong,

sorry, i don't see the image with the log. i only see the text "[image: image.png]", so i can't really tell where the problem lies. The compilation log looks fine, as far as i can see. One thing is, if you compile a program under Cygwin, you shall run it from the Cygwin command prompt/terminal, as far as i remember (Cygwin emulates Linux on Windows, so Cygwin program is not a valid native Windows program).

I'm not sure if you copied sample files from the Doc folder to the folder where your exe file is located. If not, you can try to do this as well.

As far as you are on Windows, you could also compile the program directly with Visual Studio to create a native Windows program (you need to open PackingGeneration.sln with Visual Studio). You can actually download a compiled executable for Windows here: https://github.com/VasiliBaranov/packing-generation/releases . Maybe you can try to run the executable that i provide for Windows and see if it works as expected (i didn't put any viruses there :-) ). You can run it in a virtual machine if you are afraid of malware.

Hope this helps.

Best Regards,
Vasili

@ZombieWonder
Copy link
Author

ZombieWonder commented Jul 1, 2019 via email

@VasiliBaranov
Copy link
Owner

Hi Dixiong,

if it's a complete output, that's a little strange indeed.

You can try to delete the file packing.nfo before running the program and see if it's created. Packing.xyzd shall be updated.

If this doesn't happen, please try to run the .exe from the latest release (outside cygwin, just in a normal windows cmd) and see if it works. If not, i'm not quite sure where the problem is.

Best,
Vasili

@ZombieWonder
Copy link
Author

ZombieWonder commented Jul 12, 2019 via email

@VasiliBaranov
Copy link
Owner

Hi Dixiong,

great that it works. The speed of packing generation depends on the compression rate that is specified in the config file generation.conf and the algorithm itself. By default, the Lubachevsky-Stillinger algorithm is used. The compression rate is relatively low in the sample config file, 1e-5. You can make it higher, 1e-3 or 1e-2. Maybe even 1e-1. Please see the final paragraph here for the details on the numbers: https://github.com/VasiliBaranov/packing-generation#14-note-on-final-diameters .

Please also note that the algorithm compresses the packings. It is inherently a non-equilibrium process. Equilibration of generated packings is a totally different task. Actually, when a packing is generated beyond a certain density, it is believed that it can never be equilibrated (equilibration time diverges for packings at this density, but you can easily generate packings with much higher densities). To equilibrate a packing, please use the option -md (number 6 from https://github.com/VasiliBaranov/packing-generation#3-post-processing ). To really track if equilibration is finished, you need to look at the asymptotic alpha-relaxation time of the intermediate scattering function. See these papers for example: https://journals.aps.org/prl/abstract/10.1103/PhysRevLett.102.085703 , https://journals.aps.org/rmp/abstract/10.1103/RevModPhys.82.789 , and https://journals.aps.org/pre/abstract/10.1103/PhysRevE.83.060501 . But if you just need to create some packings at some density, it all doesn't matter for you.

Hope this helps.

Best Regards,
Vasili

@ZombieWonder
Copy link
Author

ZombieWonder commented Jul 17, 2019 via email

@ZombieWonder
Copy link
Author

ZombieWonder commented Jul 24, 2019 via email

@VasiliBaranov
Copy link
Owner

Hi Dixiong,

  1. What will the program do when I double-click the .exe file? Do I still
    have to rescale the output and run -md in cygwin?

If you double-click, the OS executes the program without input parameters and without storing the output anywhere. I wrote the program in such a way that no parameters is equivalent to running it with the -ls parameter.

  1. Why the final porosity I got from double-clicking the .exe file and
    execute .exe file from cygwin are different (0.3535 vs 0.3936)?

For such a high compression rate different program runs will produce quite different final densities, because initial particle velocities are initialized randomly. You can refer to Fig. 2a, 2c here: https://pubs.rsc.org/en/content/articlehtml/2014/sm/c3sm52959b

  1. If, as you suggested, I need to decide whether the system is
    equilibrated or not: According to Parisi et al. (
    https://journals.aps.org/rmp/pdf/10.1103/RevModPhys.82.789), a system is
    considered equilibrium when the relaxation time becomes the order of the
    compression rate (1.3 x 10^-2). Is this relaxation time is recorded in
    scattering function value in scatteringFunctionData.txt (also attached)?

Actually, maybe it's really not what you need to do :-) Maybe we use different definitions of "relaxation". When this paper and others that i referred to talk about "relaxation/equilibration", they mean relaxation of a "gas" of flying hard particles and that this "gas" shall become more "uniform". But if you don't care about what happens when you let particles fly and behave like a gas/fluid/colloid, these papers maybe are really not relevant to you.

Because there is another meaning of "relaxation/equilibration". The FBA algorithm imagines that hard particles have soft elastic shells and tries to move the particles according to forces induced by these soft elastic shells. One can say that forces in the packing and the packing itself is equilibrated/relaxed (but this "forces" relaxation is an entirely different from the "gas" relaxation).

If you just need to create a very dense packing, just run the LS or FBA algorithm with a very low compression rate. Again, please refer to Fig. 2a and 2c in https://pubs.rsc.org/en/content/articlehtml/2014/sm/c3sm52959b . For the LS algorithm, rate 1e-4 or 1e-5 is quite low (and generation may take a couple of days). The resulting packing will be also very close to being mechanically stable (even if particles are frictionless). Again, you can refer to https://pubs.rsc.org/en/content/articlehtml/2014/sm/c3sm52959b as a starting paper, for example.

  1. If I now would like to use my own particle distribution as the input,
    how would you suggest I change the box dimensions? (I also attached the
    size distribution file as "diameters.txt".)

I think you don't need to change box dimensions. As the readme says, at the beginning of the generation particles are originally rescaled so that the closest pair of particles just touches. So even if you multiply all diameters by 10, the generation will proceed in exactly the same way.

Hope this helps!

Best,
Vasili

@ZombieWonder
Copy link
Author

ZombieWonder commented Aug 7, 2019 via email

@VasiliBaranov
Copy link
Owner

Hi Dixiong,

the warnings happen because the current implementation of the LS algorithm uses a heuristics (to improve speed) to search for close enough neighbors of particles and for very loose packings this heuristics breaks (and for some particles not all relevant neighbors are found). Please see point 1 here: https://github.com/VasiliBaranov/packing-generation#22-program-usage-and-options-for-generation You need to generate a very loose packing (density 0.4-0.6) with the FBA algorithm at first.

If you really need the densest packing, i think the option -ls with a very low rate will be better. -lsgd will produce the loosest of mechanically stable frictionless packings (the RCP limit), 0.64 for monodisperse packings. -ls will produce the "densest" of mechanically stable frictionless packings (denser than the RCP limit, closer to the Glass Close Packing limit). For monodisperse packings crystallization will start playing role, and almost crystalline packings will be produced, at density ~0.72. Please see Figure 2a and 2c in the paper i mentioned, https://pubs.rsc.org/en/content/articlehtml/2014/sm/c3sm52959b . You can also just run the FBA algorithm with a very low compression rate as an alternative.

Best,
Vasili

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@VasiliBaranov @ZombieWonder