Merged
Conversation
…loor from center of geometric object); update test-prism to displace objects through random 3D vector
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
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.
Together with NanoComp/meep#634 and NanoComp/mpb#83, fixes NanoComp/meep#608.
The traditional
libctlparadigm for handling geometric objects poses some difficulties for incorporating prisms, which are more complicated than the existing primitives likeblockandcylinder.In particular, the design of thegeometric_objectstructure assumes that thecenterof an object is independent of the various shape-specific data fields that live in thesubclass_data.This is is not true for prisms, for which thecenteris fixed by thevertices,axis, andheight. (Actually, for right-angle prisms theaxisis not independent either; see below.)In principle, the prism implementation could be shoehorned into the existing paradigm by e.g. eliminating
heightas an independent parameter, in which casecenterwould reemerge as an independent quantity as for the other types of geometric objects. This would at least allow prisms to be implemented without requiring any modifications to the handling of geometric objects. However, it would be unwieldy and inconvenient for users.The more natural approach, already implemented in the python and C++ interfaces, is to have users specify the
verticesandheight,then compute thecenteras a derived quantity. However,libctlin its current form doesn't allow this, for a couple of reasons:centeris a mandatory input parameter when instantiating a geometric object of any type, including prisms. There is no existing framework for instantiating objects in whichcenteris derived from other user-specified quantities.The calling convention for
geom_fix_objectroutine accepts as input ageometric_object o,passed by reference (i.e. not a pointer togeometric_object). This allowsgeom_fix_objectto modify the contents ofo.subclass_data, but noto.center.I have addressed these issues as follows.
1A. For scheme instantiation of prisms in which
centeris to be treated as a derived quantity, I have added a new scheme keywordauto-centeras the value to specify for the mandatorycenterfield. This is a specially-coded value signifying tolibctlthatcenteris to be overwritten as a derived parameter based on the caller'svertices,height, andaxis.1B. On the other hand, in some cases one might want to subject a prism to a rigid translation upon instantiating it---for example, perhaps you want to define two identical prisms separated in space by a displacement vector
Delta.In this case, instead ofauto_centersimply setcenterequal to the desired final center of your prism, and the prism defined byvertices, height, axiswill be rigidly translated in space to be centered at that point.geom_fix_objectso that it now accepts a pointer togeometric_object, allowing thecenterfield to be updated. Of course this revision breaks existing code, but the updates required in themeepandmpbcode bases turn out to be minor, because the only cases in whichgeom_fix_objectneeds to be called explicitly from those codes seem to be cases in which we need to update an entire list of objects, and for that purpose the existing routinegeom_fix_objects0suffices with no change in calling convention needed.Note: I find the name of this routine confusing, and suggest that
geom_fix_objects0be renamedgeom_fix_object_list.In conjunction with accommodating prism instantiation in scheme, I have updated the prism data structure to store more information than it did previously---for example, the vertex coordinates in both the ordinary and prism coordinate systems are stored. This simplifies some handling in
geom.pyand elsewhere.