- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hello, everyone,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The TMP array is rather large and there may not be enough stack space for it.
Please zip (or use tar -zcf ... to create a compressed tar archive) and attach the source code archive to a reply, using the "Attach Media" button. Someone may then look into the problem.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Not much can be done with the code fragments that you have given. The code is not complete, so it cannot be run to duplicate the seg-fault, and the parts that you gave are too long to check by visual inspection. Which MKL example code did you use as a basis for developing the code that you posted?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I used fgmres_full_funct_f.f and changed it as a subroutine. The main problem is the variables IA,JA,A,RHS have not been passed successfully. When I tried to print info of IA, JA, A in the subroutine, it turned out these variables got segment fault. I checked the stack size
$limit
stacksize 10240 kbytes
The size of IA is 33140. JA ,A are 234808. Not sure about whether this is because of the stack size.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The TMP array is rather large and there may not be enough stack space for it.
Please zip (or use tar -zcf ... to create a compressed tar archive) and attach the source code archive to a reply, using the "Attach Media" button. Someone may then look into the problem.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank for reply. Yes, the reason is tmp is too large. Don't know whether there is a better idea to figure this out since this is too large memory requirement, even more than storing the whole matrix.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Among remedies for stack overflow are setting larger stack or -heap-array compile option.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Most operating systems have a means for raising stack limit, while most fortrans have an option like ifort -heap-arrays to cause allocations to use heap rather than stack. You may need to use 64-bit (Intel64) mode and make the big array allocatable.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Maggie m. wrote:
Thank for reply. Yes, the reason is tmp is too large. Don't know whether there is a better idea to figure this out since this is too large memory requirement, even more than storing the whole matrix.
One solution is to allocate TMP on the heap by declaring TMP as ALLOCATABLE and allocating it in the subroutine, before passing it as an argument to other subroutines.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am back. After allocating the parameter arrays, I got such error in DCSRILU0:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please post the complete source code using either (i) the {code} button at the right of the toolbar when you reply in this forum, or (ii) as a file attachment using the "Attach media/Browse" button at the bottom left of the comment window.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I tried to print out the matrix in csr format. But got another issue here.
https://software.intel.com/en-us/forums/topic/560493
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Maggie,
There are some code errors in your code. For example, i mentioned, the function required 1 -based index whatever in C or fortran.
and the array ipar and dpar should be 128 . not N.
and the bilu0 = (double *)calloc(*NNZ, sizeof(double)) , not NN etc.
remove some correct conditions which is in original sample code, you don't need when solve the Ax=b..
I attach the modify code for your reference.
Best Regards,
Ying
[yhu5@prc-mic01 mklex]$ make
ifort -check bounds -g -traceback -i8 -openmp -w -fast -DMKL_ILP64 -m64 -I/opt/intel/mkl/include/intel64/ilp64 -I/opt/intel/mkl/include -c hypretest.f
icc -g -traceback -i8 -openmp -w -fast -DMKL_ILP64 -m64 -I/opt/intel/mkl/include/intel64/ilp64 -I/opt/intel/mkl/include -c LinearSolver.c
ifort -check bounds -g -traceback hypretest.o LinearSolver.o -L/opt/intel/mkl/lib/intel64 -lmkl_intel_ilp64 -lmkl_intel_thread -lmkl_blas95_ilp64 -lmkl_lapack95_ilp64 -liomp5 -lmkl_core -lm -lpthread -o ds
[yhu5@prc-mic01 mklex]$ ./ds
number of rows = 10
number of nonzeros = 28
sizetmpi= 306, sizeof(ia)= 8
N=10, NNZ= 28
LinearSolver: Line 48
dfgmres_init
dfgmres_end
ilu begin
ilu end
dfgmres check begin
dfgmres check end
Some info about the current run of RCI FGMRES method:
As ipar[7]=0, the automatic test for the maximal number of iterations will be
skipped
+++
As ipar[8]=0, the automatic residual test will be skipped
+++
As ipar[9]=1 the user-defined stopping test will be requested via
RCI_request=2
+++
As ipar[10]=1, the Preconditioned FGMRES iterations will be performed, thus,
the preconditioner action will be requested via RCI_request=3
+++
As ipar[11]=0, the automatic test for the norm of the next generated vector is
not equal to zero up to rounding and computational errors will be skipped,
thus, the user-defined test will be requested via RCI_request=4
+++
dfgmres begin to solve
dfgmres end of solve
dfgmres end of solve
dfgmres end of solve
dfgmres end of solve
dfgmres end of solve
dfgmres end of solve
The system has been solved
Number of iterations: 1
b( 1 )= 1.00000000000000
b( 2 )= 1.00000000000000
b( 3 )= 1.00000000000000
b( 4 )= 1.00000000000000
b( 5 )= 1.00000000000000
b( 6 )= 1.00000000000000
b( 7 )= 1.00000000000000
b( 8 )= 1.00000000000000
b( 9 )= 1.00000000000000
b( 10 )= 1.00000000000000
[yhu5@prc-mic01 mklex]$
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page