Usage of DSLPRS (subroutine from IMSL Library)

[Matthaios_Antoninis]

Hello,

We tried to use a subroutine from IMSL library: DSLPRS(sparse simplex solver) which is running for smaller problems but for bigger does not give a result, the compiler just cross the call of the subroutine (to the occasion of big problems) seems to go inside but just get out and terminate the program with Code 0 0x0. We have written a simple program that reads all the data vectors (statements for the subroutine) from a txt file and then call this subroutine. The actual size of the problems that we are going to deal is around to 140000 non zero coefficients. Please give us some advice to solve this problem.

Thank you in advance for your help.

Matthaios Antoninis

National Technical University of Athens (Greece)
School of Civil Engineering

[Steven_L_Intel1]

Are you building a 32-bit or 64-bit application? You might be running out of virtual memory. Another possibility is insufficient stack space - you could try setting the Linker > System > Stack Reserve Size property to 100000000 and see if that helps.

[Steven_L_Intel1]

You must be missing this output sent to the console:

*** FATAL ERROR 45 from Dslprs. More space is required for the sparse
*** factorization. IPARAM(7) and IPARAM(8) can be used to indicate
*** more storage.

Look at the documentation for SLPRS for how to use a call to S5PRS to set a larger workspace.

A comment - please don't call the specific D_SLPRS. Use the generic SLPRS instead.

[Matthaios_Antoninis]

Many thanks for your answer,

I have written the same program but now calling the new subroutine S5PRS and S2PRS checking now a smaller problem that was running with the simple version SLPRS, BUT now with the new subroutine does not give any result ! and I take this message :

forrtl: severe (157): Program Exception - access violation

Image PC Routine Line Source

Console3.exe 0000000140003D86 Unknown Unknown Unknown

Console3.exe 0000000140002F97 MAIN__ 39 Console1.f90

Console3.exe 000000014013DEFC Unknown Unknown Unknown

Console3.exe 00000001400CD767 Unknown Unknown Unknown

Console3.exe 00000001400CD66E Unknown Unknown Unknown

kernel32.dll 000000007705652D Unknown Unknown Unknown

ntdll.dll 000000007743C521 Unknown Unknown Unknown

Please find attached the files,.f90 and the new Input file.

We tried also much bigger values for IPARAM(7,8), something like multiplied by 1E3,or 1E6 but we took the same message.

Thank you

Matthaios

[Steven_L_Intel1]

You declared OBJ, the output value, as allocatable but didn't allocate it. Either make this a non-allocatable or include it in the ALLOCATE statement. Once you do that, it runs.

[mecej4]

There is little reason to declare a scalar variable of intrinsic type (the REAL variable OBJ in this case) as ALLOCATABLE.

[Matthaios_Antoninis]

I am really sorry that I spend your time for something stupid, It was a mistake as a result from my tries to make it run, remains there from the copy pastes.

I have corrected the program I have multiplied the following parameters

IPARAM(7) = (iHElpNonZero + iNvar + 8) * 10

IPARAM(8) = (iM * 8 ) *2

and

LW' = LW *100

LIW' = LIW * 100

But the result that I take for the objective function is equal to zero that it is off course wrong, when I run it with DLPRS (Solves a linear programming problem via the revised simplex algorithm , but not with sparse format). I will appreciate any syggestion.

Thank you again for the help.

Matthaios

[mecej4]

You changed the input data from #2 to #7. The corrected program gives the optimum result as 0.4 for the first input data and zero for the second. It is not reasonable to expect us to check whether the input data is correct, whether it represents your problem correctly, etc. That is really something that you have to take charge of.

[Matthaios_Antoninis]

Yes you are right, I have changed the input file and I am trying to solve the actual problem where I am not taking right result. The one that gives solution equal to 0.4 it was a case with smaller size in order to have a base for comparison. The real problem presents into the last input file same as #2 post (If you follow mydescriptionsyou will understand everything).Andoff course each time I refer to the special input file that I attached each time.
We use DSLPRS (sparse solver) in order to minimize the mathematical problem for large scale physical problems. That's why we tried one level bigger size problem but we could not make it run properly.

[mecej4]

> That's why we tried one level bigger size problem but we could not make it run properly.

But it did run and gave a result, as noted in #8. I have no reason to believe that the result, namely, an optimum value of zero, is wrong. If you have a reason to believe that the solution is wrong, you have not shared that reason with us.

Likewise, I have no information on whether the input file in #7 does or does not represent the intended problem.

[Matthaios_Antoninis]

I am sorry I did not give the adequate information, I have solved the same problem in CVF using the simple DLPRS (non sparse simplex) (because we have problems also using DLPRS with IVF) and we receive the a value for the Objective = 6.8964 for the input file of #8 post.

Also I want to mention that changing the value of the RPARAM(5)= 0.1 (scaling factor to scale the reduced cost estimation) and not the default one (=1.0), I receive a value equal to 44.0 (wrong), using any other value for this parameter I take different results.

Many thanks for your immediate support.

Matthaios

[baldas10]

Hello,

We use the DSLPRS subroutine but in a simulation the subroutine returns the message (black screen):

ERROR 44 from DSLPRS - A row or columns has no elemt. Here INDEX=1

We have verified that the input matrices are correctly and no rows and/or columns with all zero element are present in the inpu data.

What is the problem?

Thank you in advance for your help.

[Steven_L_Intel1]

Without a test case it is impossible to tell you what the problem is. You should be able to capture the arguments to DSLPRS and create a test program that supplies exactly that data. I looked briefly at the code in the routine that gives that error but it is dependent on the input data.