Closed RMichae1 closed 9 months ago
While addressing this bug, I recommend to also address "cosmetic" Attribute Error arising from the added BaseVAE class.
Multiprocessing attempts to pickle BaseVAE lambda objects. This is wrapped, but appears as Error to the user. Gracefully wrap and perhaps suggest to not multiprocess here.
Traceback (most recent call last): File "/Users/rcml/poli/src/poli/objective.py", line 158, in run conn.send(["ATTRIBUTE", attribute]) File "/Users/rcml/miniforge3/envs/poli__protein_cbas/lib/python3.9/multiprocessing/connection.py", line 206, in send self._send_bytes(_ForkingPickler.dumps(obj)) File "/Users/rcml/miniforge3/envs/poli__protein_cbas/lib/python3.9/multiprocessing/reduction.py", line 51, in dumps cls(buf, protocol).dump(obj) AttributeError: Can't pickle local object 'BaseVAE._build_latent_vars.<locals>.<lambda>'
This might be related, and could maybe be addressed by this issue too: the first time we import poli
from an environment that has tensorflow
, we get the following warning:
WARNING:tensorflow:From /usr/local/lib/python3.10/dist-packages/tensorflow/python/compat/v2_compat.py:108: disable_resource_variables (from tensorflow.python.ops.variable_scope) is deprecated and will be removed in a future version.
Instructions for updating:
non-resource variables are not supported in the long term
Hopefully this warning will disappear as soon as we remove the tf v1
compatibility.
Temporarily not an issue if CBas related imports are not in objective module init . Running environments in isolation is advised for the user to not encounter this issue.
under the imports of src/poli/objective_directory/gfp_cbas/make_vae tf v2 behavior is disabled. This kills eager execution across the whole environment. For experiment usage we require eager execution (to be Trieste compatible). Commenting out or removing that line from the code seems to not affect functionality. This has to be confirmed and tested.