... | ... | @@ -28,12 +28,14 @@ Summary of the meeting |
|
|
|
|
|
JC Biasci, A Gotz, L Claustre, J Bodera, J Meyer, V Honkimaki, M Guijarro, M Burghammer, W de Nolf, J Susini and H Reichert
|
|
|
|
|
|
**ACTIONS**
|
|
|
|
|
|
*Action 1*: Andy didn't have ready the dashboards and Veijo said that the format means there is too much detail. It was
|
|
|
agreed that the dashboard is not to be used during the BSC meeting but rather to be a tool used by the BCU colleagues and
|
|
|
BL staff to ensure that there is a common understanding of what is to be done and what is pending. To ensure we can
|
|
|
estimate how much work remains to be done for a beamline a list must be complete. ACTION TO BE CLOSED
|
|
|
|
|
|
*Action 2* The document wasn't shared by Harald as planned. A new document will be ready by the end of the year which will
|
|
|
*Action 2*: The document wasn't shared by Harald as planned. A new document will be ready by the end of the year which will
|
|
|
talk about Beamline restart (therefore the scope will be larger than Bliss, but it will cover Bliss and the conversion of
|
|
|
beamlines). ACTION TO REMAIN OPEN. DATE TO BE CHANGED TO 20/12/2019
|
|
|
|
... | ... | @@ -52,7 +54,45 @@ ready. |
|
|
It was also pointed out that the Insertion Devices Group are concerned about fast movements (we have
|
|
|
staff/Beamlines wanting very slow movements and others wanting fast movements).
|
|
|
|
|
|
*Action 5* Jens explained that progress has been made regarding the external data saving. There has been a meeting with
|
|
|
Armando and Wout recently. Also a virtual data set has been produced and was ok. Overall the expectation is that the work
|
|
|
should be finished in November.
|
|
|
|
|
|
*Action 6* Matias explained that only Thomas Roth volunteered. It was agreed that Thomas and Matias will report during the
|
|
|
next BSC on progress regarding the documentation review.
|
|
|
|
|
|
**STATUS OF BEAMLINE CONVERSION**
|
|
|
|
|
|
Jens used the presentation available in the table at the top. Andy pointed out that he talked with Muriele who said that
|
|
|
ID21 progress was more like 25% and not 50%. Wout said that 50% looked high to him as ID21 only can do "unimportant scans".
|
|
|
Matias explained that yesterday some BCU team members managed to do a continuous scan at ID21.
|
|
|
Jean explained that a single % is always going to be a difficult measure to interpret and Andy said that the important
|
|
|
thing is whether they can start up. Jordi suggested that the % completion should come from the beamlines as they are the
|
|
|
final customer and they should say whether they are satisfied or not with the work done. Laurent then said that rather than having a single percentage for progress we could have three, showing different key aspects of the conversion to Bliss for a beamline. **NEW ACTION: Laurent and Jens to put in place the new system** with three progress indicators instead of one that also includes the feeling/satisfaction from beamline staff.
|
|
|
Jean explained that he wants the same level of functionality as before. Extending the functionality of what is possible is
|
|
|
for him a separate project.
|
|
|
Harald noticed that other MX beamlines are not in the list and wondered whether they are finished, as they are a priority
|
|
|
as well. Jens explained that some minor changes and updates are required. Harald requested then that they are added to the
|
|
|
list of BL being converted to BLISS, so it is clear for all beamlines whether they require some work or not.
|
|
|
|
|
|
Jens then moved on to request to the Bliss Core Development team to have a stable version (or new versions that are backwards compatible), so tests once done do not need to be repeated. Veijo wondered whether there is a standard and automated test bench for Bliss. It was agreed that in order to have a stable version of Bliss there would be two branches/versions of Bliss: one stable and backwards compatible while everything that does not maintain backwards compatibility will be moved to a new version not to be installed in the beamlines in the first place.
|
|
|
Jean then wondered whether the upgrade to a new version of Bliss will be risky, because very quickly we will have 25 beamlines using Bliss. Jean remembered that moving to a new version of SPEC used to involve around 2 days of tests and debugging. Jens explained that the first major upgrade of Bliss at a beamline will be done during a long shutdown to ensure that any problems arising can be sorted. He also pointed out that the software will become more stable with time.
|
|
|
Matias explained that Bliss has been using Packages for a while and that by the definition of it they are stable. Jens then pointed out that his team needs bug fixes and new functionality (like new controllers) while avoiding breaking anything that works already. Andy said that he wants a freeze of a major version, so it is stable for the start with only minor changes (bug fixes, minor new functionality) that does not break/changes behaviour of existing functionality.
|
|
|
Jean wondered if it is known already what functionality won't be provided for the start and Laurent said this will be clear once we agree on the stable version that we keep. Matias explained that his team is working on the Data Policy, Logbook, scans and that if we could wait a bit more the stable version will be better. Jens requested a stable version by the end of November as the teams doing the conversion of the beamlines cannot wait more. **NEW ACTION: List of what is included and what not** possible in the stable Bliss version. That could take the form of a MosCow list (Must be included, Should be included, Could be Included and Won't be included).
|
|
|
|
|
|
**STATUS OF CORE DEVELOPMENT**
|
|
|
Andy presented a table showed already the day before durig the BL restart day, saying that most things will be ready for the stable version. Veijo asked if anything is a problem and Andy replied that HKL won't be ready.
|
|
|
Harald asked about Archiving and Backups. Andy explained that this part belongs to TID and that Rudolf will present at the
|
|
|
next EDMB the changes behind the scenes. Andy stressed the fact that backups and archiving is not part of Bliss but TID.
|
|
|
Manfred said that if GPFS performance is going to change that will affect them as users. Andy explained that the servers will be load balancing and bandwith will be shared, so there will be an impact. That's why a buffer system will be tested. That could affect fast detectors, analysis and visualisation.
|
|
|
|
|
|
**AOB**
|
|
|
Veijo explained what reamains to be done at ID31. He requires Continuous Scans and would like to have a software solution
|
|
|
for the _Master Energy_. He also would like to be able to import/load OH session into a global session, however he doesn't see any showstoppers.
|
|
|
Harald asked Veijo how long did it take to get used to the new system: Veijo said it was fast and easy to use Bliss. Macros and loops took a little bit more of time to get used to them, but that for users it won't make a difference. He struggled to find the XAML configuration files as it was not obvious where they are stored. How to debug and log for problems is not always evident. Laurant then pointed out that beamline technicians may have the same problems and that they will require training.
|
|
|
Harald understood that it is therefore possible to get up to speed rather quickly. Manfred then pointed out that yes as long as you know Python basics. Andy said that a Python course would be very beneficial and that is something that beamline staff can start doing now. Manfred also said that at the beginning of the documentation it should be clear what content is where.
|
|
|
|
|
|
Laurent asked whether config editing through the web application should be removed as it is not a priority. Matias explained that the web application is working again since yesterday. Andy said that it looks reasonable given the amount of work left to reduce the scope. Laurent said that it should be ok for people to edit the config file directly without using the web application. Andy confirmed that the web application for editing the configuration is a nice to have but not a priority and that Stuart Fisher will look at that later on in 2020.
|
|
|
|
|
|
|
|
|
Minutes from previous meetings:
|
... | ... | |