When I modify the viewing Angle, I get a warning that there are too many iterations

[Dirac666666]

Dear author,

hello, I used function isStopCondition in my metric.c, and then I set the observation Angle from 70 degrees to 5 degrees, but I found that the warning :"SEVERE: Photon::hit: too many iterations (100001 vs. 100000), break." appears when the observation Angle is 5 degrees, and there is no such warning at 70 degrees

Do you have any good suggestions?

I am looking forward to receiving your response.

[Dirac666666]

In addition, I changed the observation Angle to a smaller Angle, which I set to about 0 degrees, and I found that the photon ring on the picture I obtained of the accretion disk had black spots. I checked these black spots and found that the value of these spots is 0. I would like to ask you if this phenomenon is normal.

My guess: The effect of the observation Angle
Small Angle approximation: When the observation Angle is very small (e.g. 0.01), it can cause some instability in numerical calculations. A small Angle can mean that the light is almost parallel to the polar axis of the black hole, which can lead to difficulty in converging numerical algorithms when calculating light trajectories or other related physical quantities.

There are my specific documents and picture details in this attachment
problem.zip

[8djudju8]

Dear Dirac666666,

/!\ careful this might be a wrong interpretation as i am in the discovering phase of the code

i see in lib/Photon.C where the error message is thrown this comment

3- Integration loop: integrate the geodesic until stopcond is 1.
Possible stopping conditions:
- transmission_freqobs_ low [see transmission() function
in astrobjs, which defaults to 0 (optically thick)
or 1 (optically thin) in Astrobj.C]
- t < tmin_ (if dir=-1), [NB: tmin_ defaults to -DBL_MAX in Worldline.C]
- photon is at r>rmax (defined for each object) and goes even further
- metric tells it's time to stop (eg horizon crossing)
- t does not evolve [to investigate, metric should have stopped
integration before, see above]
- count>count_max [should never be used, just to prevent infinite
integration in case of a bug]

^^^^^^^^^^^^^^^^ => you're problem

Image order computation:

An image can be decomposed into various orders depending on the
number of turns that a photon executes around a black hole before
reaching the observer (this is broadly speaking, details below).
The 0th-order (aka direct) image is the map of specific intensity 
obtained by integrating the radiative transfer along the part of 
the geodesic that makes between 0 and half a turn around the BH,
when integrating from the observer towards the BH. The 1st-order
image is obtained by taking into account the intensity accumulated
between half a turn and one full turn, etc. Again this is broadly
speaking and just to have a first naive view. In particular, note that
one given geodesic is not "of order n", but it rather has some part of it
which is of order 0, some part of order 1, etc.

In more details now, there are at least 2 ways that one can encode this:
- we can keep track of the theta turning points along the geodesic,
and change the geodesic order when we encounter a theta turning point
(corresponding to a half orbit around the BH, where an orbit is defined here
as the geodesic path between one theta turning point back to this
same turning point).
This is reasonably easy to implement (but there are few tricks, which
makes it less obviously correct than the second method) and is 
spacetime agnostic.
- a more precise way of dealing with that, which is specific to Kerr,
is to keep track of the Mino time as defined eg in Gralla & Lupsasca,
Phys Rev D, 101, 044031 (2020, hereafter GL20a), Eq. 34-36. 
The Mino time is directly linked to the number of orbits around the BH. 
So here there is no trick, we simply integrate the
Mino time, and use it to define the number of orbits, and define the
image order as above as the number of half orbits. However, this is
not generalizable to a non-Kerr spacetime.

I (FV) have compared the two approaches and found 
excellent agreement in Kerr.

The image-order code below is thus decomposed into two parts, one 
which takes care of keeping track of the theta turning points, and
the other that takes care of integrating the Mino time. One can switch
between the two by choosing compute_Mino=0 or 1 below (hardcoded).

Careful: all this is well tested at low inclination but might
not be well adapted for high inclination, TBC.

^^^^^^^^^^^^^ => maybe the explanation

[8djudju8]

Dear Dirac666666,

After talking with an author, we think that you shouldn't make such modification in this way
because "count>count_max [should never be used, just to prevent infinite
integration in case of a bug]"
Maybe in the manual https://gyoto.obspm.fr/GyotoManual.pdf at the section 9 extending Gyoto could help you
for what you try to achieve

[Dirac666666]

Dear author,

Hello! Thank you very much for taking the time out of your busy schedule to help me with my problem.

However, I'm not sure I understand the statement you made: “we think that you shouldn't make such modification in this way because "count>count_max [should never be used, just to prevent infinite integration in case of a bug]".”

I studied Chapter 9 through the link you provided, and I’m still having some trouble need to ask you.

1. Are you asking me not to modify the core file photon.c directly, but to do so through the extension mechanism?

