-
Notifications
You must be signed in to change notification settings - Fork 5
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
Handle "extras" when multiple plates are concatenated #37
Comments
I cooked a workaround script as I am not 100% sure what would be the best place to add this in wellmap.file:
|
Thanks for the feature request! This should definitely be supported; I think I just overlooked this combination of features. In your specific case, though, I'd probably recommend specifying the incubation times in the layout itself (e.g. Going back to the feature request, it's a bit awkward to try to fit all the concatenated extras into a single dictionary. The issue is that the aggregator file can also have extras, and there needs to be a way to distinguish those keys and the keys identifying the concatenated files. If they both go at the top-level of the dictionary, they would be indistinguishable. If the aggregator file gets it's own special key in the top level dictionary, then the format of the extras dictionary would change depending on whether the file uses I think a better solution is to return two extras dictionaries: one for the main file, and then another for the concatenated (and maybe included?) files. That way, both of these dictionaries would always have the same structure, and none of the keys would be ambiguous. Scripts that want to handle concatenated input files would have to check both sets of extras, and merge them as necessary. I'd rather not make scripts go through this effort, but I think it's unavoidable since there's no general purpose way to merge arbitrary data structures like these. The signature for |
Thanks very much for sharing your thoughts. What I ended up doing goes along what you suggested:
Not sure how elegant this is (not very much) but I have built downstream analysis based on this approach. This becomes a convention in my plate TOML files: if something is defined in the aggregator then it applies to all plates.
In summary, I adopted this solution to avoid repeating the same parameters across plates, such repeats are always source of evil. I hope this is somewhat instructive to others. This approach still allows defining different parameters in the individual plates. A consistency check of "if defined in aggregator and plate TOML -> throw error" is left to the user for now. |
I close this as it became stale and I can live with my own solution sketched above. |
I'm going to keep this issue open, because I do want to eventually handle concatenated extras in the way outlined above. |
Hi Kale,
Thanks for all your efforts in maintaining this pioneer project. I suspect this is more of a feature request than a bug report:
I have an aggregator.toml file:
and the two other toml files. Each of those also contains extras. When doing
wellmap.load(aggregator.toml, extras=True)
only the extra_main=1 is returned but none of the "extras" defined in the actual layout TOML files. Is this intended? Should it not return a dict of dicts with the top level aggregator dict having keys defined under [meta.concat]?
The use case I am building aims to link data descriptors to routines that plot the data processed from the wells. E.g. in this case incubation time (1h vs 5h) should show up in subplot titles. I feel such annotative pieces of text have the right place in TOML files, this way plotting routines can remain much more generic and reusable.
The text was updated successfully, but these errors were encountered: