Closed king-michael closed 5 years ago
id = Column(Integer(), primary_key=True, index=True)
entry_id = Column(String(50), unique=True, index=True) # should be discussed
owner = Column(String(50), nullable=True)
url = Column(String(255), nullable=True)
path = Column(String(255))
type = Column(String(20), nullable=True)
description = Column(String(1023), nullable=True) # maybe longer in the future
created_on = Column(DateTime(), nullable=True)
added_on = Column(DateTime(), default=datetime.now)
updated_on = Column(DateTime(), default=datetime.now, onupdate=datetime.now)
dt = steps = n_atoms /size
@king-michael Hey, ich werde da morgen nochmal durchschauen aber im prinzip steht das DB model soweit? Wenn ja können wir Phase 1 ja abschließen? VG
Ja soweit schon. Frage ist nur ob wir die Attribute n_steps
, n_atoms
, time_step
im Main brauchen oder nicht in MetaData?
Vorallem da die Database ja für das Labjournal und damit nicht nur für rein Simulationen genutzt werden soll. Wenn ich Simulationen vergleiche und dafür einen Datenbankeintrag kreiere brauche ich z.B. die Attribute nicht. Bzw. wenn es nicht Simulationen gebundene Datenbankeinträge sind. Hab ich viele (Overviews, Vergleiche, Implementationen, Development von Methoden.), das würde ich denke ich mal auch für andere gelten.
Ich würde die Attribute dann eher in MetaData packen, damit bleibt die Datenbank immer noch übersichtlich und gut suchbar wird jedoch breiter anwendbar.
Das ist ein guter Punkt. Was ist mit sim_type
?
Sollen wir das zu type
umbennen und ein sim_type
Eintrag bei den MetaData machen?
Sollen wir das zu type umbennen und ein sim_type Eintrag bei den MetaData machen?
Ja ich denke wir sollten das zu type
umändern, damit wäre es auch universell.
Die Sache mit GROMACS - LAMMPS könnte man ja eher als MetaData im sinne von engine
zb speicher?
Vorschlag:
Main->type
: simulation, overview, was auch immerMetaData->keyword=engine
: LAMMPS, GROMACS, CHARMM, what everMetaData->keyword=sim_type
: irgendwas anderes? swarm simulation, metaDynamic what ever?Oder wie meinst du das mit sim_type
eintrag in MetaData? also sim_type
einfach in einem keyword speichern, oder willst du eine column sim_type
dazufuegen?
Ja doch das ist super. Wir sollten dann blos noch definieren wie unsere MetaGroups heißen sollen und welche MetaEntry zu welcher group dazu gehören.
Ich würde nacher mal das DB model ändern und pushen. Man muss dann wahrscheinlich bei den test daten schauen, dass die mit dem neuen Model noch gehen.
Dannach können wir ja Phase 1 abschließen, weitere Änderungen unter issues sammeln und entscheiden was zu Phase 2 und was zu Phase 3 dazu gehört. Ich würde vorschlagen, dass man Phase 2 so definiert (kannst gerne editieren): https://github.com/king-michael/simulation_database/projects
edit: Achja, mit dem focus, dass man Phase 2 im Alltag benutzen und presentieren kann?
kannst du einfach gerade mal einen Pull Request aufmachen für dein DataModel? dann könnte man es dort diskutieren und den code gerade online reviewn?
Weil ich gerade nicht weiß was du jetzt genau mit MetaGroups / MetaEntry meinst und bevor wir beide jetzt im master rumschmieren
Ja kann ich machen.
Aso ja, damit meine ich eher sowas wie ein CheatSheet für uns (hauptsächlich aus dem ersten beitrag von diesem issue rausgeschrieben):
https://github.com/king-michael/simulation_database/blob/master/development/metadata_structure.md
Da gehts dann eher darum, wie man die Daten in die Datenbank rein schreibt. Die liste kann man bis auf die sachen in main, dann beliebig ändern.
Ja wäre ich auch dafür.
Quasi eine Guideline, ggf. nachher auf API ebene einen Wrapper der die ganzen Argumente nimmt, mit default argumenten und **kwargs
für neue eigene.
Aufjedenfall etwas, das wir auch dokumentieren können damit es für andere nutzbar wird.
Vorschlag für wrapper:
def create_simulation_details(entry_id, n_steps=None, time_step=None, ..., **kwargs):
"""
Function that create simulation details for a given entry_id
and stores them into the database.
Note
------
If the value of an argument is None,
it will **not** be stored into the database.
Parameters:
----------------
entry_id : str
Rendered description for parameters so they are in the docs
"""
input_args = locals()
list_dropped_keys = [k for k,v in input_args.items() if v is None]
for k in list_dropped_keys:
del input_args[k]
... create entry with the rest of the keywords ...
return whatever
Aso ja, damit meine ich eher sowas wie ein CheatSheet für uns (hauptsächlich aus dem ersten beitrag von diesem issue rausgeschrieben):
https://github.com/king-michael/simulation_database/blob/master/development/metadata_structure.md
Ich hab es mal als tabelle umformatiert und eine Spalte für offene Fragen gemacht. Ich kopiers hier drunter, aber dann können wirs hier gerade diskutieren bevor wir es pushen wollen.
keyword | content | OpenQuestions |
---|---|---|
owner | me, you | |
path | where to find the simulation | ? |
url | linked url to the simulation | |
description | description of the simulation | |
created_on | creation date | |
added_on | added to the database | |
updated_on | last update in the database | |
type | what kind of entry is this |
keyword | content | OpenQuestions |
---|---|---|
engine | LAMMPS, GROMACS, CHARMM, etc. | |
sim_type | ? | |
n_steps | (targeted vs simulated?) | |
simulation_length | time units | brauchen wir das? Kann das nicht beim rauslesen berechnet werden? |
time_step | ||
method | unterschied zu sim_type? |
keyword | content | OpenQuestions |
---|---|---|
system_type | protein, mineral, polymere | |
n_atoms | total number of atoms | |
n_solvent | number of solvent atoms | or molecules??? |
n_solute | number of solute atoms |
keyword | content | OpenQuestions |
---|---|---|
thermostat_type | sollten das mapping irgendwo speichern | |
T_start | start temperature | |
T_end | final temperature | |
T_relax | relaxation time | |
thermostat_info | additional parameter | how should we do this? a list of keywords and then seperate keywords into the group? a string? |
keyword | content | OpenQuestions |
---|---|---|
barostat_type | sollten das mapping irgendwo speichern | |
p_coupling | pressure coupling | |
p_start | start pressure | |
p_end | final pressure | |
p_relax | relaxation time | |
barostat_info | additional parameter | how should we do this? a list? a string? |
Ich hab es mal als tabelle umformatiert und eine Spalte für offene Fragen gemacht.
Top!
Ich hab das model angepasst und meine DB mit dem Jupyter Notebook (dass du anscheinend irgendwann mal umgeschrieben hast ;) ) neu aufgesetzt. Kannst du deine DB nochmal aufsetzten, dann haben wir wieder zwei test cases.
Die details view sollte nun auch erstmal gehen. Schön ist es zwar noch nicht aber es funktioniert.
Super! Lass uns einfach morgen einmal kurz drüber reden und die offenen Fragen noch beantworten, dann kann man denke ich phase 1 beenden.
Ich hab das model angepasst und meine DB mit dem Jupyter Notebook (dass du anscheinend irgendwann mal umgeschrieben hast ;) ) neu aufgesetzt. Kannst du deine DB nochmal aufsetzten, dann haben wir wieder zwei test cases.
Hatte es nur ausgeführt. Wird wohl das sein was er als Änderung getrackt hat...
Ok wenn du es nicht editiert hast, dann kann ich mich nicht erinnern es so wie es ist geschrieben zu haben ;D
Ich bin heute wohl erst recht spät in Konstanz. Ich denke aber Phase 1 kannst du ruhig schließen, da das Model so wie es ist flexibel genug ist, dass wir ohne größere Änderungen daran alles implementieren können was nötig ist.
Ah wobei, gerade geschaut, du meinst das mit store dict. Ja das war ich :-)
Mir würde es nur um unsere Benennung gehen von den einzelnen Eigenschaften, also die offenen Fragen in der MetaData_structure.
Aber ja können es schließen, da sich ja am Datenbank design ja nicht mehr ändert, sondern nur das mapping.
How should our Database look like?
Updated design
main (contained in main table, no MetaEntry requeired)
simulation (MetaGroup)
system (MetaGroup)
thermostat (MetaGroup)
barostat (MetaGroup)