Some additional info output on hard test case and bug fixes on soft test case

[ggleizer]

Hey Gianluca,

I added some information to be printed in the hard constraint test case - I'm printing solver exit status and max run time among all run times. I changed some of the parameters as well, so you may not want to merge this file.

I think the soft one was more important. It was not compiling because of some errors in print function usages, as well as the dependency on files like problem_size.h. I fixed these and noticed it was having runtime errors as well. Then I saw a #if 1 that was leading to a exit(1) in the d_ip2_soft.c file. I assume it was there for debugging purposes. Setting it to #if 0 was enough for the test case to run. I still have other problems that I will report on the Issues section.

Hope this is helpful. Cheers,
Gabriel.

[giaf]

Hey Gabriel,

thanks for the changes, I like the ones to the hard test problem :)

Taking the maximum of the solution times make sense only once the CPU frequency has reached the maximum. In Linux, this can be done by setting the governor to "performance". Otherwise, the first solutions will always be slower, since normally the CPU sits at a lower frequency when not heavily used, and it takes some time (in the order of tens of milliseconds) for the frequency to rump up.

About the soft test problem, I was debugging the soft IP and I never finished :p I will do it at some point.

I have been thinking about something for a little while, and your pull request goes in this direction. It would make sense to create a new folder, called e.g. "examples", where there are some well documented and not-changing examples to use routines. Your changes with the theoretical optimal choice for the partial condensing horizon fits well. While in the test_problems folder there may be the stuff that I use for developing and testing.

What do you think about?

[ggleizer]

Thanks for the explanation. Yeah, I was willing to get a notion of the variation to the solution time but I didn't know I would be biased by the initial ramp up in frequency you mentioned.

I like what you are thinking for the examples / test_problems. I would definitely encourage that!