Intel® oneAPI Math Kernel Library
Ask questions and share information with other developers who use Intel® Math Kernel Library.

Wrong results from Poisson Solver

coulee
Beginner
686 Views
Hi,

I got a wrong result by using Poisson solver with Neumann boundary conditions.
This can be easily justified by checking the symmetry of the solution.
As I did in the attachment, the left and rightboundaries are homogeneous Neumann condtions,
while the uppor and bottom employ the same nonhomogeneous Neumann conditions specified by data in the file 'bc'.
So the solution should symmetric vertically. But the subroutine d_Helmholtz_2D do not keep this symmetry.

I add all files, and please check this result for me.
Thanks!

Another thing is, if changing the BC type from 'NNNN' to 'DNNN' in test.f90, it will report some error:

forrtl: severe (174): SIGSEGV, segmentation fault occurred

If change the size of dpar from5*(nx-1)/2+7 to 13*(nx-1)/2+7, this error disappear.
So my question is what is the size of dpar? The mannual refer to the former5*(nx-1)/2+7
while the example used the latter 13*(nx-1)/2+7.
I am confused about this.

Coulee

Sorry for forgetting the attachment.
I do it now.

The files is listed as:

bc input nonhomogeneous Neumann boundary data for upper and bottom, i.e. G(x_j)
bc.eps profile of bc data
input parameters for domain and size
Makefile
*.mod compiled mod files
run excutable file
sol.eps profile of the output solution, it is wrong
test.f90 the source code

0 Kudos
9 Replies
Gennady_F_Intel
Moderator
686 Views

Coulee,
There are no attachment file(s) related to this question. ...
What MKL version you are using?
What's your linking line?
Is this ia32 or Intel64 architecture?
--Gennady

0 Kudos
coulee
Beginner
686 Views

Coulee,
There are no attachment file(s) related to this question. ...
What MKL version you are using?
What's your linking line?
Is this ia32 or Intel64 architecture?
--Gennady


Gennady,

I attached files and some remarks.
TheMKL versionon our cluster is10.0.5.025.
Linking line is contained in the Makefile.
The cluster is Intel 64.

Thanks.

Coulee
0 Kudos
Gennady_F_Intel
Moderator
686 Views
Coulee,
Looking at your makefile:
OPT = -O3
FF77 = ifort
run: test.f90
$(FF77) $(OPT) test.f90 -o run -lguide -lmkl lpthread
+++++
The linking line is good for mkl version 9.1 but for MKL version 10.* you have to use another linking model.
The main reason dealt with the redesigning MKL and physically separating the interface, threading and computational components of the MKL.
You can detailed examples about Selecting Linkage Models, examples for all supported architectures into userguide ( see chapter 5 )

Please let us know if will have further problems.
--Gennady

0 Kudos
coulee
Beginner
686 Views
Coulee,
Looking at your makefile:
OPT = -O3
FF77 = ifort
run: test.f90
$(FF77) $(OPT) test.f90 -o run -lguide -lmkl lpthread
+++++
The linking line is good for mkl version 9.1 but for MKL version 10.* you have to use another linking model.
The main reason dealt with the redesigning MKL and physically separating the interface, threading and computational components of the MKL.
You can detailed examples about Selecting Linkage Models, examples for all supported architectures into userguide ( see chapter 5 )

Please let us know if will have further problems.
--Gennady


Gennady,

I guess you did not understand what is happening.

Using the linking line
*****
$(FF77) $(OPT) test.f90 -o run -lguide -lmkl -lpthread
*****
works for other boundary types,for example,'DDNN' and 'DNNN' (for this case need care the size of DPAR), but not for the type 'NNNN'.

Also, I have tried the new linking line for the type 'NNNN'
****
$(FF77) $(OPT) test.f90 -o run -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread
****
and it gives the same wrong result as the old one.

So I think it should be something wrong in MKL to deal withthe boundary 'NNNN'.

Any further suggestion?

Coulee




0 Kudos
coulee
Beginner
686 Views
Quoting - coulee

Gennady,

I guess you did not understand what is happening.

Using the linking line
*****
$(FF77) $(OPT) test.f90 -o run -lguide -lmkl -lpthread
*****
works for other boundary types,for example,'DDNN' and 'DNNN' (for this case need care the size of DPAR), but not for the type 'NNNN'.

Also, I have tried the new linking line for the type 'NNNN'
****
$(FF77) $(OPT) test.f90 -o run -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread
****
and it gives the same wrong result as the old one.

So I think it should be something wrong in MKL to deal withthe boundary 'NNNN'.

Any further suggestion?

Coulee





Hi, Gennady,

Did you check my problem?
Any new comment?
Am I right or MKL?

Thanks.

Coulee
0 Kudos
coulee
Beginner
686 Views
Quoting - coulee
Hi,

I got a wrong result by using Poisson solver with Neumann boundary conditions.
This can be easily justified by checking the symmetry of the solution.
As I did in the attachment, the left and rightboundaries are homogeneous Neumann condtions,
while the uppor and bottom employ the same nonhomogeneous Neumann conditions specified by data in the file 'bc'.
So the solution should symmetric vertically. But the subroutine d_Helmholtz_2D do not keep this symmetry.

I add all files, and please check this result for me.
Thanks!

Another thing is, if changing the BC type from 'NNNN' to 'DNNN' in test.f90, it will report some error:

forrtl: severe (174): SIGSEGV, segmentation fault occurred

If change the size of dpar from5*(nx-1)/2+7 to 13*(nx-1)/2+7, this error disappear.
So my question is what is the size of dpar? The mannual refer to the former5*(nx-1)/2+7
while the example used the latter 13*(nx-1)/2+7.
I am confused about this.

