GridPP PMB Minutes 367 (16.11.09) ================================= Present: David Britton (Chair), Sarah Pearce, Andrew Sansum, Tony Doyle, Jeremy Coles, Pete Clarke, Steve Lloyd, Roger Jones, Robin Middleton, John Gordon, David Kelsey, Tony Cass, Glenn Patrick, Dave Colling, Neil Geddes (Suzanne Scott, Minutes) Apologies: None 1. What is the NGI? =================== DB advised that discussion papers were now required, over this period, to assist in building the GridPP4 proposal. SP was working on one re Project Management, and one on Dissemination. A 'concrete' base was required for an NGI discussion, taken from the GridPP perspective. DB had circulated a paper. DB advised that the paper represented what affected GridPP particularly, looking at what we are contracted to deliver to EGI, defining relationships etc, to enable participation in a 'minimal' NGI. NG commented that there were assumptions about FTEs and funding - matched effort was only 33% funded, therefore we would report three months in order to get one month funded - matched effort reporting would need to be spread around. DB agreed that this was a key difficulty. NG advised that budget assumptions were changing, he had received an update yesterday from Steve Newhouse. DB had split the scope of the 'minimal' NGI paper into defined sections, and these were considered in turn: a) NGI security ---------------- DB noted that this was the clearest cut issue requiring a group/team in the UK. Up until now GridPP had done this, and funded DK and Mingchao Ma to deal with both operations and policy. The level of effort required would be 2 x FTE, with two-thirds of an FTE funded by the EU. This meant that the minimum GridPP needed to fund was ~1 x FTE in this area. This would be a GridPP post working within an NGI security team. DB asked how much effort was required in total? DK noted possibly a minimum of 2 x FTE. DB advised that we need to agree the model - that the security needs of GridPP were being handled within NGI. DB asked how much overlap there was, with what MM did now, and what was required for the Global Task? DK noted that we need a co-ordinated team for cover. DB asked if this was the right approach? An NGI team, and we fund people in this area? JG noted yes, but not necessarily geographically co-located. DB noted we would need a service-level agreement or an MoU between NGI and GridPP covering GridPP's requirements for wLCG. DB advised that a 'grey area' was bad - things needed to be clear, and a definite agreement would be required about the service level provided to us. b) Training ------------ DB advised that training was currently based in Edinburgh, with Dissemination at Manchester. NG advised that Edinburgh had bid for the training Global Task, and this could affect GridPP as it was a co-ordinating role in relation to Grid infrastructure, but it wasn't focussed on GridPP. In relation to Outreach at Manchester, there was a working assumption that NGS would do that task there - but this had not been allocated yet. DB noted that we need to do GridPP dissemination and wLCG dissemination from within GridPP, this should not be taken over by NGI. DB advised that SP was currently preparing two discussion documents, one of which would be on Dissemination. This was not something we wanted to devolve completely to NGI, but rather, work that could be done together. PC asked if this was likely to be funded in GridPP4? We should add-in ideas of 'impact' which might assist the bid. DB confirmed that we needed to do both KE and EI - Dissemination dealt with both of these issues and we would explicitly apply for a post in this area - this would maintain a focus on EI and EI within GridPP and would cover dissemination as well. c) Helpdesk/GOCDB/APEL ----------------------- DB understood these to be Global Tasks, and International Tasks as well - it was good that they overlapped. What did GridPP currently fund? JG advised 1.5 FTE excluding the ROC Managers. DB assumed we would have bid for the same effort (1.5 FTE) within GridPP4. This was agreed. d) Regional Support -------------------- DB advised that this was about deployment and support at the Tier-2 sites, which related to 8 x Tier-2 Co-ordinators. The problem was that this work fell under NGI International Tasks, for which the total funding would only be 2.1 FTE. If we wanted the deputy Tier-2 Co-ordinators to be funded, the maximum we could expect was 2 FTE, down from the current 4 FTE which would mean that 6 people would be reporting to the EU and doing all the International tasks - was it worth it for GridPP - or would we rather have 4 x FTE working for GridPP only? There was a discussion on what the International Task effort comprised. PC noted that if we increase by a factor of 1.5, only one person was needed. SL commented that 'International Tasks' was a misnomer. TD suggested that we couldn't consider the option where the International Tasks are not incorporated. NG advised that Belgium stepped out and had decided not to be included, as it was more cost effective for them that way. DB noted that there was too little funding and too much bureacracy - it was a lot of work for GridPP for the sake of a very small bit of extra effort. TD noted that with 2 x FTE, the breakdown could be north and south only - pre-supposing that the 'old' structure still existed as it was at present. e) Service Provision --------------------- DB advised that the joint working group had been set up to discuss services - but it had not managed to get very far. The minimum thing was the CA (run by NGS) and VOMS support (being transferred to NGS) and there was minimum service provision here. JG noted that Oxford ran Nagios and were keen to keep doing this; we already ran the WMSs etc. DB advised that it was premature to move these to an NGI, as they only affect GridPP. JG noted there was a requirement to run core services including the FTS. DB noted there were certain services that GridPP didn't run, and contracted-out, it would be up to NGI to continue these. JG noted that there were certain things that were crucial to GridPP. NG suggested that we identify these first and then decide the overlap. DB noted that we needed to get an understanding of what posts GridPP were required to fund. ACTION 367.1 ALL: to send email responses/thoughts to DB, or to the list, on NGI issues. TD noted that it would be good to add a paragraph on ROSCOE. RM agreed he would fill-in the grey boxes on DB's UK NGI diagram of a minimal NGI, as to what NGS would be doing in the areas listed. ACTION 367.2 RM to fill-in the grey boxes on DB's UK NGI diagram of a minimal NGI, as to what NGS would be doing in the areas listed. DB noted that this needed to be built from the bottom-up in order to begin considering management issues. 2. Status of Tier-1 Issues =========================== a) EMC hardware ---------------- AS reported that they now had a more detailed picture. Although they had already measured the voltage curves into the EMC equipment, a check last week in the machine room showed a 3khz background noise superimposed on the 50khz mains frequency - it was almost certain that this was the cause of the instability on the EMC hardware - it was being starved of current. The cause appeared to be insufficient cable length between the UPS and the load, causing insufficient inductence in the system. AS noted that a range of strategies were being developed and a number of options explored, possibly using non-UPS supply. The window would be after Christmas, to move the FTS/LFC/CASTOR. AS was meeting with the design authority on Friday. b) Disk Procurement -------------------- AS reported that regular meetings were taking place with Viglen - there was a detailed plan in place relating to a variety of parallel avenues, in order to provide a working solution by the end of November, at which time the procurement would be reviewed and the equipment probably be returned as unusable. Deployment was hoped for by January. 3. Quarterly Reporting ======================= It was noted that Quarterly Reports were still required. This was urgent. STANDING ITEMS ============== SI-1 Tier-1 Manager's Report ----------------------------- AS reported as follows: Fabric: 1) New procurements have started. - Disk ITT has closed and evaluation is complete. Expect to place an order at the end of this week. - CPU tender is closed and evaluation is underway. Indication is that evaluation will be straightforward. Expect to notify suppliers of the outcome this week. 2)We have received 9 T10KB tape drives and will begin testing the new hardware shortly (in contention with work on the faulty CASTOR RAID arrays). 3) Procurement is underway for an additional 4*1Gb/s second OPN link to CERN as resilient backup. [status as Wed 11th November] Order has not been placed yet but case for single company tender has been accepted. 4) Work to understand the underlying cause of the CASTOR/FC+FTS RAID array hardware problems has made substantial progress this week. We have identified a 3KHz ripple on the current supply delivered by the UPS. This was not visible in the voltage curves and explains why it was not seen with previous efforts to identify the cause. This ripple is probably caused by a resonance effect between the UPS room load and the UPS supply. The electrical team suggest that it is probable the supply is configured to meet an inductive load but actually is seeing a capacitive load. It is unsuprising that the RAID arrays are sensitve to this unusual electrical supply. We are investigating how (and when) the problem can be resolved. We are assessing if it is safe to continue operation of other equipment in the UPS room on the supply as it currently is. We are working on schedules that lead to a downtime (or possibly at risk) w/b 4th January to move services back to the EMC units, either on clean LPD room power or on fixed UPS room power. 5) A rolling upgrade to deploy new Linux kernels is underway. Service: 1) SAM availability for the OPS VO was 97%. Weekly production report is at: https://www.gridpp.ac.uk/wiki/RAL_Tier1_Experiments_Liaison_Meeting_Oper ations_Reports 2) Problems on the CASTOR information Provider (CIP) Monday last week following a hardware failure. We are working to make the CIP more resiliant. 3) Still problem where sometimes batch jobs land on the wrong node. Continue to be investigated. SI-2 ATLAS weekly review & plans --------------------------------- RJ reported that the Tier-2s were down with no single cause, although reliability was up slightly. JC noted this might be because of patching in relation to kernel vulnerabilities and SL5 upgrades. RJ noted they had done a hammercloud test at the weekend which had not been totally successful. They were preparing for real data. SI-3 CMS weekly review & plans ------------------------------- DC reported that the Tier-1s and Tier-2s seemed to be performing reasonably, the plots looked ok. They were discussing what custodial data goes to RAL. They were preparing for real data. SI-4 LHCb weekly review & plans -------------------------------- GP reported as follows: OPERATIONS: 1. Problem accessing shared area at RAL (GGUS ticket # 53193) last Wednesday. ~10% of LHCb jobs failed over 24 hours. 2. Epidemic of LHCb application errors - primarily segmentation faults - on sl5 (including at CERN). Under investigation. 3. Problem with some unstable DIRAC services creating issues for production jobs. OUTLOOK: 4. Ongoing productions in bursts. 5. User analysis. SI-5 Production Manager's Report --------------------------------- JC reported as follows: 1) We have a growing issue in the area of multi-user pilot jobs. Previously it was agreed through the MB/GDB that the experiments could test their frameworks with a small group of known users ahead of general uptake once SCAS/glexec is in place. Following comments at the GDB last week it became evident that wider use of multi-user pilots is already taking place and furthermore the experiment position seems to have changed. ATLAS and LHCb are indicating that even if glexec is deployed it is now too late to expect it to be thoroughly debugged and used. Feedback from the UK experiment representatives is below. Where do we go from here!? CMS: Not currently using multi-user pilots but these may come later. Stuart responded as follows: “ GlideIn's (our name for pilots) are used by 1 set of operators in production and another in analysis. The production one doesn't need to switch identity and (i believe) only runs at Tier1's. Out of 3 or so crab servers, which are used to handle user jobs, 1 runs glideins. The non- glideins submit single jobs on behalf of the user by obtaining their proxy through myproxy delegation. My knowledge of the glidein one is less clear, I just had a quick word with someone who knows more and he seems to think it would use glexec if available - and i assume just run under the initial identity if not. Basically the GlideIns are heavily pushed by certain elements of USCMS but they have never been able to get them to a state where a non expert can run them. Thus they haven't really come under as much scrutiny as the common elements of the system as no one else has ever been asked to look at running them." LHCb: Raja’s reply: “"a. Yes, we are using multi-user pilots in production. b. From what we can see, glexec is not yet stable after 3 years of testing and its configuration at sites is still very delicate. So, we will be happy to try it out (as we have been happy to help test), but given imminent data taking we may not be able to do any more large scale tests in the immediate future to put it in production. Right now, we will need to concentrate on stability for data taking." ATLAS: From Graeme: “a) whether multi-user pilots are already being run beyond the agreed levels for testing purposes; Yes. However, in the October GDB there was a clear statement from Ian Bird that the experiments had waited for long enough for glexec and that they could now run multi-user pilots. So I would dispute that the agreed levels are only for "testing purposes". b) whether the experiment as far as you know is intending to use glexec if we get sites to deploy it. Yes, in principle. However, because of the lateness of glexec and the considerable changes we had to make to our code to get it to work properly with this new infrastructure I would say that we would be extremely hesitant to rush into a widescale deployment just before accelerator operations start." My summary would be: From the site side: a) The AUP has been violated. Trust is going to be undermined. b) Some sites are going to be in a very awkward position since they pushed for something like glexec due to traceability requirements of their site security policies. c) There may be no point deploying glexec if the experiments are not actually going to use it. From the experiment side: a) The belief is that the MB decision (or an Ian Bird statement) was a green light to run these jobs? b) The experiment needs to now run these types of jobs as data taking is imminent. c) glexec is not currently available. Debugging takes time that is no longer available. There are mechanisms in place (under experiment control) to track which user ran which jobs. As mentioned last week, we are unable to progress with wider deployment of glexec as the SL5 WN release with glexec is not available. JG suggested that he would take this issue to the MB. JG noted that CMS has no plans to run such jobs at present, although future strategy might involve it. JG noted that the MB had 'encouraged' the running of multi-user-pilot jobs. DB noted that, rather, a clear statement was required. DK advised that the experiments think they have the choice to do this or not - but violating trust was very serious. DB asked how the MB could suggest doing this when glexec did not work on the WNs? DC advised that it shouldn't be up to the experiments to decide this - rules should be adhered to. JG hoped the MB would reprimand the experiments for doing this when it had not been announced. DB asked if JG could raise this with Ian Bird directly? A statement was required, as this was potentially a very serious violation of trust. TD advised that in the absence of a SL5/glexec/SCAS system, experiments should not be going ahead. It was recognised that there was always a requirement for this system, especially when experiments were faced with real data, but this had been discussd many times in the usual fora and it was generally known that this was going on. JG advised that he hadn't known about it since the last statement from GS that small test runs would be carried out at specific sites - that was the last formal announcement. RJ noted he had known about this happening for years - Biomed have misused the system a couple of times - but it was supposed to be one system. JG advised that this kind of issue should be brought up at the MB. As far as he knew, Ian Bird had gone ahead and told sites to deploy SCAS. DB asked if glexec was still the issue? JG noted it wasn't certified yet. JC noted that they couldn't currently deploy the WN release that was needed. DB noted they couldn't deploy it yet so the experiments couldn't use it yet. TD commented that the experiments should declare what their automisation policy is and what their structures are - we don't have a fully deployed and tested glexec system - it is structured and documented. DB advised that what was agreed was that ATLAS and LHCb could test multi-user pilot-jobs in limited scope and at specific sites, with few identities. JC confirmed that this had been happening. DB further noted that glexec was not available yet for the WNs so the experiments must continue limited use. JG noted he needed to raise this with IB - a clear formal statement was required. DB noted that we need to decide for ourselves in the UK - if there is no leadership then we would make our own decisions for the UK. RJ advised that there was a difference of recollection and statement - things needed to be clearer. DK noted that the MB had to move to rebuild the trust - it was their role after all. DB agreed - and it must be timely action from them. The action was on JG, and it would be monitored. ACTION 367.3 JG to contact Ian Bird directly, immediately, and ask for a clear formal statement in relation to multi-user pilot-jobs by the experiments. This formal statement was required immediately - we could not wait for this issue to be brought up at the next MB. DC suggested that something needed to be declared to the UK list to say what was happening. DB advised that information from ATLAS and LHCb had to be accurate before anything was sent out. JC asked who were the formal contacts? Statements had already been made by Graeme Stewart and Raja Nandakumar etc. TD noted that these statements were not official. GP suggested that for LHCb, Phillipe Charpentier be contacted; Dario for ATLAS; Matthias for CMS (cc Claudio). ACTION 367.4 JC to contact Phillipe Charpentier (LHCb); Dario (ATLAS); Matthias and Claudio (CMS) and elicit formal, clear, statements from the experiments in relation to their current intentions/activities re multi-user pilot-jobs. Clear formal statements were required before information was to be sent round the community. ACTION 367.5 DB to send formal information round the community re multi-user pilot- jobs, once clear statements had been received from Ian Bird (via JG) and the experiments (via JC). 2) Still on security, site response to the latest kernel vulnerability (mentioned last week as NULL pointer dereference vulnerability (CVE-2009-3547)) has been excellent. Most sites have now upgraded. We have a couple of vendor dependent interventions pending but workarounds have been implemented to reduce any risk in the interim period. 3) We are starting to see problems with the top-level BDIIs. Last week a number of CE-sft-lcg-rm tests (various sites) failed with BDII timeouts as the cause. Early indications suggest that this may be the result of longer query times as BDII log sizes grow. 4) A CA TAG meeting is expected to take place in the coming weeks (date to be confirmed). If there are any issues that the PMB would like me to raise please let me know. Before the meeting moved on to consider the Actions (they were out-of-time) - DB asked if there was AOB? AOB === RJ advised that ATLAS wanted to run another tutorial and wished to know if it was possible for GridPP to assist financially. It was agreed RJ should put a proposal together for consideration by the PMB. ACTION 367.6 RJ to submit a proposal to the PMB for funding assistance for the next ATLAS tutorial. REVIEW OF ACTIONS ================= 348.2 JC to investigate whether the decrease in job success rate metric in the last quarter is due to time-outs at busy sites or due to job-aborts due to incorrectly setup environments. This was still in progress - DB noted that the next Quarterly Reports will help and possibly render the action redundant. SP asked that this remain open until the next Quarterly Reports. 354.2 JC to consult with site admins on a framework policy for releases, with a mechanism for escalation, plus a mechanism for monitoring. 358.1 SP to work with the working group on the following issues in relation to GridPP/NGS convergence: 1. identify Institutes 2. identify manpower 3. decide who is bidding for what - a draft transition plan would be made available by the end of the year; GridPP4 requirements would also be considered. SP was waiting on the Working Group to reply to her. SP reported there had been an email exchange and she had sent suggestions on how to move forward. JC had met with Andy Richards at RAL. One of the issues was uncertainty in relation to funding - SP needed more detail re resources and options for the future, also for EGEE-funded manpower at present and what we have signed up to in NGI. She was awaiting a response. DB noted that NG was trying to understand the proposals and the funding fractions. In defining GridPP4 we needed to define these posts and responsibilities. JC noted that JG had suggested going through the EGI proposal document for info. 359.4 JC to follow up dTeam actions from the DB, as follows: --------------------------- 05.02 dTeam to try and sort out CPU shares and priority resources, at Glasgow first (perhaps by raising the job priority in Panda). --------------------------- JC would check the situation with Graeme Stewart (who was currently on annual leave). 359.5 Lee Barnby (experiment rep) still to contact Neasan O'Neill, advising where, specifically, the GridPP website should point to for his experiment, in terms of user support information. (Graeme Stewart, DC & RN had already done this). SP to follow-up. Done, item closed. 359.6 SP to ensure that Neasan O'Neill updates the GridPP website accordingly (once experiment reps have provided info as to where the GridPP website should point to for each of their experiments, in terms of user support information). Done, item closed. 361.3 JC and AS to check Tier-1 and Tier-2 gstat2 results (in relation to SL5 having been discussed at the GDB). JC reported that he had checked this, but information from AS was still awaited. JC noted that there were issues with the results. 366.1 DB to check and see if it might be possible for the 14/15 April PPRP meeting to be held in London. The answer was NO - due to cost-cutting, the meeting would be held in Swindon. Done, action closed. 366.2 RJ to provide ATLAS HW requirements for 2011-15. Ongoing. 366.3 DC to provide CMS HW requirements for 2011-15. Ongoing. 366.4 GP to provide LHCn HW reqiremens for 2011-15. Ongoing. 366.5 SL/DB to estimate what fraction of STFC funding goes to non-LHC groups. What about the theory side? Ongoing. 366.6 GP to invite input from Other Experiments. Ongoing. 366.7 DB (in consultation with AS) to provide HW-cost estimates for 2011 - 2015. Ongoing. 366.8 AS to confirm that the Tier-1 proposes to use Tape-based storage in the period 2011 - 2015. Ongoing. 366.9 RJ to confirm that ATLAS supports the use of Tape storage in the period 2011-2015. Ongoing. 366.10 DC to confirm that CMS supports the use of Tape storage in the period 2011-2015. Ongoing. 366.11 GP to confirm that LHCb supports the use of Tape storage in the period 2011-2015. Ongoing. 366.12 SP to liaise with AS to establish non-capacity costs. Ongoing. 366.13: SP to request and collect first cost estimates of posts for GridPP4. FEC and non-FEC posts need to be costed. The Tier-1 posts should be costed as accurately as possible as soon as possible since there is a large lever arm here. On hold until next week. 366.14 DK to provide first estimate of average RAL post cost on the basis of the current distribution of posts/grades. Clearly this will need refinement once we understand the final mix better. ACTIONS AS AT 16.11.09 ====================== 348.2 JC to investigate whether the decrease in job success rate metric in the last quarter is due to time-outs at busy sites or due to job-aborts due to incorrectly setup environments. This was still in progress - DB noted that the next Quarterly Reports will help and possibly render the action redundant. SP asked that this remain open until the next Quarterly Reports. 354.2 JC to consult with site admins on a framework policy for releases, with a mechanism for escalation, plus a mechanism for monitoring. 358.1 SP to work with the working group on the following issues in relation to GridPP/NGS convergence: 1. identify Institutes 2. identify manpower 3. decide who is bidding for what - a draft transition plan would be made available by the end of the year; GridPP4 requirements would also be considered. SP was waiting on the Working Group to reply to her. SP reported there had been an email exchange and she had sent suggestions on how to move forward. JC had met with Andy Richards at RAL. One of the issues was uncertainty in relation to funding - SP needed more detail re resources and options for the future, also for EGEE-funded manpower at present and what we have signed up to in NGI. She was awaiting a response. DB noted that NG was trying to understand the proposals and the funding fractions. In defining GridPP4 we needed to define these posts and responsibilities. JC noted that JG had suggested going through the EGI proposal document for info. 359.4 JC to follow up dTeam actions from the DB, as follows: --------------------------- 05.02 dTeam to try and sort out CPU shares and priority resources, at Glasgow first (perhaps by raising the job priority in Panda). --------------------------- JC would check the situation with Graeme Stewart (who was currently on annual leave). 361.3 JC and AS to check Tier-1 and Tier-2 gstat2 results (in relation to SL5 having been discussed at the GDB). JC reported that he had checked this, but information from AS was still awaited. JC noted that there were issues with the results. 366.2 RJ to provide ATLAS HW requirements for 2011-15. RJ & DC had a preliminary discussion - they need to agree common profile, even if it is flat cash. 366.3 DC to provide CMS HW requirements for 2011-15. In progress. 366.4 GP to provide LHCn HW reqiremens for 2011-15. GP had started this. DB noted he needed the numbers for hardware costings and needed something soon to begin work. The deadline was 2 weeks for prelim. numbers. AS would look at them as well. 366.5 SL/DB to estimate what fraction of STFC funding goes to non-LHC groups. What about the theory side? 366.6 GP to invite input from Other Experiments. 366.7 DB (in consultation with AS) to provide HW-cost estimates for 2011 - 2015. DB was awaiting inputs. 366.8 AS to confirm that the Tier-1 proposes to use Tape-based storage in the period 2011 - 2015. AS noted this depended on money costs. DB advised this related to long-term plans and power capacity. Physical footprint space? Alternatives? Early action on AS required. AS had sent tech questions round the team and would forward inputs when available. DC noted to the meeting that today was the 16th Nov - only 4 weeks remained until Imperial, by which time we needed to have made extensive progress. 366.9 RJ to confirm that ATLAS supports the use of Tape storage in the period 2011-2015. RJ noted they had a belief in the archival work but the cost was to be provided by the provider. Tape would have a front-end staging system. DB asked whether they might want to move to another model? We should not assume that tape will do. A statement was required. 366.10 DC to confirm that CMS supports the use of Tape storage in the period 2011-2015. 366.11 GP to confirm that LHCb supports the use of Tape storage in the period 2011-2015. 366.12 SP to liaise with AS to establish non-capacity costs. SP advised that discussions had started. DB noted a long-term question about the model. 366.13: SP to request and collect first cost estimates of posts for GridPP4. FEC and non-FEC posts need to be costed. The Tier-1 posts should be costed as accurately as possible as soon as possible since there is a large lever arm here. 366.14 DK to provide first estimate of average RAL post cost on the basis of the current distribution of posts/grades. Clearly this will need refinement once we understand the final mix better. DK had already started this and would have estimates later this week. 367.1 ALL: to send email responses/thoughts to DB, or to the list, on NGI issues discussed. 367.2 RM to fill-in the grey boxes on DB's UK NGI diagram of a minimal NGI, as to what NGS would be doing in the areas listed. 367.3 JG to contact Ian Bird directly, immediately, and ask for a clear formal statement in relation to multi-user pilot-jobs by the experiments. This formal statement was required immediately - we could not wait for this issue to be brought up at the next MB. 367.4 JC to contact Phillipe Charpentier (LHCb); Dario (ATLAS); Matthias and Claudio (CMS) and elicit formal, clear, statements from the experiments in relation to their current intentions/activities re multi-user pilot-jobs. Clear formal statements were required before information was to be sent round the community. 367.5 DB to send formal information round the community re multi-user pilot- jobs, once clear statements had been received from Ian Bird (via JG) and the experiments (via JC). 367.6 RJ to submit a proposal to the PMB for funding assistance for the next ATLAS tutorial. The next PMB would take place on Monday 23rd November at 12:55 pm.