We haven’t ever updated a Fireworks’ metadata after running it, but some options would be:
(i) create a secondary MongoDB collection that stores metadata about Fireworks but is separate from the FireWorks core collections
(ii) update the fw spec within a Firework to include something like “tags” like you said
(iii) update the fw name after completion to include your metadata like you said
(note also that if we are talking about workflow-level metadata, there is also a “metadata” key that belongs to Workflow objects).
The first option is of course completely safe since it’s separate from FireWorks itself.
The second option is fine if you know what you are doing. The built in commands for FireWorks try to encourage safe behavior for the most part, e.g., to prevent you from changing information about how the run was executed after it was executed. But, if you know some MongoDB, you could easily just change the spec using straight Mongo commands. As long as you weren’t reckless, you wouldn’t ruin anything.
The third option seems non-optimal to me. Since the name of the Firework is a string, you won’t be able to structure your metadata very well when embedding it here. Also, I tend to think of the name as something of an id that one wouldn’t expect to change. That said, FireWorks itself doesn’t put any importance in the name and you can change it afterwards if you like (e.g., via MongoDB). But I’d note that some frameworks built on top of FireWorks (e.g., “atomate”) require certain names and if you are using atomate in particular, you shouldn’t change the name afterwards.
Basically, my suggestion is to just use MongoDB to add whatever information you want afterwards. But I’d also be interested to hear the proposed functionality to see if there is something more general to add to FWS.
On Tue, Nov 14, 2017 at 10:59 AM, Jacob Boes [email protected] wrote:
I’ve been using key-value-pairs to help retrieve my calculations after they are submitted for a while, and Fireworks is well suited for this behavior as well, but it seems like there isn’t a good place to store these at the moment.
I’ve tried storing them in “name” and “spec.tags”, but both have drawbacks. There doesn’t seem to be any easy way to modify the “name” entry after the firework is submitted. Similarly, once a firework is completed, the spec field cannot be changed easily. I can understand the desire to make everything in “spec” static after a firework completes because the user risks changing information pertaining to how the calculation was performed. I’m less clear on why there are no means of changing “name” as this field is strictly for the benefit of the user, similar to key-value-pairs.
I’m interested in developing such functionality, but I wanted to check here first to see if I hadn’t missed a similar function for this purpose which has already been implemented. Secondly, I’m interested in input on where the best location to keep such user-defined input would be. “name” seems harmless enough, but perhaps that’s not a good idea for other reasons I hadn’t considered.
Thanks for the feedback,
You received this message because you are subscribed to the Google Groups “fireworkflows” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/fireworkflows.
To view this discussion on the web visit https://groups.google.com/d/msgid/fireworkflows/b44c443b-ec57-48c6-a080-36d554feb4c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.