demisjohn / camfr Goto Github PK

From @demisjohn on February 28, 2018 8:17

Current implementation requires the user to build/install many MacPorts packages. For example, boost-python-mt.dylib must be found at /opt/local/lib/libboost_python-mt.dylibin order for python to load_camfr.so` properly.

Would prefer to statically link these libraries, so that _camfr.so contains the required libs, allowing for a MacOS "installer" to simply put the camfr/ module folder into the system site-packages and it works, without the user needing to install anything on macports. Also, link against any MacOS dynamic system libraries, or else build them into the module statically.

How do you write setup.py to do that?

Several uses of numpy.oldnumeric.mlab

Dear demusjohn,

Thanks for your contribution to camfr maintenance. I installed camfr on my Macbook Pro, with "python setup.py install".
I created a virtual py27 environment using conda and changed the paths in "machine_cfg.py". Then it seems the installation is successful and the output is as follows:

running install
running build
scons: Reading SConscript files ...

scons: warning: The env.Copy() method is deprecated; use the env.Clone() method instead.
File "/Users/lrunze/Desktop/temp/CAMFR-master/SConstruct", line 19, in
scons: done reading SConscript files.
scons: Building targets ...
scons: `camfr' is up to date.
scons: done building targets.
running build_py
running install_lib
running install_data
copying camfr/_camfr.dylib -> /Users/lrunze/anaconda3/envs/camfr/lib/python2.7/site-packages/camfr/.
error: can't copy 'docs/camfr.pdf': doesn't exist or not a regular file

The camfr.pdf is not so vital. But when I run the example file "Silicon-Waveguide...", there is an error message:

ImportError: No module named _camfr

I have no idea to address this. Could you please some suggestion?

BTW. Here is my file tree in "*/site-packages/camfr/":

Thanks!

From @demisjohn on April 2, 2018 17:17

See this fork's fix for that, and incorporate:
jtambasco@40156dc

Or see if they will submit a pull request for it.

Copied from original issue: #12

From @demisjohn on March 30, 2018 5:48

# Copied from the "TODO" file in the repo.
Presumably Peter Beinstman's list of action items.

-don't polute global namespace with scipy

-document photonic wire, plot example of BlochStack, Cavity
-document BlochSection
-document band diagrams
-document Blochstack
-document ASR solver
-document keep_all_estimates?
-example with scipy.io.write_array(outfile, P_TM)
-GARCLED: tip to choose ref index non integer

-testsuite for oleds
-PhC splitter in testsuite
-what to do with code for grating at the substrate side?

-T scheme when S scheme fails due to resonance?

-change blochmode.get_kx() to blochmode.kx()

-add doc to make sure the cladding is large enough
-add doc to do all the dimensions in micron
-loss is negative index
-add doc to use geometry only fo a single period

-BlochStack(0) + .. + BlochStack(0) doesn't cache calculations.

-switch to SVN on sourceforge?
-cmake?
-investigate setuptools
-investigate pyste?
-check if numpy wrappers can get rid of copying
-check ref_counting in these wrappers
-compare with numpy boost python code
-pass C++ exception to Python
-see if camfr_wrap can be updated further (default arguments, python function)
-fPIC, optimise options for fortran, scons bug?
-testsuite windows
-overlap_slice under windows.

-write Error: didn't find enough modes, and Warning: singular system to stdout?

-check -funroll_loops
-test with -Wall

-remove explicit dependency on python version from machine_cfg.py.

-get rid of backward modes detection and use always lossy branchcut?

-speed up slabs with small delta n

-experiment with precompiled headers

-BlochSection with single non-uniform slab

-fix pw_vcsel.py
-phasar2.py
-plot doesn't work for Circ waveguide
-free_temps: slab_cache = []

-document flux failure for PML?

-circ: tracking solver in eps rather than in n

-plot n section doesn't work

-take kx0, .. into account for recalc_needed() for BlochSection

-stabilise PML in series solver
-series solver for degenerate waveguides: double_prism, zipper (relax mueller),
dircoup (PML)

-S_flux at arbitrary position
-circ S flux does not respect begin and end point

-infstack: fix ext_field_expansion, calc_interface_field, fw_bw(s.length())
-reformulate TE as fourier series
-Trent's algorithm to invert Toeplitz
-always take minimum number of modes in series solver
-stability tips for infstacks

