HomerReid / scuff-em

A comprehensive and full-featured computational physics suite for boundary-element analysis of electromagnetic scattering, fluctuation-induced phenomena (Casimir forces and radiative heat transfer), nanophotonics, RF device engineering, electrostatics, and more. Includes a core library with C++ and python APIs as well as many command-line applications.
http://www.homerreid.com/scuff-em
GNU General Public License v2.0
128 stars 51 forks source link

scuff-caspol segmentation fault when running examples/NanostructureCasimirPolder #220

Closed congzlwag closed 4 years ago

congzlwag commented 4 years ago

After successfully building and installing the package, I tried the example NanostructureCasimirPolder, following the docs, and the potential are evaluated to be 0 everywhere. I realized the main reason was incorrect polarizability, from the file NanoBeam_1006.byXi, which reads `# data columns:

1: X (um)

2: Y (um)

3: Z (um)

4: Xi (imaginary frequency) (3e14 rad/sec)

5: polarizability of Rubidium (a_0^3)

6: CP potential per unit frequency for Rubidium (neV / (3e14 rad/sec))

1.835000e-01 4.225000e-01 -5.000000e-01 1.000000e+00 0.000000e+00 0.000000e+00 1.835000e-01 4.225000e-01 -4.800000e-01 1.000000e+00 0.000000e+00 0.000000e+00 ` in the first two rows.

Thus I traced back to applications/scuff-caspol/PolModel.cc and fixed this polarizability issue by adding an initialization assignment for MP in line269 of applications/scuff-caspol/PolModel.cc. Although I can verify the program now are using the correct polarizability values, after evaluating at several Xi points, it pops out a segmentation fault error, as shown below

Screen Shot 2020-04-09 at 07 54 47

I would like to know how I can fix this. I am running the package on Mac OS X 10.15.4 and the package is built with gcc-9 and openblas.

The log file is attached scuff-caspol.log

congzlwag commented 4 years ago

My revision for the correct polarizability is #221 , with which there is still the segmentation fault on MacOS X. The same revised version has been built with gcc-7 and lapack on an Ubuntu 18.04, and there is another error stack smashing detected at the same point after evaluating GetXiIntegrand at Xi=1.030869e+2 . The log file is also attached. scuff-caspol.log

texnokrates commented 4 years ago

I am running the package on Mac OS X 10.15.4 and the package is built with gcc-9 and openblas.

My condolences, but at the same time, congratulations for getting stuff working on Mac.

Apples aside, let's look at the problem. "Segmentation fault" usually comes from some memory mismanagement, "stack smashing error" is a bit more specific, telling that one probably writes to a place on the stack for which one hasn't allocated memory.

Well, the reason for stack smashing in this case is rather obvious when one looks where it happens using gdb (this is your patched version of the code).

