Skip to content
Snippets Groups Projects
  1. Feb 10, 2023
  2. Jan 18, 2023
  3. Jan 13, 2023
  4. Jan 12, 2023
  5. Jan 11, 2023
  6. Jan 10, 2023
  7. Dec 20, 2022
  8. Sep 28, 2022
  9. Sep 26, 2022
  10. Sep 24, 2022
  11. Sep 21, 2022
  12. Sep 08, 2022
  13. Sep 07, 2022
  14. Sep 06, 2022
  15. Sep 03, 2022
  16. Sep 02, 2022
  17. Aug 25, 2022
  18. Aug 20, 2022
  19. Aug 16, 2022
  20. Aug 11, 2022
  21. Aug 09, 2022
  22. Jul 21, 2022
  23. Jul 14, 2022
  24. Jun 29, 2022
  25. May 19, 2022
  26. 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
  27. Mar 28, 2022
  28. Mar 22, 2022
  29. Mar 04, 2022
  30. Feb 21, 2022
Loading