I have a TensorFlow model which I want to convert into a tflite model, which is going to be deployed on an ARM64 platform.
It happens to be that two operations of my model (RandomStandardNormal, Softplus) seem to require custom implementations. Due to execution time being not that important, I decided to go with a hybrid model that uses the extended runtime. I converted it via:
graph_def_file = './model/frozen_model.pb'
inputs = ['eval_inputs']
outputs = ['model/y']
converter = tf.lite.TFLiteConverter.from_frozen_graph(graph_def_file, inputs, outputs)
converter.target_ops = [tf.lite.OpsSet.TFLITE_BUILTINS, tf.lite.OpsSet.SELECT_TF_OPS]
tflite_file_name = 'vae_' + str(tf.__version__) + '.tflite'
tflite_model = converter.convert()
open(tflite_file_name, 'wb').write(tflite_model)
This worked and I ended up with a seemingly valid tflite model file. Whenever I try to load this model with an interpreter, I get an error (it does not matter if I use the Python or C++ API):
ERROR: Regular TensorFlow ops are not supported by this interpreter. Make sure you invoke the Flex delegate before inference.
ERROR: Node number 4 (FlexSoftplus) failed to prepare.
I have a hard time to find documentation on the tf website on how to invoke the Flex delegate for both APIs. I have stumbled across a header file ("tensorflow/lite/delegates/flex/delegate_data.h") which seems to be related to this issue, but including it in my C++ project yields another error:
In file included from /tensorflow/tensorflow/core/common_runtime/eager/context.h:28:0,
from /tensorflow/tensorflow/lite/delegates/flex/delegate_data.h:18,
from /tensorflow/tensorflow/lite/delegates/flex/delegate.h:19,
from demo.cpp:7:
/tensorflow/tensorflow/core/lib/core/status.h:23:10: fatal error: tensorflow/core/lib/core/error_codes.pb.h: No such file or directory
#include "tensorflow/core/lib/core/error_codes.pb.h"
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
By any chance, has anybody encountered and resolved this before? If you have an example snippet, please share the link!
When building TensorFlow Lite libraries using the bazel pipeline, the additional TensorFlow ops library can be included and enabled as follows:
Enable monolithic builds if necessary by adding the --config=monolithic build flag.
Add the TensorFlow ops delegate library dependency to the build dependencies: tensorflow/lite/delegates/flex:delegate.
Note that the necessary TfLiteDelegate will be installed automatically when creating the interpreter at runtime as long as the delegate is linked into the client library. It is not necessary to explicitly install the delegate instance as is typically required with other delegate types.
Python pip package
Python support is actively under development.
source: https://www.tensorflow.org/lite/guide/ops_select
According to https://www.tensorflow.org/lite/guide/ops_select#android_aar on 2019/9/25
Python support of 'select operators' is actively under development.
You can test the model in Android by using FlexDelegate.
I ran my model successfully in the same way.
e.g. https://github.com/tensorflow/tensorflow/blob/master/tensorflow/lite/java/src/test/java/org/tensorflow/lite/InterpreterFlexTest.java
Related
I am new to the Modelica world and installed JModelica2.14 on win10 via the binary file provided from the offical webpage. From the console I call setenv.bat, start the 64bit python envrionment and import '.\install\Python_64'. However, running the example files already throws an error. The minimal code example throwing the error is provided below. I assume that the binaries do not have a bug without anyone mentioning it. It would be great if someone could give a hint about what I am missing. Thanks a lot!
import modelicacasadi_wrapper
modelicacasadi_wrapper.OptimicaOptionsWrapper()
RuntimeError Traceback (most recent call last)
<ipython-input-11-ce2bcdfa3f06> in <module>()
----> 1 modelicacasadi_wrapper.OptimicaOptionsWrapper()
C:\JModelica.org-2.14\install\Python_64\modelicacasadi_wrapper\modelicacasadi_wrapper.pyc in __init__(self, *args)
3472 __init__(ModelicaCasADi::OptimicaOptionsWrapper self, OptimicaOptionsWrapper other) -> OptimicaOptionsWrapper
3473 """
-> 3474 this = _modelicacasadi_wrapper.new_OptimicaOptionsWrapper(*args)
3475 try:
3476 self.this.append(this)
RuntimeError: java.lang.NoClassDefFoundError org/jmodelica/optimica/compiler/ModelicaCompiler
Caused by: java.lang.ClassNotFoundException: org.jmodelica.optimica.compiler.ModelicaCompiler
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
This function is only given in binary format compiled from c++ code. therefore, I can not change the function without recompiling the library (I already tried). To me it seems like the org.jmodelica.optimica.compiler.ModelicaCompiler should have been a org.jmodelica.optimica.compiler.OptimicaCompiler. This would mean that I have to install the package from source and I haven't been sucessful with that yet.
I still use JModelica 2.14 in Python 2 and then have installed virtual environment with Conda to create a Python 3 environment where I then run the FMUs with the latest PyFMI package in Python 3.10 and Jupyter notebook. It all works very fine, but as Imke Kreuger indicated you have MSL 3.2.2 build 3 and there has been development in the Modelica Standard Library since then.
During installation you are asked whether you want "Graybox OPC Automation wrapper" and I usually say "NO" there. You may have said "YES" though, right? See Chapter 2.2.1 in the User guide.
The JModelica installation actually provide you with two different compilers.
One is for standard Modelica brings as output an FMU of CS or ME type. The other compiler is for Modelica extended with Optimica and does not bring any FMU and you are bound to work in Python 2.
Tried to reproduce your error (with my installation without the "Graybox OPC..."). If I (in the Python 2 environment) literally do the two commands, I get "Press any key to continue...." and when I press key the IPython window collapse.
However if you skip the two brackets at the end of the second command, then it is accepted!
If you write a question mark at the end you get information about what arguments you should have.
If you describe better what you want to do, we likely can help you better.
Note, it seems you want to use Optimica and that is an extension of Modelica that is only partially supported by OpenModelica, what I understand. The Optimica extension is well integrated in JModelica and originated in this context. For "ordinary" Modelica use I do not think you need to use this wrapper.
I recently upgraded the tensorflow version used in my program to the recently released 2.6.0, but I ran into a trouble.
import tensorflow as tf
pattern = 'hdfs://mypath'
print(tf.io.gfile.glob(pattern))
The above API throws an exception in version 2.6:
tensorflow.python.framework.errors_impl.UnimplementedError: File system scheme'hdfs' not implemented (file:xxxxx)
Then I checked the relevant implementation code and found that the official recommendation is to use tensorflow/io to access hdfs, and the environment variable TF_USE_MODULAR_FILESYSTEM is provided to use legacy access support. Since my code is more complex and difficult to refactor in a short time, I tried to use this environment variable, but it still failed.
In general, my questions are:
In the latest version of tensorflow, if "tfio" is not used, how can I still access the HDFS file?
If "tfio" must be used, what is the equivalent code call to tf.io.gfile.glob?
TL.DR. Install tensorflow-io and import it.
After some tossing, I found a solution (it may be the official recommended way):
Since v2.6.0, Tensorflow no longer provides HDFS, GCS and other file system support in the framework, but transfers these support to the Tensorflow/IO project.
Therefore, in future versions, to have the support of HDFS, GCS and other file systems, you only need to install tensorflow-io and import it to the training program:
$ pip install tensorflow-io
$ cat test.py
import tensorflow as tf
import tensorflow_io as tfio
print(tf.io.gfile.glob('hdfs://...'))
$ CLASSPATH=$(${HADOOP_HOME}/bin/hadoop classpath --glob) python test.py
It will load libtensorflow_io.so and libtensorflow_io_plugins.so, which contains the implementation and registration logic of each extras file system:
# tensorflow_io/python/ops/__init__.py
core_ops = LazyLoader("core_ops", "libtensorflow_io.so")
try:
plugin_ops = _load_library("libtensorflow_io_plugins.so", "fs")
except NotImplementedError as e:
warnings.warn("unable to load libtensorflow_io_plugins.so: {}".format(e))
# Note: load libtensorflow_io.so imperatively in case of statically linking
try:
core_ops = _load_library("libtensorflow_io.so")
plugin_ops = _load_library("libtensorflow_io.so", "fs")
except NotImplementedError as e:
warnings.warn("file system plugins are not loaded: {}".format(e))
Ref:
Remove hdfs as support has been moved to modular file systems
Remove AWS files as s3 support is now in modular file system
SIG IO Meeting Notes
So, I'm working on a robotframework test project, and the goal is to run several test suites in parallel. For this purpose, pabot was chosen as the solution. I am trying to implement it, but with little success.
My issue is: after installing Pabot (which, I might say, I did by cloning the project and running "setup.py install", instead of using pip, since the corporate proxy I'm behind has proven an obstacle I can't overcome), I created a new directory in the project tree, moved some suites there, and ran:
pabot --processes 2 --outputdir pabot_results Login*.robot
Doing so results in the following error message:
2018-10-10 10:27:30.449000 [PID:9676] [0] EXECUTING Suites.LoginAdmin
2018-10-10 10:27:30.449000 PID:400 EXECUTING Suites.LoginUser
2018-10-10 10:27:30.777000 PID:400 FAILED Suites.LoginUser
2018-10-10 10:27:30.777000 [PID:9676] [0] FAILED Suites.LoginAdmin
WARN: No output files in "pabot_results\pabot_results"
Output:
[ ERROR ] Reading XML source '' failed: invalid mode ('rb') or filename
Try --help for usage information.
Elapsed time: 0 minutes 0.578 seconds
Upon inspecting the stderr file that was generated, I have this message:
Traceback (most recent call last):
File "C:\Python27\Lib\site-packages\robotframework-3.1a2.dev1-py2.7.egg\robot\running\runner.py", line 22, in
from .context import EXECUTION_CONTEXTS
ValueError: Attempted relative import in non-package
Apparently, this has to do with something from the runner.py script, which, if I'm not mistaken, came with the installation of robotframework. Since manually modifying that script does not seem to me the optimal solution, my question is, what am I missing here? Did I forget to do anything while setting this up? Or is this an issue of compatibility between versions?
This project is using Maven as the tool to manage dependencies. The version I am running is 3.5.4. I am using a Windows 10, 64bit system; I have Python 2.7.14, and Robot Framework 3.1a2.dev1. The Pabot version is 0.44. Obviously, I added C:\Python27 and C:\Python27\Scripts to the PATH environment variable.
Edit: I am also using robotframework-maven-plugin version 1.4.0.8, if that happens to be relevant.
Edit 2: added the error messages in text format.
I believe I've come across an issue similar when setting up parallel execution on my machine. Firstly I would confirm that pabot is installed using pip show robotframework-pabot.
Then you should define the directory your results are going to using -d.
I then modified the name of the -o to Output.xml to make it easy to identify.
This is a copy of the code I use. Runs optimally with 8 processes
pabot --processes 8 -d results -o Output.xml Tests
Seems that you stumbled on a bug in the prerelease version of robot framework (3.1a2.dev1).
Please install a release version of robot framework. For example 3.0.4.
Just in case anyone happens to stumble upon this issue in the future:
Since I can't use pip, and I tried a good deal of workarounds that eventually made things more unstable, I ended up saving my project and removing everything Python-related from my system, so as to allow me to install everything from scratch. In a Windows 10, 64bit system, I used:
Python 2.7.14
wxPython 2.8.12.1, win64, unicode, for py27
setuptools 40.2.0 (to allow me to use the easy_install command)
Robot Framework 3.0.4
robotremoteserver 1.1
Selenium2Library 3.0.0
and Pabot version 0.45.
I might add that, when installing the Selenium2Library the way I described above, it eventually tries to download some things from the pip repositories - which, if you have a proxy, will cause you trouble. I solved this problem by browsing https://pypi.org/simple/selenium/, manually downloading the 2.53.6 .tar.gz file, then extracting it and running setup.py install on the command line.
PS: Ideally, though, anyone should be able to use proxy settings from the command line (--proxy http://user:password#server:port) to get pip and then use it; however, for some reason, probably related to network security configurations that I didn't want to lose time with, this didn't work in my case.
Does anyone have any experience with trying to install cairo for django using buildout?
It will install pycairo or py2cairo (the first is for python >3.0, the latest is for python 2.6, which I Am using)
I found 2 recipes to use for installation, both of them gives me errors, in buildout.cfg I have them as 2 parts (of course tried them seperately, not thogether).
The errors are totally different, but the result is the same: I can't get cairo installed using buildout.......
based on: http://pypi.python.org/pypi/tl.buildout_gtk/
[cairo_tl]
recipe = tl.buildout_gtk
#pycairo-url = http://cairographics.org/releases/py2cairo-1.10.0.tar.bz2
pycairo-url = http://cairographics.org/releases/py2cairo-1.8.10.tar.gz
pycairo-md5sum = http://cairographics.org/releases/py2cairo-1.8.10.tar.gz.md5
based on: https://bitbucket.org/lgs/yaco.recipe.pycairo
[cairo_yaco]
recipe = yaco.recipe.pycairo
find-links = http://pypi.python.org/pypi/yaco.recipe.pycairo/0.1.1
#find-links = http://pypi.python.org/pypi/yaco.recipe.pycairo/0.1
# pkg-config-path ?
Both need a local install of cairo (pycairo and py2cairo depend on this):
so use on the server:
sudo apt-get install libcairo2-dev
The part jusing tl.buildout_gtk:
Either using the py2cairo-1.10.0 or pycairo-1.8.2 gives me a MD5 checksum mismatch
(see for available releases: http://cairographics.org/releases/)
e.g:
Error: MD5 checksum mismatch downloading 'http://cairographics.org/releases/py2cairo-1.10.0.tar.bz2'
or:
Error: MD5 checksum mismatch downloading 'http://cairographics.org/releases/py2cairo-1.8.10.tar.gz'
The part jusing yaco:
I Am pretty sure this part is not configured correctly (pkg-config-path refering to the local cairo package), but I do not even get to that point.
It gives an error:
DistributionNotFound: zc.recipe.cmmi
However, this is installed in the eggs
By the way, I had the same kind of headache trying to install PIL by buildout, which I solved combining a lot of options and posts on the internet, together with a lot of time and trials and errors.
If anyone want to know how I finally got it working, just ask, and I will publish it.
(I consider myselve still a django starter, so I do not know for sure if anyone is interested in the solution)
PIL does not have all the options I found in cairo, so I started using cairo. On my local PC everything works fine (ubuntu desktop), on my server (Ubuntu server) I can't getting it to work......
Any other options for making drawings on the fly..... (like matplotlib...) let me know.
Pretty sure you have to give the real md5 hash to the pycairo-md5 option instead of a string with some url in it.
I would avoid specialized recipes like those two whenever possible. There are some cases when a specialized recipe really is needed, but those are cases where the dependency is so egregiously eccentric that no common build/install pattern is usable. I don't know pycairo so that may be the case.
But before assuming it is, try the following. Always try using an egg first by adding it to the eggs option of the relevant buildout part. If that doesn't work, update your question with those details, and then try adding a separate zc.recipe.egg part with build options that may help the distribution build successfully. If that doesn't work or the distribution uses a ./configure && make && make install (AKA "CMMI") build system, update your question with those details, and then try using zc.recipe.cmmi to build the package after which you can use the extra-paths option of your zc.recipe.egg part to include the relevant bits of the CMMI part (extra-paths = ${cmmi-part:location}/weird/path/to/python/modules).
This is the general dance for getting poorly/oddly behaved distributions. If this doesn't work, then a specialized recipe may be in order but in general there's a way to get it to work with the above and that will be much more maintainable.
I'm trying to install GDAL via buildout on MacOSX. I have following config:
[gdal]
recipe = zc.recipe.cmmi
url = http://download.osgeo.org/gdal/gdal-1.7.2.tar.gz
extra_options =
--with-geos=${geos:location}/bin/geos-config
--with-static-proj4=${proj:location}
--with-jpeg={libjpeg:location}
--with-spatialite=${spatialite-lib:location}
--with-sqlite=${spatialite-lib:location}
I tried many other configurations but all I've got is the following error:
http://pastebin.com/s0WxfnUu
Any clues?
I've managed to resolve the problem - description below.
Just for the record - proper configuration for building GDAL on MacOSX (for example purposes I've cut off additional stuff):
[libiconv]
# ...
[gdal]
recipe = hexagonit.recipe.cmmi
url = http://download.osgeo.org/gdal/gdal-1.7.3.tar.gz
configure-options =
--with-python
--with-jpeg=internal
--with-spatialite=${spatialite:location}
CFLAGS=-I${libiconv:location}/include
LIBS="${libiconv:location}/lib/libiconv.la ${libiconv:location}/lib/libcharset.la"
You need to specify libiconv (in my example I'm building it from source) - it will prevent charset errors.
Also my problem was in the version of jpeglib, so I've definied --with-jpeg=internal so the GDAL will use it's own libs. Depending on the error you can use --with-png=internal, --with-tiff=internal etc.
Good luck!
Buildout is great for a lot of things, but even I tend to hand over some responsibility to the OS.
The whole whopping geo stack is one of those things. Gdal, geos, libproj4, mapnik, I don't know what. Compiling everything from source is just too cumbersome, especially as you have a lot of dependencies.
In your case, it looks like there's a mismatch in some of the libraries that gdal compiles against. Wrong length of arguments.
My tip is to install gdal and friends via your OS (so: windows installer, apt-get, rpm, whatever).