You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hat tip to Lixin and Yu who discovered the following problem (1) after laborious debugging:
1.Apparently parallelization for python fails when multiple processes are operating on the same instance from the same class object.
This also helps to keep the OTF class itself smaller and focused, while freeing up the predict functions to be used for other purposes.
For instance, the module I'm developing of gp_from_aimd has great cause to use the predict functions, and to avoid duplicating code, having them be in a different file allows them to be called without an OTF instance. I currently have implemented this in my development branch, for reviving gp_from_aimd. Lixin has done the same in hers, so one of us will push it eventually.
The text was updated successfully, but these errors were encountered:
@YuuuuXie @nw13slx Is there still a parallelization bug? I remember noticing an issue with the parallelization in otf a few months ago, but patched it with 5dd377a and haven't noticed any problems since. Seems that the parallel methods as implemented work fine and give a significant speed up.
But yes, the predict on structure methods can be moved, perhaps changed to methods of the gp class.
To do: Test an OTF job on Odyssey to ensure this works in parallel. Test if moving it to another file breaks anything (moving it outside of a class seems to make it work okay, says Yu).
Hat tip to Lixin and Yu who discovered the following problem (1) after laborious debugging:
1.Apparently parallelization for python fails when multiple processes are operating on the same instance from the same class object.
For instance, the module I'm developing of gp_from_aimd has great cause to use the predict functions, and to avoid duplicating code, having them be in a different file allows them to be called without an OTF instance. I currently have implemented this in my development branch, for reviving gp_from_aimd. Lixin has done the same in hers, so one of us will push it eventually.
The text was updated successfully, but these errors were encountered: