Batch scorefxn evaluation

[john-zcliu]

I need to evaluate scorefxn for a lot of poses, but it seems the scorefxn can't be pickled. More details:

• python: 3.8.19
• pyrosetta: PyRosetta-4 2024 [Rosetta PyRosetta4.Release.python38.ubuntu.cxx11thread.serialization 2024.42+release.3366cf78a3df04339d1982e94531b77b098ddb99]
• OS: ubuntu22.04.5 LTS

def calculate_residue_energies_parallel(pose, scorefxn, num_samples=1000000, num_workers=4):
    ...some code

    # Create tasks for each residue
    tasks = [
        (res, pose.clone(), scorefxn)
        for res in range(1, num_residues + 1)
    ]

    # Use multiprocessing to distribute the work
    with multiprocessing.Pool(num_workers) as pool:
        results = pool.map(calculate_residue_energy_worker, tasks)

    ... more code

Error: TypeError: cannot pickle 'pyrosetta.rosetta.core.scoring.ScoreFunction' object

May I ask if there is a better way of implementing this, or, if there is a version of the scorefxn that I should use.

Many thanks!

[lyskov]

Hm… simplest workaround would probably be to create a separate score function for each process (ie pack not the score function but say its name or some object that specify it)

[john-zcliu]

Thank man! Yes, I ended up with passing the score funciton name into subprocess.

[vmullig]

Note that not all Rosetta scoreterms are threadsafe. Some cache data internally during scoring. Additionally, cloning objects in Rosetta does not reliably produce a deep clone, so scorefunctions or poses derived from a common parent can continue to share data in a way that is not threadsafe. (For poses, detached_copy() is the way to make a threadsafe deep clone.) Use care when parallelizing this.

…

On Wed, Dec 11, 2024, 9:45 AM john-zcliu ***@***.***> wrote: Thank man! Yes, I ended up with passing the score funciton name into subprocess. — Reply to this email directly, view it on GitHub <#257 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABACZUF7IQT42MXBA3H4AJL2FBFW5AVCNFSM6AAAAABSVVOFM6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNJTGQYDONY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[john-zcliu]

Much appriciations!! I would never know about this otherwise. Thanks

[john-zcliu]

After some tweaking, I've settled with passing PDB_ID.pdb string and scorefxn_name to each subprocess and spawn new instances of Pose and scorefxn() objects. I guess something like intramolecular interactions (e.g. new disulfide bonds) or rotamer modifications (e.g. side-chain repacking source) would leave some cached data somewhere. I do have those kinds of reactions in my experiments. So, I grouped similar experiments together for one parallel worker. But, it would be really hard to eyeball it if there is something going wrong. Could you please let me know what data are shared in the scorefxn?

I believe it would be nice to make Pose objects pickle-able. Then, It would make distributed pipelines so much easier without saving files onto disks.

Btw, detached_copy() is not exposed in the python interface. I would be nice to be avaliable though : )

[roccomoretti]

Most PyRosetta builds should be built with serialization. The Pose serialization feature is intended to be used with inter-process communication in a distributed environment. (See pyrosetta.distributedand documentation surrounding it for examples.) -- If this is not working for you for some reason, it would be considered to be a bug.

There should be very little internally cached state on scorefunctions. Scorefunctions initialized with the same weights file and the same energy method options (command line options) should work identically. Again, if they don't, that would be considered a bug.

The issues Vikram mentioned are strictly due to multi-threaded use of these objects. Multi-processor use of the objects ("distributed" type pipelines) should not be affected by those concerns. (Note that Python proper has also historically had issues with multithreading vs. multiprocess parallelization.)

[vmullig]

Also, the ref2015 scorefunction's terms are all threadsafe now. I just meant the hundred or so other scoreterms that are available -- I can't vouch for all of Rosetta scoring.

…

On Thu, Dec 12, 2024 at 1:21 PM Rocco Moretti ***@***.***> wrote: Most PyRosetta builds should be built with serialization. The Pose serialization feature is intended to be used with inter-process communication in a distributed environment. (See pyrosetta.distributedand documentation surrounding it for examples.) -- If this is not working for you for some reason, it would be considered to be a bug. There should be very little internally cached state on scorefunctions. Scorefunctions initialized with the same weights file and the same energy method options (command line options) should work identically. Again, if they don't, that would be considered a bug. The issues Vikram mentioned are strictly due to *multi-threaded* use of these objects. *Multi-processor* use of the objects ("distributed" type pipelines) should not be affected by those concerns. (Note that Python proper has also historically had issues with multithreading vs. multiprocess parallelization.) — Reply to this email directly, view it on GitHub <#257 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABACZUFMR747OIABINY5H5L2FHH3XAVCNFSM6AAAAABSVVOFM6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNJUG43TQMA> . You are receiving this because you commented.Message ID: ***@***.***>

[john-zcliu]

Thank you all for your constructive advice! I do appriciate them. I can happily work with my code now.