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