Intuitively, the accuracy of the octree in Puma-EM will be increase respect to the NB_DIGITS [number of digits for the L computation], but the test result is not as the expected.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The testing model is cubi.geo, the frequecy is 3GHz, incident direction is theta=45 degrees and phi=225 degrees, the RCS is phi=45 degrees cut [theta from 0 to 180 degrees].
Another thing, for the convergent, NB=1, the iterate number is 21, NB=3, the iterate number is 20, NB=5, the iterate number is 22, NB=7, Puma-EM doesn't convergent.
From the RCS result, NB=3 is the best option. In Puma-EM, the Interpolator is local Interpolator, not global Interpolator, maybe this is the problem. But for MLFMM, if increase
NB, it must produce more accurate result. Hope someone can fix this problem.
Hi all Puma-EM users may concern,
Intuitively, the accuracy of the octree in Puma-EM will be increase respect to the NB_DIGITS [number of digits for the L computation], but the test result is not as the expected.
Here is the testing result:
The testing model is cubi.geo, the frequecy is 3GHz, incident direction is theta=45 degrees and phi=225 degrees, the RCS is phi=45 degrees cut [theta from 0 to 180 degrees].
Another thing, for the convergent, NB=1, the iterate number is 21, NB=3, the iterate number is 20, NB=5, the iterate number is 22, NB=7, Puma-EM doesn't convergent.
From the RCS result, NB=3 is the best option. In Puma-EM, the Interpolator is local Interpolator, not global Interpolator, maybe this is the problem. But for MLFMM, if increase
NB, it must produce more accurate result. Hope someone can fix this problem.
Best Regards!
Daopu
Last edit: xiangdaopu 2016-04-13