-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Assign energy BEFORE user source is called #38
Comments
in this current structure that's not easily done, but I don't see why I should not assign an energy BEFORE user_create_ray is called. The user source is the free to overwrite that energy or not. I'll just move this line: https://github.com/Chandra-MARX/marx/blob/master/marx/libsrc/s-user.c#L205 before user_generate_ray is called (with some minor modifications). I'll try to get that in before I release the next marx version (7 days from now), but I can't promise. If not, I'll be in the next release. |
User-compiled sources (``SourceType="USER"``) have a function called ``user_create_ray`` which is called with a pointer to ray properties (direction, time, and energy). All ray properties used to be undefined before calling this function and the user function could return ``-1`` for energy and time to have |marx| assign energy and time. Now, ``energy`` is initialized *before* ``user_create_ray`` is called, to allow user code that assigns locations based on the ray energy. With this change, marx.par must contain a valid specification for the source spectrum, since an energy will be drawn, even if the user source later assigns a different value. For backwards-compatibility, if ``user_create_ray`` sets the energy to a negative value, |marx| will assign the energy drawn before to the variable again. closes Chandra-MARX#38
User-compiled sources (``SourceType="USER"``) have a function called ``user_create_ray`` which is called with a pointer to ray properties (direction, time, and energy). All ray properties used to be undefined before calling this function and the user function could return ``-1`` for energy and time to have |marx| assign energy and time. Now, ``energy`` is initialized *before* ``user_create_ray`` is called, to allow user code that assigns locations based on the ray energy. With this change, marx.par must contain a valid specification for the source spectrum, since an energy will be drawn, even if the user source later assigns a different value. For backwards-compatibility, if ``user_create_ray`` sets the energy to a negative value, |marx| will assign the energy drawn before to the variable again. closes Chandra-MARX#38
User-compiled sources (``SourceType="USER"``) have a function called ``user_create_ray`` which is called with a pointer to ray properties (direction, time, and energy). All ray properties used to be undefined before calling this function and the user function could return ``-1`` for energy and time to have |marx| assign energy and time. Now, ``energy`` is initialized *before* ``user_create_ray`` is called, to allow user code that assigns locations based on the ray energy. With this change, marx.par must contain a valid specification for the source spectrum, since an energy will be drawn, even if the user source later assigns a different value. For backwards-compatibility, if ``user_create_ray`` sets the energy to a negative value, |marx| will assign the energy drawn before to the variable again. closes #38
suggested by @andrea-belfiore:
I was actually wondering whether there is a way to get (read-only)
the value of the energy assigned externally (through the standard
spectral model, say XSPEC-style).
I see one can interface directly XSPEC within the plugin and take
the XSPEC model parameters as input parameters to the plugin,
but it would be much easier (and flexible, as you can change
the spectral model without having to write and compile a new plugin)
to keep the two things (spectrum and extension) disentangled.
My impression is that the photon energy is determined only
after the user plugin is called (conditionally to the *energy=-1
setting, otherwise it takes the energy from the plugin itself).
If you confirm that, then I will fall back on the above option.
In which case I'll have to dig out how you encode a simple
call to XSPEC as it is ordinarily done by MARX.
clues about that?
The text was updated successfully, but these errors were encountered: