https://sourceforge.net/p/meepext/wiki/Home/Recent changes to HomeenSat, 16 Jul 2011 08:48:13 -0000https://sourceforge.net/p/meepext/wiki/Home/<pre>--- v13 +++ v14 @@ -1,69 +1,69 @@ -Export fluxes and DFT data +MEEP: Export fluxes and DFT data ========================== -Fluxes +Fluxes, with flux objects --- The function to save the dft data in human readable form (well, with the help of MATLAB) is called *pretty-save-flux*, and is called like ~~~~~~ :::scheme (pretty-save-flux "filename" fx) ~~~~~~ where fx is a flux object. Also see the example [test ctl] file for an example how to use it and some output. The [test ctl] file contains a single dipole in vacuum, and 3 flux objects are created, one in each principal direction. After the simulation, the 3 flux objects are exported to disk and one can find 3 HDF5 files, each containing the appropriate E- and H-fields (real and imaginary parts) for each flux object, for just as many frequencies as are specified in the ctl file. Quirks with flux export ------ 1. When exporting *fluxes* to disk, the data is always exported such, that multiplying, in a point-wise fashion, the relevant e-field and h-field components and summing the resulting matrix over all rows and columns gives the flux. In MATLAB language: assume Ex and Ey are 2d matrices containing the x-component and y-component of the electric field, as exported from the computer memory to disk. Similarly, assume Hx and Hy to be the same for the H-field. Then the total flux is given by sum(sum(Ex.\*Hy+Ey.\*Hx)). Note the plus, and not a minus. This is due to MEEP, as it creates flux objects that internally weigh the 2nd electric field component with a negative factor. -2. Related to the above, the 2nd exported electric field component is exported with an additional -1 factor. Therefore, to get the actual electric field component, multiply with -1. These fields are: +2. Related to the above, the 2nd exported electric field component is exported with an additional -1 factor. Therefore, to get the actual electric field component, multiply that component with -1. These fields are: * Flux in x-direction: Ez * Flux in y-direction: Ex * Flux in z-direction: Ey 3. When exporting fluxes, the electric field component is exported with the necessary weights to include the surface area/volume. -4. when a flux plane is defined between grid points, MEEP will use 2 planes with DFT data, both located on grid points, and weigh them accordingly such that the fluxes shown with (display-fluxes ...) correspond with the flux at the requested position. When this data is saved by the function I've introduced, both DFT planes are exported including the proper weight factors. For a DFT on a plane, this means that 3D data is exported. Sum the data in this 3rd dimension to get the DFT on the desired plane . +4. when a flux plane is defined between grid points, MEEP will use 2 planes with DFT data, both located on grid points, and weigh them accordingly such that the fluxes shown with (display-fluxes ...) correspond with the flux at the requested position. When this data is saved by the function I've introduced, both DFT planes are exported including the proper weight factors. For a DFT on a plane, this means that 3D data is exported. Sum the data in this 3rd dimension to get the DFT on the desired plane. In the most extreme case, when the flux at a single point is requested, internally MEEP can up to 8 points. All 8 points will be exported. 5. Adding multiple flux regions to a single flux object, and then exporting it, **is not supported!** 6. Exporting flux objects when periodic boundary conditions are in use **is not tested by me!** However, I think it should work. 7. I **haven't tested** cylindrical coordinates. -8. An additional quirk is that in contrast to the normal output-Xfield functions, the exported data just contains the contents in memory. This means that if symmetry planes are used, you don't get the full solution on disk, but just the part that is actually calculated. You have to unfold the symmetry yourself. This is because I simply didn't get how in the source code the output-Xfield functions take care of the symmetry. +8. Symmetry: in contrast to the normal output-Xfield functions, the exported data just contains the contents in memory. This means that if symmetry planes are used, you don't get the full solution on disk, but just the part that is actually calculated. You have to unfold the symmetry yourself. This is because I simply didn't get how in the source code the output-Xfield functions take care of the symmetry. Quirks 2-4 are actually just because of the way MEEP sets up the flux objects and the corresponding DFT objects. Nothing to worry about, but something one should know. -DFT +DFTs, with DFT objects ------- Finally, it should be possible to directly add DFT objects instead of using flux objects with ~~~~~~ :::scheme (define mydft (meep-fields-add-dft Ez (volume (size ...) (center ...)) freqmin freqmax Nfreq false)) ~~~~~~ source: http://article.gmane.org/gmane.comp.science.electromagnetism.meep.general/2834/match=add_dft But I got errors ("No matching method for generic function `meep_fields_add_dft'"). If anyone finds out how to to this, the dft should be exported to disk with ~~~~~~ :::scheme (pretty-save-dft "ez" mydft) ~~~~~~ -but I couldn't test this. +but I couldn't test this. The benefit of using DFT objects over flux objects is that you can simply specify the component you're interested in and save the memory and computational load for components that do not matter. **Update:** it seems that the correct syntax for adding a DFT object is not to specify a volume, but a volume list. Not tested so far. Hacking/Improving ================= -Most of the modifications of MEEP are in dft.cpp, but some too in meep.hpp. Also, I modified meep.scm and meep.scm.i (don't know if both are necessary to modify) to have a nice scheme function. +Most of the modifications of MEEP are in dft.cpp, but some too in meep.hpp. Also, meep.scm and meep.scm.i are modified (I don't know if both are necessary to modify) to have a nice scheme function. </pre>rjmSat, 16 Jul 2011 08:48:13 -0000https://sourceforge.netb2bff8cf1d9697b622267e38129fc5e6a0ffde81https://sourceforge.net/p/meepext/wiki/Home/<pre>--- v12 +++ v13 @@ -28,7 +28,7 @@ 4. when a flux plane is defined between grid points, MEEP will use 2 planes with DFT data, both located on grid points, and weigh them accordingly such that the fluxes shown with (display-fluxes ...) correspond with the flux at the requested position. When this data is saved by the function I've introduced, both DFT planes are exported including the proper weight factors. For a DFT on a plane, this means that 3D data is exported. Sum the data in this 3rd dimension to get the DFT on the desired plane . -5. Adding multiple flux regions to a single flux object, and then exporting it, **is not tested by me.** Probably doesn't work! +5. Adding multiple flux regions to a single flux object, and then exporting it, **is not supported!** 6. Exporting flux objects when periodic boundary conditions are in use **is not tested by me!** However, I think it should work. </pre>rjmMon, 04 Jul 2011 20:30:31 -0000https://sourceforge.net5e26d355fdd789d8e39388c21dd3bff0452e5fc9https://sourceforge.net/p/meepext/wiki/Home/<pre>--- v11 +++ v12 @@ -26,13 +26,13 @@ 3. When exporting fluxes, the electric field component is exported with the necessary weights to include the surface area/volume. -4. when a flux plane is defined between grid points, MEEP will use 2 planes with DFT data, both located on grid points, and weigh them accordingly such that the fluxes shown with (display-fluxes ...) correspond with the flux at the requested position. When this data is -saved by the function I've introduced, both DFT planes are exported including the proper weight factors. - -5. Adding multiple flux regions to a single flux object, and then exporting it, is not tested by me. Probably doesn't work! -6. Exporting flux objects when periodic boundary conditions are in use is not tested by me! However, I think it should work. - -7. I haven't tested cylindrical coordinates. +4. when a flux plane is defined between grid points, MEEP will use 2 planes with DFT data, both located on grid points, and weigh them accordingly such that the fluxes shown with (display-fluxes ...) correspond with the flux at the requested position. When this data is saved by the function I've introduced, both DFT planes are exported including the proper weight factors. For a DFT on a plane, this means that 3D data is exported. Sum the data in this 3rd dimension to get the DFT on the desired plane . + +5. Adding multiple flux regions to a single flux object, and then exporting it, **is not tested by me.** Probably doesn't work! + +6. Exporting flux objects when periodic boundary conditions are in use **is not tested by me!** However, I think it should work. + +7. I **haven't tested** cylindrical coordinates. 8. An additional quirk is that in contrast to the normal output-Xfield functions, the exported data just contains the contents in memory. This means that if symmetry planes are used, you don't get the full solution on disk, but just the part that is actually calculated. You have to unfold the symmetry yourself. This is because I simply didn't get how in the source code the output-Xfield functions take care of the symmetry. </pre>rjmMon, 06 Jun 2011 07:46:42 -0000https://sourceforge.net29ac579a439945e615cca561648ab09d87a89470https://sourceforge.net/p/meepext/wiki/Home/<pre>--- v10 +++ v11 @@ -43,7 +43,16 @@ DFT ------- -Finally, it should be possible to directly add DFT objects instead of using flux objects with (define mydft (meep-fields-add-dft Ez (volume (size ...) (center ...)) freqmin freqmax Nfreq false)) (source: http://article.gmane.org/gmane.comp.science.electromagnetism.meep.general/2834/match=add_dft), but I got errors ("No matching method for generic function `meep_fields_add_dft'"). If anyone finds out how to to this, the dft should be exported to disk with +Finally, it should be possible to directly add DFT objects instead of using flux objects with + +~~~~~~ +:::scheme +(define mydft (meep-fields-add-dft Ez (volume (size ...) (center ...)) freqmin freqmax Nfreq false)) +~~~~~~ + +source: http://article.gmane.org/gmane.comp.science.electromagnetism.meep.general/2834/match=add_dft + +But I got errors ("No matching method for generic function `meep_fields_add_dft'"). If anyone finds out how to to this, the dft should be exported to disk with ~~~~~~ :::scheme </pre>rjmSun, 05 Jun 2011 08:08:21 -0000https://sourceforge.net61b23d0b6f77d2e84827e2551ff0f07a2fba5051https://sourceforge.net/p/meepext/wiki/Home/<pre>--- v9 +++ v10 @@ -4,43 +4,55 @@ Fluxes --- -The function to save the dft data in human readable form (well, with the help of MATLAB) is called *pretty-save-flux*, and is called like (pretty-save-flux "filename" fx) where fx is a flux object. Also see the example [test ctl] file. It simply contains a single dipole in vacuum, and 3 flux objects are created, one in each principal direction. After the simulation, the 3 flux objects are exported to disk and one can find 3 HDF5 files, each containing the appropriate E- and H-fields (real and imaginary parts) for each flux object, for just as many frequencies as are specified in the ctl file. - -Quirks +The function to save the dft data in human readable form (well, with the help of MATLAB) is called *pretty-save-flux*, and is called like + +~~~~~~ +:::scheme +(pretty-save-flux "filename" fx) +~~~~~~ + +where fx is a flux object. Also see the example [test ctl] file for an example how to use it and some output. The [test ctl] file contains a single dipole in vacuum, and 3 flux objects are created, one in each principal direction. After the simulation, the 3 flux objects are exported to disk and one can find 3 HDF5 files, each containing the appropriate E- and H-fields (real and imaginary parts) for each flux object, for just as many frequencies as are specified in the ctl file. + +Quirks with flux export ------ 1. When exporting *fluxes* to disk, the data is always exported such, that multiplying, in a point-wise fashion, the relevant e-field and h-field components and summing the resulting matrix over all rows and columns gives the flux. In MATLAB language: assume Ex and Ey are 2d matrices containing the x-component and y-component of the electric field, as exported from the computer memory to disk. Similarly, assume Hx and Hy to be the same for the H-field. Then the total flux is given by sum(sum(Ex.\*Hy+Ey.\*Hx)). Note the plus, and not a minus. This is due to MEEP, as it creates flux objects that internally weigh the 2nd electric field component with a negative factor. 2. Related to the above, the 2nd exported electric field component is exported with an additional -1 factor. Therefore, to get the actual electric field component, multiply with -1. These fields are: - Flux in x-direction: Ez - Flux in y-direction: Ex - Flux in z-direction: Ey + * Flux in x-direction: Ez + * Flux in y-direction: Ex + * Flux in z-direction: Ey 3. When exporting fluxes, the electric field component is exported with the necessary weights to include the surface area/volume. 4. when a flux plane is defined between grid points, MEEP will use 2 planes with DFT data, both located on grid points, and weigh them accordingly such that the fluxes shown with (display-fluxes ...) correspond with the flux at the requested position. When this data is saved by the function I've introduced, both DFT planes are exported including the proper weight factors. 5. Adding multiple flux regions to a single flux object, and then exporting it, is not tested by me. Probably doesn't work! 6. Exporting flux objects when periodic boundary conditions are in use is not tested by me! However, I think it should work. 7. I haven't tested cylindrical coordinates. 8. An additional quirk is that in contrast to the normal output-Xfield functions, the exported data just contains the contents in memory. This means that if symmetry planes are used, you don't get the full solution on disk, but just the part that is actually calculated. You have to unfold the symmetry yourself. This is because I simply didn't get how in the source code the output-Xfield functions take care of the symmetry. Quirks 2-4 are actually just because of the way MEEP sets up the flux objects and the corresponding DFT objects. Nothing to worry about, but something one should know. DFT ------- Finally, it should be possible to directly add DFT objects instead of using flux objects with (define mydft (meep-fields-add-dft Ez (volume (size ...) (center ...)) freqmin freqmax Nfreq false)) (source: http://article.gmane.org/gmane.comp.science.electromagnetism.meep.general/2834/match=add_dft), but I got errors ("No matching method for generic function `meep_fields_add_dft'"). If anyone finds out how to to this, the dft should be exported to disk with - *(pretty-save-dft "ez" mydft) * + +~~~~~~ +:::scheme +(pretty-save-dft "ez" mydft) +~~~~~~ + but I couldn't test this. -Update: it seems that the correct syntax for adding a DFT object is not to specify a volume, but a volume list. Not tested so far. +**Update:** it seems that the correct syntax for adding a DFT object is not to specify a volume, but a volume list. Not tested so far. Hacking/Improving ================= </pre>rjmSun, 05 Jun 2011 08:06:41 -0000https://sourceforge.netbc16b49bb1f7b509a13b110d8e42ad191f3f8e3bhttps://sourceforge.net/p/meepext/wiki/Home/<pre>--- v8 +++ v9 @@ -10,33 +10,35 @@ ------ 1. When exporting *fluxes* to disk, the data is always exported such, that multiplying, in a point-wise fashion, the relevant e-field and h-field components and summing the resulting matrix over all rows and columns gives the flux. In MATLAB language: assume Ex and Ey are 2d -matrices containing the x-component and y-component of the electric field, as exported from the computer memory to disk. Similarly, assume Hx and Hy to be the same for the H-field. Then the total flux is given by sum(sum(Ex.*Hy+Ey.*Hx)). Note the plus, and not a minus. This is due to MEEP, as it creates flux objects that internally weigh the 2nd electric field component with a negative factor. - +matrices containing the x-component and y-component of the electric field, as exported from the computer memory to disk. Similarly, assume Hx and Hy to be the same for the H-field. Then the total flux is given by sum(sum(Ex.\*Hy+Ey.\*Hx)). Note the plus, and not a minus. This is due to MEEP, as it creates flux objects that internally weigh the 2nd electric field component with a negative factor. + 2. Related to the above, the 2nd exported electric field component is exported with an additional -1 factor. Therefore, to get the actual electric field component, multiply with -1. These fields are: Flux in x-direction: Ez Flux in y-direction: Ex Flux in z-direction: Ey 3. When exporting fluxes, the electric field component is exported with the necessary weights to include the surface area/volume. 4. when a flux plane is defined between grid points, MEEP will use 2 planes with DFT data, both located on grid points, and weigh them accordingly such that the fluxes shown with (display-fluxes ...) correspond with the flux at the requested position. When this data is saved by the function I've introduced, both DFT planes are exported including the proper weight factors. 5. Adding multiple flux regions to a single flux object, and then exporting it, is not tested by me. Probably doesn't work! 6. Exporting flux objects when periodic boundary conditions are in use is not tested by me! However, I think it should work. 7. I haven't tested cylindrical coordinates. 8. An additional quirk is that in contrast to the normal output-Xfield functions, the exported data just contains the contents in memory. This means that if symmetry planes are used, you don't get the full solution on disk, but just the part that is actually calculated. You have to unfold the symmetry yourself. This is because I simply didn't get how in the source code the output-Xfield functions take care of the symmetry. Quirks 2-4 are actually just because of the way MEEP sets up the flux objects and the corresponding DFT objects. Nothing to worry about, but something one should know. DFT ------- -Finally, it should be possible to directly add DFT objects instead of using flux objects with (define mydft (meep-fields-add-dft Ez (volume (size ...) (center ...)) freqmin freqmax Nfreq false)) (source: http://article.gmane.org/gmane.comp.science.electromagnetism.meep.general/2834/match=add_dft), but I got errors ("No matching method for generic function `meep_fields_add_dft'"). If anyone finds out how to to this, the dft should be exported to disk with (pretty-save-dft "ez" mydft) but I couldn't test this. +Finally, it should be possible to directly add DFT objects instead of using flux objects with (define mydft (meep-fields-add-dft Ez (volume (size ...) (center ...)) freqmin freqmax Nfreq false)) (source: http://article.gmane.org/gmane.comp.science.electromagnetism.meep.general/2834/match=add_dft), but I got errors ("No matching method for generic function `meep_fields_add_dft'"). If anyone finds out how to to this, the dft should be exported to disk with + *(pretty-save-dft "ez" mydft) * +but I couldn't test this. Update: it seems that the correct syntax for adding a DFT object is not to specify a volume, but a volume list. Not tested so far. </pre>rjmSat, 04 Jun 2011 19:59:01 -0000https://sourceforge.net1e15f95e34c9a66aad5e72438ec77a399ec9cf9dhttps://sourceforge.net/p/meepext/wiki/Home/<pre>--- v7 +++ v8 @@ -24,6 +24,7 @@ 5. Adding multiple flux regions to a single flux object, and then exporting it, is not tested by me. Probably doesn't work! 6. Exporting flux objects when periodic boundary conditions are in use is not tested by me! However, I think it should work. + 7. I haven't tested cylindrical coordinates. 8. An additional quirk is that in contrast to the normal output-Xfield functions, the exported data just contains the contents in memory. This means that if symmetry planes are used, you don't get the full solution on disk, but just the part that is actually calculated. You have to unfold the symmetry yourself. This is because I simply didn't get how in the source code the output-Xfield functions take care of the symmetry. </pre>Robert MoerlandSat, 04 Jun 2011 19:40:21 -0000https://sourceforge.netc0851beb652bf53b820758120124d1b72a0174eahttps://sourceforge.net/p/meepext/wiki/Home/<pre>--- v6 +++ v7 @@ -35,20 +35,11 @@ DFT ------- -Finally, it should be possible to directly add DFT objects instead of -using flux objects with (define mydft (meep-fields-add-dft Ez (volume -(size ...) (center ...)) freqmin freqmax Nfreq false)) (source: -http://article.gmane.org/gmane.comp.science.electromagnetism.meep.general/2834/match=add_dft), -but I got errors ("No matching method for generic function -`meep_fields_add_dft'"). If anyone finds out how to to this, the dft -should be exported to disk with (pretty-save-dft "ez" mydft) but I -couldn't test this. - +Finally, it should be possible to directly add DFT objects instead of using flux objects with (define mydft (meep-fields-add-dft Ez (volume (size ...) (center ...)) freqmin freqmax Nfreq false)) (source: http://article.gmane.org/gmane.comp.science.electromagnetism.meep.general/2834/match=add_dft), but I got errors ("No matching method for generic function `meep_fields_add_dft'"). If anyone finds out how to to this, the dft should be exported to disk with (pretty-save-dft "ez" mydft) but I couldn't test this. + Update: it seems that the correct syntax for adding a DFT object is not to specify a volume, but a volume list. Not tested so far. Hacking/Improving ================= -Most of the modifications of MEEP are in dft.cpp, but -some too in meep.hpp. Also, I modified meep.scm and meep.scm.i (don't -know if both are necessary to modify) to have a nice scheme function. +Most of the modifications of MEEP are in dft.cpp, but some too in meep.hpp. Also, I modified meep.scm and meep.scm.i (don't know if both are necessary to modify) to have a nice scheme function. </pre>Robert MoerlandSat, 04 Jun 2011 16:50:33 -0000https://sourceforge.net019c809e84468a5bd0193d613c00da69d645b7abhttps://sourceforge.net/p/meepext/wiki/Home/<pre>--- v5 +++ v6 @@ -1,50 +1,53 @@ -Use +Export fluxes and DFT data +========================== + +Fluxes --- The function to save the dft data in human readable form (well, with the help of MATLAB) is called *pretty-save-flux*, and is called like (pretty-save-flux "filename" fx) where fx is a flux object. Also see the example [test ctl] file. It simply contains a single dipole in vacuum, and 3 flux objects are created, one in each principal direction. After the simulation, the 3 flux objects are exported to disk and one can find 3 HDF5 files, each containing the appropriate E- and H-fields (real and imaginary parts) for each flux object, for just as many frequencies as are specified in the ctl file. Quirks ------ 1. When exporting *fluxes* to disk, the data is always exported such, that multiplying, in a point-wise fashion, the relevant e-field and h-field components and summing the resulting matrix over all rows and columns gives the flux. In MATLAB language: assume Ex and Ey are 2d matrices containing the x-component and y-component of the electric field, as exported from the computer memory to disk. Similarly, assume Hx and Hy to be the same for the H-field. Then the total flux is given by sum(sum(Ex.*Hy+Ey.*Hx)). Note the plus, and not a minus. This is due to MEEP, as it creates flux objects that internally weigh the 2nd electric field component with a negative factor. 2. Related to the above, the 2nd exported electric field component is exported with an additional -1 factor. Therefore, to get the actual electric field component, multiply with -1. These fields are: Flux in x-direction: Ez Flux in y-direction: Ex Flux in z-direction: Ey 3. When exporting fluxes, the electric field component is exported with the necessary weights to include the surface area/volume. 4. when a flux plane is defined between grid points, MEEP will use 2 planes with DFT data, both located on grid points, and weigh them accordingly such that the fluxes shown with (display-fluxes ...) correspond with the flux at the requested position. When this data is saved by the function I've introduced, both DFT planes are exported including the proper weight factors. 5. Adding multiple flux regions to a single flux object, and then exporting it, is not tested by me. Probably doesn't work! 6. Exporting flux objects when periodic boundary conditions are in use is not tested by me! However, I think it should work. 7. I haven't tested cylindrical coordinates. 8. An additional quirk is that in contrast to the normal output-Xfield functions, the exported data just contains the contents in memory. This means that if symmetry planes are used, you don't get the full solution on disk, but just the part that is actually calculated. You have to unfold the symmetry yourself. This is because I simply didn't get how in the source code the output-Xfield functions take care of the symmetry. Quirks 2-4 are actually just because of the way MEEP sets up the flux objects and the corresponding DFT objects. Nothing to worry about, but something one should know. -Add DFT +DFT ------- Finally, it should be possible to directly add DFT objects instead of using flux objects with (define mydft (meep-fields-add-dft Ez (volume (size ...) (center ...)) freqmin freqmax Nfreq false)) (source: http://article.gmane.org/gmane.comp.science.electromagnetism.meep.general/2834/match=add_dft), but I got errors ("No matching method for generic function `meep_fields_add_dft'"). If anyone finds out how to to this, the dft should be exported to disk with (pretty-save-dft "ez" mydft) but I couldn't test this. Update: it seems that the correct syntax for adding a DFT object is not to specify a volume, but a volume list. Not tested so far. Hacking/Improving ------------------ +================= Most of the modifications of MEEP are in dft.cpp, but some too in meep.hpp. Also, I modified meep.scm and meep.scm.i (don't </pre>Robert MoerlandSat, 04 Jun 2011 16:36:51 -0000https://sourceforge.netf1f254121d86e29a2809d4e846e3bd32300bf3a2https://sourceforge.net/p/meepext/wiki/Home/<pre>--- v4 +++ v5 @@ -1,72 +1,51 @@ Use --- -The function to save the dft data in -human readable form (well, with the help of MATLAB) is called -pretty-save-flux, and is called like (pretty-save-flux "filename" fx) -where fx is a flux object. Also see the example [test ctl] file. It simply contains a single dipole in vacuum, and 3 flux objects are created, one in each principal direction. After the -simulation, the 3 flux objects are exported to disk and one can find 3 -HDF5 files, each containing the appropriate E- and H-fields (real and -imaginary parts) for each flux object, for just as many frequencies as -are specified in the ctl file. - +The function to save the dft data in human readable form (well, with the help of MATLAB) is called *pretty-save-flux*, and is called like (pretty-save-flux "filename" fx) where fx is a flux object. Also see the example [test ctl] file. It simply contains a single dipole in vacuum, and 3 flux objects are created, one in each principal direction. After the simulation, the 3 flux objects are exported to disk and one can find 3 HDF5 files, each containing the appropriate E- and H-fields (real and imaginary parts) for each flux object, for just as many frequencies as are specified in the ctl file. + Quirks ------ -1. When exporting *fluxes* to disk, the data is always exported such, -that multiplying, in a point-wise fashion, the relevant e-field and -h-field components and summing the resulting matrix over all rows and -columns gives the flux. In MATLAB language: assume Ex and Ey are 2d -matrices containing the x-component and y-component of the electric -field, as exported from the computer memory to disk. Similarly, assume -Hx and Hy to be the same for the H-field. Then the total flux is given -by sum(sum(Ex.*Hy+Ey.*Hx)). Note the plus, and not a minus. This is due -to MEEP, as it creates flux objects that internally weigh the 2nd -electric field component with a negative factor. - -2. Related to the above, the 2nd exported electric field component is -exported with an additional -1 factor. Therefore, to get the actual -electric field component, multiply with -1. These fields are: -Flux in x-direction: Ez -Flux in y-direction: Ex -Flux in z-direction: Ey - -3. When exporting fluxes, the electric field component is exported with -the necessary weights to include the surface area/volume. - -4. when a flux plane is defined between grid points, MEEP will use 2 -planes with DFT data, both located on grid points, and weigh them -accordingly such that the fluxes shown with (display-fluxes ...) -correspond with the flux at the requested position. When this data is -saved by the function I've introduced, both DFT planes are exported -including the proper weight factors. - -5. Adding multiple flux regions to a single flux object, and then -exporting it, is not tested by me. Probably doesn't work! -6. Exporting flux objects when periodic boundary conditions are in -use is not tested by me! However, I think it should work. +1. When exporting *fluxes* to disk, the data is always exported such, that multiplying, in a point-wise fashion, the relevant e-field and h-field components and summing the resulting matrix over all rows and columns gives the flux. In MATLAB language: assume Ex and Ey are 2d +matrices containing the x-component and y-component of the electric field, as exported from the computer memory to disk. Similarly, assume Hx and Hy to be the same for the H-field. Then the total flux is given by sum(sum(Ex.*Hy+Ey.*Hx)). Note the plus, and not a minus. This is due to MEEP, as it creates flux objects that internally weigh the 2nd electric field component with a negative factor. + +2. Related to the above, the 2nd exported electric field component is exported with an additional -1 factor. Therefore, to get the actual electric field component, multiply with -1. These fields are: + Flux in x-direction: Ez + Flux in y-direction: Ex + Flux in z-direction: Ey + +3. When exporting fluxes, the electric field component is exported with the necessary weights to include the surface area/volume. + +4. when a flux plane is defined between grid points, MEEP will use 2 planes with DFT data, both located on grid points, and weigh them accordingly such that the fluxes shown with (display-fluxes ...) correspond with the flux at the requested position. When this data is +saved by the function I've introduced, both DFT planes are exported including the proper weight factors. + +5. Adding multiple flux regions to a single flux object, and then exporting it, is not tested by me. Probably doesn't work! +6. Exporting flux objects when periodic boundary conditions are in use is not tested by me! However, I think it should work. 7. I haven't tested cylindrical coordinates. -8. An additional quirk is that in contrast to the normal output-Xfield -functions, the exported data just contains the contents in memory. This -means that if symmetry planes are used, you don't get the full solution -on disk, but just the part that is actually calculated. You have to -unfold the symmetry yourself. This is because I simply didn't get how in -the source code the output-Xfield functions take care of the symmetry. +8. An additional quirk is that in contrast to the normal output-Xfield functions, the exported data just contains the contents in memory. This means that if symmetry planes are used, you don't get the full solution on disk, but just the part that is actually calculated. You have to unfold the symmetry yourself. This is because I simply didn't get how in the source code the output-Xfield functions take care of the symmetry. Quirks 2-4 are actually just because of the way MEEP sets up the flux objects and the corresponding DFT objects. Nothing to worry about, but something one should know. +Add DFT +------- + Finally, it should be possible to directly add DFT objects instead of using flux objects with (define mydft (meep-fields-add-dft Ez (volume (size ...) (center ...)) freqmin freqmax Nfreq false)) (source: http://article.gmane.org/gmane.comp.science.electromagnetism.meep.general/2834/match=add_dft), but I got errors ("No matching method for generic function `meep_fields_add_dft'"). If anyone finds out how to to this, the dft should be exported to disk with (pretty-save-dft "ez" mydft) but I -couldn't test this. - -Hacking/Improving: most of the modifications of MEEP are in dft.cpp, but +couldn't test this. + +Update: it seems that the correct syntax for adding a DFT object is not to specify a volume, but a volume list. Not tested so far. + +Hacking/Improving +----------------- + +Most of the modifications of MEEP are in dft.cpp, but some too in meep.hpp. Also, I modified meep.scm and meep.scm.i (don't know if both are necessary to modify) to have a nice scheme function. </pre>Robert MoerlandSat, 04 Jun 2011 16:27:02 -0000https://sourceforge.netf66ebf191c093f058a6660883bfd37651d1e638b