-planar set_kt

-time 'a = b + multiply()' vs 'c.reference(multiply()); a = b+c'

-band calculation with fixed k_t

-averaging of eps

-remove f,zabs debug code from slabmode.cpp
-document field_calc_heuristic

-mode_calc from core only for guided modes

-try RCWA like overlap scheme. Could be more stable.

-definition of cladding index in 3D doesn't work well for graded index
structures.

CAMFR 3D:

-implement Ez, Hz in plane wave modes
-use blas for overlap calculations
-revisit calc_global in combination with arnoldi eigensolver.
-calc_band --> calc_overlap: need normalisation for calc_global?
-check if creation of extra interface in middle of core is needed
-clean up RefSectionMode::field (not used, but still)
-re-enable symmetry?
-improve interface of SectionDisp, remove f member of Section
-rework place where stack gets split up in left and right part (3D_core.py)
-optimise ref section overlap
-Section1D: both TE and TM modes, normalise, fw_bw_at, compare to 2D, kz=0
-free slabmatrixcache?
-generalise cache to work with different M in each section.
-implement SectionFlux
-pml=0 in simple_stack.py worng sign of kz
-dispersion relation of 2D slabs: try to eliminate need for O_II_I in
interface.cpp
-Remove kludge for normalising coodinates in field profiles
-PML in z direction (check field profiles, numeric overlap integral)
-speed up nomalisation through cache?
-slaboverlap TE_TM: introduce 'same' function

MEDIUM TERM:

-enum.export_values()
-speed up M - U1, where U1 is unit matrix
-speed up S_scheme_fields by avoiding explicit matrix multiplication.
-short cut check_error in Bessel functions

-try to prevent user from plotting in an infstack.

-inc/ext_S_flux: split over materials
-possibility to set PML layer by layer

-more general handling of decoupled waveguides

-eliminate warning for zero transmission through wall when calculating fields in stack

-group identical sections in Geometry

-blochmode fw,bw at

-easier notation for InfStack: inf*(expression)?

-prevent GC of temporary objects in expressions (walls, flipped, infstack)

-new function: stack::field(r0, r1, delta_r) to calc field on a grid,
ability to cache field profiles and speed up

-stack field on layer discontinuity: speed up by not propagating

-cleverer inc/ext_field_expansion that does not calculate internal fields
when not needed

-implement Bloch modes for MonoScatterers, InfStack for DiagScatters
-speed up Bloch for symmetric structures?

-investigate throwing exceptions to Python

-tune new complex zero finder
-related: make definition of C_upperright uniform
-related: test it for leaky modes
-related: reenable complex modes in circ
-related: test sign of beta in backward modes in circ (using power flux)

-investigate mode problems for CircM with large claddings
-use asymptotic expansions to find high order modes for circular
structures
-write a GUI for defining complicated structures
-add Python docbook comments

-making stripping of executable dependent on debug switches

-automatic setting of global.orthogonal
-explicitly return all modes found in Cavity::find_all_modes
-make 'precision' dynamic
-global numeric status register?

-cavity::calc_sigma: instead of using only the fw field, is it more robust
to use fw_backward field to determine dominant mode?
-cavity: instead of using SVD, use eigenvalue decomposition or Arnoldi
-try out LAPACK 3.0 special svd routine (zgesdd)

-PC_wall: add waveguide interface if needed
-faster location of PC_wall eigenmodes
-convert slabwall PC to Material Stacks
-slabwall: cache get_R12 for startfield, get_error
-kill virtual functions in SlabWall (perhaps elsewhere too, get_kz()?)
-PC and TBC walls for Sections

SOURCE MAINTENANCE

-dynamic name of camfr library (i.e. camfr vs camfr_work defined in only
one place) http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/223972
-Use scons Clean function
-remove old mode profile calculator
-Section sorter to mode.h
-build: eliminate as many makefiles as possible
-remove set_precision_enhancement and friends
-make the C++ naming convention more uniform and in sync with Python names
(e.g. circ_disp -> CircDisp, Material_length -> MaterialLength, ...)
-use BaseMaterial where appropriate
-completely redesign / rework Expression and its link to Stack
-make state of inc_field_bw consistent when calling set_interface_field

