I set summarise = TRUE in the function run.jags, then saved the output object as save(out, file="out.RData").
When I later load this object I can retrieve the summaries, plots, etc.
However, when I use the exact same code and run the model, and save output on a Linux cluster, then later load the object in Windows to work with it, the summaries and plots are not available. When I type summary(out), print(out), plot(out), or add.summaries(out), I get the following error message:
Error: Invalid runjags.object provided; the output of a runjags function (with class 'runjags') must be supplied
This even though class(out) returns "runjags".
In fact, names(out) reveals that the summaries (and a lot of other stuff) is not included in the output. The help file does indicate that summaries/plots, etc, are included by default.
Is there something about running the model in Linux that 1) prevents summaries from being generated, or 2) messes up the class of the output object?
I can of course use the coda package and do out2 <- as.mcmc.list(out), then I can use coda function to work with the output.
The problem was not Linux (see comment by Matt Denwood), but an old version of runjags. I updated runjags on the Linux machine (well, I had the system admin do it), and that fixed the problem.
Related
I'm currently working on a small raster refining tool. The goal is, to have a simple CLI tool, to compute tiles from a georeferenced source raster and create a corresponding index.shp. For this I'm using python 3.7 and gdal. The tool runs smoothly and generates the expected tiles and shapefile, but it gets rid of the projection, which is stored in the source raster. Qgis defaults the newly computed tiles to EPSG 4326 while informing me about an unknown projection. The original raster is in EPSG 25832.
My Setup:
Windows 10 64 bit
Python 3.7.2
Gdal I cannot access the specific version, since gdal-config is not installed and I cannot make it work, but it is 64-bit and I installed it through the binaries provided on gisinternals.com. Windows software list says GDAL 204 MSVC 2017.
While running the script, I get error messages telling me about missing files, e.g. pcs.csv, datum.csv ellipsoid.csv and so on. This indicates that having those files, would fix my problem.
But oddly enough, I have used Osgeo4W to install, python 2.7 with gdal and it works like a charm, of course having adjusted the python parts. Tiles get calculated and stay in the projection of the source. Without any external files which specify a projection, in fact using the exact same data which is really confusing to me.
To my understanding, there is no flag or option which forces gdal to keep the projection. If have overlooked or missunderstood the docs im glad for advice.
Before anyone asks, i know that using the osgeo4w installer is obviously the easy and working solution here. But keeping in mind that python 2.7 will soon be discontinued and also using this as a chance to learn new things i wanted to build a 3.7 based tool with gdal installed on my machine
The corresponding code looks like this and does the following :
1.) Command string is build
2.) string is handed to os.system, which in turn executes accordingly
for i in range(0, width, tilelenght):
y = 0
for j in range(0, height, tilelenght):
gdaltranString = f'gdal_translate -of GTIFF -srcwin {i}, {j}, {tilelenght}, {tilelenght} {input_filepath} {output_filepath}{x}_{y}.tif'
subprocess.run(gdaltranString)
y = y+1
x = x+1
The expected result, would be a collection of functional .tif files which have the EPSG code of the source file, in this case 25832.
But as already mentioned, the projection gets lost somewhere in the process.
So,i have found the solution to my problem, without really understanding how it became an issue to begin with.
The solution was to create an user variable GDAL_DATA with the path to the projection definition files.
The weird thing is, i now have GDAL_DATA, as system variable and user variable, both pointing to the same directory.
If someone knows more about the mysterious ways of windows system variables, please share your wisdom, or the source of said wisdom.
So I am a newbie to OpenModelica. I have a bit of experience using LMS Amesim. I created my first simple model using OM and simulated it from within the OMeditor.
When I switch to the plot window, there are NO output variables to plot. That tells me that the simulation may not have run. However, no error messages popped up. When I checked the model, I found it to be fine (not overconstrained or underconstrained).
What gives? This is OM 1.14 on Linux Ubuntu 16.04.
My Modelica file is a simple 2nd order system with feedback control is available via pastebin here or may be downloaded here via google drive link
The messages that I have from the output window are:
/tmp/OpenModelica_drN/OMEdit/Feedback/Feedback -port=35318 -logFormat=xmltcp -override=startTime=0,stopTime=100,stepSize=0.2,tolerance=1e-6,solver=dassl,outputFormat=csv,variableFilter=.* -r=/tmp/OpenModelica_drN/OMEdit/Feedback/Feedback_res.csv -w -lv=LOG_STATS -inputPath=/tmp/OpenModelica_drN/OMEdit/Feedback -outputPath=/tmp/OpenModelica_drN/OMEdit/Feedback
The initialization finished successfully without homotopy method.
The simulation finished successfully.
This was a bug. Should be fixed now:
https://trac.openmodelica.org/OpenModelica/ticket/5251
This is a great package for Bayesian optimization of hyperparameters (especially mixed integer/continuous/categorical...and has shown to be better than Spearmint in benchmarks). However, clearly it is meant for Linux. What do I do...?
First you need to download swig.exe (the whole package) and unzip it. Then drop it somewhere and add the folder to path so that the installer for SMAC3 can call swig.exe.
Next, the Resource module is going to cause issues because that is only meant for Linux. That is specifically used by Pynisher. You'll need to comment out import pynisher in the execute_func.py module. Then, set use_pynisher:bool=False in the def __init__(self...) in the same module. The default is true.
Then, go down to the middle of the module where an if self.use_pynisher....else statement exists. Obviously our code now enters the else part, but it is not setup correctly. Change result = self.ta(config, **obj_kwargs) to result = self.ta(list(config.get_dictionary().values())). This part may need to be adjusted yet depending on what kind of inputs your function handles, but essentially you can see that this will enable the basic example shown in the included branin_fmin.py module. If doing the random forest example, don't change at all...etc.
I have been working on a way to export models from Simulink to a FMU, which we will open source when we have a not-so-buggy version. Me and a collegue finally got a working version and extracted our first FMU from just a zip.
As it turns out, we must be doing something wrong within the program. Our FMU works fine, except for inputs. None of the inputs seem to be working. This have been tested mutliple times, like having a constant go to an out, which works, and I have also tested working FMUs made from our other non-open-source software and they work. I just can't seem to find what is different from theirs to ours FMU.
Here is a dropbox link if anyone wants the source of the test FMU. The model is simple, with one input going straight towards the output and one output getting fed from a constant. Currently, I can read the one output getting a constant, but not the input one. It's always 0. The dropbox folder includes the generated zip file from the model, the model.slx file, the generated FMU and also a folder containing everything inside the FMU. I know we aren't including all sources inside the FMU just yet, but I will fix that when we find out what our issue is with the FMU's. The sources exist inside the zip, so nothing is left out.
If anyone with experience around FMI has had this issue before or maybe have a clue what we could be doing wrong, I would be so greateful if you could share your experience.
I fixed my issue by changing the FMUSDK fmuTemplate.c file to call functions and handle my own inputs and outputs instead.
I have a wireshark dissector plugin.
I also have a wireshark installed from apt-get.
The wireshark loads fine without the plugin inserted in the right place.
When I include the plugin .so file and try to run wireshark, I get the following error:
$ wireshark
08:23:45 Err register_subtree_array: subtree item type (ett_...) not -1 ! This is a development error: Either the subtree item type has already been assigned or was not initialized to -1.
Trace/breakpoint trap (core dumped)
I tried understanding the problem. It says the subtree was already assigned (I'm assuming assigned an ett value) or was not initialized with -1. there are 3 files in my plugin where the API is called and I checked the values of ett[] being supplied to the API in each of these places. They are all initialized to -1.
Stuck in a roadblock. Any suggestion would be helpful.
Also, I do not understand where wireshark dumps the core. I could not find any core.
Any idea about this?
Generally, if you want to insert a plugin into a program, you have to ensure that the library API that the plugin was compiled against is the same as that provided by the program.
Unless wireshark provides documented versioning in its library API, this means that you have to have the plugin compiled against the same version of wireshark that you intend to use it with. So, if you compile your wireshark or the plugin yourself, you should compile the other as well. If you get your plugin in binary form, you should get your wireshark also from exactly the same place, otherwise you may not know if the two are compatible or not. If you only get a core dump when you insert the plugin, that's a strong indication that the two may not be compatible.
register_subtree_array: subtree item type (ett_...) not -1
...
there are 3 files in my plugin where the API is called and I checked the values of ett[] being supplied to the API in each of these places. They are all initialized to -1.
To which API are you referring? You must not call register_subtree_array() on any particular ett_ array more than once; if you're calling it twice, the first call will cause the ett_ values in the array to be set to values different from -1, so the next call will fail with that error.