Closed
Conversation
added 13 commits
December 7, 2018 20:50
stevengj
reviewed
Dec 31, 2018
Makefile.am
Outdated
| endif | ||
| #if WITH_LIBCTL | ||
| # SUBDIRS += scheme | ||
| #endif |
Collaborator
There was a problem hiding this comment.
this needs to be uncommented
stevengj
reviewed
Dec 31, 2018
| | `Re Ex` | Real part of *x*-directed electric source amplitude | ||
| | `Im Hy` | Imaginary part of *y*-directed magnetic source amplitude | ||
| | `norm` | Sum of squared magnitudes of all source components of all field types | ||
| | `indicator` | Binary indicator function: 1 if any source component has nonzero amplitude, 0 otherwise |
Collaborator
There was a problem hiding this comment.
It seems more consistent with the other APIs if you just pass a component Ex, Hy, etcetera, and it gives you a complex array. Any other computations can be done in post-processing.
stevengj
reviewed
Dec 31, 2018
src/meep.hpp
Outdated
| public: | ||
| virtual ~source_indicator()=0; | ||
| virtual bool point_in_source(const vec &p)=0; | ||
| }; |
Collaborator
There was a problem hiding this comment.
Looks like PR #635 leaked into this PR. Can we separate the two?
Collaborator
|
Looks good modulo the three comments above. |
…scheme inclusion from makefile.am
stevengj
pushed a commit
that referenced
this pull request
Jan 7, 2019
* updates * updates * updates * updates * updates * updates * updates * updates * source_slice * updates * removed overlap with geometric_object_source branch, uncommented out scheme inclusion from makefile.am * Replace get_source_slice parsing with just component * Update docs * no need for slice_component!=Permeability
bencbartlett
pushed a commit
to bencbartlett/meep
that referenced
this pull request
Sep 9, 2021
…mp#652) * updates * updates * updates * updates * updates * updates * updates * updates * source_slice * updates * removed overlap with geometric_object_source branch, uncommented out scheme inclusion from makefile.am * Replace get_source_slice parsing with just component * Update docs * no need for slice_component!=Permeability
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The pure-text format of problem definitions in meep is very convenient for scripting, but without visual confirmation of the geometry you specified it can be easy to make inadvertent errors in e.g. the placement and size of geometrical entities. Visualization of the material geometry (e.g.
output_epsilon) has been supported for a long time, but I wasn't aware of any similar functionality for source distributions. In addition to offering a useful sanity check on text-format input files, the ability to visualize the locations and amplitudes of sources may prove useful for analyzing the more complicated source distributions that arise in applications such as adjoint-based sensitivity analysis.This PR extends the existing
array_sliceprotocol, used thus far for field-component arrays, to the acquisition of source-component arrays. It adds a new routine namedget_source_sliceto the python and C++ interfaces, which is handled internally by adding a new branch to the existingdo_get_array_slicemaster routine inarray_slice.cpp.The C++ and python calling conventions are similar to those forget_array_slice/get_array: the user inputs aVolumeand gets back a multidimensional array describing sources at the grid points it encompasses. The specific significance of the entries in the array depend on the input parametersource_slice_type, with 4 possibilities currently supported:source_slice_typesource_slicearrayRe ExIm HznormindicatorAs anticipated in the comments to #635, one use for
source_slicefunctionality is to verify the implementation of sources defined bygeometric_objects.. Inpython/examples/object_source.pyI have put a somewhat contrived example code that illustrates bothgeometric_object_sourcesandsource_slices.The code simply creates a geometry with three distinct source distributions--one conventional source defined by aVolumeand two sources defined bygeometric_objects(oneCylinderand onePrism)--and captures various types ofsource_sliceto visualize aspects of the source distributions, which involve spatially-varying complex amplitudes in addition to the positional restrictions imposed by the defininggeometric_objects.