Windows and NEOS Server - [Error 32] files being used by another process

[franktoffel]

When trying to solve the diet problem with NEOS Server I get the following error:

[Error 32] The process cannot access the file because it is being used by another process

This is apparently due to the fact that Windows tries to clean up temporary files (see old ticket).

Is there a solution nowadays or NEOS Server cannot be called from windows terminals?

Log details:

C:\Users\franz\Documents\GitHub\pyomo-instalacion\test_example\LP>pyomo solve --solver-manager=neos --solver=cbc
diet1.py diet.dat
[    0.00] Setting up Pyomo environment
[    0.00] Applying Pyomo preprocessing actions
[    0.00] Creating model
[    0.04] Applying solver
Job 4300633 submitted to NEOS, password='ZydGqRwA'
Check the following URL for progress report :
http://www.neos-server.org/neos/cgi-bin/nph-neos-solver.cgi?admin=results&jobnumber=4300633&pass=ZydGqRwA
Job 4300633 dispatched
password: ZydGqRwA
---------- Begin Solver Output -----------
Job submitted to NEOS HTCondor pool.
[   11.29] Pyomo Finished
ERROR: Unexpected exception while running model:
ERROR: Unexpected exception (WindowsError) while running model diet1.py:
        [Error 32] The process cannot access the file because it is being used by another process: 'c:\\users\\franz\\ap
pdata\\local\\temp\\tmplqee_t.neos.sol'

Traceback (most recent call last):
  File "c:\miniconda3\envs\py27\lib\runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "c:\miniconda3\envs\py27\lib\runpy.py", line 72, in _run_code
    exec code in run_globals
  File "C:\Miniconda3\envs\py27\Scripts\pyomo.exe\__main__.py", line 9, in <module>
    sys.exit(main())
  File "c:\miniconda3\envs\py27\lib\site-packages\pyomo\scripting\pyomo_main.py", line 71, in main
    retval = ret[0].func(*ret)
  File "c:\miniconda3\envs\py27\lib\site-packages\pyomo\scripting\plugins\solve.py", line 214, in solve_exec
    name='pyomo solve')
  File "c:\miniconda3\envs\py27\lib\site-packages\pyutilib\workflow\task.py", line 109, in __call__
    self.execute()
  File "c:\miniconda3\envs\py27\lib\site-packages\pyomo\util\_task.py", line 160, in execute
    retval = self._fn(**self._kwds)
  File "c:\miniconda3\envs\py27\lib\site-packages\pyomo\scripting\util.py", line 983, in run_command
    TempfileManager.pop(remove=not options.runtime.keep_files)
  File "c:\miniconda3\envs\py27\lib\site-packages\pyutilib\component\config\tempfiles.py", line 177, in pop
    os.remove(filename)

I have tried two workarounds but neither of them seem to fix this issue:

1. Changing deletion_errors_are_fatal = False in pyutilib\component\config\tempfiles.py (line 24) returns an assert error as described below
2. Using --keepfiles flag when calling pyomo returns an unexpected error either in python 2 and python 3.

(C:\Users\franz\Documents\GitHub\pyomo-instalacion\test_example\LP>pyomo solve --solver-manager=neos --solver=cbc diet1.py diet.dat --keepfiles
[    0.00] Setting up Pyomo environment
[    0.00] Applying Pyomo preprocessing actions
[    0.01] Creating model
[    0.06] Applying solver
Job 4301895 submitted to NEOS, password='JBSQmUpo'
Check the following URL for progress report :
http://www.neos-server.org/neos/cgi-bin/nph-neos-solver.cgi?admin=results&jobnumber=4301895&pass=JBSQmUpo
Job 4301895 dispatched
password: JBSQmUpo
---------- Begin Solver Output -----------
Job submitted to NEOS HTCondor pool.
[    6.31] Pyomo Finished
ERROR: Unexpected exception while running model:
)

[astrojuanlu]

I am working with @franktoffel and I managed to detect another issue. When using --keepfiles, an empty AssertionError is raised (that's why there's no error message) when parsing the .sol file coming from NEOS.

Here is the resulting .sol file:

CBC 2.9.4 optimal, objective 2.81
0 nodes, 0 iterations, 0.003 seconds

Options
3
1
1
0
3
3
9
9
0
0
0
1
0
1
1
0
0
0
0
0
objno 0 0
suffix 0 9 8 0 0
sstatus
0 1
1 1
2 1
3 1
4 1
5 1
6 1
7 1
8 1
suffix 1 3 8 0 0
sstatus
0 3
1 3
2 3
kestrel_options:solver=cbc

Executing on neos-7.neos-server.org
CBC 2.9.4: 

And the failing assertion is exactly this one:

https://software.sandia.gov/trac/pyomo/browser/pyomo/trunk/pyomo/opt/plugins/sol.py?rev=10784#L174

I am fairly new to Pyomo but this was worth an hour of careful debugging, so I hope it's useful.

[ghackebeil]

@Juanlu001, thanks for tracking down the issue in the SOL parser. I've actually never encountered an NL file with that section inside of it (kestrel_options:..), but we will have to correct the SOL parser to handle that.

I'll also do some testing on my Windows VM and try to come up with a more forgiving way of cleaning up files on Windows. Not sure why that flag is not having any effect.

[franktoffel]

@ghackebeil I have repeated my test with --keepfilesand indeed @Juanlu001 is right: I have got an AssertionError

I have updated the description above. At this point I am not sure if this error was always there and I confused while writing this issue.

[astrojuanlu]

There are two problems here actually. On the one side there's the problem with closing temporary files on Windows, and on the other side there's a closs platform failure to parse certain .sol files. @ghackebeil Do you want us to file a separate issue for Pyomo? I must confess that GitHub is very convenient for me to have these discussions but I understand that Pyomo's home is elsewhere.

[ghackebeil]

@Juanlu001, I believe I have fixed the issue with the .sol parser in Pyomo. You are correct that part of this conversation belongs on the Pyomo trac site. It would be great if you could open up a ticket there, so I can document the fix.

[astrojuanlu]

I just submitted a new ticket which is now awaiting moderation, sorry @whart222 for the noise but the system rejected me twice for putting too many links (one). For future reference, here is the changeset:

https://software.sandia.gov/trac/pyomo/changeset/11162

We will try to patch the latest released version of Pyomo with these changes so we can move on. Thanks a lot for working on this @ghackebeil.

[astrojuanlu]

I just tried the latest patches and the error is gone. Thanks again.

[ghackebeil]

@franktoffel: I just realized from your comment that the deletion_errors_are_fatal flag was working as expected (because the error changed to an assertion error that was related the SOL file issue). I think we can close this issue.