Adding stresstest function to MechanisticInferer

[SamuelBrand1]

This PR adds a stresstest method to the MechanisticInferer class which:

• runs a trace on the numpyro model defined within a class instance to gather parameter names.
• Generates a N long list of parameters with cauchy random values.
• Passes these to potential_energy. NB: potential_energy expects parameters in the unconstrained domain, which is convenient here.
• Returns all parameters which cause:
  • model run failure.
  • NaN return value.
  • Inf return value.

I've added a unit test too which only covers whether it runs and returns a list.

Caveats

I'm expecting this method to be inherited by any subtype of MechanisticInferer so that overloaded loglikelihood model methods should be covered by stresstest, but I'm not very strong at python so I might be misunderstanding inheritance here.

NB: For stresstest to work it requires kwargs to pass to the model via get_trace, which kwargs depends on the model (e.g. for the default model tf = a_number was sufficient).

Closes #197

Local pytest fail

I'm seeing this, but I can't seem to fix it on my local testing.

FAILED tests/test_integration.py::test_output_matches_previous_version - AssertionError: a change was detected in the 0 compartment. This can be for a couple of valid reasons:

[SamuelBrand1]

Actually, this test is too harsh because it can vary the observables. I'll have a think about how to only hit the inferable params. One option might be to pass some pseudo-data and then filter out only the non-observed params. Open to suggestions here!

[arik-shurygin]

Lets maybe look for a way to only randomly vary parameters we actually sample, rather than all numpyro parameters (which includes data)

[SamuelBrand1]

I think we can do this by passing the data you want to pass into kwargs, sampling from the model prior and using that to create the stress test params.

[arik-shurygin]

hey @SamuelBrand1 I apologies for the extended period of nothing happening with this ticket. Do you still think it is necessary? I did not realize you had responded to my comment requesting changes

[SamuelBrand1]

It would be a handy feature but its low priority since we identified the problem was with the ODE solver tol.

[SamuelBrand1]

bayeux #244 Should cover this functionality if we use that.