Skip to content
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

Closed
hamogu opened this issue Dec 6, 2019 · 1 comment · Fixed by #39
Closed

Assign energy BEFORE user source is called #38

hamogu opened this issue Dec 6, 2019 · 1 comment · Fixed by #39

Comments

@hamogu
Copy link
Member

hamogu commented Dec 6, 2019

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?

@hamogu
Copy link
Member Author

hamogu commented Dec 6, 2019

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.

hamogu added a commit to hamogu/marx that referenced this issue Dec 9, 2019
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
@hamogu hamogu closed this as completed in #39 Dec 9, 2019
hamogu added a commit to hamogu/marx that referenced this issue Nov 29, 2022
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
hamogu added a commit that referenced this issue Nov 16, 2023
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant