topic steve, in Intel® Fortran Compiler

: Runtime errors when using D_NNLPF routine (new IMSL)

suresh_p_1 — Fri, 17 May 2013 21:08:04 GMT

we are using the routine D_NNLPF for optimization . The previous version of the above routine is called DNCONF

It appears the signature of the new D_NNLPF is changed. It has required and optional arguments.

The following are arguments we are passing to the D_NNLPF

CALL D_NNLPF(FCN7, M, ME, IBTYPE, XLB, XUB, X,N, XGUESS, XSCALE, IPRINT, MAXITN, EPSDIF, TAU0, DEL0, EPSFCN, IDTYPE, TAUBND, SMALLW, DELMIN,SCFMAX, FVALUE)

Per documentation, below is the call without optional arguments.

CALL D_NNLPF(FCN7, M, ME, IBTYPE, XLB, XUB, X)

We are getting run-time errors such as access violations when we run the program. We suspect the order of optional arguments and size of arrays could be source of the problem.

But not sure, how to troubleshoot to understand where is the problem. Also, we would like to know how to enable debugging of IMSL to understand internally what is going wrong.

Appreciate your quick response.

Quote:suresh p. wrote:

mecej4 — Fri, 17 May 2013 23:04:00 GMT

suresh p. wrote:

we are using the routine D_NNLPF for optimization . The previous version of the above routine is called DNCONF. It appears the signature of the new D_NNLPF is changed. It has required and optional arguments.

These routines are from different original authors (Schittkowski for the older, Spellucci for the newer); they are superficially equivalent, but the algorithms and calling sequences are quite different.

We are getting run-time errors such as access violations when we run the program. We suspect the order of optional arguments and size of arrays could be source of the problem.

Did you call the specific name D_NNLPF, or did you call the generic name NNLPF? Did you provide the required interface using "USE NNLPF_INT?"

But not sure, how to troubleshoot to understand where is the problem. Also, we would like to know how to enable debugging of IMSL to understand internally what is going wrong.

That is not feasible to do since the source code to IMSL is not available. Even if the source code had been available, few end users of IMSL would be capable of debugging it, because of the rather complex algorithms that underlie the code. Most crashes from IMSL-dependent code are caused by errors in declaring and defining the arguments before making the call.

Do you have USE NNLPF_INT in

Steven_L_Intel1 — Sat, 18 May 2013 01:10:42 GMT

Do you have USE NNLPF_INT in your source? You need that to call the "Fortran 90 interface". I recommend against using the D_ name form - just call NNLPF which is generic. But DO make sure you are using the _INT module!

steve, we are using D_NNLPF

suresh_p_1 — Sat, 18 May 2013 15:08:05 GMT

steve, we are using D_NNLPF because all the arguments we are passing are double precision. But as per your recommendation I will use NNLPF and USE NNLPF_INT directive.

It's ok if you call D_NNLPF,

Steven_L_Intel1 — Sun, 19 May 2013 01:20:51 GMT

It's ok if you call D_NNLPF, but if you do, you MUST add USE NNLPF_INT.

Steve,

suresh_p_1 — Tue, 21 May 2013 15:57:04 GMT

Steve,

Per your suggestion, I'm using NNLPF and the directive USE NNLPF_INT.

Now, on the error code (I couldnt follow the documentation). I'm getting error code 9. Do you shed some light on this? I understand Error Code of 0 means solution is converged and valid.

With the same data using previous version of IMSL i.e., DNCONF, we got error code of 0.0 and solution seem converged.

What is the text of the error

Steven_L_Intel1 — Tue, 21 May 2013 17:44:47 GMT

What is the text of the error message printed? I see a couple of different things that can give a code of 9. The fatal error with code 9 is "The unscaled penalty-term bound must be greater than zero while TAU0 = %(d1) is given." (%(d1) gets substituted with text based on the arguments, I think.)

steve,

suresh_p_1 — Tue, 21 May 2013 18:30:53 GMT

steve,

It seems that the reason we dont converge on a solution is due to the following message. Please find the attached output.txt for more information on how NNLPF tried the solve the case.

TERMINATION REASON:
STEPSIZESELECTION: DIRECTIONAL DERIV. VERY SMALL, INFEASIBLE

How do we adjust the step-size to acheive convergence?

Just for information, below are the defaults we are using in our program:

IDTYPE = 1 !! Type of numerical differntiation
EPSDIF = EPSILON(X(1)) !! Relative precision in gradients
TAU0 = 1.0 !! Universal boundry condition
DEL0 = 0.5*TAU0 !! Phase minimization constraint
EPSFCN = EPSILON(X(1)) !! Relative precision to evaluate to
TAUBND = 1.0 !! Amount by which bounds may be violated
SMALLW = exp(2*log(epsilon(x(1)/3))) !! Error allowed in multipliers
DELMIN = min(DEL0/10, max(EPSDIF,min(DEL0/10,max(.000001*DEL0,SMALLW)))) !! Allowable constraint violations
SCFMAX = 10000

