A common error amongst our users is when CUTEst is compiled with a different compiler to that which the Python environment is using (see e.g. #2, #7, #14).
By default our automatic shell script installer should pick up the shell default gfortran:
$ gofrtran --version
but for some users this is not the same as that picked up by their Python interpreter:
This situation then leads to the dreaded and very user-unfriendly error:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File ".../python3.6/site-packages/pycutest/build_interface.py", line 347, in import_problem
drop_fixed_variables=drop_fixed_variables)
File ".../python3.6/site-packages/pycutest/problem_class.py", line 52, in __new__
[module.info](http://module.info/) = module.setup() # setup CUTEst problem
File ".../CUTEST/pycutest_cache/pycutest_cache_holder/ARGLALE_M200_N100/__init__.py", line 69, in setup
(n, m)=_pycutestitf.dims()
Exception: Failed to open data file
The question is, can we handle this error more gracefully than at present?
Should we change the shell script to automatically detect the python gfortran?
A common error amongst our users is when CUTEst is compiled with a different compiler to that which the Python environment is using (see e.g. #2, #7, #14).
By default our automatic shell script installer should pick up the shell default gfortran:
but for some users this is not the same as that picked up by their Python interpreter:
which is what PyCUTEst uses by default.
This situation then leads to the dreaded and very user-unfriendly error:
The question is, can we handle this error more gracefully than at present?
Should we change the shell script to automatically detect the python gfortran?