Database Design

[king-michael]

How should our Database look like?

Updated design

main (contained in main table, no MetaEntry requeired)

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

simulation (MetaGroup)

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?

system (MetaGroup)

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

thermostat (MetaGroup)

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?

barostat (MetaGroup)

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?

[andrejberg]

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

[andrejberg]

@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

[king-michael]

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.

[andrejberg]

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?

[king-michael]

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 immer
• MetaData->keyword=engine : LAMMPS, GROMACS, CHARMM, what ever
• MetaData->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?

[andrejberg]

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?

[king-michael]

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

[andrejberg]

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.

[king-michael]

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

[king-michael]

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.

main (contained in main table, no MetaEntry requeired)

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

simulation (MetaGroup)

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?

system (MetaGroup)

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

thermostat (MetaGroup)

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?

barostat (MetaGroup)

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?

[andrejberg]

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.

[king-michael]

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...

[andrejberg]

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.

[king-michael]

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.