PARDISO size limitation?

PARDISO size limitation?

I'm using an evaluation copy of MKL pardiso package. It works in small and middle size problems, but wouldn't work in large size problems (number of equations is greater than 60,000). Is it because my evaluation copy expired?

6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.


The evaluation version of the sparse solver is not limited in this way (problem size). Something else must be going on here. Are you getting an error message?


Hi, Todd,

We have an application using traditional LDLT as the equation solver, and are trying to replace it with PARDISO. The solver is an ATL in-process component written with C++, C and Fortran. The compilers are Visual Studio .Net 2003 and Intel Fortran 8.1.025. The test computer is a single processor Intel 3.3GHz P4 with 2GB RAM and 3.5 GB free disk space, and the operating system is Windows XP.

The solver component is launched from a GUI as a new thread. All matrixes are formulated within the solver component. The selected models are tested by first exporting the matrixes to a data file, then running a console application with the PARDISO C example. All test models were running successfully.

To avoid overhead, we would like to include the PARDISO directly into our solver ATL component and access the matrixes directly. Our first attempt was to attach the PARDISO C example directly solver ATL component. It always crashed in the second call (ERROR during numerical factorization), even we bypassed our matrixes formulation and use the very simple data provided in the example. This leads us to believe that it might be a conflict between our threaded ATL model and PARDISO threaded model. So we created a simple GUI and simple ATL component with just the given PARDISO C example, then it runs perfectly. The only difference between the test component and the real component is that the real component has some other stuff, but the other stuff was never called.

Next, we wrapped the PARDISO C example as an ATL in-process component (dll), and the component was called from our solver component. It worked for small and middle size problems (number of equations <60,000), but failed for a model with 120,000 equations (ERROR during symbolic factorization). In all cases, the size of the matrixes is less than 35MB, which is really small. There is another weird behavior for the in-process component. If a large model is failed in the PARDISO, then a small model will fail too unless the GUI is re-started.

Finally, we made an ATL out-process component (exe), and all test problems worked. As you see, we have been through a lot of different scenarios, they all should work. Unless we know what really went wrong,our last solutioncould break down again with certain combinations.




Did I understand that when you create a .exe the problem runs correctly?


Message Edited by bsgreer on 12-15-2004 11:38 AM


That's correct. An out-proc ATL exe works fine for large problems. But why?



My replydid not get through. That wasmy first post to this bboard several days ago. So I am trying again:

I once experiencedsimilar problemin calling a solver from DLL that I think might able to explain your problem or a clue.

I hada ~2,000,000 DOFS model. It faileda solver inDLL called from a FORTRAN program under Windows OS. But itsuccesses when the solver isan .exespawned by the same FORTRAN program.

Eventually I found that under Windows OS (XP) without /3GB switch, an application program supposed to have 2GB address spaceactually only has about 1.7GB available after some system DLLs loaded at top. When your application program has some self DLL's to load, for example this solver DLL, especially by default it is loaded somewhere in middle of that space, then itmake continued memory even smaller. So in that case, I had to rebase the solver DLL and made it worked. When I use the solver inanother .exe which uses different address space it avoids the said problem automatically.

If your are close to 32bit OS barrier, this probably is same problem you got.


Leave a Comment

Please sign in to add a comment. Not a member? Join today