Wrong results from Poisson Solver

[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

[Gennady_F_Intel]

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

[coulee]

Quoting - Gennady Fedorov (Intel)

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

[Gennady_F_Intel]

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

[coulee]

Quoting - Gennady Fedorov (Intel)

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

[coulee]

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

[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

[Alexander_K_Intel2]

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. 2^nd and 4^th 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

[coulee]

Quoting - Alexander Kalinkin (Intel)

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. 2^nd and 4^th 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

[Alexander_K_Intel2]

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