error in `pseudotime()`

[zoepiran]

Hi, first of all thank you for curating this package! it is super useful and convenient to use :) TBH I am not sure the behavior i encounter is a bug in the code or a consequence of a "bad" tree assignment due to lack of signal in the data. With that said i would appreciate your input. I am running the analysis pipeline following the tutorial Tree_Analysis_Bone_marrow_fates.ipynb Now, upon calling pseudotime() i encounter an error in line 210 (see content below) since cells_back is defined over segs from allsegs (there are segs that do not appear after allsegs = allsegs.apply(lambda x: x.value_counts(), axis=1)) whereas boo contains all segs (of dim).

i thought of modifying this - - after defining allsegs relating only to segs according to allsegs.columns but wanted to verify this makes sense or could it be the problem is in the cells assignment i obtained in previous steps.

Thank you in advance.

ValueError: Unable to coerce to DataFrame, shape must be (10, 37): given (10, 42)

[LouisFaure]

It could be indeed a lack of signal in the data.

If you are following the tutorial exactly, tl.pseudotime is run with multiple mappings, meaning that cell pseudotime assgnment is performed n times by selecting the closest node randomly using the values from R matrix as probabilities. In the end the mean of all pseudotime over the mappings is calculated, which can lead to pseudotime values being higher or lower to the assigned segment, hence the re-assignment step were the cells is assigned to the up- or down-stream segment in such case.

The error happing at line 210 tells me that the first run of reassignment of cells having a pseudotime below their assigned segment went through, but that it might have led to empty segments. If that is the case, that means that some segments of the tree are not stable enough and the tree require more careful tweaking to get a more robust one.

Two solutions:

• You can avoid doing multiple mapping by removing the parameters n_map and n_jobs in tl.pseudotime, but the fact it breaks down during multiple mapping could tell something about the validity of such tree.
• Re-run the tree algorithm in order to capture a more robust one, how stable is that tree? are trees looking the same among differents runs?

All of this is under the assumption that my interpretation of that error is right, but to be sure I would be happy to have a look at your data so I could try and debug myself!

[zoepiran]

Thank you for the prompt response! Let me first try to test your hypothesis, if I fail to reach a conclusion I will share the data and code for reproducibility (wouldn't want to waste your time atm mainly as I am also suspicious regarding the tree construction)

[GabyBG]

I had a similar issue, and it got solved by removing the n_map and n_jobs hope it works for you too.