Saving bifiltration to RIVET

[odinhg]

Describe the bug:

I believe the to_rivet() method of the SimplexTreeMulti class does not work as expected for multi-critical filtrations. It includes brackets that should not be there if I understand the RIVET documentation correctly. For example, for a simplex $\sigma=\lbrace0,1\rbrace$ with birth set $b(\sigma)=\lbrace(0,1),(1,0)\rbrace$, calling to_rivet() creates a line 0 1 ; [0. 1.] [1. 0.] in the output file, but it should be 0 1 ; 0 1 1 0.

Also, for one-critical filtrations, if a filtration value is -inf then RIVET does not recognize this value and throws an error.

Minimal example:

import gudhi as gd
import multipers as mp
import numpy as np

def test_rivet(st):
    for s, F in st.get_simplices():
        print(f"Simplex: {s}, filtration value(s): {F}")

    st.to_rivet("rivet_dataset.txt", overwrite=True)

    with open("rivet_dataset.txt", "r") as f:
        print(f.read())

# One-critical example
st = gd.SimplexTree() # usual gudhi simplextree
st.insert([0,1],1)
st.insert([1],0)
# converts the simplextree into a multiparameter simplextree
st_multi = mp.SimplexTreeMulti(st, num_parameters=2)
test_rivet(st_multi)

# Multi-critical example
st = mp.SimplexTreeMulti(num_parameters=2, kcritical=True, dtype = np.float64)
st.insert([0,1,2], [0,1])
st.insert([0,1,2], [1,0])
st.remove_maximal_simplex([0,1,2])
st.insert([0,1,2], [1,2])
st.insert([0,1,2], [2,1])
st.insert([0,1,2],[1.5,1.5])
st.insert([0,1,2], [2.5,.5])
st.insert([0,1,2], [.5,2.5])
test_rivet(st)

which outputs

Simplex: [0 1], filtration value(s): [  1. -inf]
Simplex: [0], filtration value(s): [  1. -inf]
Simplex: [1], filtration value(s): [  0. -inf]
# This file was generated by multipers.
--datatype bifiltration
--xlabel time of appearance
--ylabel density

# block of dimension 0
0 ; 1.0 -inf 
1 ; 0.0 -inf 
# block of dimension 1
0 1 ; 1.0 -inf 

Simplex: [0 1 2], filtration value(s): [array([0.5, 2.5]), array([1., 2.]), array([1.5, 1.5]), array([2., 1.]), array([2.5, 0.5])]
Simplex: [0 1], filtration value(s): [array([0., 1.]), array([1., 0.])]
Simplex: [0 2], filtration value(s): [array([0., 1.]), array([1., 0.])]
Simplex: [0], filtration value(s): [array([0., 1.]), array([1., 0.])]
Simplex: [1 2], filtration value(s): [array([0., 1.]), array([1., 0.])]
Simplex: [1], filtration value(s): [array([0., 1.]), array([1., 0.])]
Simplex: [2], filtration value(s): [array([0., 1.]), array([1., 0.])]
# This file was generated by multipers.
--datatype bifiltration
--xlabel time of appearance
--ylabel density

# block of dimension 0
0 ; [0. 1.] [1. 0.] 
1 ; [0. 1.] [1. 0.] 
2 ; [0. 1.] [1. 0.] 
# block of dimension 1
0 1 ; [0. 1.] [1. 0.] 
0 2 ; [0. 1.] [1. 0.] 
1 2 ; [0. 1.] [1. 0.] 
# block of dimension 2
0 1 2 ; [0.5 2.5] [1. 2.] [1.5 1.5] [2. 1.] [2.5 0.5] 

Trying to import the last one in RIVET gives the following (expected) error message:

Computation thread running
Checking for a module invariants file
# Thi
console:  READING FILE: rivet_dataset.txt 

console:  DataReader: Found a bifiltration file.

console:   

console:  terminate called after throwing an instance of 'InputError'

console:    what():  line 7: Could not read vertex: '[0.' is not a number

terminate called after throwing an instance of 'std::runtime_error'
  what():  Arrangement was not delivered
Aborted (core dumped)

For the first one, we get:

Computation thread running
Checking for a module invariants file
# Thi
console:  READING FILE: rivet_dataset.txt 

console:  DataReader: Found a bifiltration file.

console:   

console:  terminate called after throwing an instance of 'InputError'

console:    what():  line 7: Could not read vertex: '-inf' is not a number

terminate called after throwing an instance of 'std::runtime_error'
  what():  Arrangement was not delivered
Aborted (core dumped)

Maybe writing to a string or a buffer before writing the bifiltration to file can speed things up a bit too?

Setup:

• OS [e.g., macOS 14 on arm, fedora]: EndeavourOS Linux (Kernel is 6.13.2-arch1-1)
• version [e.g. 2.0, or commit hash if compiled]: f0bcd41
• C++ compiler (if compiled from source) [e.g., gcc 12.1, clang 18.1]: g++ (conda-forge gcc 13.3.0-1) 13.3.0

Checks.

• I have a working environment (i.e., pytest multipers passes)
• I have checked that the bug is not already present in the issue tracker
• I am willing to do a PR to fix this issue (Thank you!)

[DavidLapous]

Thanks for noticing this, I wrote that when there were no multicritical simplextrees ;
The multicritical issue should be fixed with b1900d1, but this function may be slow.

The implementation for Slicer IO with scc2020 (to_scc) also works with rivet's firep file format, with the rivet_compatible=True flag enabled, and is much faster. There are a few caveats though:

• Rivet doesn't seem to accept multicritical filtrations with this format
• Rivet randomly crashes on my laptop depending on the bins you give it
• if you compute a minimal resolution in a slicer, and put it in firep format, rivet will also crash (but minimal presentation is fine at least)

I think a good option would be to implement the "multicritical to onecritical" function to multipers, which should simplify things a lot. cf https://doi.org/10.1016/j.jpaa.2016.09.001 and the implementation in rivet

[odinhg]

Thanks, saving the bifiltration to RIVET seems to work as expected now! I also experience random crashes and unexpected results when importing to RIVET, but I guess this is up to RIVET and not multipers. My main motivation for using RIVET was to visually compare to the degree-Rips bifiltration, as I have been unable to really understand the multipers interface for degree-Rips.

Having multi-critical to 1-critical functionality in multipers as you suggest, sounds like an ideal approach to me.

[DavidLapous]

Sorry I forgot to answer this

My main motivation for using RIVET was to visually compare to the degree-Rips bifiltration, as I have been unable to really understand the multipers interface for degree-Rips.

Yes, I'm not a big fan of the current interface, it is currently very hacky... @hschreiber is currently factorizing/optimizing the classes to handle multifiltrations. I'll redo the code for this once it's done (and I have time for this 😐), i.e., put it in the multipers.filtrations and make the corresponding slicer behave as expected.

Having multi-critical to 1-critical functionality in multipers as you suggest, sounds like an ideal approach to me.

In terms of implementation, yes, but this will add a bunch of generators / relations to the presentation (i.e., positive/negative "duplicate simplices"), so I hope this will still be tractable for "reasonable datasets".
Some invariants need a projective (i.e. free) presentation / resolution to be computed, so this would also be very beneficial regarding this. I haven't really looked at the specifics, but from what I remember from this article, it seemed "easy to implement" ; so I'll try to implement this when I have time.