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
There is increasing evidentiary support that more fine-grained control over optional simulation parameters is necessary to achieve the closest approximation to real data. This could be supported by adapting the profile table to include per-genome simulation options and parameters values.
We have examples where genomes suffered systematic variation in non-specific cleavage.
The inter-arm anti-diagonal is not apparent in some genomes
Various degrees of CID intensity (including none)
The profile is currently a flat table, which in database language is not first normal form. That is, the cell column is repeated as many times as it has chromosomes. Since cells contain chromosomes, there is a natural hierarchy. To define the profile in another way, is of debatable value in the simple case we are using now.
However, if we were to begin including other runtime options, making the profile much more of a simulation definition, then it would make sense to abandon the flat table. Perhaps, in this case, a mark-up such as yaml and the use of dictionaries.
e.g. Below, we have defaults for control parameters not appearing and in the simplest case, a chromosme would not require anything beyond its name. I am still unsure that this will be appreciated by users.
There is increasing evidentiary support that more fine-grained control over optional simulation parameters is necessary to achieve the closest approximation to real data. This could be supported by adapting the profile table to include per-genome simulation options and parameters values.
The profile is currently a flat table, which in database language is not first normal form. That is, the cell column is repeated as many times as it has chromosomes. Since cells contain chromosomes, there is a natural hierarchy. To define the profile in another way, is of debatable value in the simple case we are using now.
However, if we were to begin including other runtime options, making the profile much more of a simulation definition, then it would make sense to abandon the flat table. Perhaps, in this case, a mark-up such as yaml and the use of dictionaries.
e.g. Below, we have defaults for control parameters not appearing and in the simplest case, a chromosme would not require anything beyond its name. I am still unsure that this will be appreciated by users.
The text was updated successfully, but these errors were encountered: