C++ to Python Model Translation

[bytetec]

Hi all

I'm currently trying to translate the C++ sugarscape model from https://github.com/FLAMEGPU/FLAMEGPU2/blob/master/examples/cpp/sugarscape/src/main.cu to a Python model. But I am struggling with the following error:

      # Define constants
      AGENT_START_COUNT = int(2)
      # ENV_WIDTH = int(AGENT_COUNT**(1/3))
      ENV_HEIGHT = int(256)
      ENV_WIDTH = int(256)
      AGENT_STATUS_UNOCCUPIED = int(0)
      AGENT_STATUS_OCCUPIED = int(1)
      AGENT_STATUS_MOVEMENT_REQUESTED = int(2)
      AGENT_STATUS_MOVEMENT_UNRESOLVED = int(3)
      # Growback variables
      SUGAR_GROWBACK_RATE = int(1)
      SUGAR_MAX_CAPACITY = int(7)
      
      @pyflamegpu.agent_function
      def movement_request(message_in: pyflamegpu.MessageArray2D, message_out: pyflamegpu.MessageArray2D):
          best_sugar_level = -1
          best_sugar_random = -1
          best_location_id = pyflamegpu.getID()
      
          # if occupied then look for empty cells {
          # find the best location to move to (ensure we don't just pick first cell with max value)
          status = pyflamegpu.getVariableInt("status")
          agent_x = pyflamegpu.getVariableIntArray2("pos", 0)
          agent_y = pyflamegpu.getVariableIntArray2("pos", 1)
      
          # if occupied then look for empty cells
          if status == AGENT_STATUS_MOVEMENT_UNRESOLVED:
              # TODO is it translated correctly?
              for current_message in message_in.wrap(agent_x, agent_y):
                  # if location is unoccupied then check for empty locations
                  if current_message.getVariableInt("status") == AGENT_STATUS_UNOCCUPIED:
                      # if the sugar level at current location is better than currently stored then update
                      message_env_sugar_level = current_message.getVariableInt("env_sugar_level")
                      message_priority = pyflamegpu.random.uniformFloat()
                      if (message_env_sugar_level > best_sugar_level or
                              (message_env_sugar_level == best_sugar_level and message_priority > best_sugar_random)):
                          best_sugar_level = message_env_sugar_level
                          best_sugar_random = message_priority
                          best_location_id = current_message.getVariableInt("location_id")
              # endfor
      
              # if the agent has found a better location to move to then update its state
              # if there is a better location to move to then state indicates a movement request
              # TODO how to translate next line
              # status = best_location_id != flamegpu::ID_NOT_SET ? AGENT_STATUS_MOVEMENT_REQUESTED : AGENT_STATUS_OCCUPIED;
              status = best_location_id != pyflamegpu.getID()
              pyflamegpu.setVariableInt("status", status)
      
          # add a movement request
          message_out.setVariableInt("agent_id", pyflamegpu.getVariableInt("agent_id"))
          message_out.setVariableInt("location_id", best_location_id)
          message_out.setVariableInt("sugar_level", pyflamegpu.getVariableInt("sugar_level"))
          message_out.setVariableInt("metabolism", pyflamegpu.getVariableInt("metabolism"))
          # TODO is it translated correctly?
          message_out.setIndex(agent_x, agent_y)
      
          return pyflamegpu.ALIVE

I think is about the scope of the variable AGENT_STATUS_MOVEMENT_UNRESOLVED and AGENT_STATUS_UNOCCUPIED which are defined outside of the agent function. I see in the IDE that the variable has the correct value. Is the handling of the variables in FLAMEGPU for C++ different to Python or do I missing something else?
Thanks for your help in advance.
Bytetec

[Robadob]

I've now had a better look at this and done some testing.

• The code you've provided, whereby the identifier of the agent function movement_request to codegen.translate() causes only the body of the agent function to be captured. Hence the constants declared before are not available when it's compiled in isolation.
  • It's possible (e.g. this is speculation on my part and would require some testing), we could detect out of scope variables whilst performing the transpilation, and look for them in the file scope to automatically include them in some manner.
• If you pass all the relevant code as to codegen.translate() as a string, since BugFix: Edgecase in handling standalone msg input would break transpilation. #1143 has been merged it will compile correctly.
  • It's not clear how the NVRTC (pure cuda) compiler handles these variables, I expect you will be able to modify them from agent functions. Possibly leading to race conditions etc. Likewise if correct, they exist purely on the device in that agent function, so updating/reading their value in the Python code or other agent functions would have no impact (not even clear whether they would retain any data between calls to the same agent function).
    • We could instead translate them similar to how you find them in the sugarscape example #define foo 0 or even constexpr int foo = 0;. In both these cases, the value would be constant, effectively replaced with a literal at compile time. However, this may mislead Python users, and lead to issues if they then try to update these values.

Given, the lack of a clear solution I will need to discuss this with the wider FLAMEGPU team to see how we believe this should be addressed. I've created the new issue #1144 to track this. We will hopefully discuss it on Friday and may have an update to resolve it next week if we can agree on a plan.

Current workarounds (with the latest codegen from master) are either to pass the agent function and constants as a string, or to move the constants inside the agent function.

[Robadob]

FYI, I've just updated the above comment.

[Robadob]

We've now discussed this internally.

The plan is to allow "constants" to be marked with a decorator e.g. @pyflamegpu.constant which will pull them in via codegen as a constexpr or similar.

This is noted in #1144, we don't currently have an eta for making this change.