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
Currently, we use dictionaries, e.g. fmu_instances to enable the process of setting up the simulation APIs, checking a possible license server only n_cpu times, and then simulate again using multiprocessings pool.
The only way I found to enable this setup was to use class attributes, instead of instance attributes. Class attributes are kept in memory, while the pickle creates a new instance each time pool.map (or apply async o.s.) is called.
Researching how multiprocessing and pickle packages work, I could not come up with a better solution.
On the single core, an instance attribute is used. If we are going to multiple cores, the API is stored in the class attribute.
The main issue with using class attributes is that it introduces possible bugs when users implement nested multiprocessing setups.
However, as the time-consuming part is mostly on the simulation part, such nested setups should not be necessary anyway.
The text was updated successfully, but these errors were encountered:
Currently, we use dictionaries, e.g.
fmu_instances
to enable the process of setting up the simulation APIs, checking a possible license server onlyn_cpu
times, and then simulate again using multiprocessings pool.The only way I found to enable this setup was to use class attributes, instead of instance attributes. Class attributes are kept in memory, while the pickle creates a new instance each time pool.map (or apply async o.s.) is called.
Researching how multiprocessing and pickle packages work, I could not come up with a better solution.
On the single core, an instance attribute is used. If we are going to multiple cores, the API is stored in the class attribute.
The main issue with using class attributes is that it introduces possible bugs when users implement nested multiprocessing setups.
However, as the time-consuming part is mostly on the simulation part, such nested setups should not be necessary anyway.
The text was updated successfully, but these errors were encountered: