failed unit tests

[amrit-poudel]

Hello,

I configured scuff-em with the following options:

./configure --prefix=/home/api852/HPC_LIB/INTEL/SCUFFEM_MPI --with-hdf5=/home/api852/HPC_LIB/HDF5_MPI --with-blas=/opt/intel/composer_xe_2013.2.146/mkl/lib/intel64/libmkl_rt.so --with-lapack=/opt/intel/composer_xe_2013.2.146/mkl/lib/intel64/libmkl_rt.so "CXX=mpic++" --without-python

Several unit tests failed during make check.

make[2]: Entering directory `/home/api852/HPC_SOURCE/scuff-em/unitTests' error: could not open reference file unit-test-BEMMatrix.reference.hdf5 (aborting) FAIL: unit-test-BEMMatrix **warning: common-vertex, short imaginary wavelength: H[1]: ((+7.29796535e-05,+3.99291723e-05),(+7.29796957e-05,+3.99291829e-05))

/bin/sh: line 5: 9991 Aborted (core dumped) ${dir}$tst FAIL: unit-test-PPIs 57/86 tests successfully passed.

FAIL: unit-test-PFT

3 of 3 tests failed

I could not attach scuff-unit-tests.log file here, but I can send it to you if needed.

I will appreciate any help.

Thank you.

[HomerReid]

This is a symptom of the incomplete status of #22 and #21. The fact that the tests are failing does not mean that the code doesn't work or was incorrectly compiled on your machine, but rather that the testing infrastructure is incomplete and in fact rather unhelpful at this point. Any effort you might be willing to make toward improving this would be much appreciated.

[amrit-poudel]

Thanks for that note. This is a very useful/powerful library and if I find some time I will certainly make an effort in that direction. However, at this point, I will use this library to compare results with other FDTD methods (for surface plasmon calculations). Is there a separate forum to ask questions related to running scuff-em simulations? Some very basis questions I wanted to ask were: Are all the units in MKS in scuff-em? In C++ scuff-em library, is there a way to output total field (scattered+incident) in an hdf5 file within a user-defined volume, just like in MEEP?

[amrit-poudel]

While I have figured out other answers, I am still confused about the units in scuffem. Does .scuffgeo file expect \omega in SI units? I read on the manual that the angular frequency \omega should be given in the units of c/a, where a = characteristic length of the system. Also, will scuffem automatically run in a 2D mode if the .msh file is for a 2D geometry? Thanks for any help.

[HomerReid]

Here is some API code to output fields in HDF5 format. This code snippet assumes that the scattering problem has already been solved with IF pointing to the incident-field structure and KN pointing to the solution vector of surface-current coefficients.

HMatrix *XMatrix=new HMatrix("EPFile"); 
HMatrix *FMatrix=GetFields(IF, KN, Omega, XMatrix);
FMatrix->ExportToHDF5("Fields.HDF5","F");

Here EPFile should be a simple text file containing the x,y,z coordinates of the evaluation points, i.e. for evaluation points on the z-axis its content would read

0.0 0.0 0.0
0.0 0.0 0.1
...
0.0 0.0 1.0

After the above snippet has run, you will have a binary HDF5 file named Fields.HDF5 containing a dataset F in the form of an N x 6 matrix (where N is the number of evaluation points in your EPFile). The 6 columns for each row are the electric and magnetic field components (Ex, Ey, Ez, Hx, Hy, Hz) at the evaluation point corresponding to that row.

You can modify the above snippet to output only incident fields, or only scattered fields, by replacing the KN or IF arguments to GetFields with NULL pointers.

Regarding the units of angular frequency, the --omega argument to scuff-scatter should be specified in units of 3e14 rad/sec (=c/1 micron), i.e. saying --omega 3.0 will give you a simulation at 9e14 rads/sec. The reason for this choice is that typically one wants to run at photon wavelengths comparable to the dimensions of the system under study, and it's typically more convenient to think in terms of these units when specifying frequencies at which to run simulations.

On the other hand, for frequency-dependent material designations, the w variable is always interpreted in units of rad /sec (NOT 3e14 rad/sec). The reason for this is that frequency-dependent dielectric functions in standard reference tables are typically reported in these units, and it would be inconvenient to have to translate the units for use in SCUFF-EM.

Feel free to continue the discussion here, or close the issue if satisfied.

[amrit-poudel]

Thanks a lot for this detailed information. I have figured out the hdf5 part.

As for the units, I am using scuff-em as a C++ library, so in my C++ file, should I be using SI units of angular frequency? Suppose I have a cubical geometry with L=10 nm dimension and incident wavelength is around \lambda =100 nm. I create a .geo file of a cube with L=10. If I use SI units for angular frequency \omega = 2_pi_c/100e-9 rad/sec, how do I set the dimension of the length in C++ file? In MEEP, this is done by considering a characteristic length scale "a", so SI units L = 10 nm becomes dimensionless 10 in MEEP, if a = 1nm. This characteristic length scale is also used to scale the frequency, that is, f_meep = f_SI*c/a, c = 3e8 m/s. f_meep is dimensionless.

However, what I gather from above is that, in C++ scuff-em, f_scuffem = f_SI.

Are the units of the output fields Ex, Ey, Ez in Volts/meter or Volts/nanometer in this example?

Thank you very much for your help.

[HomerReid]

Short answer: The easiest way to think about this is that SCUFF-SCATTER uses fixed units of 1 microns for length and 3e14 rad/sec for angular frequency. Thus, to simulate a 10 nm cube at a frequency corresponding to a free-space wavelength of 100 nm, you would write the .geo file to describe a cube with dimension L=0.01 and run SCUFF calculations with --omega 62.8.

Longer answer: There is actually no intrinsic length scale in SCUFF-EM. If you have a PEC cube described by a .geo file with dimensions L=0.01 and you run calculations with --omega 62.8, then your calculation can be interpreted in any of the following ways:

• A 10-nm cube at wavelength 100 nm.
• A 1-micron cube at wavelength 10 microns.
• A 1-millimeter cube at wavelength 10 millimeters.

Equivalently (again assuming a PEC cube), you could write the .geo file to have dimensions L=1 and run with --omega 0.628, and your results will be equivalent to all of the above. Thus, there is no intrinsic length scale in SCUFF-EM, and calculations are invariant under uniform simultaneous scaling of both object dimensions and simulation wavelengths.

However, in problems involving materials with frequency-dependent dielectric functions, then there is an intrinsic length scale, set by the frequency dependence of the permittivity. Thus, the above discussion holds true for a PEC cube or for a dielectric cube with frequency-independent permittivity (such as CONST_EPS_10), but does not hold true for materials like GOLD or SIO2 which have frequency-dependent dielectric functions. In this case, scaling up both the length and the wavelength will not yield invariant results, because it will change the effective permittivity of the object at the frequency in question.

Thus, when working with frequency-dependent dielectric functions, the easiest protocol (as stated above) is to assume that length units are microns and frequency units are 3e14 rad/sec.

Alternatively, in API codes, the default length scale on which material properties are evaluated may be changed using the API function MatProp::SetLengthUnit. For example, the RWGGeometry constructor issues the following call to establish the default length units of 1 micron:

MatProp::SetLengthUnit(1.0e-6);

but you can override this in your own API codes if you know what you are doing.

Regarding the units of output fields: Since SCUFF-EM handles only linear materials, the output fields are proportional to the overall scaling magnitude of the input fields. Thus, suppose you run a SCUFF-SCATTER calculation with an x-polarized plane-wave incident field described by the command-line option

--pwPolarization  1 0 0 

and suppose the reported value of the scattered E-field in the x direction reads 0.13. This means the following:

• If your structure is illuminated with a plane wave with E-field amplitude 1 volt/meter, then the scattered field will have amplitude 0.13 volts/meter.
• If your structure is illuminated with a plane wave with E-field amplitude 1 volt/nanometer, then the scattered field will have amplitude 0.13 volts/nanometer.

Similarly, all power, force, and torque (PFT) data reported by SCUFF-SCATTER are proportional to the square of the incident-field units. The units reported for these quantities in the SCUFF-SCATTER output files (which are: watts for power, nanoNewtons for force, nanoNewtons x microns for torque) are computed assuming the incident-field amplitude was specified in units of volts/microns. If you actually intended your incident field to be specified in units of volts/nanometers (i.e 1e3 times larger than the assumed volts/microns), then you would simply reinterpret the PFT data as giving results in units that are 1e6 times larger than the default: megawatts for power, milliNewtons for force, and milliNewtons x microns for torque.

[amrit-poudel]

Thank you for this info.

I will modify the source code in the following way and recompile the library.

RWGGeometry::RWGGeometry(const char *pGeoFileName, int pLogLevel, double length) {

MatProp::SetLengthUnit(length);

.........

}

Also the declaration of RWGGeometry object in the header file libscuff.h.

/* constructor / RWGGeometry(const char *GeoFileName, int pLogLevel = SCUFF_NOLOGGING, double length=1.0e-6);

I assume I do not have to set the frequency unit.

Are there any other places in the software, other than the ones above, where the characteristic length scale is hard coded?