Dilution test BufferError: memoryview has 1 exported buffer

[dagl1]

While running the Dilution test on two different computers I ran into the following error during the Dilution_test part of the code:

Computer 1:
Python version: 3.12
Solver: Gurobi 11.0.2
Cobrapy: 29.1
Pandas: 2.2.2
OS: Windows 11
Memory: 16gb

Computer 1:
Python version: 3.12
Solver: Gurobi 11.0.2
Cobrapy: 29.1
Pandas: 2.2.2
OS: Windows 10
Memory: 64gb

Last part of output:

Read LP format model from file C:\Users\P700881\AppData\Local\Temp\tmptzwqakv1.lp
Reading time = 0.05 seconds
: 6913 rows, 24730 columns, 92346 nonzeros
Exception ignored in tp_clear of: <class 'memoryview'>
Traceback (most recent call last):
File "C:\Git\Metabolic_Task_Score.venv\Lib\site-packages\pandas\core\dtypes\base.py", line 576, in find
return dtype_type.construct_from_string(dtype)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
BufferError: memoryview has 1 exported buffer
Read LP format model from file C:\Users\P700881\AppData\Local\Temp\tmp6l2yris8.lp
Reading time = 0.03 seconds
: 6913 rows, 24730 columns, 92346 nonzeros
Read LP format model from file C:\Users\P70088~1\AppData\Local\Temp\tmp6tzlle5b.lp
Reading time = 0.05 seconds
: 6913 rows, 24730 columns, 92346 nonzeros

Process finished with exit code -1073741819 (0xC0000005)

It is unclear to mem what exactly is going wrong as this happens after about 50-80 iterations (I didn't count, but it's a lot). I initially thought this was due to a memory problem on my end, but with 64gb memory I hope this is not the case...

[dagl1]

On further investigation it now appears to happen even with regular FVA calls, so I am thinking this has nothing to do with Macaw, except that potentially installing pebble did something to the multiprocessing lib. Either way this is not the concern of Macaw (although I will post the solution here too, once i get there).

[dagl1]

This appears to be an error related to multiprocessing, and has nothing to do with any installation of Macaw (as far as I can tell). When running in debug mode in Pycharm, this apparently can happen https://youtrack.jetbrains.com/issue/PY-54447/
I just had not been running FVA in debug mode before apparently.

[dagl1]

After running the dilution test for around 6 hours I instead get:
exception in thread Thread-14 (pool_manager_loop):
Traceback (most recent call last):
File "E:\Python\Lib\threading.py", line 1038, in _bootstrap_inner
self.run()
File "E:\Python\Lib\threading.py", line 975, in run
self._target(*self._args, **self._kwargs)
File "E:\Git\Metabolic_Task_Score\venv\Lib\site-packages\pebble\pool\process.py", line 182, in pool_manager_loop
pool_manager.update_status()
File "E:\Git\Metabolic_Task_Score\venv\Lib\site-packages\pebble\pool\process.py", line 235, in update_status
self.update_tasks()
File "E:\Git\Metabolic_Task_Score\venv\Lib\site-packages\pebble\pool\process.py", line 241, in update_tasks
self.worker_manager.stop_worker(task.worker_id)
File "E:\Git\Metabolic_Task_Score\venv\Lib\site-packages\pebble\pool\process.py", line 412, in stop_worker
stop_process(self.workers.pop(worker_id))
File "E:\Git\Metabolic_Task_Score\venv\Lib\site-packages\pebble\common\process.py", line 59, in stop_process
raise RuntimeError("Unable to terminate PID %d" % os.getpid())
RuntimeError: Unable to terminate PID 11884

I suppose with these long run times overall, it would be beneficial to save the current iteration and continue where one left off. I will implement such a thing, but the overall error still is a bit annoying. I suppose this lays with pebble itself, or are there reasons that this would happen that I can prevent?

[Devlin-Moyer]

I have never had that specific error. The reason that I started using pebble instead of just multiprocessing is that optimizing a model after imposing dilution constraints sometimes makes the process hang for no discernible reason, and multiprocessing has no way to terminate a single process within a pool without terminating the whole pool (and losing whatever progress the non-hanging processes in the pool made), but pebble does. So I would guess that something else is interfering with pebble's attempts to kill one of these hanging processes, because the ability to set timeouts on processes within ProcessPools is something they went out of their way to add

[dagl1]

Ill attempt some debugging on Monday, and add the ability to start from a failed/partial run as well, I really like the idea of Macaw, even if the dilution test might be too computationally expensive for my own applications (and my only goal is to reduce the model as much as humanly possible, but removing any things that don't pass dilution test is of course a bit counterintuitive), nevertheless other people might run into the same issues.

What is interesting is that when I ran it in debug mode, I got the multiprocessing error (see initial post), which from your description is something that shouldn't be used in the first place (or Pebble does use it somewhere under the hood).

[Devlin-Moyer]

pebble is built on top of multiprocessing (just adds more functionality), so it's not weird to see an error from multiprocessing when using pebble