Overhaul of Result() implementation

This effectively rewrites the interactions of the samplers with the result. Rather than allowing for an arbitrary add-to-the-result and let it save all its contents, instead this enforces a defined set of attributes which are always initialised and always saved.

• Fix bug when running with --use-cached, it looks like the prior isn't properly converted into an actual prior and is just a dictionary of strings

I'm not a fan of fixing the entries.

This has also removed the nested samples from the output of the nested samplers, I would really like to save these.

I've also found a couple of occasions where it's been invaluable to add extra data into the result. Can we leave it possible to add extra things but basically say (a more diplomatic version of) "you added something we don't support, it pickled it, that's your problem"?

Seems to be happening because "UniformInComoving volume" etc is not defined in the bilby.core.prior file. I think this is a bigger problem - it means that bilby.gw.priors won't get picked up when loading results files (i.e. they will just be a string).

The saving of priors issue by the way is one that is one master, it is just exposed here (try calling a priors loaded from a saved result using UniformInCoMovingVolume etc

It shouldn't have removed the nested_samples - they are there (at least on the gaussian_example.py).

I'm fine with adding extra things. The problem was we where doing all these crazy hasattr everywhere, because it was never clear what had been added to the object when.

added 2 commits

• 7c1cb86a - Fix for parameter_labels and parameter_labels_with_unit
• 8ea5c0d4 - Add meta_data to stored result

Compare with previous version

Can you address this, https://git.ligo.org/Monash/bilby/issues/216, here? Apologies if you already have.

Re: the other issue, thanks I guess I was just not understanding properly what is being done.

added 1 commit

• f01ff9b1 - Improve testing of the results object

Compare with previous version

@colm.talbot , there was always a meta_data attribute that could be used to add arbitrary data through a dictionary. I've just patched this branch to explicitly have that (I forgot it yesterday).

Do you want to be able to do result.X = 'something' and it be stored for any X?

I've also hacked a fix the caching bug for now

@colm.talbot I'm not sure what you mean with #216 (closed), can you point to a place where the filename is saved? How should it know it is a filename?

One of the attributes is outdir, can this be saved as self.outdir = os.path.abspath(outdir)? It makes it stable to reloading the file in a different directory.

Some of my results have a result.prior which is stored with a relative path, although that doens't seem to be in this MR.

I did not know there was a meta_data attribute...

That's sufficient to quell my concerns, although being able to call result.foo = bar would be nice if not too difficult.

@colm.talbot

I can easily fix the outdir to be an absolute path.

The result.prior you mention, would be be cleaner to have a result.prior_file?

The problem with result.foo = bar getting saved is that you have to save everything in the result.__dict__. I think there are a few options

1. Revert to old behaviour: all attributes saved. Problem: leads to dodgy coding where you add an attribute and use it later on, but it isn't guaranteed to be there so then you have an hasattr

2. Ask the users politely to add extra "meta" data to meta_data which is then stored in a sensible way

Maybe we can chat about this

added 1 commit

• 15e4789f - Make outdir absolute path

Compare with previous version

unmarked as a Work In Progress

Okay, I think this is ready to merge now.

added 1 commit

• 7f7cf094 - Fix some miinor bugs for pymc3 running

Compare with previous version

added 1 commit

• f693a3f0 - Change repr to str and add more detailed warning message

Compare with previous version