necadam1@chadwick:~/repo/scuff-em/examples/NanostructureCasimirPolder$ gdb scuff-caspol
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from scuff-caspol...done.
(gdb) set args --geometry NanoBeam_1006.scuffgeo --EPFile EPFile --Atom Rb
(gdb) r
Starting program: /m/home/home4/46/necadam1/unix/.local/bin/scuff-caspol --geometry NanoBeam_1006.scuffgeo --EPFile EPFile --Atom Rb
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff1d7b700 (LWP 58250)]
[New Thread 0x7fffef57a700 (LWP 58251)]
[New Thread 0x7fffecd79700 (LWP 58252)]
@Xi=1.000000e+00, Alphas[0][0,0] = 3.138374e+02
[New Thread 0x7ffff7ff6700 (LWP 58253)]
[New Thread 0x7fffdbde3740 (LWP 58254)]
[New Thread 0x7fffdb9e2780 (LWP 58255)]
[New Thread 0x7fffdb5e17c0 (LWP 58256)]
@Xi=1.000000e-06, Alphas[0][0,0] = 3.186000e+02
^[[A^[[A^[[A@Xi=5.828427e+00, Alphas[0][0,0] = 2.115060e+02
@Xi=1.715729e-01, Alphas[0][0,0] = 3.184042e+02
@Xi=2.527414e+01, Alphas[0][0,0] = 3.686294e+01
@Xi=3.956613e-02, Alphas[0][0,0] = 3.185548e+02
@Xi=2.239829e+00, Alphas[0][0,0] = 2.961176e+02
@Xi=4.464627e-01, Alphas[0][0,0] = 3.176444e+02
@Xi=1.030869e+02, Alphas[0][0,0] = 6.933850e+00
*** stack smashing detected ***: /m/home/home4/46/necadam1/unix/.local/bin/scuff-caspol terminated
*** stack smashing detected ***: /m/home/home4/46/necadam1/unix/.local/bin/scuff-caspol terminated

Thread 8 "scuff-caspol" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffdb5e17c0 (LWP 58256)]
0x00007ffff63ed428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54      ../sysdeps/unix/sysv/linux/raise.c: Tiedostoa tai hakemistoa ei ole.
(gdb) bt
#0  0x00007ffff63ed428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007ffff63ef02a in __GI_abort () at abort.c:89
#2  0x00007ffff642f7ea in __libc_message (do_abort=do_abort@entry=1, fmt=fmt@entry=0x7ffff654749f "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:175
#3  0x00007ffff64d115c in __GI___fortify_fail (msg=<optimized out>, msg@entry=0x7ffff6547481 "stack smashing detected") at fortify_fail.c:37
#4  0x00007ffff64d1100 in __stack_chk_fail () at stack_chk_fail.c:28
#5  0x00007ffff6d6bebb in scuff::GFullTwiddle1D (kx=kx@entry=25.680593898554164, Rho=<optimized out>, k=..., dGdRho=0x7fffdb5dfee0) at GBarVDEwald.cc:351
#6  0x00007ffff6d6bffb in scuff::GetGLongTwiddle1D (kx=kx@entry=25.680593898554164, Rho=Rho@entry=0.98482266124242301, k=..., E=E@entry=5.1543434459908681, dGdRho=dGdRho@entry=0x7fffdb5dfee0, Singular=@0x7fffdb5dffdf: false) at GBarVDEwald.cc:366
#7  0x00007ffff6d6c49f in scuff::AddGLong1D (R=R@entry=0x7fffdb5e05e0, Rho=Rho@entry=0.98482266124242301, k=..., P=P@entry=0x7fffdb5e0100, m=m@entry=-1, Gamma=Gamma@entry=0x7fffdb5e0120, E=E@entry=5.1543434459908681,
    GBarVD=GBarVD@entry=0x7fffdb5e01f0, Singular=@0x7fffdb5dffdf: false) at GBarVDEwald.cc:445
#8  0x00007ffff6d6ceed in scuff::GetGBarDistant (R=R@entry=0x7fffdb5e05e0, Rho=<optimized out>, k=..., kBloch=kBloch@entry=0x7fffdb5e0100, Gamma=Gamma@entry=0x7fffdb5e0120, LDim=LDim@entry=1, E=E@entry=5.1543434459908681, pnCells=pnCells@entry=0x0,
    Sum=Sum@entry=0x7fffdb5e01f0) at GBarVDEwald.cc:481
#9  0x00007ffff6d6f42b in scuff::GBarVDEwald (R=R@entry=0x7fffdb5e05e0, k=..., kBloch0=kBloch0@entry=0x7fffffffbd50, LBV=LBV@entry=0xb6f590, LDim=LDim@entry=1, E=5.1543434459908681, E@entry=-1, ExcludeInnerCells=ExcludeInnerCells@entry=false,
    GBarVD=GBarVD@entry=0x7fffdb5e03b0) at GBarVDEwald.cc:967
#10 0x00007ffff6d67e8f in scuff::GetGBarFullEwald (R=0x7fffdb5e05e0, GBA=0xb6f570, dGBar=0x7fffdb5e0670, ddGBar=0x0) at GBarAccelerator.cc:622
#11 0x00007ffff6d69bad in scuff::GetGBar (R=R@entry=0x7fffdb5e05e0, GBA=<optimized out>, dGBar=dGBar@entry=0x7fffdb5e0670, ddGBar=ddGBar@entry=0x0, ForceFullEwald=ForceFullEwald@entry=false) at GBarAccelerator.cc:1000
#12 0x00007ffff6d74ccc in scuff::RFIntegrand (X=X@entry=0x7fffdb5e0800, b=b@entry=0x7fffdb5e07e0, Divb=29.695589916425504, UserData=UserData@entry=0x7fffdb5e09b0, W=0.0006034766443945975, Integral=Integral@entry=0x7fffdb5e0a10) at GetFields.cc:103
#13 0x00007ffff6d85fd5 in scuff::GetBFCubature2 (G=G@entry=0x61e310, ns=<optimized out>, ne=<optimized out>, Integrand=Integrand@entry=0x7ffff6d74c10 <scuff::RFIntegrand(double*, double*, double, void*, double, double*)>,
    UserData=UserData@entry=0x7fffdb5e09b0, IDim=IDim@entry=12, Order=7, Integral=0x7fffdb5e0a10, PanelOnly=-1) at PanelCubature.cc:782
#14 0x00007ffff6d75afc in scuff::RWGGeometry::GetRFMatrix () at GetFields.cc:297
#15 0x00007ffff4dba453 in __kmp_invoke_microtask () from /u/46/necadam1/unix/.local/lib/libomp.so
#16 0x00007ffff4d67214 in __kmp_invoke_task_func () from /u/46/necadam1/unix/.local/lib/libomp.so
#17 0x00007ffff4d65ab3 in __kmp_launch_thread () from /u/46/necadam1/unix/.local/lib/libomp.so
#18 0x00007ffff4d8537a in __kmp_launch_worker(void*) () from /u/46/necadam1/unix/.local/lib/libomp.so
#19 0x00007ffff21c66ba in start_thread (arg=0x7fffdb5e17c0) at pthread_create.c:333
#20 0x00007ffff64bf41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
(gdb) frame 5

So it's this function

#5  0x00007ffff6d6bebb in scuff::GFullTwiddle1D (kx=kx@entry=25.680593898554164, Rho=<optimized out>, k=..., dGdRho=0x7fffdb5dfee0) at GBarVDEwald.cc:351

Let's look at its source:

/*****************************************************/
/* Compute the 1D Fourier transform of GFull (the    */
/* full Helmholtz Green's function).                 */
/*****************************************************/
cdouble GFullTwiddle1D(double kx, double Rho, cdouble k,
                       cdouble *dGdRho=0)
{
  cdouble kt2 = kx*kx - k*k;
  cdouble kt = sqrt(kt2);
  cdouble K[2];
  AmosBessel('K',kt*Rho,0.0,3,false,K,0);
  double Denom = 4.0*M_PI*M_PI;

  if (dGdRho)
   { dGdRho[0] = -kt*K[1] / Denom;
     dGdRho[1] = kt2*(K[0] + K[2])/(2.0*Denom);
  };

  return K[0] / Denom;
}

The reason is rather obvious, you can try to find it. Anyway, a I made a pull request #222 with a patch, which includes your fix for the initialisation as well.

There is a problem that no pull requests have been merged into upstream for quite a long time, some of them fixing rather critical bugs. So until @HomerReid awakens and includes them to upstream, I recommend using my fork, where I try to include all the bugfixes I know about: https://github.com/texnokrates/scuff-em This one will be included as well as soon as I see it's really working, (the example just takes some time to run).

congzlwag commented 4 years ago

My condolences, but at the same time, congratulations for getting stuff working on Mac.

Thanks, indeed it's not easy with a Mac.

I have verified your patch. It has perfectly solved the issue, although that specific example takes an unusually long time. I doubt whether the equivalent surface detection has been carried out. That example looks to have the symmetry that allows simplification by equivalent surface detection, but it makes no difference when I set up SCUFF_MATRIX_2018=1 as an environment variable. What would you suggest about utilizing equivalent surface detection?

Also thanks for recommending your fork and your perseverance. I started using your fork to save repeating patches.