eval_objective command for automatic architectures - openmdao

This is an automatic architecture code(source: http://openmdao.org/releases/0.13.0/docs/tutorials/mdao/optproblem.html)
I have a doubt that what will be the code to print the minimum value of the objective function.
It may be very trivial but I am not getting it. I tried using eval_objective but it is not working. What code is to be added to this existing one?
def display_results():
print "Minimum found at (%f, %f, %f)" % (problem.dis1.z1,
problem.dis1.z2,
problem.dis1.x1)
print "Couping vars: %f, %f" % (problem.dis1.y1, problem.dis2.y2)
print "Function calls dis1: %d, dis2: %d"%(problem.dis1.exec_count,problem.dis2.exec_count)
print "\n"

that code assumes that the optimizer finished and left the model sitting at the point that gave the lowest objective. For all gradient based optimizers this is a reasonable assumption.
To do the same thing in openmdao > 1.7.x, see the following tutorial:
http://openmdao.readthedocs.io/en/1.7.3/usr-guide/tutorials/paraboloid-tutorial.html#optimization-of-the-paraboloid-with-a-constraint
print('Minimum of %f found at (%f, %f)' % (top['p.f_xy'], top['p.x'], top['p.y']))

Related

Optimization in R: Levenberg-Marquardt using nls.lm in minpack.lm: resetting `maxiter' to 1024

I am trying to learn how to work with nls.lm in the R library minpack.lm by using the Rosenbrock function to see if the algorithm converges to the global minimum at f(x,y) = (1,1). I do so both with and without the analytic Jacobian. In both instances, I get a warning telling me that the algorithm has decided to revert the maximum number of iterations specified in the call to nls.lm to 1024:
Warning messages:
1: In nls.lm(par = initpar, fn = objective_rosenbrock, jac = gradient_rosenbrock, :
resetting `maxiter' to 1024!
2: In nls.lm(par = initpar, fn = objective_rosenbrock, jac = gradient_rosenbrock, :
lmder: info = -1. Number of iterations has reached `maxiter' == 1024.
The algorithm never quite reaches (1,1) as a result given my initial guess of (-1.2, 1.0). I found the source code for the library on GitHub and the following lines of code are pertinent here:
https://github.com/cran/minpack.lm/blob/master/src/nls_lm.c
OS->maxiter = INTEGER_VALUE(getListElement(control, "maxiter"));
if(OS->maxiter > 1024) {
OS->maxiter = 1024;
warning("resetting `maxiter' to 1024!");
}
Is there any logic to why the maximum number of iterations is capped to 1024? Something with bits and 2^10? I would like to use the library for a different application, but this cap on iterations might prevent that. Any insight would be appreciated.
Git blame says that this code limiting the max iterations was introduced in version 1.1-0, in 2008. The NEWS file for the package only goes back as far as version 1.1-6. I can't find the code in any public repo other than the one you point to (which is only a CRAN mirror; it doesn't contain any comments/commit messages/etc. from developers that might give us clues.)
Other than contacting the maintainer I think it's going to be hard to figure out what the rationale is for this limit.
I do have some guesses though.
The only places that maxiter is actually used in the code are here and here - in R code, not Fortran or C code, so it seems extremely unlikely that we are dealing with something like a 10-bit unsigned integer type (which seems an unlikely choice in any case). I think the limitation is there because we also have a buffer defined for holding trace information here:
double rsstrace[1024];
which, as you can see, is hard-coded to a length of 1024. Presumably bad things would happen if we tried to stuff 1025 iterations'-worth of tracing information into this array ...
My suggestions:
change all instances of '1024' in the code to something larger and see what happens. There are only four:
$ find . -type f -exec grep -Hn 1024 {} \;
./src/nls_lm.c:141: if(OS->maxiter > 1024) {
./src/nls_lm.c:142: OS->maxiter = 1024;
./src/nls_lm.c:143: warning("resetting `maxiter' to 1024!");
./src/minpack_lm.h:20: double rsstrace[1024];
it would be best to #define MAXITER 2048 (or whatever) in src/minpack_lm.h and use that instead of the numerical value.
Contact the maintainer (maintainer("minpack.lm")) and ask them about this issue.

Julia Distributed, redundant iterations appearing

I ran
mpiexec -n $nprocs julia --project myfile.jl
on a cluster, where myfile.jl has the following form
using Distributed; using Dates; using JLD2; using LaTeXStrings
#everywhere begin
using SharedArrays; using QuantumOptics; using LinearAlgebra; using Plots; using Statistics; using DifferentialEquations; using StaticArrays
#Defining some other functions and SharedArrays to be used later e.g.
MySharedArray=SharedArray{SVector{Nt,Float64}}(Np,Np)
end
#sync #distributed for pp in 1:Np^2
for jj in 1:Nj
#do some stuff with local variables
for tt in 1:Nt
#do some stuff with local variables
end
end
MySharedArray[pp]=... #using linear indexing
println("$pp finished")
end
timestr=Dates.format(Dates.now(), "yyyy-mm-dd-HH:MM:SS")
filename="MyName"*timestr
#save filename*".jld2"
#later on, some other small stuff like making and saving a figure. (This does give an error "no method matching heatmap_edges(::Surface{Array{Float64,2}}, ::Symbol)" but I think that this is a technical thing about Plots so not very related to the bigger issue here)
However, when looking at the output, there are a few issues that make me conclude that something is wrong
The "$pp finished" output is repeated many times for each value of pp. It seems that this amount is actually equal to 32=$nprocs
Despite the code not being finished, "MyName" files are generated. It should be one, but I get a dozen of them with different timestr component
EDIT: two more things that I can add
the output of the different "MyName" files is not identical, but this is expected since random numbers are used in the inner loops. There are 28 of them, a number that I don't easily recognize except that its again close to the 32 $nprocs
earlier, I wrote that the walltime was exceeded, but this turns out not to be true. The .o file ends with "BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES ... EXIT CODE :9", pretty shortly after the last output file.
$nprocs is obtained in the pbs script through
#PBS -l select=1:ncpus=32:mpiprocs=32
nprocs= `cat $PBS_NODEFILE|wc -l`
As pointed out by adamslc on the Julia discourse, the proper way to use Julia on a cluster is to either
Start a session with one core from the job script, add more with addprocs() in the Julia script itself
Use more specialized Julia packages
https://discourse.julialang.org/t/julia-distributed-redundant-iterations-appearing/57682/3

Error when using acre.pro routine: "Programs can't be compiled from single statement mode"

I am trying to use acre.pro routine. It is a cosmic ray extraction program used to identify and remove cosmic ray strikes from an image. Here is an excerpt from the documentation of the routine (https://www.boulder.swri.edu/~buie/idl/pro/acre.html)
CALLING SEQUENCE:
; pro acre,dirty_im,clean_im,thresh,width
INPUTS:
; dirty_im - Original input image to be cleaned.
; thresh - Deviation threshold, in sigma, from background to cause
; pixel to be fixed.
; width - Median smoothing width to get local background reference.
OUTPUTS:
; clean_im - Final cleaned up image.
I followed the above procedure to use this program, however, IDL gives me two errors:
"Syntax Error" and "Programs can't be compiled from single statement mode."
Here is two of the many things that I've tried and the errors that I got:
IDL> pro acre ,'N1487262225_2cal.IMG','cosmic_clean.IMG',3,7
pro acre ,'N1487262225_2cal.IMG','cosmic_clean.IMG',3,7
^
% Syntax error.
IDL> pro acre ,N1487262225_2.IMG,cosmic_clean.IMG,3,7
pro acre ,N1487262225_2.IMG,cosmic_clean.IMG,3,7
^
% Programs can't be compiled from single statement mode.
pro acre ,N1487262225_2.IMG,cosmic_clean.IMG,3,7
^
% Programs can't be compiled from single statement mode.
pro acre ,N1487262225_2.IMG,cosmic_clean.IMG,3,7
^
% Syntax error.
Try:
IDL> acre, 'N1487262225_2cal.IMG', 'cosmic_clean.IMG', 3, 7

How to avoid sign extension with AutoIT BitShift()?

While trying to port an algorithm from C, I have determined that the AutoIT BitShift( ) function does sign extension if the high bit of a 32-bit field is set.
ConsoleWrite("Bit shift test: (0x80112233 >> 4)=" & hex(BitShift(0x80112233,4)) & #CRLF) ;### Debug Console
ConsoleWrite("Bit shift test: (0x60112233 >> 4)=" & hex(BitShift(0x60112233,4)) & #CRLF) ;### Debug Console
Bit shift test: (0x80112233 >> 4)=F8011223
Bit shift test: (0x60112233 >> 4)=06011223
See how the first test adds an 'F' to the front.
I think I'm straying outside the normal operations of AutoIT (not a lot of documentation on BitShift and BitRotate, and I don't see anybody else that ran into this problem), but I'm hoping somebody has an easy fix for this.
I'm using 3.6.6 of SciTe, if that matters.
I don't consider current BitShift() working wrong. Official documentation says this:
Bit operations are performed as 32-bit integers.
Since it doesn't say "as unsigned 32-bit integers", sign extension seems quite OK.
However, I don't see you point. If you know desired behavior, why not implementing custom function to fit your needs? Here is my variant:
Func BitShiftUnsigned($value, $shift)
If $shift > 0 Then
Return BitAnd(BitShift($value,$shift), BitShift(0x7fffffff, $shift-1))
Else
Return BitShift($value,$shift)
EndIf
EndFunc

Annuity or Angle Operation Symbol in LaTeX

How do I set the symbol for the angle or annuity operation in LaTeX? Specifically, this is the actuarial a angle s = (1-vs)/i.
I've looked at Life's Contingency's Package, various Actuarial Outpost forum threads, and the Comprehensive Symbol List for LaTeX, and combined the best into the following macros:
\DeclareRobustCommand{\lcroof}[1]{
\hbox{\vtop{\vbox{%
\hrule\kern 1pt\hbox{%
$\scriptstyle #1$%
\kern 1pt}}\kern1pt}%
\vrule\kern1pt}}
\DeclareRobustCommand{\angle}[1]{
_{\lcroof{#1}}}
You can then use this macro for the problem's example by typing
$a\angle{s}$
If you need a full set of actuarial symbols, you should use the Life's Contingency's Package lifecon. Using lifecon, you can set the above by typing
$a_{\lcroof{s}}$
For a very comprehensive list of LaTeX symbols, see The Comprehensive LaTeX Symbol List. Worth printing out and keeping under your pillow. Page 95 has some code that may do what you want.
I had the same problem with the actuarial symbol and the subscript/superscript, sooo I made a package to make my life easier and help other.
Plus, I’ve add some shortcut to save time.
The project page and the CTAN.
All you need is the actuarialsymbol package.
At the beginning of the code you have to write
\usepackage{actuarialsymbol}
For the sub/superscript
\actsymb['subscripLeft']['superscriptL']{<middle>}{'subscriptR'}{'superscriptR'}
Example of output:
Example of shortcut for actuarial symbol :
I've been doing some typesetting for a professor of mine and it turns out I needed some help producing the accumulated value of an annuity notation.
I asked this question on the tex stack exchange here
The result that Heiko Oberdiek produced was
\documentclass{article}
\usepackage{siunitx}
\makeatletter
\newcommand*{\NegationLike}[1]{%
\mathop{%
\mathpalette\#NegationLike{#1}%
}%
% A little space is added automatically,
% if a math ord atom follows.
}
\newdimen\BarLineWidth
\newcommand*{\#NegationLike}[2]{%
% #1: math style
% #2: argument
\vbox{%
% The rule thickness of \overline or \underline
% is available in the font dimen register 8
% of the math family 3 of the current size.
\BarLineWidth=%
\the\fontdimen8%
\ifx\displaystyle#1\textfont
\else\ifx\textstyle#1\textfont
\else\ifx\scriptstyle#1\scriptfont
\else\scriptscriptfont
\fi\fi\fi
3\relax
% The rule at the top
\hrule height\BarLineWidth
% Move the box with the vertical line
% as height as the top of the upper line
% to get a better corner.
Which produces:
accumulated value of annuity
\annu
A good list of latex symbols can be found here http://www.ctan.org/tex-archive/info/symbols/comprehensive/symbols-a4.pdf

Resources