LOW PRIORITY

-is reciprocity exploitable?
-auto-partitioning of stacks in optimal diagonal substacks

-narrower minima in cavity::find_all_modes? (Peter)
-tilde in S_scheme: return more refs? (Peter)
-split scaling (Peter)
-scaling for complex modes, scaling when tracing (Peter)

-check sqrt(power) -> -1 norm (Peter)
-related: consolidate signedsqrt in material.h and circ.cpp (Peter)

Copied from original issue: #11

From @demisjohn on March 7, 2018 13:43

Note from ~2010:

You can NOT pass the calculated waveguide (Section or Slab) object as a returned variable if you try to pass it & use it, you get a segmentation fault or other strange errors.

Hence the need to perform analysis of the mode within the same function that solves for it, redoing the same modesolver multiple times in a single script if you choose to functionalize it.

Apparently this is only true of a Section object that has already had SectionObj.calc() called on it (modes solver for).

Should check this to see if it's still true that this crashes python. Not sure where in the cython code this could be caused, but presumably we could find the array that is not malloc()'d properly or something.

Copied from original issue: #7

From @demisjohn on February 28, 2018 2:50

My main reason to fork this repo. Compile on Mac OS 10.12 at least.

Copied from original issue: #1

How do I install this package? In the readme it says to, "see the 'releases' or 'tags' section of this github repo" but on GitHub it says "no releases published"? Thank you for any help you can provide me. (I understand there is no working version for python 3.x)

From @demisjohn on February 28, 2018 19:38

Move comments in machine_cfg.py.MacOSX into a new file INSTALL.MacOS, detailing how to use MacPorts for installing all dependencies.

First, test this on a new MacPorts install to find the minimum port installations for compiling CAMFR on a MacOS system.

Copied from original issue: #6

If I create an object and then pass the object separately as a constructor for another class in another line, everything seems to be fine.

m=Material(1.2)
r=Planar(m)
r.N()
1

r.core()
Isotropic n=(1.2,0)

However, if I try to create and call both classes in the same command (as follows)

t=Planar(Material(1.2))
print(t)
TE (inf,nan) Theta nan

t.N()
1

t.core()
zsh: segmentation fault python

I get this Seg.. fault error. Stranger is that the error does not appear at the time of creating but when calling some function of the class. and the error does not appears for all. Here, N() function worked but the core() function caused the error.

From @demisjohn on March 22, 2018 3:30

See this commit that solves this
jtambasco@40156dc

Copied from original issue: #10

From @demisjohn on February 28, 2018 8:20

Currently the build produces a compiled _camfr.dylib, but Python expects to import a _camfr.so.
The user must manually rename the .dylib --> .so for the installation to work.

Should have setup.py do this rename automatically, OR set the proper linker flag to have it produce the correct library extension.

It might be that changing the link_flag= -dynamic to -bundle might do this, but I'm not sure.

Copied from original issue: #3

Hello,

I was wondering if I could somehow take over ownership of this repo, and just add you as a maintainer.
Not sure of the exact logistics of that, but I assume it's possible somehow. Happy to add anyone as collaborators, but I will actually take the time to look at pull requests etc.

GitHub looks like a perfect place to continue development and post upgrades to CAMFR, continuing it's excellent utility. Although I'm not particularly great at coding up mathematical models, I will try to upgrade the package to keep it current (currently working on Python3 upgrade). Maybe the community can help with actual modeling coding.

Let me know what you think.
-- Demis

From @demisjohn on February 28, 2018 9:38

the module repeatedly calls from numpy import *, which, aside from being bad practice, actually has stomped on one of it's own functions.

