Skip to content

restructure injfind workflow to bypass sql-xml and xml-sql conversion process

Leo Tsukada requested to merge master-inspinjfind-rework into master

modify inspinjfind executable (based on lalinspiral_injfind.py) and find_injection_layer to bypass sql-xml and xml-sql conversion process.

Accordingly I added share/simplify.sql, share/inj_simplify.sql

Related issue : https://git.ligo.org/gstlal/projects/-/issues/147

I have found a weird behavior for loading sql files. actually, the code seems to have populated all the rows in each table, but it looks as if it is an empty list. i.e. Here is a minimal set of script to reproduce the behavior.

import sqlite3
from ligo.lw import lsctables
from ligo.lw import dbtables

filename = "/ligo/home/ligo.org/leo.tsukada/projects/rerank_new_workflow/small_bns_injfind_bypass_test/rank/triggers/11700/H1L1-GSTLAL_TRIGGERS_BNS-1170000000-10000.sqlite"
with dbtables.workingcopy(filename, verbose = True) as target:
    xmldoc = dbtables.get_xml(sqlite3.connect(str(target)))
    sngl_inspiral = lsctables.SnglInspiralTable.get_table(xmldoc)
    for row in sngl_inspiral:
        print(row.mass1)
    print(len(sngl_inspiral))
    print(sngl_inspiral)

then here is output

...
2.1919413
2.1919413
2.0092938
2.0092938
355
[]

So the sngl_inspiral works as an iterator but doesn't have anything as list. but it is odd cuz the parent class of lsctable is list, so I would have thought len() should be based on its list class. with this I don't know where this len() comes from.

for the time being, the workaround I am doing in this MR is like to add (see this line)

for row in sngl_inspiral_table:
     sngl_inpiral_table += [row]
Edited by Leo Tsukada

Merge request reports