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

Refactor conversion to InferenceData #44

Merged
merged 12 commits into from
May 28, 2021
Merged

Refactor conversion to InferenceData #44

merged 12 commits into from
May 28, 2021

Conversation

gibsramen
Copy link
Collaborator

@gibsramen gibsramen commented May 19, 2021

cc @mortonjt

Refactor of InferenceData conversion code. Adds a flag to automatically convert a fitted CmdStanMCMC to InferenceData. For parallelized models this should convert after each fit and not after all are completed. If this flag is specified, the BaseModel.fit object will be of type InferenceData or List[InferenceData].

Also changes the way to_inference_object works. Now, an arbitrary BaseModel class should call the specify_model method to pass in params, coords, dims, etc. to_inference_object now uses these specifications instead of taking them as arguments.

Still need to update documentation. After this will probably bump up version to 0.0.3.

@mortonjt
Copy link

Great! Is the parallelism ready to be tested on a cluster?

@gibsramen
Copy link
Collaborator Author

I think it's worth trying. My guess is it will not yet work, though.

@gibsramen
Copy link
Collaborator Author

Note to myself - should have some sort of error handling such that if the conversion to inference fails the fit will still be saved as CmdStanMCMC. Otherwise the whole fit would be thrown away which could cause some headache.

@mortonjt
Copy link

@gibsramen yes this makes a lot of sense, since jobs fail all the time...
One possibility is we have a robust merge, where we merge together the runs that succeeded and have some record of which runs failed, so that we can rerun those features.

Copy link

@mortonjt mortonjt left a comment

Choose a reason for hiding this comment

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

Spotted one potential typo

I'm testing this locally atm - so far, its smooth.

Regarding the cluster setup, it looks like it can be completely decoupled from Birdman. So long as dask calls are being made inside of Birdman model fits, Birdman should not care how the dask cluster is setup. From my experiments, it looks like there does not need to have a dask cluster accepted as input for any of the methods.

That being said, it'll still be painful for users to setup the cluster. I think we can tackle this two ways

  1. We can have simple commands (i.e. qiime2 commands) that don't have cluster support, but can make use of local threads.
  2. We can have launch scripts for running these models on clusters that are supported with documentation which advanced users can use as a template.

I'm going to test this on the cluster shortly.

:returns: ``arviz`` InferenceData object with selected values
:rtype: az.InferenceData
"""
if dask_cluster is not None:
dask_cluster.scale(jobs=jobs)

Choose a reason for hiding this comment

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

I believe that this should be extended to the BaseModel as well

@mortonjt
Copy link

mortonjt commented May 25, 2021

Hi @gibsramen I've just verified that the slurm deployment appears to be working!
And this is without even passing in dask_cluster as input, so I think we can just go ahead an kill all of those parameter inputs.

Copy link

@mortonjt mortonjt left a comment

Choose a reason for hiding this comment

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

Ok, I missed a couple of things in my previous review. I have provided fixes that work on my cluster.

# if already Inference, just return
if isinstance(self.fit, az.InferenceData):
return self.fit
if isinstance(self.fit, list):

Choose a reason for hiding this comment

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

zoops, spoke too soon. Turns out that self.fit can be a tuple, so this will need to be

Suggested change
if isinstance(self.fit, list):
if isinstance(self.fit, list) or isinstance(self.fit, tuple):

return self.fit
if isinstance(self.fit, list):
if isinstance(self.fit[0], az.InferenceData):
return self.fit

Choose a reason for hiding this comment

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

I'd think we'd want to concat these objects together right? If so, the following will do

Suggested change
return self.fit
cat_name = self.specifications["concatenation_name"]
coords = self.specifications["coords"]
return concatenate_inferences(self.fit, coords, cat_name)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Good catch. I think here it makes sense to check if combine_individual_fits == True and then proceed accordingly.

import pandas as pd
from patsy import dmatrix

from .model_util import single_fit_to_inference, multiple_fits_to_inference
from .model_util import (single_fit_to_inference, multiple_fits_to_inference,
_single_feature_to_inf)

Choose a reason for hiding this comment

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

If you like the previous suggestion, you'll want to change this to

Suggested change
_single_feature_to_inf)
_single_feature_to_inf, concatenate_inferences)

gibsramen added 6 commits May 26, 2021 08:58
Now if self.fit is a sequence of InferenceData objects, can concatenate
them in to_inference_object.
Remove dask-jobqueue as dependency as that can be handled outside of
BIRDMAn. Bump version to 0.0.3.
@mortonjt
Copy link

It looks like the slurm deployment is working!

@gibsramen gibsramen changed the title [WIP] Refactor conversion to InferenceData Refactor conversion to InferenceData May 28, 2021
@gibsramen
Copy link
Collaborator Author

@mortonjt Is this good to merge or are you still testing/have suggestions?

@mortonjt
Copy link

mortonjt commented May 28, 2021 via email

@gibsramen gibsramen merged commit 2b26ead into main May 28, 2021
@gibsramen gibsramen deleted the restructure-inf branch July 1, 2021 22:36
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.

2 participants