The camfr function full(), as in set_mode_correct(full), has been replaced by numpy.full() (which presumably didn't exist in ~2005). This now pops an error.

    set_mode_correction(full)
Boost.Python.ArgumentError: Python argument types in
    camfr._camfr.set_mode_correction(function)
did not match C++ signature:
    set_mode_correction(Mode_correction)

Must go thru the python files and replace the import statement with import numpy as np and go through to prepend all numpy functions with np.!

Copied from original issue: #5

From @demisjohn on March 7, 2018 13:51

Currently, getting help() on a boost object (defined in C I think), does not show any useful user-written documentation on how to use the object.

Should add documentation to clarify how to use these objects.

Example of help( camfr.Section ), which should say something like

 __init__( self, first_pass_modes, second_pass_modes)

The line s = Section(all, 10, 40) means we use (2*10+1)^2 plane waves in the first stage, and refine it using 40 1D modes in each Slab during the second stage.

instead we get a cryptic:

>>> help(c.Section)
Help on class Section in module camfr._camfr:

class Section(MultiWaveguide)
 |  Method resolution order:
 |      Section
 |      MultiWaveguide
 |      Waveguide
 |      Boost.Python.instance
 |      __builtin__.object
 |  
 |  Methods defined here:
 |  
 |  __init__(...)
 |      __init__( (object)arg1, (Expression)arg2 [, (int)arg3 [, (int)arg4]]) -> None :
 |      
 |          C++ signature :
 |              void __init__(_object*,Expression {lvalue} [,int [,int]])
 |      
 |      __init__( (object)arg1, (Expression)arg2, (Expression)arg3 [, (int)arg4 [, (int)arg5]]) -> None :
 |      
 |          C++ signature :
 |              void __init__(_object*,Expression {lvalue},Expression {lvalue} [,int [,int]])
 |      
 |      __init__( (object)arg1, (Term)arg2) -> None :
 |      
 |          C++ signature :
 |              void __init__(_object*,Term)
 |  
 |  __reduce__ = <unnamed Boost.Python function>(...)
 |  
 |  disp(...)
 |      disp( (Section)arg1, (complex)arg2) -> complex :
 |      
 |          C++ signature :
 |              std::__1::complex<double> disp(Section {lvalue},std::__1::complex<double>)
 |  
 |  eps(...)
 |      eps( (Section)arg1, (Coord)arg2) -> complex :
 |      
 |          C++ signature :
 |              std::__1::complex<double> eps(Section {lvalue},Coord)
 |  
 |  height(...)
 |      height( (Section)arg1) -> float :
 |      
 |          C++ signature :
 |              double height(Section {lvalue})
 |  
 |  mode(...)
 |      mode( (Section)arg1, (int)arg2) -> SectionMode :
 |      
 |          C++ signature :
 |              SectionMode* mode(Section,int)
 |  
 |  mu(...)
 |      mu( (Section)arg1, (Coord)arg2) -> complex :
 |      
 |          C++ signature :
 |              std::__1::complex<double> mu(Section {lvalue},Coord)
 |  
 |  n(...)
 |      n( (Section)arg1, (Coord)arg2) -> complex :
 |      
 |          C++ signature :
 |              std::__1::complex<double> n(Section {lvalue},Coord)
 |  
 |  set_estimate(...)
 |      set_estimate( (Section)arg1, (complex)arg2) -> None :
 |      
 |          C++ signature :
 |              void set_estimate(Section {lvalue},std::__1::complex<double>)
 |  
 |  set_sorting(...)
 |      set_sorting( (Section)arg1, (Sort_type)arg2) -> None :
 |      
 |          C++ signature :
 |              void set_sorting(Section {lvalue},Sort_type)
 |  
 |  width(...)
 |      width( (Section)arg1) -> float :
 |      
 |          C++ signature :
 |              double width(Section {lvalue})
 |  
 |  ----------------------------------------------------------------------
 |  Data and other attributes defined here:
 |  
 |  __instance_size__ = 120
 |  
 |  ----------------------------------------------------------------------

Copied from original issue: #8

From @demisjohn on March 7, 2018 14:6

Mode solvers should use MatPlotLib to plot.

Should generate nice colored plots, like this:

Copied from original issue: #9

From @demisjohn on February 28, 2018 8:23

Will try Python 3.5 first since I have that installed.

Copied from original issue: #4

Most of the python code is auxiliary, shouldn't be too hard, right?

Hello! I tried to built Camfr for Windows 10 but failed. In the end, I downloaded .exe file from that source . It worked eventually but I have some issues with the plotting. I could not get the same results as in

examples/contrib/Example - Silicon-Waveguide ModeSim v2018-01.py

the Section.plot() does not seem to be there.
I think, that is because the link has different version of Camfr. Can you, please, give an instruction how to download it on Windows with upgraded version of Camfr? Many thanks!