2. I don't see an expansion guide for the photon class on GyotoManual, does this mean that my expansion needs to be done on mymetric.c, for example an extension to IsStopCondition()?

Thanks again for your help

Best regards

[paumard]

Dear Dirac666666,

The black spots are of course not normal.

Indeed, spherical coordinates behave badly near he polar axis. If the observer is set too close to this axis, Gyoto will actually move the starting point of the integration and issue a warning.

What I would do to investigate is identify one of those black pixels and run Gyoto on this single pixel in debug mode using --imin, --imax, --jmin, --hmax and --debug.

If you would like us to build and test your code, can you provide everything necessary for that (including necessary Makefiles, StdPlug.C or the equivalent etc.)? If you have integrated your code directly in Gyoto, the easiest would be to fork Gyoto on github, push your modifications to your fork and point us to your repository. Which would also be the starting point for integrating your work in the main Gyoto repository once it works well!

Best regards, Thibaut.

[Dirac666666]

Dear Dirac666666,

The black spots are of course not normal.

Indeed, spherical coordinates behave badly near he polar axis. If the observer is set too close to this axis, Gyoto will actually move the starting point of the integration and issue a warning.

What I would do to investigate is identify one of those black pixels and run Gyoto on this single pixel in debug mode using --imin, --imax, --jmin, --hmax and --debug.

If you would like us to build and test your code, can you provide everything necessary for that (including necessary Makefiles, StdPlug.C or the equivalent etc.)? If you have integrated your code directly in Gyoto, the easiest would be to fork Gyoto on github, push your modifications to your fork and point us to your repository. Which would also be the starting point for integrating your work in the main Gyoto repository once it works well!

Best regards, Thibaut.

Dear Thibaut,

Thank you for your reply.

First, yes, I would very much like you to help me build and test my code.
Second, my code is not integrated into gyoto, but I used a plugin to extend gyoto.

If you could take the time out of your busy schedule to help me with the test, I would appreciate your help!
Here are all the relevant files for my plugin.
MyPlugin.zip

Best regards,
Dirac666666.

[8djudju8]

Dear Dirac666666,

using in ../plugins/MyPlugin/lib/HYB.C

#define GYOTO_HYB_HORIZON_SECURITY 0.01

and in ../plugins/MyPlugin/33.xml

<DeltaMaxOverR>0.1</DeltaMaxOverR>

it seems that the stepping will converge and not cross the limits

./bin/gyoto ../plugins/MyPlugin/33.xml 33.fits
WARNING: unable to load optional plug-in libgyoto-lorene.so
Reading parameter file: ../plugins/MyPlugin/33.xml
Copyright (c) 2011-2019 Frédéric Vincent, Thibaut Paumard,
Odele Straub and Frédéric Lamy.
GYOTO is distributed under the terms of the GPL v. 3 license.
We request that use of Gyoto in scientific publications be properly
acknowledged. Please cite:
GYOTO: a new general relativistic ray-tracing code,
F. H. Vincent, T. Paumard, E. Gourgoulhon & G. Perrin 2011,
Classical and Quantum Gravity 28, 225011 (2011) [arXiv:1109.4769]

j = 400/400
Thread terminating after integrating 4724 photons
Thread terminating after integrating 4270 photons
Thread terminating after integrating 5000 photons
Thread terminating after integrating 4806 photons
Thread terminating after integrating 4807 photons
Thread terminating after integrating 4872 photons
Thread terminating after integrating 4844 photons
Thread terminating after integrating 5416 photons
Thread terminating after integrating 5571 photons
Thread terminating after integrating 5452 photons
Thread terminating after integrating 4483 photons
Thread terminating after integrating 4612 photons
Thread terminating after integrating 4968 photons
Thread terminating after integrating 4702 photons
Thread terminating after integrating 5199 photons
Thread terminating after integrating 4427 photons
Thread terminating after integrating 5502 photons
Thread terminating after integrating 5521 photons
Thread terminating after integrating 5835 photons
Thread terminating after integrating 4878 photons
Thread terminating after integrating 5451 photons
Thread terminating after integrating 5115 photons
Thread terminating after integrating 5605 photons
Thread terminating after integrating 5811 photons
Thread terminating after integrating 4868 photons
Thread terminating after integrating 5401 photons
Thread terminating after integrating 4467 photons
Thread terminating after integrating 5681 photons
Thread terminating after integrating 4792 photons
Thread terminating after integrating 4104 photons
Thread terminating after integrating 3898 photons
Thread terminating after integrating 4918 photons
Raytraced 160000 photons in 7.85323s using 32 threads

Saving to file: 33.fits

[Dirac666666]

Dear author,

Thank you for your help, my question has been solved.
Wish you a happy life and work

Best regards,
Dirac666666.

[paumard]

Problem solved, happy to help.