Coulee

Sorry for forgetting the attachment.
I do it now.

The files is listed as:

bc input nonhomogeneous Neumann boundary data for upper and bottom, i.e. G(x_j)
bc.eps profile of bc data
input parameters for domain and size
Makefile
*.mod compiled mod files
run excutable file
sol.eps profile of the output solution, it is wrong
test.f90 the source code


Hi,

Anybody meet the same problem?
Is there some ideas to fix it?
Thanks.

Coulee
0 Kudos
Alexander_K_Intel2
686 Views
Quoting - coulee
Quoting - coulee
Hi,

I got a wrong result by using Poisson solver with Neumann boundary conditions.
This can be easily justified by checking the symmetry of the solution.
As I did in the attachment, the left and rightboundaries are homogeneous Neumann condtions,
while the uppor and bottom employ the same nonhomogeneous Neumann conditions specified by data in the file 'bc'.
So the solution should symmetric vertically. But the subroutine d_Helmholtz_2D do not keep this symmetry.

I add all files, and please check this result for me.
Thanks!

Another thing is, if changing the BC type from 'NNNN' to 'DNNN' in test.f90, it will report some error:

forrtl: severe (174): SIGSEGV, segmentation fault occurred

If change the size of dpar from5*(nx-1)/2+7 to 13*(nx-1)/2+7, this error disappear.
So my question is what is the size of dpar? The mannual refer to the former5*(nx-1)/2+7
while the example used the latter 13*(nx-1)/2+7.
I am confused about this.

Coulee

Sorry for forgetting the attachment.
I do it now.

The files is listed as:

bc input nonhomogeneous Neumann boundary data for upper and bottom, i.e. G(x_j)
bc.eps profile of bc data
input parameters for domain and size
Makefile
*.mod compiled mod files
run excutable file
sol.eps profile of the output solution, it is wrong
test.f90 the source code


Hi,

Anybody meet the same problem?
Is there some ideas to fix it?
Thanks.

Coulee

Hi,

First of all, thank you for using Intel MKL

Length of dpar must be 5*(nx-1)/2+7 for odd nx in your notation and 5*(nx-1)/2+8 for even nx. 2nd and 4th letter in word "NNNN" denote normal derivative on x and z accordingly, which are equal minus derivatives on x and z accordingly on lines x = bx and z = bz. So, if you want to see symmetrical solution you can change string "bd_az=bd_bz" in your example on string "bd_az=-bd_bz". On the other hand, if you use Neumann boundary condition as in your example and zero right hand side, problem have no any solution, because for pure Neumann problem and zero right hand side integral of boundary condition must be zero.

With best regards,

Alexander Kalinkin

0 Kudos
coulee
Beginner
686 Views

Hi,

First of all, thank you for using Intel MKL

Length of dpar must be 5*(nx-1)/2+7 for odd nx in your notation and 5*(nx-1)/2+8 for even nx. 2nd and 4th letter in word "NNNN" denote normal derivative on x and z accordingly, which are equal minus derivatives on x and z accordingly on lines x = bx and z = bz. So, if you want to see symmetrical solution you can change string "bd_az=bd_bz" in your example on string "bd_az=-bd_bz". On the other hand, if you use Neumann boundary condition as in your example and zero right hand side, problem have no any solution, because for pure Neumann problem and zero right hand side integral of boundary condition must be zero.

With best regards,

Alexander Kalinkin


Alexander,

Thanks for your answer.

(1) Sosetting the size of dpar to be 5*(nx-1)/2+8 will work for any case?
I tested it and found that it works for the boundary type 'DNNN'.

(2) According to the MKL Reference Manual, I should set "bd_az=bd_bz", because they are the normalderivative values. The same normal derivativewill give the symmetrical solution. If change it to "bd_az=-bd_bz", the exact solution is not symmetric, and so do the numerical one.

(3) I used the subroutine HWSCRT in Fishpack to solve this problem, and got the symmetrical solution (attached).

Hence, I think the problem is still there.

Coulee


0 Kudos
Alexander_K_Intel2
686 Views
Quoting - coulee

Alexander,

Thanks for your answer.

(1) Sosetting the size of dpar to be 5*(nx-1)/2+8 will work for any case?
I tested it and found that it works for the boundary type 'DNNN'.

(2) According to the MKL Reference Manual, I should set "bd_az=bd_bz", because they are the normalderivative values. The same normal derivativewill give the symmetrical solution. If change it to "bd_az=-bd_bz", the exact solution is not symmetric, and so do the numerical one.

(3) I used the subroutine HWSCRT in Fishpack to solve this problem, and got the symmetrical solution (attached).

Hence, I think the problem is still there.

Coulee



Coulee,

Let's investigate 1d Laplace problem with pure Neumann condition, for example:

-d^2u/d^2x = 0, 0<1, du/dn = 1 on x = 0 and x = 1
Solution of this problem without taking boundary condition into consideration is u = C_1*(0.5-x) + C_2, where C_1 and C_2 - constant. Now, if we try to find out C_1 and C_2 used boundary condition (let's insert u into boundary condition) we obtain two equations:

-C_1 = 1 (du/dx= -du/dn =-1 on x = 0)

C_1 = 1 (du/dx = du/dn = 1 on x = 1)

It's clear that such equations have no solution. The same situation is in 2d problem. This problem could not be solved, so Fishpack and Poisson Library gave some solution but both solutions are wrong, I think

With best regards,

Alexander Kalinkin

P.S.
I change some equations cause du/dn determine derivative on external normal, not internal

0 Kudos
Reply