How to solve the severe :"norm is drifting - with norm, normref=........."?

[Dirac666666]

Dear author
I'm sorry to bother you, but I have a problem that is very confusing to me. When I used my metric to draw my black hole shadow, the black hole shadow is based on the thin disk model, I found that my picture was very strange, there was a white edge, it looked like it had not been calculated, And in the process of calculation, I got a large number of severe: "norm is drifting - with norm, normref=.........".
I looked at my metric a hundred times, and I still couldn't find any problem, and at the same time, I calculated the innermost stable orbital under the metric, and there is a innermost stable orbital under the parameter in my xml file. But from a theoretical analysis, it seems possible to draw a normal black hole shadow like a Schwarzschild black hole.
The specific details, such as the images I get, my plugins, and the xml files , I put in the zip package.
I would appreciate it if you could reply me in your busy schedule
my plugin.zip

[paumard]

Dear user,
I tried to reproduce your problem. To do that I integrated your two files in the Null plug-in. When running gyoto on the XML file, I don't get "norm drifting" warnings but another SEVERE warning : "SEVERE: Photon::hit: too many iterations (100001 vs. 100000), break". The output image is by eye identical to the one you sent as PNG.

When ray-tracing without multithreading (so that the messages arrive in order on the terminal), I see that this message appears only for a few pixels between row number 23 and row number 32. On rows 25 and 26, I count 14 such messages (each). The dark region in the center of the disk there is 20 pixels wide. I can make an educated guess that those messages arise from photons that come too close to the horizon so that time evolution stalls there. The vicinity of the horizon is also a place where the norm could legitimately diverge (numerically). To avoid such problems, we implement a sink radius in KerrBL::isStopCondition(). You could use the same mechanism.

The "white edge" is another issue. Note that it is not filled with zeros, but with NaNs. This means that the integration worked correctly and that gyoto detects that the photon trajectory crosses the disk but that something fishy happens when computing the emission. I ran Gyoto in debug mode for a single pixel:
gyoto -T1 thindisk_hyb.xml \!thindisk_hyb_part.fits --debug --imin=1 --imax=1 --jmin=50 --jmax=50
nan appears first in this line:
DEBUG: virtual double Gyoto::Metric::Generic::SysPrimeToTdot(const double*, const double*) const: v=[0,0,-nan]
whete SysPrimeToTdot is called by Gyoto::Metric::HYB::circularVelocity.

My educated guess here is that you prescription for angular velocity is non physical at this distance (v>c?), more specifically this line must yield a division by zero or the square root of a negative number:
vel[3] = dir*sqrt(-rr * (-3. / rr / rr + 2. * pow(rr, -1.-2.* (1+3.* Ww_ -4. * Aa_ * Ww_)/(2.-3.* Aa_ + Aa_ * Ww_) ) * (1.+3.*Ww_ -4.*Aa_ * Ww_)/(2. - 3. * Aa_ + Aa_ * Ww_)))/ sqrt(2.)/rr;

[Dirac666666]

Dear author,
Thanks for your reply.
When I learned that you did not have the severe "norm drifting", but other severe warning : "SEVERE: Photon::hit: too many iterations (100001 vs. 100000), break", I felt so shocked. I tried to reproduce my problem, and I still got this severe "norm drifting". So I applied a new condition, Ww=0 Aa=0, also with a large amount of severe "norm drifting", but there was no problem when I used Ww=0 Aa=0.4.

at Ww=0 Aa=-0.4, if you still get the warning : "SEVERE: Photon::hit: too many iterations (100001 vs. 100000), please do a simulation at Ww=0 Aa=0 and Ww=0 Aa=0.4 respectively

Because the Thindisk need the parameter inner radius, I put the data for Ww, Aa and Inner Radius in this table, and This table may help you to reproduce my problem more clearly

About the severe warning : "SEVERE: Photon::hit: too many iterations (100001 vs. 100000), break", I also encountered this warning, but only when I used my metric to calculate PageThorneDisk, and this question will not be discussed now

And about the issue "white edge" , I checked my formula for angular velocity, and it doesn't seem to yield a division by zero or the square root of a negative number. I guess there's a limitation to my metric that this angular velocity is non-physical at Ww=0 Aa=-0.4, so this issue will not be discussed now. But the angular velocity seem to is physical at Ww=0 Aa=0，and I hope you to do a simulation at Ww=0 Aa=0.

Due to my problem is very complicated, I am very sorry to bother you and hope you can forgive my disrespect and offense
table.docx

[Dirac666666]

Dear Author,
Thank you for your assistance. With your help, I have acquired a satisfactory image.
I restructured a new Ubuntu system, and the severe "norm drifting" has disappeared; however, there remains another grave warning: "SEVERE: Photon::hit: too many iterations (100001 vs. 100000), break." Consequently, I added the isStopCondition() function into my metric.C file, and successfully obtained a satisfactory image.
Yet, when I utilized the isStopCondition() alongside the sink radius, I encountered a new issue.
KerrBL::KerrBL() : Generic(GYOTO_COORDKIND_SPHERICAL, "KerrBL"), spin_(0.), a2_(0.), a3_(0.), a4_(0.), difftol_(GYOTO_KERRBL_DEFAULT_DIFFTOL), rsink_(2.+GYOTO_KERR_HORIZON_SECURITY), drhor_(GYOTO_KERR_HORIZON_SECURITY), generic_integrator_(false) {}
How is the GYOTO_KERR_HORIZON_SECURITY defined in this code? In other words, which file pertains to GYOTO_KERR_HORIZON_SECURITY? For instance, the GYOTO_KERRBL_DEFAULT_DIFFTOL can be located in GyotoKerrBL.h:
#define GYOTO_KERRBL_DEFAULT_DIFFTOL 1e-2

[paumard]

Dear user,

it is defined in GyotoDefs.h:

$ grep -R "#define GYOTO_KERR_HORIZON_SECURITY" .
./include/GyotoDefs.h:#define GYOTO_KERR_HORIZON_SECURITY 0.01

Cheers

[Dirac666666]

Dear author，
I can only express my gratitude by thanking you three thousand times, You showed me that science has no distance.
Thank you very much.