Global cache OperatorTemplate.cache prevents sequential simulation

[PC-DOS]

Hope this issue finds you well

I'm still working on my simulation project, and find another issue which prevents sequential simulation caused by the global cache defined as dict OperatorTemplate.cache.

My code involves simulation with different durations, thus, I need to create stimulation patterns with different length. The code looks like the following:

# First time, 5 seconds of simulation
arrStimPattern = CreateStimWave(dDuration=5)
jrcModel = CreateStandardJRC()
dctResult = jrcModel.run(
    simulation_time=5.0,
    step_size=1e-4,
    sampling_step_size=1.0/500.0,
    inputs={
        "PATH/TO/INPUT/SIG" : arrStimPattern
    },
    # Outputs ignored
    clear=True,
    verbose=False
)
# Data postprocessing & plotting

# Second time, 200 seconds of simulation
arrStimPattern = CreateStimWave(dDuration=200)
jrcModel = CreateStandardJRC()
dctResult = jrcModel.run(
    simulation_time=200.0,
    step_size=1e-4,
    sampling_step_size=1.0/500.0,
    inputs={
        "PATH/TO/INPUT/SIG" : arrStimPattern
    },
    # Outputs ignored
    clear=True,
    verbose=False
)
# Data postprocessing & plotting

The first simulation ends successfully. However, when running the second simulation, the simulator crashes and says:

IndexError: index 50000 is out of bounds for axis 0 with size 50000

After checking my own code, I'm very sure that the length of stimulation pattern generated by CreateStimWave() function is Okay. I also found that if I run the simulation in a child process with concurrent.futures.ProcessPoolExecutor() sequentially, it works fine.

Then, I used a debugger to follow the code path. When leaving the in_op = OperatorTemplate(...) line in create_input_node() (called by CircuitTemplate._add_input()) during second simulation, the length of input signal goes wrong in the NodeTemplate instance created. It's still using the value stored in global static cache OperatorTemplate.cache, and CircuitTemplate.clear() won't clear it.

I modified CircuitTemplate.clear(), adding a line before gc.collect():

OperatorTemplate.cache.clear()

Now, the sequential simulation works fine.

[Richert]

Hi @PC-DOS, thank you for raising this issue! Actually, this is not a bug, but intended behavior, to keep template in cache that are shared across different models. We provide a function cpyrates.utility.clear_frontend_caches that can be imported from pyrates that also executes the line that you added to the clear() method. There is also a function pyrates.utility.clear that calls both CircuitTemplate.clear and clear_frontend_caches that can be used instead of setting clear=True, to ensure a full clean after a simulation.

Let me know if these work for your purposes!

[PC-DOS]

Hi @PC-DOS, thank you for raising this issue! Actually, this is not a bug, but intended behavior, to keep template in cache that are shared across different models. We provide a function cpyrates.utility.clear_frontend_caches that can be imported from pyrates that also executes the line that you added to the clear() method. There is also a function pyrates.utility.clear that calls both CircuitTemplate.clear and clear_frontend_caches that can be used instead of setting clear=True, to ensure a full clean after a simulation.

Let me know if these work for your purposes!

Thank you for your kindful reply. I've learnt that pyrates.utility.clear() can call OperatorTemplate.cache.clear(). But I still wonder if it's an intended behavior to keep CircuitTemplate.cache untouched even when clear is set to True in CircuitTemplate.run() (while the comment in CircuitTemplate.clear() says it "Also deletes operator template caches")

Thanks a lot for your detailed explanations again ;-)