DD : current sprint - ends 2/6 DD – GUFE 111 - DS, I kinda agree, but it would be really cumbersome. I think protocols should specify whether they can run extensions. So the protocoldagresult for an extendable protocol would return all of the outputs from the items before it as well as its own. DS – I think that may be impossible, because even then the protocoldagresult would need to access the things before it. RG – DD, are you talking about concatenating results in each extension result? That would require N^2 storage. DS – That would be storage-dependent, it could just store the previous trajectory file names/handles DD – It becomes a tradeoff between storage and retrieval time. JC – All you need is a tiny numpy array, right? DD – When it comes to deciding whether to extend a transformation, that should be the job of the “strategist” component. It shouldn’t be the job of the protocol to decide. DS – I think we’d discussed that the protocol WOULD make this choice. DD – So a protocol would either run until it reached a max point or until it satisfied some criteria? DS – RG, I think we decided that the protocol would have this logic. The strategist would decide WHICH edges to run, and IF an extension should be run. RG – I think we’re envisioning a different split than you, DD. DD – Ok, I’ll think more. I’m not sure about how I feel if a whole chain needs to be pulled down when you get a result. (Discussion will continue at a power hour)
PLB 83 IP – This is what I’d mentioned last week - I could run all the tansformations specified in the newl generated edges, but I noticed that TYK2 is a star map. IA initially said it shouldn’t do that, but I found that running the star map looked fine and went over the full dynamic range. DD – I think that meets the criteria for merge, so this should be good to go if you want IP RG – I talked with IA about this. I think the star map is valid, this is just something that happens when you have a common core. But it’s possible that a star map would be a minimum spanning graph. DD – Ok, that makes sense. IP, please coordinate merging/final approval with IA.
PLB 87 Alchemiscale 56 Alchemiscale 70 Alchemiscale 77 GUFE 110 MH – No new updates, I’ll work with DS this afternoon to advance this. IP – Are there any breaking changes expected from your working session with DS? MH – Possibly. We mostly wanted to figure out how to get test cases into this. DS – I suspect we’ll change the serialization format. So old serialized intermediates may no longer load. But the roundtrips didn’t previously work so it’s debatable whether this is breaking. MH –
Perses 1066 IP – Worked with DD on a minimal set of tests for the protocol. Tests benzene to toluene transformation. Still need to work on catching failures. Also need to do a larger test using 20 independent simulations. The nice part is that I’ve integrated the PR from the setting object and the ligand atom mapping with the protocol implementation here. Though I did ask in GUFE PR 116… this works fine but I maybe should have mentioned that the docstring needs to more clearly specify meaning of keys and values. DD – Oh, this is documented in the base class docstring, but not the subclass. RG – I need to unsquash the subclass docstring DS – Also it would be good to mention that the mapping goes FROM A TO B (so the keys are in A and the values are in B). IP – In perses, we have example code in the docstring that documents this sort of thing really well. JC – I’m all for making this as explicit as possible. Mappings as method inputs are a common source of confusion and they can’t be documented too much. IP – I set up a meeting next week with JC and DD to review the testing of the protocol. IP – And I think there will be one more set of changes after this, FYI.
Alchemiscale 46
|
DD : Transformation.mapping as the basis for ChemicalSystem Component relationships in a Protocol DD – Motivated by work on noneqcyclingprotocol with IP. RG – If you have something that’s vanishing/appearing, you’d want it to map to None. But if you have two things appearing, then you’d have two None keys, and a python dict may squash them in a way you can’t follow. DS – This may be a different problem. I think the key that this is happening is if there’s a key/value in one transformation that isn’t in another. Also I know this is scheduled for discussion at a power hour so maybe we shouldn’t go too far here without IA. (JC will join Friday noon EST power hour)
JC – IA was concerned about how we’re going to represent transformation for both absolute and relative FE calcs. So he was wondering how we’re going to represent these in a protocol-independent way. JC – … JW – Ok, that makes sense (see recording starting aruon 33 minuteS)
|