-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support Extensions on the end of a Strand #34
Comments
I removed the "High Priority" label, since the workaround with 5'/3' modifications is fairly simple and actually not that hacky. |
Note: after some consideration, it makes sense to have this be a third type of Substrand called Extension. Also, the position of the end of it (the one not connected to the adjacent Domain) should be customizable by the user, by dragging in the web interface, or using units of nanometers for the Python interface. |
This is a reminder to implement the following behavior. Each extension stores a The default offset should be
The default could be 1 nm in each z,y direction (and as usual, if equal to the default then this is not written to the JSON); but we'll adjust this based on how it looks. A feature that would be nice (and toggle-able view the Edit menu whether this happens or not) is that when any of the following happen and affect where an extension is drawn:
|
Release notesSingle-stranded extensionsSingle-stranded extensions on the end of a strand can now be specified. See related notes in the Python package. Like a Loopout, it is single-stranded, so does not occupy a Helix. However, Loopouts always reside between two Domains (which are on a Helix and in general intended to be double-stranded), whereas an Extension is always at the 5' or 3' end of a strand. This is useful for describing toeholds and other single-stranded extensions on the end of a strand, particularly when there is not available space adjacent on the helix to represent it with an unbound Domain: Like a Loopout, an Extension has a number of bases that must be specified when creating it. The displayed length and angle relative to the nearest domain are also configurable: Currently they must be typed in the dialog as shown, but eventually one will be able to click and drag the free end of the extension to change how it is displayed; see #799. |
closed by #800 |
This would give a nice way to specify toeholds and extensions common in DNA strand displacement and structural designs.
See also UC-Davis-molecular-computing/scadnano-python-package#2.
Display
One thing that is not straightforward is how to display such extensions. One idea is to make it a straight line at an angle, with length proportional to the number of DNA bases. Some complications:
What angle?
Should the angle be customizable?
If so, independently for each extension, or just one option in the View menu to apply to all of them?
If it is customizable individually for each extension, then the natural place to store it is in the Design json, rather than as an AppUIState field. But this is a bit ugly; there's very little other UI specifications in the Design object.
Should the length be equivalent to a Domain of the same length? Or should it be shorter, with the DNA bases rendered closer together, to reduce the potential for visual clutter?
Workarounds
If you want to put a single-stranded extension/overhang on a strand before this feature is implemented, there are two solutions. The first is recommended:
5' or 3' modification: Add a 5' or 3' modification to the strand, and specify its
idt_text
to be the sequence you want. Normally the idt_text is a code for a DNA modification, e.g.,/5Biosg/
for 5' biotin. However, it is simply placed inline with the DNA sequence when creating an IDT formatted file. So you can simply give a DNA sequence. For example, here is a screenshot showing how to add a tail of 6 T's to the 3' end of a strand:add crossover to a "fake" helix: This is less elegant, but you can also create a "fake" helix where the single-stranded part is represented as a
Domain
instead of anExtension
:The text was updated successfully, but these errors were encountered: