Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move data interpretation to pymosa #6

Open
themperek opened this issue Apr 16, 2018 · 14 comments
Open

Move data interpretation to pymosa #6

themperek opened this issue Apr 16, 2018 · 14 comments
Assignees

Comments

@themperek
Copy link
Member

Make data interpretation part from https://github.com/SiLab-Bonn/pyBAR_mimosa26_interpreter to pymosa

@laborleben
Copy link
Contributor

I'd keep it separate. Other packages depend on it (e.g., testbeam-analysis). You can rename it. But why bother?

@themperek
Copy link
Member Author

themperek commented Apr 16, 2018

To keep everything in one place, tested (with unit tests) and in sync.
Testbeam analysis can import pymosa.
Same for #7

To be discussed.

@laborleben
Copy link
Contributor

The interpreter is not part of pymosa IMHO. And should stay separated because it is shared between projects. I don't like the idea to install basil, pymosa, and all the dependencies, etc. just to get testbeam-analysis running.

@themperek
Copy link
Member Author

You need to install: pyBAR_mimosa26_interpreter what difference it makes if you have to install pymosa instead?

The gain is it better tested, will have a package and will be in one place.

@laborleben
Copy link
Contributor

One part is analysis software, the other one is hardware related. I would not mix them up. And as I pointed out it is not only pymosa, but instead many (hardware related) dependencies which come automatically if you do a pip install. This is useless stuff if you need the interpreter only.

@laborleben
Copy link
Contributor

The tests can be in added to the Mimosa26 interpreter project. Anything speaks against it?

@DavidLP
Copy link
Contributor

DavidLP commented Apr 17, 2018

The reverse is also true: if you just want to take data and use another TB-system (e.g. Eudaq) you do not want to be forced to install beasty packages like numba. Although these issues can be solved by specifying pip install options for subpackages. But that is also messy to my mind,

@laborleben
Copy link
Contributor

Please, no subpackages.

@themperek
Copy link
Member Author

https://github.com/SiLab-Bonn/pyBAR_mimosa26_interpreter/blob/master/requirements.txt

numba can be done optional (use if you have not use if you have not)

@YannickDieter
Copy link
Collaborator

What is now the status? Should we move the new mimosa26 interpreteter to pymosa?
I would also be in favor to move it to pymosa. It is still separated and people only need to install pymosa to use our M26 stuff.

I am almost done with it, apart from some documentation for the interpreter which is definetly needed since it is a very complex thing which should be documented.

@laborleben
Copy link
Contributor

I still would keep it separate.

  1. No need to change subsequent packages that require pyBAR_mimosa26_interpreter. Would you like to break all existing installations/dependencies? Do you update all branches of other packages?
  2. Keep the interpreter separate from Mimosa26 readout since they depend on different base packages. How would you separate the requirements (especially basil_daq) without programming sub-packages (as @DavidLP pointed out)?
  3. Less clutter when distributing newer versions of the Mimosa26 interpreter. Do you want to distribute the whole pymosa package with firmware (almost 20MB alone for that), configuration files, etc., just to distribute fixes of the Mimosa26 interpreter (which has a few kB)? Believe me, you will have plenty of fixes and new features in the near future. Have a look at the current git history of the Mimosa26 interpreter or the FEI4 interpreter.

Yes, pyBAR_mimosa26_interpreter is not the best name since it is in wide use. But you will have much less work if you keep the packages separate - at least for some time.

@laborleben
Copy link
Contributor

laborleben commented Jun 4, 2018

PS: A good time for merging both projects would be the time when we do the transition to Python 3.x.

@DavidLP
Copy link
Contributor

DavidLP commented Jul 11, 2018

Just for your info: With EUDAQ integration we have to do data analysis during data taking, thus this package has to depend on the interpretation package.

@YannickDieter
Copy link
Collaborator

I am so far done with the new (cleanup of Tokos code) Mimosa26 interpreter. You can see it here.
As soon as possible I will write a documentation and explain how to use the interpreter and how the event building is done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants