IMSL question

[steven_p_simpson]

I'm using the IMSL routine neqnf. This routine requires a funciton calculation. When I calculate the function in a subroutine, this value is sent back to the IMSL routine, but when the function is called again, the value of the function is totally different. This really messes up the math. How do I stop IMSL from changing the value of the function?

[TimP]

If you mean that you want to preserve the value of an argument passed to the IMSL subroutine, the surest way is to copy it to a new variable which you supply as the call argument.

[Steven_L_Intel1]

I'm a bit confused too. You pass your own function as the FCN argument to NEQNF. NEQNF will call your function multiple times, presumably with different arguments. What do you think NEQNF is changing that shouldn't be changed?

[steven_p_simpson]

I'm sorry if wasn't clear. NEQNF( non linear equation solver)will call the user supplied FCN routine to obtain function values from the independent variables that I initially guess and pass into NEQNF. NEQNF will then use these function values to update my independent variables. However, everytime I return to my FCN subroutine the function values have been changed to different values from the previous call of FCN. For example, leaving my FCN routine the value of one of the functions will be .1257. Upon returning to the FCN routine, this value will be 1.58e-38. I'm pretty sure my independent variables were changed based on the 1.58e-38 value because the new updated independent variable is much much different from the initial guess value.

I tried to explain this as best as I could, but I think the reason I'm not explaining this problem too well is because my lack of understanding of what is going on. What I think is happening is that my function values are getting overwritten in memory somehow in the IMSL library,but I don't know why.

I have since gone out and got a shareware version of the NEQNF. This version seems to work okay, but it is very slow. I would still like to get the IMSL version working to see if that would speed up my program.

Thank you for responding to my message.

[Steven_L_Intel1]

The function value will not persist across calls to the function. Are you expecting that it will? Each time NEQNF calls your function, it should do its computation based on the arguments and not care what value was returned on the last call.

I suggest you start with the example in the documentation and modify it to use your own function and see if you can make it work the way you want.

[steven_p_simpson]

You're right, the function value changes for every call to NENQF.

When I call my FCN subroutine from within NENQF my function values are assigned certain values - the correct values. However, when the program returns to NENQF from the FCN subroutine, these values are changed in the NENQF (I know this because when the NENQF first returns to the FCN subroutine the values of the functions have been changed before I go through the calculations for the functions in FCN). These values should only be changed while in the FCN subroutine - NENQF should not change these values. NENQF then uses these changed values to calculate the new direction for the independent variables in order to solve the system of equations, and these changed values for the functions are obivously incorrect (very large values). Thismakes the new direction chosen for the independent variables very wrong, and the program soon crashes because of theincorrect values.

Again, thank you for taking your time and answering my question.

Example

main program

c FCN - function call

c x - independent variable

c xguess - initial guess for independent variable guess

external FCN

call nenqf(FCN,ERRREL,N,200,XGUESS,X,FNORM)

end

subroutine FCN(X,F,N)

c x - independent variable

c f- function values

f(1)=x(1)**2+x(2)

f(2)=x(1)**1.5+2*x(2)

end

if x(1)=1 and x(2)=2 then f(1) =3 and f(2)=5. However when NEQNF returns to FCN, the value of f(1) is 1.57e38 and f(2) is 1.4e-38. f(1) and f(2) are recalculated based on the new x(1) and x(2), but these new x(1) and x(2) are based on the incorrect f(1) and f(2).

[Steven_L_Intel1]

I guess I'm still missing something. Array F is an output argument for FCN. Your function should not be looking at what its value is on entry to the routine, and the pseudocode you posted shows F being assigned to but never fetched.

You should not assume that the array F passed on subsequent calls is the same as on previous calls, or that it keeps its values. That's not part of the specification. I'd assume that NEQNF is creating a stack temporary for F to receive the values from your FCN - on return, it does something with the values and discards them.

What does your FCN really look like? And why do you care what values were returned previously?

[steven_p_simpson]

You're right my FCN does not care what the values of F are right when I enter the FCN routine. However, I just happen to look at these values when the program reenters into the FCN.These values are different from the values I previously had passed from FCN to NEQNF. Since these F values are calculated again in FCN, I initially wasn't too concerned with the fact that the F values had been changed by NEQNF. However, the F values are used by the NEQNF routine to calculate a new Jacobian matrix which helps determine the new independent variables, X ( these are the ultimate values I'm looking for) In this case, the X values are a temperature distribution in a piece of metal.TheF values are actually equations which relate the temperatures to eachother.

The new X values based on the calculated F's from FCN are obviously based on the incorrect, changed F's because the new X values are far, far different from the old X values. The new X values should just change a small percentage from the old X values for each iteration. I just wondering why these F values are being changed. I have successfully used this routine before without this problem.

I'm sorry it took me a couple days to respond - Christmas.

[Steven_L_Intel1]

You should ignore the fact that the F values on reentry to FCN are different than what was returned on the previous call. NEQNF does not save the value and initialize F to it on subsequent calls.

If you think that the routine is behaving incorrectly, that's another story and not related to F being uninitialized on entry. If you want, we can try to take a look to see if we can spot a problem. Submit a support request to Intel Premier Support and attach the source of your example program. I'd suggest working up a small example that shows just this problem. It may be a week or more before we can look at it, as several of us are on vacation this week (including myself.)