Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add DrWatsonSim functionality #333

Draft
wants to merge 8 commits into
base: main
Choose a base branch
from
Draft

Add DrWatsonSim functionality #333

wants to merge 8 commits into from

Conversation

sebastianpech
Copy link
Contributor

@sebastianpech sebastianpech commented Jan 30, 2022

Next up

  • write docstrings
  • add examples from readme to DrWatson doc
  • Include docstrings in the doc
  • add simple "real world" example
  • add "real world" example where a parameter config is loaded and altered and then started as a new simulation.

@codecov
Copy link

codecov bot commented Jan 30, 2022

Codecov Report

Merging #333 (c3c515c) into master (77defda) will decrease coverage by 9.71%.
The diff coverage is 46.62%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #333      +/-   ##
==========================================
- Coverage   92.63%   82.91%   -9.72%     
==========================================
  Files           7        9       +2     
  Lines         665      843     +178     
==========================================
+ Hits          616      699      +83     
- Misses         49      144      +95     
Impacted Files Coverage Δ
src/DrWatson.jl 93.75% <ø> (ø)
src/simulation.jl 12.00% <12.00%> (ø)
src/metadata.jl 71.84% <71.84%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 77defda...c3c515c. Read the comment docs.

Locking is only required when multiple threads write one metadata file at the same time. I think this is a very common problem (IO in mult-threaded env.), so the users have to take care of locking them self.
@Datseris
Copy link
Member

Datseris commented Mar 2, 2022

Alrighty, after the meeting with Alex, here are the actionable points:

  1. A restrictive format of metadata storage has some important advantages: portability, security, standardization.
  2. This restrictive format would limit to the following types: Int, Float64, Bool, String, Symbol. And then, composite Julia types, as well as Vector, Dict of the basic types are also possible.
  3. The output format for the matadata can be a Yaml format. There are several advantages for that: human readable, there is a Julia package that directly transforms dictionaries to Yaml, it is faster to search, and integrates with CaosDB.
  4. Allowing the possibility for "additional fields" for each metadata field is important. Such fields could be a "string describing the metadata field" (like, what does parameter "a" stand for?), or units for the parameter, or whatever.

Alright. I have some ideas on how to do the last point 4. It relies on the concept of additional dictionaries and intuitive commands to add stuff to them. I'm not yet sure on how the final code imlementation would be, and whether we would have many dictionaries each saved to a different file, but we'll see as we go.

First way

So the idea is that whenever a user adds a descriptive field to a metadata entry, a new dinctionary is initialized that has as name the field name. E.g., a user tries to add a "desription" to field "a". A dictionary called "description" is initialized, and then obtains a key-value pair "a" => acxtual description string. When the user tries to add a description to another pameter, the existing "description" dictionary is used.

The way to store this as an additional field of the Metadata struct, that is ::Dict{String, Dict}. So it maps strings (e.g. "description") to actual dictionary instances that contain the metadata descriptions for these fields such as "a" => actual dewscription".

Second way
The second way would be that the actual values of the main dictionary of Metadata are dictionarties themselves, that must always have the "value" key. Other keys of this inner dictionary would be descriptions of the metadata entry such as "description" or "units".


How would be the API for adding descriptions to metadata? I can see several ways (d is always a Metadata instanve)

@describe d["a"] = 10 "descrriptop"
d["a", "descriptiopn"] = (10, "descr")
add!(m, "a" => 10, "description" => 10)

d["a"] = 10
meta!(d, "a"; keywrds....) # keywrds are key-value pairs such as "description" => x, "unitws" =>y (

and more proposals welcomed of course


Based on this twin dictionaries approach, we can allow an infrastructure for "autoextraction" of metadata descriptions. For example. If someone tries to add a Unitful.jl quantity to the metadata, we detect that, and we add the value of the quantity in the metadata, and its units in the "units" twin dictionary.


Other points of discussion that are not directly related with implementation:

  • What are metadata? What separates them from data?
  • XSD basede types

@Datseris
Copy link
Member

Datseris commented Mar 2, 2022

@sebastianpech that's the write down, let me know what you think.

@sebastianpech
Copy link
Contributor Author

@Datseris I have not forgotten about this, just really focusing on finishing my phd at the moment. I'll post my thoughts and ideas about this in the next days.

@Datseris
Copy link
Member

@sebastianpech How is your PhD progressing? Have you defended? Any chance to get back to this?

@sebastianpech
Copy link
Contributor Author

@Datseris I defended my thesis, all done :) I will try to get back to it soon

@Datseris
Copy link
Member

Congratulations man, well deserved!!!

@Datseris
Copy link
Member

Datseris commented Jul 3, 2023

Bump here!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants