camfr-users Mailing List for CAMFR (Page 29)
Brought to you by:
pbienst
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
(8) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
|
Feb
|
Mar
(3) |
Apr
(2) |
May
(13) |
Jun
(8) |
Jul
(2) |
Aug
|
Sep
(5) |
Oct
(2) |
Nov
(1) |
Dec
|
2004 |
Jan
|
Feb
|
Mar
(5) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
(2) |
Dec
|
2005 |
Jan
|
Feb
(2) |
Mar
(7) |
Apr
|
May
(2) |
Jun
|
Jul
(10) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(4) |
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(7) |
Jun
(2) |
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(4) |
2007 |
Jan
(5) |
Feb
(5) |
Mar
(2) |
Apr
(12) |
May
(2) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(24) |
Dec
(2) |
2008 |
Jan
(2) |
Feb
(23) |
Mar
(7) |
Apr
(15) |
May
(14) |
Jun
(48) |
Jul
(24) |
Aug
(17) |
Sep
(19) |
Oct
(6) |
Nov
(10) |
Dec
(5) |
2009 |
Jan
(6) |
Feb
(26) |
Mar
(28) |
Apr
(11) |
May
(2) |
Jun
(12) |
Jul
(21) |
Aug
(6) |
Sep
(21) |
Oct
(22) |
Nov
(16) |
Dec
(4) |
2010 |
Jan
(4) |
Feb
(4) |
Mar
(2) |
Apr
(2) |
May
|
Jun
(8) |
Jul
(5) |
Aug
|
Sep
(2) |
Oct
(6) |
Nov
(11) |
Dec
(19) |
2011 |
Jan
(11) |
Feb
(6) |
Mar
(4) |
Apr
(2) |
May
(4) |
Jun
(2) |
Jul
|
Aug
(1) |
Sep
|
Oct
(2) |
Nov
(2) |
Dec
(3) |
2012 |
Jan
(3) |
Feb
(13) |
Mar
|
Apr
(7) |
May
(2) |
Jun
(5) |
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(4) |
2013 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(11) |
Jul
(23) |
Aug
(6) |
Sep
|
Oct
(4) |
Nov
|
Dec
(5) |
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2022 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Peter B. <Pet...@ug...> - 2003-05-06 14:40:36
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is the output I get with camfr 1.1, and after adding=20 set_sweep_steps(100), which looks a lot better: >0 (3.34854583881-0.00213938835882j) >1 (3.28335532424-0.00872674804143j) >2 (3.17177722644-0.0203230972895j) >3 (3.00875131076-0.038080007238j) >4 (2.80639710422-0.00341002504308j) >5 (2.78546570349-0.0642523885642j) >6 (2.48625597032-0.103622019746j) >7 (2.0804035866-0.168476781619j) >8 (0.193363472706-3.65592039952j) >9 (0.00266761863477-3.78403535655j) It still complains about problems during sweep though, but that is a proble= m=20 related to the fact that your structure contains lossy metals. I'm currently working on a better, more efficient solver for metallic=20 structures, which should improve the situation even more, but I still need = to=20 fine-tune the code. Hope this helps, Peter =2D ------------------------------------------------ Peter Bienstman Ghent University, Dep. of Information Technology Sint-Pietersnieuwstraat 41, B-9000 Gent, Belgium tel: +32 9 264 34 45, fax: +32 9 264 35 93 WWW: http://photonics.intec.ugent.be email: Pet...@ug... =2D ------------------------------------------------ =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+t8lj4dgPAIjyquoRAkfBAKCAlK8Dr7l6WxRlVc4BLEpvJiRj1gCfbXGz oz1Lrayc+DDYu6cPfahbVao=3D =3DJKvM =2D----END PGP SIGNATURE----- |
From: Po D. <po...@ph...> - 2003-05-06 14:24:05
|
Hi, Thanks for your reply. I am using Camfr 1.0. My script is as follows. ""set_precision_rad(150) set_precision(400) set_lambda(1.55) set_N(20) set_polarisation(TE) set_stability(SVD) # Define materials. GaAs = Material(3.37) air = Material(1) Oxide = Material(1.5) Si = Material(3.505) metal = Material(0.2-6.5j) PML = -0.1 slab = Slab(GaAs(2+PML*1j)+ metal(0.1)+ Oxide(1.2)+ GaAs(0.24)+Oxide(4)+Si(0.25)+metal(0.1)+air(2+PML*1j)) slab.calc() for mode in arange(0,10): print mode, slab.mode(mode).n_eff()""" I changed the thickness of cladding layers to 2. The slab.calc results are similar as before (see below): Restarting: resolution now 40 Restarting: resolution now 80 Restarting: resolution now 160 Restarting: resolution now 320 Restarting: resolution now 640 Restarting: resolution now 1280 Error: inrecoverable problem during sweep. Invalidating zero (-0.000617662,27.0196) 0 (-2.80881333134+3.58003546997e-013j) 1 (-2.80642877121+0.00347950980434j) 2 (3.61314920932-2.86494647518j) 3 (-1.45936012272+2.93411404257e-005j) 4 (-1.42161738112+8.99988252097e-005j) 5 (-1.37937479799+0.000139274879785j) 6 (-1.30546627674+0.000195831018307j) 7 (-1.20750508343+0.000322422782778j) 8 (-1.09158922777+0.000524736191763j) 9 (-0.940309425501+0.000825344795279j) Restarting: resolution now 40 Restarting: resolution now 80 Restarting: resolution now 160 Restarting: resolution now 320 Restarting: resolution now 640 Restarting: resolution now 1280 So, I still have the problem. Thanks for your help. Po -----Original Message----- From: Peter Bienstman [mailto:Pet...@ug...] Sent: Tuesday, May 06, 2003 1:52 AM To: Po Dong; cam...@li... Subject: Re: [Camfr-users] modes calculation of multi-layer slab waveguide structure Hi, Your cladding thickness 0.1 is really too small (use 2, 3, ...). Your guided modes will be influenced by the PML absorption, which can give rise to modes that look like they have gain. Also, which version of CAMFR are you using? In the latest version, defining PML by using imaginary thicknesses is deprecated, one should use set_upper_PML() and set_lower_PML(). If you still have problems, please send me your entire simulation file. Hope this helps, Peter On Tuesday 06 May 2003 02:47, Po Dong wrote: > Hi, > > I defined a slab waveguide structure as follows, > > "Slab(GaAs(0.1+PML*1j)+ metal(0.1)+ Oxide(1.2)+ GaAs(0.24)+ > Oxide(4)+Si(0.25)+metal(0.1)+air(0.1+PML*1j))" > > and the slab.calc results are: > > "Restarting: resolution now 40 > Restarting: resolution now 80 > Restarting: resolution now 160 > Restarting: resolution now 320 > Restarting: resolution now 640 > Restarting: resolution now 1280 > Error: inrecoverable problem during sweep. Invalidating zero > (-0.000617662,27.0196) > 0 (-2.80881333134+3.58003546997e-013j) > 1 (-2.80642877121+0.00347950980434j) > 2 (3.61314920932-2.86494647518j) > 3 (-1.45936012272+2.93411404257e-005j) > 4 (-1.42161738112+8.99988252097e-005j) > 5 (-1.37937479799+0.000139274879785j) > 6 (-1.30546627674+0.000195831018307j) > 7 (-1.20750508343+0.000322422782778j) > 8 (-1.09158922777+0.000524736191763j) > 9 (-0.940309425501+0.000825344795279j)" > > The real part of the effective index is negative, which is not > correct. Anybody knows why? Thanks. > Po -- ------------------------------------------------ Peter Bienstman Ghent University, Dep. of Information Technology Sint-Pietersnieuwstraat 41, B-9000 Gent, Belgium tel: +32 9 264 34 45, fax: +32 9 264 35 93 WWW: http://photonics.intec.ugent.be email: Pet...@ug... ------------------------------------------------ |
From: Peter B. <Pet...@ug...> - 2003-05-06 05:52:22
|
Hi, Your cladding thickness 0.1 is really too small (use 2, 3, ...). Your guided modes will be influenced by the PML absorption, which can give rise to modes that look like they have gain. Also, which version of CAMFR are you using? In the latest version, defining PML by using imaginary thicknesses is deprecated, one should use set_upper_PML() and set_lower_PML(). If you still have problems, please send me your entire simulation file. Hope this helps, Peter On Tuesday 06 May 2003 02:47, Po Dong wrote: > Hi, > > I defined a slab waveguide structure as follows, > > "Slab(GaAs(0.1+PML*1j)+ metal(0.1)+ Oxide(1.2)+ GaAs(0.24)+ > Oxide(4)+Si(0.25)+metal(0.1)+air(0.1+PML*1j))" > > and the slab.calc results are: > > "Restarting: resolution now 40 > Restarting: resolution now 80 > Restarting: resolution now 160 > Restarting: resolution now 320 > Restarting: resolution now 640 > Restarting: resolution now 1280 > Error: inrecoverable problem during sweep. Invalidating zero > (-0.000617662,27.0196) > 0 (-2.80881333134+3.58003546997e-013j) > 1 (-2.80642877121+0.00347950980434j) > 2 (3.61314920932-2.86494647518j) > 3 (-1.45936012272+2.93411404257e-005j) > 4 (-1.42161738112+8.99988252097e-005j) > 5 (-1.37937479799+0.000139274879785j) > 6 (-1.30546627674+0.000195831018307j) > 7 (-1.20750508343+0.000322422782778j) > 8 (-1.09158922777+0.000524736191763j) > 9 (-0.940309425501+0.000825344795279j)" > > The real part of the effective index is negative, which is not correct. > Anybody knows why? > Thanks. > Po -- ------------------------------------------------ Peter Bienstman Ghent University, Dep. of Information Technology Sint-Pietersnieuwstraat 41, B-9000 Gent, Belgium tel: +32 9 264 34 45, fax: +32 9 264 35 93 WWW: http://photonics.intec.ugent.be email: Pet...@ug... ------------------------------------------------ |
From: Po D. <po...@ph...> - 2003-05-06 00:47:59
|
Hi, I defined a slab waveguide structure as follows, "Slab(GaAs(0.1+PML*1j)+ metal(0.1)+ Oxide(1.2)+ GaAs(0.24)+ Oxide(4)+Si(0.25)+metal(0.1)+air(0.1+PML*1j))" and the slab.calc results are: "Restarting: resolution now 40 Restarting: resolution now 80 Restarting: resolution now 160 Restarting: resolution now 320 Restarting: resolution now 640 Restarting: resolution now 1280 Error: inrecoverable problem during sweep. Invalidating zero (-0.000617662,27.0196) 0 (-2.80881333134+3.58003546997e-013j) 1 (-2.80642877121+0.00347950980434j) 2 (3.61314920932-2.86494647518j) 3 (-1.45936012272+2.93411404257e-005j) 4 (-1.42161738112+8.99988252097e-005j) 5 (-1.37937479799+0.000139274879785j) 6 (-1.30546627674+0.000195831018307j) 7 (-1.20750508343+0.000322422782778j) 8 (-1.09158922777+0.000524736191763j) 9 (-0.940309425501+0.000825344795279j)" The real part of the effective index is negative, which is not correct. Anybody knows why? Thanks. Po |
From: Peter B. <Pet...@ug...> - 2003-05-05 06:28:22
|
On Monday 05 May 2003 03:59, cw...@mi... wrote: > Hi, > Can anybody send me a python file for the calculation of photonic band > structure? any example is ok. > thanks > cw See e.g. http://camfr.sourceforge.net/docs/camfr_11.html#SEC11 and look at BlochStack. If you have any more questions, feel free to send me your python file, and I'll have a look at it. Cheers, Peter ------------------------------------------------ Peter Bienstman Ghent University, Dep. of Information Technology Sint-Pietersnieuwstraat 41, B-9000 Gent, Belgium tel: +32 9 264 34 45, fax: +32 9 264 35 93 WWW: http://photonics.intec.ugent.be email: Pet...@ug... ------------------------------------------------ |
From: <cw...@mi...> - 2003-05-05 01:59:22
|
Hi, Can anybody send me a python file for the calculation of photonic band structure? any example is ok. thanks cw |
From: Peter B. <Pet...@ug...> - 2003-04-30 07:42:58
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Nadav, camfr_wrap.cpp takes a long time to build and uses lots of memory: on my=20 machine 350 M and 2 minutes. I'm afraid that's essentially a gcc limitation. Strangely enough I found that it compiles quicker as a normal user instead = of=20 as root. Other option is turning off compiler optimisation, that should speed up the= =20 compilation process considerably. Hope this helps, Peter =2D ------------------------------------------------ Peter Bienstman Ghent University, Dep. of Information Technology Sint-Pietersnieuwstraat 41, B-9000 Gent, Belgium tel: +32 9 264 34 45, fax: +32 9 264 35 93 WWW: http://photonics.intec.ugent.be email: Pet...@ug... =2D ------------------------------------------------ =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+r35+4dgPAIjyquoRAq/sAJ44mbiaUrS2x4VyoiUBWVP8f/FUugCgk2oP Yfbczn9v5WqBjoQ0Qg5mHfU=3D =3DL93E =2D----END PGP SIGNATURE----- |
From: Nadav H. <Nadav@VisionSense.com> - 2003-04-30 07:21:54
|
I've posted this issue as a bug, but maybe it isn't: I tried to compile camfr 1.1 (either the official release or from the CVS repository) under Linux (RH7.3 and RH 8.0), gcc versions 3.2, 3.2.2, 3.2.3. The compilation goes smoothly until it gets to the camfr_wrap.c file --- then the compieler stucks and starts to consume all the avaiable memory (I have a 256M and a 192M machines). The machine_cfg.py variables that I modified are: include_dirs = ["/usr/lib/python2.2/site-packages/weave/blitz-20001213/blitz", "/usr/local/boost_1.30", "/usr/include/python2.2"] # Library directories. library_dirs = [] # Library names. libs = ["boost_python", "blitz"] Nadav. |
From: Peter B. <Pet...@ru...> - 2003-03-05 15:04:26
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 05 March 2003 14:47, Andreas Witzig wrote: > Hello > > I am having trouble with the eigenmode search for VCSELs. CAMFR returns > wavelength and gain but the fields don't look like good VCSEL fields. > - Is there an error criterion where I can find out if CAMFR converged? > - What does the runtime screen output mean? (I figured out only the > following: 1st column =3D wavelength and 3rd column =3D gain) 2nd column: imaginary part of the gain material 4th column: singular value (sigma): this should be smaller than 1e-4 for a= =20 decent mode. This number is too high in your case. 5th column: dominant mode in the field expansion. The fact this is such a h= igh=20 number in your case indicates that this is definitely not the ground mode,= =20 which will require a very gain to lase ;-) Also take into account that the gain region searched for modes is by defaul= t=20 the range n_imag < 0.015. You see that in your case you are hitting this=20 limit. You can change this limit by using the extra parameters to find_mode= =20 (see docs). A good strategy to find a laser mode is to first get a rough idea of where = the=20 modes are. You can do this by sweeping the wavelength and calling=20 cavity.calc_sigma() for each wavelength, like e.g. for l =3D arange(.745,0.747): set_lambda(l) # define your VCSEL cavity.calc_sigma() The minina in sigma correspond to modes. Once you get an idea of the=20 wavelength interval the mode is located in, you can put this interval in=20 find_mode(). You can more or less automate all of this by using find_modes() instead of= =20 find_mode(), which will try to find all modes in the wavelength region you= =20 specify. This can be time consuming though, as most of the time you'll only= =20 be interested in the ground mode. (find_modes() is only available in the=20 newly released camfr 1.1). Hope this helps, Peter =20 =2D ------------------------------------------------ Peter Bienstman Ghent University, Dep. of Information Technology Sint-Pietersnieuwstraat 41, B-9000 Gent, Belgium tel: +32 9 264 34 45, fax: +32 9 264 35 93 email: Pet...@ru... =2D ------------------------------------------------ =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+ZiBr4dgPAIjyquoRAifnAJ9JIPI6TjCPFOc6Hg3PZP0Tj2+l1wCgtcX3 vGDJwme1O9jnCgFBI98ayUE=3D =3DwYia =2D----END PGP SIGNATURE----- |
From: Andreas W. <wi...@ii...> - 2003-03-05 14:48:05
|
Hello I am having trouble with the eigenmode search for VCSELs. CAMFR returns wavelength and gain but the fields don't look like good VCSEL fields. - Is there an error criterion where I can find out if CAMFR converged? - What does the runtime screen output mean? (I figured out only the following: 1st column = wavelength and 3rd column = gain) CAMFR input and screen output are attached below. Thanks Andreas **** screen output CAMFR 1.0 - Copyright (C) 1998-2002 Peter Bienstman - Ghent University. @ 0.745764 0 0 0.112585 94 @ 0.746236 0 0 0.114158 94 @ 0.745472 0 0 0.111261 94 @ 0.745292 0 0 0.110282 94 @ 0.74518 0 0 0.10961 94 @ 0.745111 0 0 0.109169 94 @ 0.745069 0 0 0.108886 94 @ 0.745043 0 0 0.108707 94 @ 0.745026 0 0 0.108596 94 @ 0.745016 0 0 0.108526 94 @ 0.74501 0 0 0.108483 94 @ 0.745006 0 0 0.108456 94 @ 0.745006 0.00572949 966.42 0.100788 94 @ 0.745006 0.00927051 1563.7 0.095776 90 @ 0.745006 0.011459 1932.84 0.0926466 90 @ 0.745006 0.0128115 2160.98 0.0907834 90 @ 0.745006 0.0136475 2301.98 0.0896775 90 @ 0.745006 0.0141641 2389.12 0.0890109 90 @ 0.745006 0.0144834 2442.98 0.0886046 90 @ 0.745006 0.0146807 2476.26 0.0883554 90 @ 0.745006 0.0148027 2496.84 0.088202 90 @ 0.745006 0.014878 2509.55 0.0881074 90 @ 0.745006 0.0149246 2517.41 0.088049 90 @ 0.745006 0.0149534 2522.26 0.088013 90 @ 0.745006 0.0149712 2525.26 0.0879907 90 Done pass 1: lambda 0.745006, gain 2525.26 done calculation **** input file: #!/usr/bin/env python #################################################################### # # Find laser mode in air-post VCSEL # #################################################################### from camfr import * from camfr_tk import * from Numeric import * set_lambda(0.75) set_N(100) set_circ_order(1) set_sweep_from_previous(1) # Define materials. GaAs_m = Material(4.121) AlGaAs_m = Material(2.641) AlAs_m = Material(3.989) air_m = Material(1.00) cavity_m = Material(3.409) gain_m = Material(3.409) loss_m = Material(3.53 - 0.01j) set_gain_material(gain_m) # Define geometry parameters set_circ_PML(-0.1) r = 2.0 d_cladding = 3.0 # Define cross sections Airpost_GaAs = Circ(GaAs_m(r) + air_m(d_cladding)) Airpost_AlAs = Circ(AlAs_m(r) + air_m(d_cladding)) Airpost_AlGaAs = Circ(AlGaAs_m(r) + air_m(d_cladding)) Gainregion = Circ(gain_m(r) + loss_m(d_cladding)) Cavityregion = Circ(cavity_m(r+d_cladding)) GaAs = Circ(GaAs_m(r+d_cladding)) AlGaAs = Circ(AlGaAs_m(r+d_cladding)) AlAs = Circ(AlAs_m(r+d_cladding)) Air = Circ(air_m(r+d_cladding)) # Define top half of cavity. top = Stack( Gainregion(0) + Cavityregion(0.106) \ + 8*(Airpost_AlAs(0.071) + Airpost_AlGaAs(0.189)) \ + Airpost_GaAs(0.091) + Air(0) ) # Define bottom half of cavity. bottom = Stack( Gainregion(0.008) + Cavityregion(0.106) \ + 10*(AlAs(0.071) + AlGaAs(0.189)) + GaAs(0) ) # Define cavity and find laser mode. cavity = Cavity(top, bottom) cavity.find_mode(.745, .747) print "done calculation" # Plot r_x = arange( 0.0, 4.0, 0.01) r_z = arange( -4.0, 4.0, 0.01) outfile = file("out.dat",'w') for x in r_x: for z in r_z: print >> outfile, x, z, cavity.field(Coord(x,0,z)).abs_E() outfile.close() -- ------------------------------------------------------------------------- Dr. Andreas Witzig Phone: +41 1 632 52 43 Optoelectronics Modeling mailto:wi...@ii... Integrated Systems Laboratory http://www.iis.ee.ethz.ch/~laser/ ETH Zurich, Department of Electrical Engineering, ETZ J66.4, Gloriastrasse 35, CH-8092 Zurich, Switzerland. ------------------------------------------------------------------------- |
From: Peter B. <Pet...@ru...> - 2003-03-05 14:29:10
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 CAMFR 1.1 has been released, with the following new features: - improved stability for Slabs - inc_S_flux and ext_S_flux are now much faster - Python doesn't terminate abruptly anymore when faced with some user errors or lost modes - the refractive index profile can now be displayed on top of the field plots (Lieven Vanholme) - animation of field profiles is much smoother (Lieven Vanholme) - field plots can be saved in a variety of formats (jpg, gif, png, ...) Animations can be saved as an (uncompressed) animated gif (Lieven Vanholme) e.g. plot_field(s, lambda f : f.E2().real, r_x, r_z, "field.jpg") - plot_n and plot_field now works for BlochStacks, BlochModes and Cavities too - added Stack.fw_bw(z), which returns a tuple of the expansion coefficients of the forward and backward field at position z in the Stack. Also works for Blochmodes. e.g. fw, bw = stack.fw_bw(0) fw, bw = blochstack.mode(0).fw_bw(0) - Cavity.find_modes_in_region() has been renamed to Cavity::find_all_modes() - the constructor for Cavity has been changed from Cavity(top, bottom) to Cavity(bottom,top). This makes the coordinate system more intuitive. - arbitrary sources can now be placed inside a cavity e.g. cavity.set_Source(fw, bw) - fixed memory corruption when doing exotic things with Expressions - fixed crash when plotting uniform layers or planars Enjoy! - ------------------------------------------------ Peter Bienstman Ghent University, Dep. of Information Technology Sint-Pietersnieuwstraat 41, B-9000 Gent, Belgium tel: +32 9 264 34 45, fax: +32 9 264 35 93 email: Pet...@ru... - ------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+Zhgl4dgPAIjyquoRAkXhAKCGSN9YRgr6i4cEulKGitJMJJG22wCeOm0q XVEGn8/96vw4MN6mSNdHAuI= =CRst -----END PGP SIGNATURE----- |
From: Mathias V. <mat...@pa...> - 2002-12-14 20:53:29
|
Hello, does anyone else, besides me, have problems linking matlab to camfr/python code. I have a faint feeling, it has something to do with me using Matlab 5 instead of Matlab 6. Has the pymat module been tested with Matlab 5? Here's my problem: the third example (the one with importing and exporting python arrays to and from Matlab)in the visualisation dir simply crashes as soon as the script reaches the matlab commands. Matlab is properly started however, and the array variable is constructed in the Matlab workspace. But it remains empty. When I put the Matlab commands in the python script as comment, there is no problem running the script. As soon as one line of Matlab commands is tried, python crashes in the most annoying way (the famous adagium "... has generated erros and will be closed. An error log is being generated" Always wondered where windows keeps on finding the place to save all the error logs I've caused lately ;-) ) Your enlightening comments would be very much appreciated indeed. I say. cheerio Mathias |
From: Peter B. <Pet...@ru...> - 2002-11-12 18:04:34
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 12 November 2002 18:54, you wrote: > I use the following versions: > boost 1.27.0 This won't work I'm afraid. > blitz 20021011 I once tried compiling this Blitz version, but it gave me headaches, so I= =20 reverted to the previous version. > When do you expect to release camfr 1.1? Hopefully in a couple of weeks, but no guarantee, though. Peter - --=20 - ------------------------------------------------ Peter Bienstman Ghent University, Dep. of Information Technology Sint-Pietersnieuwstraat 41, B-9000 Gent, Belgium tel: +32 9 264 34 45, fax: +32 9 264 35 93 email: Pet...@ru... - ------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE90UKI4dgPAIjyquoRAsmfAJ9CI/5FXb2qdUqa4lRPemm0taNifACg+mGC dC/X8uuNcgFmNYAtjM/mUAY=3D =3DYwJR -----END PGP SIGNATURE----- |
From: Jan N. <ja...@go...> - 2002-11-12 17:54:14
|
Hi Peter! Thank you for the fast answer! On Tue, Nov 12, 2002 at 06:50:17PM +0100, Peter Bienstman wrote: > Did you adapt your machine_cfg.py to reflect where your boost and blitz lives? No, but as the compiler found both boost and blitz, I don't think this is the problem. > Since you have a blitz in /usr, I assume it's a different version than the one > I use (20001213), because the line numbers don't match. Probably Debian has > made some buggy modifications to its Blitz version. I use the following versions: boost 1.27.0 blitz 20021011 The error message doesn't look like it's bug in camfr, the reason I asked on this list was mainly because I hoped someone already had and solved that problem with debian. > you want, I can mail it to you or alternatively you could wait for camfr 1.1, > which will use a release version of Boost. When do you expect to release camfr 1.1? Jan |
From: Peter B. <Pet...@ru...> - 2002-11-12 17:51:08
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 12 November 2002 18:05, Jan Niehusmann wrote: > Hi! > > Did anybody of you compile camfr 1.0 successfully under debian/unstable= ? > I get the following error message: > > g++ -ftemplate-depth-60 -DFORTRAN_SYMBOLS_WITH_SINGLE_TRAILING_UNDERSCO= RE > -DNDEBUG -O3 -funroll-loops -fstrict-aliasing -g -fPIC > -I/home/pbienst/blitz-20001213 -I/home/pbienst/boost_cvs/boost Did you adapt your machine_cfg.py to reflect where your boost and blitz l= ives?=20 I'd be surprised if you have a user pbienst on your machine. > -I/usr/include/python2.2 -c -o camfr/field.o camfr/field.cpp > /usr/include/blitz/memblock.h: In method `int > blitz::MemoryBlock<complex<double> >::references() const': > /usr/include/blitz/memblock.h:382: instantiated from > `blitz::MemoryBlockReference<complex<double> >::numReferences() const' > /usr/include/blitz/array/methods.cc:316: instantiated from > `blitz::Array<complex<double>,1>::makeUnique()' camfr/field.cpp:190: =20 > instantiated from here /usr/include/blitz/memblock.h:228: passing `cons= t > pthread_mutex_t *' as argument 1 of `pthread_mutex_lock(pthread_mutex_t= *)' > discards qualifiers /usr/include/blitz/memblock.h:230: passing `const > pthread_mutex_t *' as argument 1 of `pthread_mutex_unlock(pthread_mutex= _t > *)' discards qualifiers scons: *** [camfr/field.o] Error 1 > make: *** [camfr] Error 2 Since you have a blitz in /usr, I assume it's a different version than th= e one=20 I use (20001213), because the line numbers don't match. Probably Debian h= as=20 made some buggy modifications to its Blitz version. I'd suggest compiling Blitz from scratch yourself. Note: in order to compile camfr 1.0, you need a specific snapshot of boos= t. If=20 you want, I can mail it to you or alternatively you could wait for camfr = 1.1,=20 which will use a release version of Boost. Peter - --=20 - ------------------------------------------------ Peter Bienstman Ghent University, Dep. of Information Technology Sint-Pietersnieuwstraat 41, B-9000 Gent, Belgium tel: +32 9 264 34 45, fax: +32 9 264 35 93 email: Pet...@ru... - ------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE90T9Z4dgPAIjyquoRAjhcAKDWJhBL+a9L7vXdEvrngAuXWjxNNgCgrks5 hiXwQPX0z5yH1JtKqrNHsug=3D =3DllSo -----END PGP SIGNATURE----- |
From: Jan N. <ja...@go...> - 2002-11-12 17:21:11
|
Hi! Did anybody of you compile camfr 1.0 successfully under debian/unstable? I get the following error message: g++ -ftemplate-depth-60 -DFORTRAN_SYMBOLS_WITH_SINGLE_TRAILING_UNDERSCORE -DNDEBUG -O3 -funroll-loops -fstrict-aliasing -g -fPIC -I/home/pbienst/blitz-20001213 -I/home/pbienst/boost_cvs/boost -I/usr/include/python2.2 -c -o camfr/field.o camfr/field.cpp /usr/include/blitz/memblock.h: In method `int blitz::MemoryBlock<complex<double> >::references() const': /usr/include/blitz/memblock.h:382: instantiated from `blitz::MemoryBlockReference<complex<double> >::numReferences() const' /usr/include/blitz/array/methods.cc:316: instantiated from `blitz::Array<complex<double>,1>::makeUnique()' camfr/field.cpp:190: instantiated from here /usr/include/blitz/memblock.h:228: passing `const pthread_mutex_t *' as argument 1 of `pthread_mutex_lock(pthread_mutex_t *)' discards qualifiers /usr/include/blitz/memblock.h:230: passing `const pthread_mutex_t *' as argument 1 of `pthread_mutex_unlock(pthread_mutex_t *)' discards qualifiers scons: *** [camfr/field.o] Error 1 make: *** [camfr] Error 2 Please Cc: replies to my email address, as I'm not subscribed to the mailing list. Thank you! Greetings, Jan |
From: Peter B. <Pet...@ru...> - 2002-11-07 13:17:41
|
On Thu, 7 Nov 2002, Melanie Ayre wrote: > Hello, me again > > I'd like to know if many other people use camfr/ mailing list? Many people use CAMFR, but so far you're the only one that makes use of the mailing list. > Anyway, anothe day, another problem. > > This code gets as far as displaying the index profile, and then stops > dead when I close the window. The problem this time is the misplaced free_tmps(). This will throw away all the stuff that has been calculated so far, and since you try to use this information again, it will crash. You should only use free_tmps at the end of the loop. Some other tips: -If you calculate the Blochmodes, it's much quicker to use just one unit cell in the z direction, rather than the 10 you use now. -I assume you want to look at the field profile of the Bloch mode? In your code you're calculating something different: you excite a finite stack with your Bloch mode, meaning that you will also see the influence from reflections at the edges of the crystal. You can write something like plot_field(blochstack.mode(0), lambda f : f.E2().real, etc... -Be careful with polarisation: TE means the TE of the waveguide people, i.e. E field perpendicular to the plane of the figure. This is what PhC people call TM. Cheers, Peter |
From: Melanie A. <ma...@st...> - 2002-11-07 11:49:09
|
Hello, me again I'd like to know if many other people use camfr/ mailing list? Anyway, anothe day, another problem. This code gets as far as displaying the index profile, and then stops dead when I close the window. Using the command line instead of idle gets slightly further - the next print command runs, and then it quits. Also, if i don't repeat the to_expression command, then the stack doesn't run at all. As ever the code is attached. Many, many thanks for your help Melanie |
From: Peter B. <Pet...@ru...> - 2002-11-04 12:43:52
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Good catch, the example file still uses an old syntax for the geometry=20 definition.=20 It works if you make the following changes: set_lower_PML(-0.1) set_upper_PML(-0.1) exp =3D g.to_expression(prop0, prop1, d_prop, trans0, trans1, d_trans) This will be fixed in the next version. Thanks, Peter On Monday 04 November 2002 13:33, Melanie Ayre wrote: > Hello > > Now I'm having trouble with geometry. > > The file camfr/examples/other/geometry.py (from the tutorial) won't run= , > with the error message : > > Traceback (most recent call last): > File "C:\Python22\Lib\site-packages\camfr\examples\other\geometry.py"= , > line 28, in ? > exp =3D g.to_expression( prop0, prop1, d_prop, trans0, trans1, > d_trans, PML1, PML2 ) > TypeError: to_expression() takes at most 8 arguments (9 given) > > > my local friendly guru tells me that this is because self, i.e. 'g' is > another argument. > > Could you please tell me what's going on, and how to make this work? > I'm having trouble with geometry constructs of my own, so I thought th= e > tutorial would be the first place to try for help. > > Thanks > > Melanie - ------------------------------------------------ Peter Bienstman Ghent University, Dep. of Information Technology Sint-Pietersnieuwstraat 41, B-9000 Gent, Belgium tel: +32 9 264 34 45, fax: +32 9 264 35 93 email: Pet...@ru... - ------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9xmt+4dgPAIjyquoRAhXqAJ94LEFEVGNKB3dERORw5cNKNiQs1gCgvn1T gOtnLMXrZl3hmqftV8FiIMg=3D =3Dz2rC -----END PGP SIGNATURE----- |
From: Melanie A. <ma...@st...> - 2002-11-04 12:35:17
|
Hello Now I'm having trouble with geometry. The file camfr/examples/other/geometry.py (from the tutorial) won't run, with the error message : Traceback (most recent call last): File "C:\Python22\Lib\site-packages\camfr\examples\other\geometry.py", line 28, in ? exp = g.to_expression( prop0, prop1, d_prop, trans0, trans1, d_trans, PML1, PML2 ) TypeError: to_expression() takes at most 8 arguments (9 given) my local friendly guru tells me that this is because self, i.e. 'g' is another argument. Could you please tell me what's going on, and how to make this work? I'm having trouble with geometry constructs of my own, so I thought the tutorial would be the first place to try for help. Thanks Melanie ______________________________________ Melanie Ayre PhD Student Photonic Crystals Group School of Physics and Astronomy University of St Andrews Scotland |
From: Peter B. <Pet...@ru...> - 2002-10-30 18:56:46
|
Hello, After running from the command prompt, I get this error message: Warning: complex widths don't match: (2.295,0) and (2.25,0) This means that the slabs you're trying to join in a stack don't have the same width. Still, CAMFR shouldn't drastically terminate the python interpreter. I'll fix the next version to exit more gracefully. Hth, Peter PS1: geometry *is* some sort of interpolation function PS2: 10 modes might be a bit to few PS3: you forgot parentheses after calc PS4: you should restrict your r_x to [0:4]. CAMFR doesn't automatically extend the fields yet outside the unit cell. On Wed, 30 Oct 2002, Melanie Ayre wrote: > Hello > > I hate to ask, but I'm having a debugging problem. > > I can't fix it myself, because at the wgb.calc statement something > serious enough to close all invocations of python happens before I can > read the warning message. > > I've compared with the tutorial, and I don't think I'm trying to do > anything unreasonable. > > I'm running python v2.2.1, camfr v1.0 on windows 2000 (on vmware on > debian linux). > > The code is attached. The many print and sleep commands are just for > debugging purposes. > > Thanks for your help > > Melanie > > ----------------------------------------------- > Melanie Ayre > PhD Student > Photonic Crystals Group > School of Physics and Astronomy > University of St Andrews > Scotland > > > |
From: Melanie A. <ma...@st...> - 2002-10-30 16:41:32
|
Hello I hate to ask, but I'm having a debugging problem. I can't fix it myself, because at the wgb.calc statement something serious enough to close all invocations of python happens before I can read the warning message. I've compared with the tutorial, and I don't think I'm trying to do anything unreasonable. I'm running python v2.2.1, camfr v1.0 on windows 2000 (on vmware on debian linux). The code is attached. The many print and sleep commands are just for debugging purposes. Thanks for your help Melanie ----------------------------------------------- Melanie Ayre PhD Student Photonic Crystals Group School of Physics and Astronomy University of St Andrews Scotland |
From: Peter B. <Pet...@ru...> - 2002-10-04 11:29:50
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I had plans to use camfr for a near-field simulations of a blazed > grating and microlens arrays. The optics features and the distances all > of the order of 10 microns. Do I shop in the right store? Nobody has ever done such a thing, but if (for the time being) you're happy= =20 with a 2D approximation, CAMFR is certainly worth a try.=20 Cheers, Peter =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9nXuE4dgPAIjyquoRAqwvAKDihR9Qb7UueT9J1aRA5aFer1j8tQCgn/w+ KD9DO7m6cCVAxYg51vKGLmo=3D =3DQ73F =2D----END PGP SIGNATURE----- |
From: Nadav H. <Na...@en...> - 2002-10-03 08:02:13
|
My initial problem was that I was looking for the files that were in a subdirectory of where camfr-1.0.taz was located. As you designated, it is more then a few minutes work even for an old pythonist (I do not use boost, and have blitz only as a part of SciPy package). I'll sleep on it during the weekend and let you know the results. I had plans to use camfr for a near-field simulations of a blazed grating and microlens arrays. The optics features and the distances all of the order of 10 microns. Do I shop in the right store? Thank you a lot for your help, Nadav. |
From: alibaba <Lie...@ru...> - 2002-10-02 20:32:12
|
hi, I just installed camfr on RH-linux and wrote something about it in this file; http://allserv.rug.ac.be/~lvholme/camfr/instal/camfrinstall/installonlinux.txt these are just the major steps. (compiling of the libraries and camfr) and don't handle all possible problems in detail. so, feel free to ask for more information. mmm, you will face a problem with getting the boost library at this time... (this recent cvs version don't fit in with the camfr version) i'll send you a mail with a solution. bye lieven On Wed, 2 Oct 2002, Nadav Horesh wrote: > I've downloaded camfr-1.0.tgz, unpacked it and found no way to proceed > with the installation. Please advice me what to do. > System: RH linux 7.2 on dual PIII. > > Thank you, > > Nadav. > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Camfr-users mailing list > Cam...@li... > https://lists.sourceforge.net/lists/listinfo/camfr-users > |