General HELP!

[marzKup]

Hi, I am studying the Casimir Effect for my undergraduate senior thesis and I am trying to get your program to work (I am a complete noob when it comes to Linux).

I have downloaded scuff-em (correctly I think) based off the instructions on this page http://homerreid.github.io/scuff-em-documentation/reference/Installing/

I have tried running the program for some of the examples that were downloaded using a bin bash file based off the instructions from this page http://homerreid.github.io/scuff-em-documentation/examples/SiliconSlabs/SiliconSlabs/

I think it may be working, but it took over 72 hours of run time and the program was still running so I aborted it. I also tried running it directly from the command line using scuff-cas2d and then tried with Casimir2D and their 3D counterparts.

I am just looking for some more guidance on actually running and using the program because I am not sure if/what I am missing to cause the run time to be so long or if I am executing it improperly. I apologize for the vagueness of this issue.

Thank you!

[HomerReid]

If the problem is that the program is taking too long to run, it could be that you didn't compile with multithreading support. You can look through the .log files for statements such as "OpenMP multithreading (8 threads)", and if you don't see them then you probably want to recompile with multithreading support. This may require you to add some packages to your system, such as (for example) libopenmpi-dev.

Otherwise, look through the .log file to see which procedures are taking the longest amount of time, and let me know if anything stands out.

[jfeist]

@marzKup: Are you actually sure that it is running? I.e., is it producing some logging output in, e.g., scuff-cas3d.log or on the command line? Does a process monitor (such as top on the command line) show the program running and using the CPU(s)? If yes, another possibility could be that you have the reference BLAS/LAPACK libraries installed, instead of more optimized ones. That can produce changes of orders of magnitude in the runtime. Depending on the operating system, you might need to install libopenblas-dev or something like that.

BTW, @HomerReid, just an idea: I think it would be great to have a reference docker image that comes with scuff, gmsh and all dependencies etc installed, which could then be used without having to worry about installing all the necessary dependencies, configuring, or compiling. Unfortunately, I don't know enough about Docker to do it, but if I ever have time, I might take a look. Since the travis-ci integration is already working, I imagine that a similar script could provide a good starting point.

[marzKup]

It is actually running, but I do not see any statements of "OpenMP multithreading (8 threads)". I tried downloading those packages but none of them were recognized and wouldn't download. I also tried downloading openmpi (suggested by a peer).

The thing that is taking longest to run is "Computing ZForce...".

[marzKup]

Also "Assembling BEM matrix block" takes a while to run

[HomerReid]

@marzKup: It sounds like you don't have multithreading enabled, so the code will work but will not be as fast as you would like. Rectifying this should be a matter of installing g++ and libgomp (or the Intel equivalents if you are using the Intel compilers) and should be the kind of thing that you can get help on from local open-source-software experts at your site. If you get stuck, I can take a look at your system description and try to help out.

@jfeist: This is the first I've heard of Docker, and it sounds like a good idea! If it works as well as the Docker blurbs suggest, it would eliminate a lot of barriers to entry for people who aren't experts in linux software installation. It even looks like the Docker bundle can be used on Windows. I will look into this further---thanks for the suggestion.

[marzKup]

@HomerReid What will be the approximate run time on the program after installing g++ and libgomp? Also I still see no reference of the OpenMP multithreading in the log file.

[HomerReid]

I can't give you a runtime estimate because that is too machine-dependent. But if you are still not seeing any reference to OpenMP multithreading in the log files then your configuration process probably didn't succeed in figuring out where to find the OpenMP libraries and headers on your system. The way to assess this is to look in config.log file for the section relating to OpenMP, or to look in config.h to see if USE_OPENMP is defined.

Another way to check is to run a SCUFF-EM code and use the top command from another window. When the code is doing something CPU-intensive like assembling or factorizing the BEM matrix, top should report close to 800% CPU usage (for a system with 8 CPU cores.) If you instead see something closer to 100%, you probably don't have multithreading enabled.