barisicgroup / unf Goto Github PK

• naStrand field references individual nucleic acid single strands. Equal functionality in the area of proteins is provided by chains field (in proteins). Therefore, it is possible to store a single protein structure consisting of several chains. However, NA single strands are all stored individually -- if more strands should be part of a single structure, group functionality is supposed to be used. Therefore, the behavior of strands and chains is not fully consistent in this regard. Should the strands become children of something like naStructure (same as proteins) or should the proteins be replaced purely with chains and all grouping of chains/strands would have to use groups functionality?

Open for discussion.

Suggestion by Paul Sorensen (@ncadpaul):

It looks like the Id field is a number locally unique to file; could an optional string encoded UUID (see https://datatracker.ietf.org/doc/html/rfc4122) be added per object? For example: “uuid" : "2948446b-6213-44ba-b81f-c4e5f7dab2eb”.
For example, this would assist in mapping from UNF to my apps format for round trip processing in apps like OxDNA / OxView that might support it going forward; otherwise, I have to generate a separate file to track that information.

A possible solution in the current version of UNF:

Utilization of misc field by adding something like uuidMap of a form "id" -> "uuid" where id is a local unique ID in unf, UUID is desired UUID.

Is there a common desire for this feature? How this should be handled on a design side, etc.? Opinions welcome.

All virtual helices contain altPosition and altOrientation fields, which allow overriding their world position with respect to the world origin of a lattice. I feel like that, at the moment, this feature is unnecessary and more of a burden. Can it be removed?

Suggest adding DNA/RNA wildcard base letter ’N’ to “abAbbrev" values, because the user may prefer to use a separate app to do sequence assignment and/or optimization.

Currently, UNF stores a creation date of the structure (field creationDate).
Would it be useful to store also the date of the last modification?
For example, the creation date would be initialized during the conversion from PDB to UNF, and when creating UNF structure from scratch, while the date of last modification would be set by design/simulation programs.

The contents of the UNF file can be perceived as a "molecular scene" in a sense. For example, it may contain a lattice-based DNA structure, combined with coarse-grained protein and a fully atomistic molecule. Thus, the UNF file may contain a multi-component structure (spanning also different abstraction levels) consisting of structures created by various authors.

Example: Imagine a PDB structure converted to UNF using the PDB->UNF converter. Then, edit this UNF file by adding a multilayer DNA origami lattice. The file now contains two structures/components created by different authors.

Right now, the root-level fields name and author refer (according to their description) to a structure name and author, respectively.
However, due to the aforementioned reasons, these fields should probably refer to the file name/author – their semantic meaning should be therefore changed. Moreover, author field (and potentially also DOI ?) should be probably added also to the lattices and structures. This way, more fine-grained distinction of individual parts of the UNF file will be enabled.

I am considering including this feature in one of the upcoming releases.

The root-level comments field, aimed at storing textual comments/notes by the users during the structure design/analysis, would probably benefit from storing also the comment author, i.e. addition of author field to the existing content.

On top of that, replies field could be added, containing IDs of comments which reply to the given one, to allow chaining of comments (similar to Google Docs system).

All of these features are considered for the next release.

Would it be useful to store multiple DOIs, i.e., to convert the string doi field to [string] doi, allowing to reference more related papers? Right now, this can be done by simply storing more DOIs in the string itself but this would provide a better defined way how to achieve this.

Currently, UNF stores lattice cells -> nucleotide references.
However, it seems that it might be desired to also store the nucleotide -> lattice (cell, ...) references.

How this should be stored in UNF? Will it be easy to manage / keep track of when modifying UNF files?

Idea nr. 1:
The nucleotide now contains altPosition field, storing its (freeform) 3D position in the world.
A field called lattPosition could be added storing lattice-based position (how would it look?) .
The existing rules for determining nucleotide position would still apply (alternative position > lattice position).
However, I feel like this may introduce some redundancy to the stored data (as the lattice will reference nucleotides and the nucleotides will reference lattice at the same time).

What is recommended way to represent circular strands in UNF?

Presume having 5’ previous id point to 3’ id, and 3’ next id point to 5’ id.

Perhaps an optional "isCircular" boolean field could be considered.

One parameter which is missing for robust handling of oxDNA (and other simulation types as well) is a box_size argument which could be included with the units section. When converting into and out of simulations, a box needs to be set at some point. If there is not a box provided, we generally set it to 1.5 * (maximum coordinate in any dimension), which is a safe, but generally overestimated box size. By including a box size in UNF, boxes defined in oxDNA or other simulation formats could be maintained through conversion.