Open ianmkenney opened 7 months ago
One limitation of GufeTokenizable
s, including ProtocolDAGResult
s: they must be JSON-serializable, and therefore can't have binary data. So any outputs of a ProtocolUnit._execute
method must also be data types that are JSON-serializable.
Is this the case for the outputs added in this PR?
These are not json serializable. I can add another step in (de)serialization for converting to and from base64.
@ijpulidos any idea why my tests fail on license keys?
@ianmkenney My guess is that the secrets fail since it's coming from a fork? Let me dig around and see if there's a way to make this work.
One way would be making a separate PR in the repo, but I'll see if there's another way.
@ianmkenney My guess is that the secrets fail since it's coming from a fork? Let me dig around and see if there's a way to make this work.
One way would be making a separate PR in the repo, but I'll see if there's another way.
That is exactly what is going on, the quick fix is for someone who has write access, to push this branch to the choderalab/feflow
remote, that will trigger the tests to run with the secrets and since the commit hash is the same, github will report the test results here
to kick off ci (you need write access to the repo for this to work)
$ gh pr checkout 44
$ git push origin feature-noneq_cycling_extends
This is currently blocked by #38.
@ianmkenney @dotsdl Is this ready to be reviewed? If so, can you mark it as such? Thanks!
@ijpulidos I think an initial review works, not sure if you want to wait for gufe/openfe v1.0.0 before merging though.
@ijpulidos will make another review now that #38 is in! Thanks @ijpulidos!
I was looking over these changes again, and I think we should take a closer look at how we’re supporting extensions. While this works, I’m not sure it will generalize well to other protocols we plan to host here. Probably worth a bit more discussion to make sure we are not limiting ourselves down the line.
From today's iteration meeting - let's put this on the agenda for the next protocol devs call.
We reached a consensus on that extending protocols depend a lot on what the protocols do themselves, therefore it is expected that create method of the protocol to deal with it in a specific manner.
We should be good to solve the merge conflicts and merge this.
This PR introduces the ability to extend a NonEquilibriumCycling protocol by including serialized and compressed OpenMM State, System, and Integrator in the main simulation units. When instantiating new NonEquilbriumProtocols which extend a previous result, these objects are used to bypass the normal function of the SetupUnit. Closes #2.