test.second_q.drivers.psi4d.test_driver_methods_psi4.TestDriverMethodsPsi4.test_oh_rohf
---------------------------------------------------------------------------------------
Captured traceback:
~~~~~~~~~~~~~~~~~~~
Traceback (most recent call last):
File "/home/runner/work/qiskit-nature/qiskit-nature/test/second_q/drivers/psi4d/test_driver_methods_psi4.py", line 82, in test_oh_rohf
result = self._run_driver(driver)
^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/runner/work/qiskit-nature/qiskit-nature/test/second_q/drivers/test_driver_methods_gsc.py", line 45, in _run_driver
problem: BaseProblem = driver.run()
^^^^^^^^^^^^
File "/home/runner/work/qiskit-nature/qiskit-nature/qiskit_nature/second_q/drivers/psi4d/psi4driver.py", line 176, in run
os.remove(run_directory + "/" + local_file)
FileNotFoundError: [Errno 2] No such file or directory: '/home/runner/work/qiskit-nature/qiskit-nature/psi.3265.clean'
Given it must have found the file my only take on it failing the remove is that the same scratch directory was being used by another psi4 unit test in another process - stestr runs tests across processes. Hence this logic does not really seem safe across processes in that regard. Now it has been like this forever and normal use would be to do a single computation. One could "fix" the failure by doing a try, catch pass around the removed - that does not allieviate any concern that it might be removing a file from another process that is still needed. I think the scratch dir can be set (env var?), so anyone doing this manually, ie trying to do different psi4 drivers in different processes would have a workaround.
Since it failed I noted it here. I don't really see any need for change at this point. We could possibly note this as a behavior of the driver in its docstring, but I doubt anyone in practice would see this.
A recent nightly run failed https://github.com/qiskit-community/qiskit-nature/actions/runs/8398484669/job/23003395683 as follows:
This is the psi4driver cleaning up at the end and it does so in a loop looking for files https://github.com/qiskit-community/qiskit-nature/blob/cbba76c516cbf372903a336b17fdeb2c31cd6d57/qiskit_nature/second_q/drivers/psi4d/psi4driver.py#L173-L176
Given it must have found the file my only take on it failing the remove is that the same scratch directory was being used by another psi4 unit test in another process - stestr runs tests across processes. Hence this logic does not really seem safe across processes in that regard. Now it has been like this forever and normal use would be to do a single computation. One could "fix" the failure by doing a try, catch pass around the removed - that does not allieviate any concern that it might be removing a file from another process that is still needed. I think the scratch dir can be set (env var?), so anyone doing this manually, ie trying to do different psi4 drivers in different processes would have a workaround.
Since it failed I noted it here. I don't really see any need for change at this point. We could possibly note this as a behavior of the driver in its docstring, but I doubt anyone in practice would see this.