You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It isn't clear how hierarchical designs are handled in terms of strand directionality. So if there is an engineered region in the top level that then has its orientation flipped to the lower strand, when navigating into this to define the parts they automatically get added in the conventional top strand approach - but is the assumption that we are looking at the reverse complement (i.e. they are reversed because the parent object is reversed - this is what I assumed would be the case), or is it still looking in the top strand (not reversed) orientation.
I couldn't find any information to give the user any clues .
When I created a combinatorial design with one of the top levels reversed, but the lower layer following the 'forward' notation, the CSV file listed them all in top strand format i.e. the reversed component was not reversed from a part order level.
There may be a discrepance between CSV and SBOL output - I didn't check the latter.
In BASIC assembly we have linkers that can reverse parts or assemblies, and Golden Gate also has reversing destination constructs, so somehow tagging this in CSV files that can produce output would be an interesting proposition. I'm not sure how this would work though!
The text was updated successfully, but these errors were encountered:
My guess is the CSV output is not consistent with SBOL. I believe there were mistakes in the SBOL previously that are fixed, but we will need to check that as well. We recently added the capability of computing the higher-level sequences from the lower-level ones, so doing tests with sequences should help highlight how this works.
Computing the higher level sequences sounds like a good advance - I nearly added this as an issue as I noticed that after assigning all of the lower level sequences, the higher level did not have any sequence.
If you create an Engineered Region and Reverse, then focus into the Engineered Region and add four parts with a composite sequence of acgtcatc, then return to the top level, and select the entire design (blue dashes), you will see the top level sequence has been reverse complemented to gatgacgt
Let me know if this is clear? The CSV issue is a separate problem.
The SBOL resulting from enumeration is indeed dropping the reverse complement information. This is a problem in the libSBOLj enumerate function. The CSV output might also have issues, but it may also be that the CSV output is just giving the wrong answer because the SBOL is incorrect. For now, it is recommended that you do not use reverse complement with Combinatorial Derivations. This will be pretty involved to fix. Reverse complement without combinatorial seems to be working fine.
It isn't clear how hierarchical designs are handled in terms of strand directionality. So if there is an engineered region in the top level that then has its orientation flipped to the lower strand, when navigating into this to define the parts they automatically get added in the conventional top strand approach - but is the assumption that we are looking at the reverse complement (i.e. they are reversed because the parent object is reversed - this is what I assumed would be the case), or is it still looking in the top strand (not reversed) orientation.
I couldn't find any information to give the user any clues .
When I created a combinatorial design with one of the top levels reversed, but the lower layer following the 'forward' notation, the CSV file listed them all in top strand format i.e. the reversed component was not reversed from a part order level.
There may be a discrepance between CSV and SBOL output - I didn't check the latter.
In BASIC assembly we have linkers that can reverse parts or assemblies, and Golden Gate also has reversing destination constructs, so somehow tagging this in CSV files that can produce output would be an interesting proposition. I'm not sure how this would work though!
The text was updated successfully, but these errors were encountered: