Chris,

Sorry I haven’t kept up with the numpy releases. I haven’t had a chance to do any MGET development since last July, until very recently. Right now I’m working on ArcGIS 10.3 compatibility. I will update numpy compatibility at that time. It will probably take me a few more weeks to do this.

The underlying cause of this relates to how performance-sensitive part of MGET are compiled against numpy’s application binary interface (ABI), allowing direct C calls between MGET and numpy rather than going through the Python interpreter. Because MGET supports so many different versions of ArcGIS, it also must support different versions of numpy. But when numpy changes their ABI, modules that call it (such as MGET) must recompile against the new ABI or they will crash when they try to call the new one. Numpy has only done this rarely, but to insulate MGET from it, we rebuild the parts of MGET that call the ABI each time a new numpy is released.

As you may have discovered, the latest version of MGET that numpy supports is 1.8.1. Here are two ways you might be able to hack MGET to work before I issue the new release:

1.    Close ArcGIS.

2.    Rename C:\Python27\ArcGIS10.2\Lib\site-packages\numpy to something else, such as C:\Python27\ArcGIS10.2\Lib\site-packages\numpy_191

3.    Start ArcGIS and run the MGET tool that needs numpy. MGET will load numpy 1.6.1 that it keeps in C:\Python27\ArcGIS10.2\Lib\site-packages\GeoEco\AggregatedModules\numpy in case the user does not have numpy.

4.    Rename numpy_191 back to numpy.

5.    Continue to use ArcGIS. Until you close it, MGET should continue to use that numpy 1.6.1 even though C:\Python27\ArcGIS10.2\Lib\site-packages\numpy now exists. But this is only good for that instance of ArcGIS. If you open another instance, you have to do it again.

That approach might be more convenient that uninstalling and reinstalling numpy all the time. Alternatively you could try a more complicated one-time hack that would not require you to do renaming every time you wanted to use MGET. This hack assumes that numpy did not change the ABI between numpy 1.8.1 and 1.9.1. I don’t know if that is true, but it’s worth a shot:

1.    Search the C:\Python27\ArcGIS10.2\Lib\site-packages\GeoEco directory for *_1_8_1.pyd (e.g. dir C:\Python27\ArcGIS10.2\Lib\site-packages\GeoEco\*_1_8_1.pyd /s from cmd shell).

2.    For each file you find, copy it to a file with the identical name and location except give it _1_9_1.pyd.

3.    Try MGET again. It will try to load the _1_9_1.pyd files. If the numpy ABI did not change, it will “just work”. If the ABI did change, ArcGIS might crash.

4.    If it works, you’re good to go. You don’t have to do anything else. MGET will continue to use 1.9.1.

Let me know if either of those will work for you…

Jason

Hi,

I am trying to use your tool to convert HDF’s to rasters ( something I will need to do quite regularly) and I get the error message below. I have found a work around which involves downgrading numpy but the problem is I then need to upgrade it again in order to do other things. I was wondering if there was a plan to release a version of MGET that was compatible?

Thanks for your great work on the tool to date,

Chris

--------------
Chris Mcowen  PhD
Program Officer (Modelling and Analysis)  Marine Programme
Co-PI Nereus Program

United Nations Environment Programme - World Conservation Monitoring Centre
219 Huntingdon Road
Cambridge CB3 0DL, UK

Phone:  +44 (0) 1223 814 689
Switchboard: +44 (0) 1223 277 314
Fax:  +44 (0) 1223 277 136

www.unep-wcmc.org

UNEP-WCMC - serving the biodiversity community for 30 years
** Confidentiality Statement and Disclaimer **
  This e-mail, together with any attachments, may contain confidential information and/or copyright material. Any views or opinions presented are solely those of the author and do not necessarily represent those of UNEP-WCMC. It is intended only for the person named above. Any copying, distribution, dissemination, disclosure or use of this message or its contents unless authorised by us is strictly prohibited. If you have received this message in error, please notify us immediately.
You should understand and accept that email communication with UNEP-WCMC is not a totally secure communications medium. Although we have taken steps to ensure that this e-mail and attachments are free from any virus, we cannot guarantee that they are virus free. We do not, to the extent permitted by law, accept any liability (whether in contract, negligence or otherwise) for any virus infection and/or external compromise of security and/or breach of confidentiality in relation to transmissions sent by e-mail.
Thank you.