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

Error handling struct #76

Merged
merged 25 commits into from
Feb 15, 2017
Merged

Error handling struct #76

merged 25 commits into from
Feb 15, 2017

Conversation

reneehlozek
Copy link
Collaborator

I updated the status variables to be pointers and have passed them throughout the code.
This is propagated through the src and test codes.
In the src code, additional non-pointer status variables where created when needed for "if" statements.

[eg. look for pkstatus in src/ccl_power.c]

Copy link
Collaborator

@elikrause elikrause left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After a few fixes, I still get a segmentation fault in

ccl_test_cls.c, line 109
(CCL_ClTracer *tr_wl_1=ccl_cl_tracer_lensing_simple_new(cosmo,nz,zarr_1,pzarr_1,&status);),

which I haven't been able to track down yet; I will look into this tomorrow.

In addition to this problem, @philbull, @damonge, can you comment on what changes to the python wrapper routines will be required before merging in this pull request?

@elikrause
Copy link
Collaborator

I've reviewed this and pushed a bunch of changes.
make check in this branch now completes without crashing.
I checked that status gets passed and read out correctly by artificially setting it to error codes inside the computation for each test.
Issues that should be address later on, but are not required for this pull request:

  • I noticed that the status handling in ccl_cls.c is sometimes inconsistent, with several instances of local status flags that are only read out, but do not get passed back (see integrand_wl for an example) - this will be an issue later on when we allow for "softer" error handling to catch exceptions without exiting.
  • We are inconsistent in reading out gsl status for gsl routines (in particular, spline evaluation + integration)

@philbull
Copy link
Collaborator

@elikrause: The call signatures of all the functions have changed, so we should review the Python wrapper to make sure nothing has broken. I've written some unit tests that should help with this (currently in the pywrapper branch).

Python doesn't really have input/output function arguments like C does, so we'll have to decide how to deal with that. swig will probably add the status variable to the end of the list of return values, but it'd be a bit inconvenient to return a second variable every time the user calls any function. So, I suggest writing a "decorator" that we apply to each function to do the status handling in a more Pythonic way. I'll investigate this, but I'm not sure if I can have it finished by Wednesday.

@reneehlozek
Copy link
Collaborator Author

yes @elikrause, some of this was because there are some flags that are used in testing "if" statements etc, where the pointer class was not appropriate - but I'll also readily admit that it was in a desire (but possibly a failing) to be consistent through the module.

…hrough

the status pointer are not handled yet, though.
@philbull
Copy link
Collaborator

OK, I went through the Python wrapper and managed to make most of the changes that were needed (see the most recent commit). I'm getting a segfault in ccl_massfunc for some reason, so I'll debug that next.

@joezuntz
Copy link
Collaborator

@reneehlozek why are the files like class/include/hermite3_interpolation_csource.h removed?

@@ -14,6 +15,9 @@ void ccl_check_status(ccl_cosmology *cosmo){
case CCL_ERROR_SPLINE: // spline allocation error, always terminate
fprintf(stderr,"%s",cosmo->status_message);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The status_message will no longer necessarily match the integer that you pass in now. In fact if we're going for thread safety the status_message violates that just as the status integer did before. I think the right thing to do is not look anything up in the cosmo struct but instead to map the possible values of the status integer to messages.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that this may scramble the status_message in cosmo, so in the current version status_message may not be helpful for debugging and one should rely only on the error code...

@joezuntz
Copy link
Collaborator

What is the plan if status!=0 on entry to a function? Just fall through like cfitsio does?


# Check for known error status
if status in core.error_types.keys():
raise RuntimeError("Error %d: %s" % (status, core.error_types[status]))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest creating a new error class derived from StandardError that can take the status value as a parameter, so that it is easier to catch certain types of error.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this will happen eventually, but isn't critical for this release.

@philbull
Copy link
Collaborator

I'm merging the latest from master into this branch. Hang fire while I fix a few errors...

philbull and others added 3 commits February 13, 2017 17:48
 * Fix conflicts with status handling in new massfunction functions
 * Fix Python wrapper given changes in massfunction
* master:
  Update ccl_sample_run.c
  small change in user_pz_probability
  Now passing status to halo_bias
  Default config changed to Tinker10
  Adding halo bias in the CCL example
  updated compilation command
  upated REAME with lsst_spec example
  updated lsst_spec example
  fix ccl_specs_free_photoz_info
  fix ccl_specs_free_photoz_info
  Other minor fixed
  Fixed lines that were being cut-off
  Changes in the README to update the compilation of the CCL example

# Conflicts:
#	src/ccl_massfunc.c
Copy link
Collaborator

@joezuntz joezuntz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dealt with except for hermite files.

@joezuntz joezuntz merged commit 31623e4 into master Feb 15, 2017
sukhdeep2 pushed a commit that referenced this pull request Mar 8, 2017
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 this pull request may close these issues.

None yet

5 participants