Skip to content
Snippets Groups Projects
  1. Jan 13, 2023
  2. Dec 20, 2022
  3. Sep 28, 2022
  4. Sep 26, 2022
  5. Sep 24, 2022
  6. Sep 21, 2022
  7. Sep 08, 2022
  8. Sep 07, 2022
  9. Sep 06, 2022
  10. Sep 03, 2022
  11. Sep 02, 2022
  12. Aug 25, 2022
  13. Aug 20, 2022
  14. Aug 16, 2022
  15. Aug 11, 2022
  16. Aug 09, 2022
  17. Jul 21, 2022
  18. Jul 14, 2022
  19. Jun 29, 2022
  20. May 19, 2022
  21. Apr 28, 2022
    • Arin Wongprommoon's avatar
      Extractor properly handles number of time points from metadata · e82bddae
      Arin Wongprommoon authored
      When an extractor is defined (based on the Extractor object) without
      specifying time points (the `tps` argument), the program raises a
      `TypeError`.
      
      The definition of `tps` when it is not otherwise defined in `.run()` is
      based on the assumption that the number of time points is stored as a
      scalar in the metadata of the HDF5
      file (`self.meta["time_settings/ntimepoints"]`).  This is wrong -- the
      number of time points is stored as a one-element numpy array.  The
      reason it is stored in this way is down to the behaviour of the log file
      parser (https://git.ecdf.ed.ac.uk/swain-lab/aliby/agora/-/blob/master/logfile_parser/logfile_parser.py)
      and how it processes tables as defined in the JSON file that specifies
      the grammar.
      
      This issue does not occur when the whole pipeline is run because the
      scalar element of the numpy array that stores the number of time points
      is properly extracted in
      https://git.ecdf.ed.ac.uk/swain-lab/aliby/aliby/-/blob/master/aliby/pipeline.py,
      line 89.
      
      The alternative way to fix it was to fix the behaviour of the log file
      parser.  The 'proper' way is to store the number of time points as
      scalars, not an array with one element.  However:
       (a) It is JSON-parsing code that I am not familiar with, and
       (b) There is a risk of breaking parts of the code base that relies on
       other parts of the metadata.
      
      So, this is essentially a quick-and-dirty fix, and it *should* be okay
      given that `time_settings/ntimepoints` only appears twice in the
      project.  However, if we decide to handle the metadata
      differently (unlikely given the fixed nature of our log files, and we've
      kind of exhausted all the useful information already), we will be in for
      adding `[0]`s at various places.
      
      Fixes issue #20.
      e82bddae
  22. Mar 28, 2022
  23. Mar 22, 2022
  24. Mar 04, 2022
  25. Feb 21, 2022
  26. Jan 20, 2022
  27. Jan 09, 2022
  28. Jan 07, 2022
Loading