search

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
126 stars 50 forks source link

SCUFF-CAS3D gives slightly different results for transformations in --TransFile #93

Closed cyhng closed 7 years ago

cyhng commented 8 years ago

It is known that it is more efficiency for SCUFF-CAS3D to calculate several transformations at once because some of the resources can be shared among all transformations. However, results from single run multiple transformations do slighly differ from the results from separated runs. For individual calculation case, each run contains only one transformation and you have to do it multiple times.

Here is the test case : PEC cylinder embedded in a cylindrical cavity with PEC boundary

problem1

Geometry file

LATTICE
    VECTOR 0.2 0.0 
ENDLATTICE

OBJECT INTERIORSHELL
    MESHFILE cyl_0.5.msh
        MATERIAL PEC
ENDOBJECT

OBJECT EXTERIORSHELL
    MESHFILE cyl_1.msh
        MATERIAL PEC
ENDOBJECT

Transformation file

TRANSFORMATION 0.0

    OBJECT INTERIORSHELL
    DISPLACED 0 0 0.0

ENDTRANSFORMATION

TRANSFORMATION 0.1 

    OBJECT INTERIORSHELL
    DISPLACED 0 0 0.1

ENDTRANSFORMATION

TRANSFORMATION 0.2

    OBJECT INTERIORSHELL
    DISPLACED 0 0 0.2

ENDTRANSFORMATION

TRANSFORMATION 0.3

    OBJECT INTERIORSHELL
    DISPLACED 0 0 0.3

ENDTRANSFORMATION

TRANSFORMATION 0.4

    OBJECT INTERIORSHELL
    DISPLACED 0 0 0.4

ENDTRANSFORMATION

Here are the results (Force per unit length : hbar c / micron^4) result1

There is a 1% off from different methods to run the code. Is this expected or is it a minor bug?

Thanks in advance

HomerReid commented 8 years ago

Thanks for pointing this out. I am not 100% sure what is going on here, but it may have to do with slight differences in the computation of interpolation tables. I will keep this in mind as I make improvements to the code.

However, the errors are quite small and probably less than the meshing resolution and/or internal tolerances for things like Brillouin-zone integration and imaginary-frequency integration (both of which are set to 1% by default), so I don't consider this a major error for now.

It may be interesting to ask how the results vary with (a) mesh resolution, (b) error tolerances for numerical quadrature. Try running with command-line arguments --BZIRelTol 1.0e-3 --RelTol 1.0e-3.