GNU Astronomy Utilities - Bugs: bug #52295, Cosmology library integrals crash...
You are not allowed to post comments on this tracker with your current authentication level.
bug #52295: Cosmology library integrals crash for high z
Submitter: | Mohammad Akhlaghi <makhlaghi> | ||
Submitted: | Fri 27 Oct 2017 12:18:21 PM UTC | ||
Category: | Libraries | Severity: | 3 - Normal |
Item Group: | Crash | Status: | Fixed |
Privacy: | Public | Assigned to: | alteholz |
Open/Closed: | Closed |
Jump to the original submission
Fri 02 Feb 2024 12:42:56 AM UTC, comment #7: |
Mohammad Akhlaghi <makhlaghi> |
Wed 24 Jan 2024 09:10:43 PM UTC, comment #6: Commit d74dbcbe on branch bug52295 looks fine to me to handle the higher redshifts:
|
Boud Roukema <boud> |
Wed 24 Jan 2024 06:05:34 AM UTC, comment #5: |
Thorsten Alteholz <alteholz> |
Tue 23 Jan 2024 06:35:22 PM UTC, comment #4:
|
Boud Roukema <boud> |
Tue 23 Jan 2024 06:11:51 PM UTC, comment #3:
|
Thorsten Alteholz <alteholz> |
Tue 23 Jan 2024 04:04:16 PM UTC, comment #2: On three different machines, as of around Tue Jan 23 13:40 UTC 2024 or so
gives me nothing. Is the site down?
so the bug is reproducible.
|
Boud Roukema <boud> |
Tue 16 Jan 2024 06:14:22 PM UTC, comment #1: I assume gsl_integration_qng() was choosen for the reason that it is fast. So I propose to check whether it could successful integrate and if it fails just choose a slower function. Using gsl_integration_qag() did work in all cases when gsl_integration_qng() fails, so I propose the following commit:
|
Thorsten Alteholz <alteholz> |
Fri 27 Oct 2017 12:18:21 PM UTC, original submission:
The cosmology library functions use GSL's qng integration function for their integrations. However, when you run them with a high redshift (for example 200, as shown in the example below with the CosmicCalculator program which uses those library functions), they crash:
|
Mohammad Akhlaghi <makhlaghi> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 3 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2024-02-02 | makhlaghi | Status | Confirmed | Fixed | |
Assigned to | None | alteholz | |||
Open/Closed | Open | Closed |
Powered by Savane 3.13-f8d8.
Corresponding source code
Thanks a lot Thorsten for the nice fix; and thank you very much Boud for confirming the fix :-).
The fix has been merged into the 'master' branch of Gnuastro as Commit d6447d2b26 (I rebased it over the lastest 'master' branch and done some stylistic fixes to make it fit into Gnuastro's coding conventions). Some tips in this regard:
Another important tip: do not put two independent bug fixes or tasks to be merged in the same branch (this commit was placed on top of the commit for bug #46225). I had to separate your commit from that of bug #46225, since I don't have time to check both at this moment ;-).
Thanks again for the nice fix Thorsten.
Thanks also Boud for the comments regarding speed. I agree that things can be greatly improved, as you mentioned, the problem is primarily the time needed to develop this; especially that the speed of this calculation has never been our bottleneck so far; so there has always been higher priority bugs/tasks.
Ultimately, as mentioned in the main Gnuastro tutorial, if this is indeed the bottleneck for some project, they can fix it with custom program (which is easy through Gnuastro's library) ;-).