Sorry, that involves deeper

Steven_L_Intel1 — Tue, 21 May 2013 19:30:10 GMT

Sorry, that involves deeper understanding of IMSL than I have. Perhaps some of the users here are familiar with this routine, or you could ask in http://forums.roguewave.com/forumdisplay.php?110-IMSL-Numerical-Libraries

Quote:Suresh P wrote:How do

mecej4 — Tue, 21 May 2013 19:55:00 GMT

Suresh P wrote:
How do we adjust the step-size to achieve convergence?

You have not reached a point where that is a reasonable question.

Your output is full of NaN-s and shows numerous instances of the large number -0.62774D+67, which indicate that you are either not calling NNLPF properly or that your problem functions are properly coded. If you make up a small self-contained example it may be feasible to check into the reasons. With what you have shown so far, we do not even know what the objective function and constraints are, so it is premature to speculate as to why the library routine did not find your desired optimum.

After further debugging, I

suresh_p_1 — Wed, 22 May 2013 13:17:08 GMT

After further debugging, I see the routine FCN (where objective function and constraints are calculated) never gets called when IACT=0. IACT=0 when objective function is requested.

Any idea why objective function is never requested?

from IMSL doc -

IACT – Integer indicating whether evaluation of the objective function is requested or
evaluation of a constraint is requested. If IACT is zero, then an objective
function evaluation is requested. If IACT is nonzero then the value if IACT
indicates the index of the constraint to evaluate. (Input)

mecej4 ,

suresh_p_1 — Wed, 22 May 2013 15:27:21 GMT

mecej4 ,

While further troubleshooting, it appears that FCN WAS NEVER CALLED WITH IACT=0 (i.e., it never requested the objective function)

FCN is User-supplied subroutine to evaluate the objective function and constraints at a given point. The internal usage is CALL FCN (X, IACT, RESULT, IERR)

below is the excerpt from the document

IACT – Integer indicating whether evaluation of the objective function is requested or evaluation of a constraint is requested. If IACT is zero, then an objective function evaluation is requested. If IACT is nonzero then the value if IACT indicates the index of the constraint to evaluate. (Input)

Now UNDER WHAT CONDITIONS NNLPF NEVER REQUESTS FOR OBJECTIVE FUNCTION?

Please don't start new

Steven_L_Intel1 — Wed, 22 May 2013 15:29:40 GMT

Please don't start new threads for existing issues.

I commented in your other thread that you should make sure the project property Fortran > External Procedures > Calling Convention is set to Default.

The problem appears to be

avinashs — Mon, 15 Jul 2013 21:44:51 GMT

The problem appears to be with the NLP program, which in my opinion is not a robust NLP solver. It is based on a legacy code called DONLP2, which I did not have a good experience with and I don't know whether IMSL fixed all the bugs. Here, each call to FCN must yield either a constraint or the objective function. In maintaining constraint feasibility, the value of the objective function is not required, hence no calls with IACT=0 are needed. My suggestion would be to first solve a simple toy problem to make sure the IMSL routine works as required. Then, I would change TAUBND to zero in your code and make sure the initial guess for each variable is at least a distance of 1E-5*(1 + abs(X)) away from each bound. Looking at your output, it appears as though constraints have resulted in some kind of NaN error such as evaluating the log of a negative number. Finally, play with TAU0 setting it to a large value so that constraint feasibility is not strictly met at all iterations. Unfortunately, IMSL does not have a robust NLP solver. I don't have the latest IMSL and have stopped using it since CVF days because of compatibility issues.

Also, I have found that using option /iface:cvf is necessary when linking to these legacy codes. The Intel compiler catches many errors that did not appear using g77, CVF etc. since it strictly adheres to the latest standards. Unfortunately, the developers of legacy codes did not use this compiler and their codes produced the correct output with these "errors" involving non-standard FORTRAN in place.

[comment=avinashs]The problem

mecej4 — Tue, 16 Jul 2013 18:57:00 GMT

avinashs wrote:
The problem appears to be with the NLP program, which in my opinion is not a robust NLP solver....Unfortunately, IMSL does not have a robust NLP solver. I don't have the latest IMSL and have stopped using it since CVF days

This thread is mostly about using NNLPF, which is the constrained NLP solver supplied with current versions of IMSL. The routine supplied with the older IMSL 4 that came with CVF is a different routine. If you have found NNLPF to be "not robust", it is not clear what the reasons were. Or were you commenting about NCONF?

No NLP solver, or for that matter no library routine, is likely to be robust w.r.t. being passed incorrect arguments. Secondly, NLP routines typically call user-provided routines for function, constraint and gradient evaluations, which gives scope for more errors than is usual for calling library routines with no call-backs.