Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for Melting Pot scenarios #114

Open
s-a-barnett opened this issue Nov 16, 2023 · 6 comments
Open

Add support for Melting Pot scenarios #114

s-a-barnett opened this issue Nov 16, 2023 · 6 comments

Comments

@s-a-barnett
Copy link

Currently, MeltingPotCompatibilityV0 works only when the input env is a substrate, rather than a scenario. This is because self._env.observation_spec()[0] has no attribute "WORLD.RGB". This can be rectified by replacing lines 90-92 of meltingpot_compability.py with

        if type(self._env) is meltingpot.utils.scenarios.scenario.Scenario:
            _env = self._env._substrate
        else:
            _env = self._env
        self.state_space = utils.dm_spec2gym_space(
            _env.observation_spec()[0]["WORLD.RGB"]
        )

and lines 129-131 with

        if type(self._env) is meltingpot.utils.scenarios.scenario.Scenario:
            _env = self._env._substrate
        else:
            _env = self._env
        observation_space = utils.remove_world_observations_from_space(
            utils.dm_spec2gym_space(_env.observation_spec()[0])  # type: ignore

However, the code still runs into a pickling error later down the line. What would be the best way to fix this and add the feature?

@pseudo-rnd-thoughts
Copy link
Member

Thanks for reporting this, what is the difference between a substrate and a scenario?

@elliottower should be able to advise on updating the environment

Could you post the follow up pickle error?

@s-a-barnett
Copy link
Author

Broadly speaking, a scenario is a substrate with a background population controlling some of the player roles. More formally, it is an instance of a substrate (the underlying substrate can be recovered with the _substrate property, as with the above code, but with various modifications made to it. The following code reproduces the error:

from shimmy import MeltingPotCompatibilityV0
import supersuit as ss
from meltingpot import scenario

mp_env = scenario.build_from_config(scenario.get_config('clean_up_0'))
env = MeltingPotCompatibilityV0(env=mp_env)
env = ss.observation_lambda_v0(env, lambda x, _: x["RGB"], lambda s: s["RGB"])
env = ss.frame_stack_v1(env, 4)
env = ss.pettingzoo_env_to_vec_env_v1(env)
env = ss.concat_vec_envs_v1(env, num_vec_envs=1, num_cpus=1, base_class="stable_baselines3")

And this is the error once the adjustments to meltingpot_compatibility.py above are made:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.10/dist-packages/supersuit/vector/vector_constructors.py", line 64, in concat_vec_envs_v1
    vec_env = MakeCPUAsyncConstructor(num_cpus)(*vec_env_args(vec_env, num_vec_envs))
  File "/usr/local/lib/python3.10/dist-packages/supersuit/vector/concat_vec_env.py", line 23, in __init__
    self.vec_envs = vec_envs = [vec_env_fn() for vec_env_fn in vec_env_fns]
  File "/usr/local/lib/python3.10/dist-packages/supersuit/vector/concat_vec_env.py", line 23, in <listcomp>
    self.vec_envs = vec_envs = [vec_env_fn() for vec_env_fn in vec_env_fns]
  File "/usr/local/lib/python3.10/dist-packages/supersuit/vector/vector_constructors.py", line 12, in env_fn
    env_copy = cloudpickle.loads(cloudpickle.dumps(env))
  File "/usr/local/lib/python3.10/dist-packages/cloudpickle/cloudpickle_fast.py", line 73, in dumps
    cp.dump(obj)
  File "/usr/local/lib/python3.10/dist-packages/cloudpickle/cloudpickle_fast.py", line 632, in dump
    return Pickler.dump(self, obj)
TypeError: cannot pickle 'dmlab2d.dmlab2d_pybind.Lab2d' object

@elliottower
Copy link
Member

Thanks for pointing this out, not sure exactly how we would get around the pickling error—I remember running pickle errors previously as well, the lab2d objects don’t seem to be able to be serialized easily via pickle at least.

If it’s not possible to fix the pickling problem I wouldn’t be against adding support for scenarios and just having a disclaimer about the inability to pickle it.

@s-a-barnett
Copy link
Author

Is there a quick way to circumvent the pickling steps and make the code run?

@pseudo-rnd-thoughts
Copy link
Member

Is there a quick way to circumvent the pickling steps and make the code run?

I suspect not using supersuit

@elliottower
Copy link
Member

Yeah unfortunately the supersuit vec env wrapper I believe uses pickling for the multi processing, so can’t really get away from that problem. Maybe if you set number of cpus to one it won’t actually do the pickling?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants