I am using the following code to work with pyomo model.
opt = pe.SolverFactory('gurobi')
res = opt.solve(model, tee=False,options=solver_opt)
walltime = res.solver.time
I tried several times to get the code snippet "res.solver.time" for obtaining the "walltime". Hence, I want to know where I can get the full list of methods and attributes in "opt". Then I can obtain other useful information. Thank you for help.
Anytime I'm poking around for a particular feature, I keep a terminal window open with ipython and use the code introspection feature to poke around (input 4 below). Then you can use ? or ?? (deep info, typically the source code) to get more info as in input 3 below.
Just type the command, '.', tab and poke around
This is the same stuff you would get from any IDE that supports introspection based code completion. I like PyCharm for same reasons.
Realize of course that what is shown below are the methods associated with pyomo's opt object and NOT the solver (glpk in my case, gurobi in yours) options!
Related
I have a few complex classes generated by a third party domain-specific tool. The classes are complex because the tool tries to be generic as much as possible, so that I was asked to design a GDB pretty printer python script to improve the debugging experience.
I designed it by "to_string" APIs which can print the information with organized rich text (e.g. colors), so far everything works fine.
However, I don't know how to get the output format user requests, no matter that user uses "p" or "p/x" will all output the same string because my script does not know user wants hex rather than decimal.
I tried googling but didn't figure out an elegant approach. I indeed have a few workarounds but they all change the usages (for example, implement two printers to be switched), please give me some suggestions, thank you.
Just realized there had been a feature request to GDB already.
Bug 17291 - IWBN if the print format was available to pretty-printers.
A little configuration information to start:
Xcode 13
Qt 5.15.5
iOS 14.7.1 (18G82) (I'm running on a device, not a
simulator)
Host MacOS Big Sur 11.6
I'm debugging a large Qt app, all written in C++, except for the necessary few files to make it work in iOS (so it's really an Objective-C++ app with an enormous amount of native C++ linked to it, everything of Qt it needs). I have a break point within the LoadApplication method - Qt has been built from source for development (that is, in debug configuration with symbols). There are a number of native Qt QUrl objects whose values I'd like to inspect. I have successfully installed lldbbridge.py, but I think the problem may be unrelated to that, because I saw it when I was using other tricks to see the data without the bridge. There is a method called toString on the QUrl class that produces a text representation of the URL (and another called toDisplayString that may be more human readable). These methods produce (of course) QString objects. So here are the failure modes:
First the bridge should be helping me to inspect the QUrl and all I see are the raw object descriptions that hide all the private interfaces. It isn't.
before I installed the lldbbridge.py script, I was able to view some of these objects (local variables, but not parameters), using code like expr url.toString().toStdString().c_str(). It still might work on local variables, but I would really like to be able to inspect parameters as well.
the error feedback I get is
error: <lldb wrapper prefix>:21198:9: module 'std' not found
#import std;
~~~~~~~^~~
this is a pretty legit error, because I have scoured my system and the internet for evidence of this std.framework whose existence is implied, and cannot find it, though its name suggests that it would be an assist to Objective-C or Swift to deal with std::string and the like. Possibly it was a thing in Xcode 12 that has been dropped in Xcode 13, but if so, it has no footprint on the web that I can find. Still, presumably Qt 5.15.5's lldbbridge.py was compiled and run and against it at some point in the recent past.
this isn't the only trick that doesn't work when inspecting a QString, with or without the bridge. I also tried expr (const wchar_t*)url.toString().toUtf16() and expr (const char*)url.toString().toUtf8() and so forth. The same error feedback results, complaining about the mysterious "std" framework or module.
and don't get too hung up on QUrl objects, because I get the same result with other QStrings.
one more symptom: if I do an expr #import std; in the lldb command line, it appears to work. That is, it gives no error feedback and appears to complete. This just makes the world weirder, because if exists, it must be hiding somewhere inside Xcode's contents, but I've done file searches in there, and see no evidence of such a thing. And if it does exist, why is the lldb wrapper prefix giving me grief? Could the wrapper be underspecified in terms of framework search paths, but the lldb command line not?
So as if it's not too obvious, here are my questions (besides WTF???):
Am I the first to see this? I've seen some forum talk about string inspection no longer working for others in Xcode 13 lldb, but the specific failure mode is different. Anyone else see this?
Does anyone have any idea about this mysterious "std" framework or module? Could its functionality have been sucked up into some other module or framework for Xcode 13?
Any ideas about work-arounds that I haven't thought of? I'm not a complete lldb novice, but I'm not an expert either.
I'd like to turn up the log levels look at those for clues, but I've never used that feature before, and I don't really even know where to FIND the logs.
I notice that the feedback suggests that there are at least 21198 lines in this "wrapper" BEFORE we get to the failing import statement. Seems a little excessive to wrap a request to view the contents of a string. Perhaps the whole wrapper is corrupted in some way. Any thoughts on how to test that hypothesis? How about a way to inspect the contents of the wrapper prefix itself?
Could the #import std; be a red herring and just co-lateral damage in some other unrelated failure mode? It's tempting to imagine it's some kind of std library support thing, but I don't want to assume too much at this point.
one more things about "std", whatever it is - lldb is super dynamic. It's always compiling inline code on-the-fly to support its functionality. That's the whole llvm magic. Is it possible it exists only as some inline text within lldb's source? And again, if so, why is it only selectively available?
Well, that's my nightmare. Unless my setup is horribly corrupted in some way and it's my unique curse, I'm sure this problem will show up for others, so cogent answers will make you a hero. Any pointers are appreciated. Thanks.
Situation:
I'm attempting to get coverage reports for a project that uses both C++ and Python. I'm using LCOV/GCOV for C++, and attempting to use Coverage.py for the python stuff. The only issue is, most of the python code that's being used is simply utility functions being called one function at a time. No initialization, no real life-cycle, or exit. So no real way to use the API to start/stop/save, or use the coverage command line to measure.
With this, I thought the easiest way to accomplish this would be using the sitecustomize.py method like outlined here. I have gotten that to work, and it measures all configured python code as expected. Now I'm looking at how to accomplish this with compiled python code (.pyc).
I can get it to work if I keep source(.py) and (.pyc) in the same directory when running, and then reporting. However, I'm looking for a way to RUN the files and generate the measurement data. Then at a later time point to the actual source files, and run the actual reports. Ideally I wouldn't need the source(.py) files at all, but I haven't found a way to accomplish this.
Objective:
In the end I want to be able to compile the python files(.pyc), install them on the target, and run coverage like stated above. It will generate coverage data files, then pull those files to my host machine which houses the source(.py) .. and do the actual coverage reporting.
Is this possible currently?
[Edit] Thanks to Ned's advice, I looked into the [paths] usage, and it worked exactly how I needed it to.
I am learning how to use quantlib to price derivatives. What is the best way to output some of the Quantlib specific classes to console window? For example
shared_ptr<YieldTermStructure> forwardCurve(new InterpolatedDiscountCurve<LogLinear>(dates,discountFactor,Actual360()));
Handle<YieldTermStructure> forwardingTermStructure(forwardCurve);
shared_ptr<IborIndex> euribor(new Euribor(3*Months,forwardingTermStructure));
What will be the best way for me to output forwardCurve to and euribor to console window? Then I can see the intermediate result of the code to see if they are as expected.
Many thanks.
There's no predefined way to output those classes to console, but you can use their inspector to output the relevant data (so, e.g., you can call forwardCurve->times() and forwardCurve->discounts() to inspect the values you're interpolating) or you can call their methods to see the results of their calculations (e.g., forwardCurve->discount(d) to retrieve the discount factor at a given date, or euribor->fixing(d) to retrieve the expected index fixing). The returned values can be written to console.
As an alternative, you might consider stepping through the code inside a debugger. In modern IDEs, this will give you the same information more easily.
I would like to able to plot the progress of a MIP solved by cplex. Specifically I would like to plot lower and upper bounds as functions of cpu-time. But copying an pasting from the node log does not seem to be a smartest way of proceeding. Is it possible to access these information and to print them out/to file during the optimization?
I am using the concert technology C++ interface.
You can add a "MIP info callback" using the API routine CPXsetinfocallbackfunc or its analogue in Concert.
(Copying-and-pasting the log it dumps to the terminal is perfectly fine for getting a rough idea of what's going on, but be aware that the results can be highly variable.)
Callbacks are what you are looking for. You can find a nice introduction here:
http://eaton.math.rpi.edu/cplex90html/usrcplex/callbacks.html