I am getting the following error while using IPOPT from pyOptSparse in OpenMDAO.
I followed pyoptsparse documentations to install pyOptSparse with IPOPT which went very smooth.
The SLSQP optimizer works perfect but IPOPT gives this error.
Thank you
1
It looks like something is getting messed up with the user termination signal. To investigate though, it will help if you can provide the vesion information that rfalck asked for.
The pyoptsparse driver, when used with SNOPT, supports "clean termination" which means you can send use "kill -SIGUSR1 pid" with your run process ID to terminate, and it will still clean up and give a summary. IPOPT doesn't support this, nor does SLSQP. We generally don't have any problems with SLSQP or IPOPT, but maybe some combination of your OS and IPOPT is causing a hiccup.
As a workaround, try the following setting:
prob.driver.options['user_terminate_signal'] = None
That should turn off any of the signal caching and cleanup code. The error you got occured after the optimization finished, so you are almost there.
Related
In the process of submitting a package to CRAN I'm trying to run check_win_devel() and check_win_release() from devtools; both throw the error outlined above. Tried both with rstudio on windows and rstudio-server on wsl. After extensive Googling I haven't been able to find a workaround; I'm pretty clueless at this stage. Anyone came across the issue yet?
Thanks.
Those two devtools functions submit your package to an external machine at win-builder.r-project.org for testing. It looks as though that machine isn't allowing connections to receive your submission (maybe it's offline for the holiday break) or during tests your submission is trying to connect somewhere else, and that's failing.
I'd recommend following the instructions on win-builder.r-project.org for submitting your package instead of relying on devtools functions to do it. Then you'll see the errors first hand if it's a submission problem.
I have an OpenCL application that runs fine when using an AMD GPU.
When using an NVidia card, the clBuildProgram call crashes the application (does not even return a failure value, just a crash). When debugging, the crash yields:
read access violation in the nvopencl.dll module. code 0xc0000005. The debugger indicates the clGetExportTable function (inside nvopencl.dll) as source of the violation.
By commenting random parts of the kernels, I have reached this point:
In the code fragment:
if (something){
//some stuff
float3 gradient = (float3)(0,1,0);
gradient = normalize(gradient);
return;
}
By deleting the "gradient = normalize(gradient);" line, the clBuildProgram does not crash, but letting it there, crashed the program. the gradient variable is not even used inside the kernel, so it is not related to any other part of it. And the normalize funcion by itself should not be the source of the problem, because it is used in other parts of the code.
I think it may be related to some driver bug. Because installing the latest CUDA version (6.5) makes the OpenCL Volume Rendering sample binaries distributed by NVidia to misbehave, while using a CUDA 6 installation make the Volume Rendering sample to work properly.
My code is related to volume rendering techniques, that is why I think that it may be related, but my problem appears with both CUDA 6.5 and CUDA 6 installations.
Have you experienced something similar? What could be the cause of the problem, and how can I handle it?
Thank you.
After further analysis, the problem seems to be a bug in the drivers, as Xapa mentioned.
The linker for an iOS simulator target I have is reporting the following warning:
ld: warning: too many personality routines for compact unwind to encode
No line number is given, nor anything else that is actionable. Googling turned up some Apple open source code, but I'm not groking it.
What does it mean and what can I do to address it?
I found some information in the C++ ABI for Itanium docs that sheds some light on what this means.
The personality routine is the function in the C++ (or other language) runtime library which serves as an interface between the system unwind library and language-specific exception handling semantics.
Extrapolating, this warning indicates that you've got too many kinds of exception handling in the same binary, and at least one of them may fail. Indeed this is exactly what is observed in this question.
Sadly, there's no clear way to fix this, only workarounds. You can suppress the warning, remove code, rewrite code in a different language, disable a language's exception handing and possibly others.
If you have a crash on exception with this warning, i.e. ::terminate() call on every throw, the workaround is to use old dwarf exception-handling tables. Add following flags to Build Settings/Linking/Other Linker Flags:
-Wl,-keep_dwarf_unwind -Wl,-no_compact_unwind
You can try silencing the warning with -Wl,-no_compact_unwind for the Other Linker Flags setting. I think it's harmless.
I bumped into this issue as well when trying to run on the iOS simulator while my code was running correctly on the device. In my case, it was not a warning but a linker error.
Luckily, i remembered that I added two flags for luajit to run correctly following the instructions of this page under the section Embedding LuaJIT:
-pagezero_size 10000 -image_base 100000000
My guess is that the image_base address is simply out of bounds on the host CPU.
Anyway, removing these settings made it work in my configuration.
So go to your project's settings and look for any hard wired values of this kind if not the same.
Hope this helps,
M
I'm trying to simulate my VHDL code using Xilinx ISim.
When I try to generate the testbench for the simulation, the simulator throws up the following error:
FATAL_ERROR:Simulator:Fuse.cpp:500:1.133 - Failed to compile generated C file isim/
I tried to simulate it on an 32-bit Ubuntu 12.04 using ISE 14.3, a 32-bit Windows XP SP3 also ISE 14.3 and a 64-bit Windows 7 SP1 same ISE version as before.
The Xilinx support provided a reinstall as solution, but that didn't solve the problem.
Maybe the community on Stack Overflow has an idea?
That is a tool crash and it's going to be hard to get an answer here on stackoverflow, at least without providing some code and the steps that cause the problem. I would get back with Xilinx support and open a case -- this is something they need to fix in the tool. Can you provide your code as a testcase to them? Potentially cutting it down so it's as simple as possible while still causing the problem.
I can never provide production code to EDA vendors as a testcase due to confidentiality. Quite often I find that while creating a smaller testcase that I can send that I'm able to also find a workaround to the original problem. Try a binary search procedure -- remove or black box half of your design and see if the crash still happens.
And -- can you find the particular C file that fails to compile? Looking at it may give a clue as to what in your design may be causing the problem.
I've recently had a horrible problem with QTCreator. After the first time of running the program, ALL debugging instances segfault upon constructing the MainWindow object. Even if i make a blank QTwidget project and run in debug (without editing a single bloody thing), i get a segfault.
This persists after dozens of reinstalls. I have tried both the SDK as well as the IDE and library seperately. The version of the library is irrelevant, i always get the seg fault and its only on my tower. My laptops work just fine.
Does anyone have any possible solutions? Any help will be appreciated.
I needed to run QtCreator in admin mode in order for GDB to function properly.
Without knowing more (please answer to cbamber85's comment), such issues are known to be caused by uberprotectious anti-virus solutions or other software that hooks into places where GDB would usually hook in (Vendor OS-'enhancement' tools are infamous for doing that). This is a known Problem with GDB.
You could try to disable your virus scanner or remove/unload/remove from autostart the vendor tools and try again.
If that doesn't work, the content of the debugger output log pane (Windows > Views > Debugger Log) would be interesting.