Deploy Steph's Fragment Knitting tactically (bypass #944)

[phraenquex]

Scope out feasibility - Ruben thinks it should be "pretty simple"< because it looks like Fragmenstein to Squonk.

[phraenquex]

Critical dependency before release to users: deal with PyRosetta problem - either obtain license, or reimplement as OpenMM @matteoferla, create new ticket please.

[phraenquex]

In scope: include the query-expansions to include single-atom variants of things from the Fragment Network.

[matteoferla]

Critical dependency before release to users: deal with PyRosetta problem - either obtain license, or reimplement as OpenMM @matteoferla, create new ticket please.

Xref to issue: matteoferla/Fragmenstein#33

[phraenquex]

About removing PyRosetta and replacing with OpenMM:
Primary goal for this ticket: have it available for release in synch with the frontend features, without PyRosetta (absolute requirement)
If OpenMM is not ready, then just use the RDkit conformation optimization. In that case, create a separate ticket for OpenMM work, and add to green release. (@tdudgeon )

Also, please remove PyRosetta from deployed (but user-invisible) Fragmenstein.

[phraenquex]

Base container already updated to NOT use PyRosetta - existing Fragmenstein job will be redeployed today, and @rsanchezgarc will do sanity checks.

Ticket to restore full minimization by OpenMM: #1078 .

[phraenquex]

If at all possible, have the one-atom expansions included in this release. @rsanchezgarc will coordinate with Steph.

[phraenquex]

Update from @tdudgeon : base container without PyRosetta is now deployed in staging and production, and in the public repository. (Thank you!)

[matteoferla]

Awesome!
If speed is an issue w/ the Fragmenstein part even without PyRosetta minimisation (Wictor, ie. Victor without Igor), I have not tried it but I believe subclassing two modified classes (Wictor and Quicktor) of the main one (Victor) might make it a decent amount faster.
I can test it if needed.
For an experiment last week ("Arthorian quest") I played around with a streamlined Monster and it was mighty faster...

[phraenquex]

@tdudgeon will play with the configuration to find a query and set of filters that will produce output even from the test graph database. @rsanchezgarc will talk Tim through this.

@alanbchristie will investigate a port forwarding / secrets / kube-config solution that would allow tests to access the full production database.

[phraenquex]

@tdudgeon says (in response to @phraenquex's question whether ticket is ready for production: "we really need to add event reporting so that the users can see that something is happening.".

My counter-question (also to @rsanchezgarc) :

• is that a crucial feature for release?
• is that something just for the job execution code?
• How much work?
• When can this get into production? I'm really really anxious to have it finalised: we need it for real science, and we need to move on to next jobs.

[rsanchezgarc]

• I guess that for Fragalysis is not that important since you need to go to Squonk to see the status. Moreover, you can always check the log files to see what is going on.
• It only affects the job code, so it won't modify anything in Fragalysis (@tdudgeon correct me If I am wrong)
• If the latter is true, we could move it to production, leaving the improvements (not only the logs, but also defining parameters for the users) for a future release.

[phraenquex]

This ticket is waiting for #1078.

[mwinokan]

@mwinokan to test

[phraenquex]

Willl be revisited in OSCARS, and no job execution currently in production. So moving to won'tfix.