star-qaboard-l@lists.bnl.gov
Subject: STAR QA Board
List archive
RE: [[STAR-QAboard] ] Weekly QA Board Meeting - 09/Aug/2024 at noon 12 EDT (Dongsheng Li)
- From: "Tsang, Chun Yuen" <ctsang@bnl.gov>
- To: 李东升 <erl@mail.ustc.edu.cn>
- Cc: ASHIK IKBAL <ashikhep@gmail.com>, "star-qaboard-l@lists.bnl.gov" <star-qaboard-l@lists.bnl.gov>
- Subject: RE: [[STAR-QAboard] ] Weekly QA Board Meeting - 09/Aug/2024 at noon 12 EDT (Dongsheng Li)
- Date: Tue, 10 Sep 2024 21:26:20 +0000
Hi Dongsheng,
Sorry for the late reply. I missed your email.
I think the agreement is that QA worker probably needs to manually review those 44 bad runs. AI can only narrow down the run list so you don’t need to go through all ~500 runs, but people still need to do the final inspection.
If you think the shift log entries for some of those 44 runs are not that bad, I suggest that you take those runs out, make a list of runs that you “recovered” (hopefully there’s only a few of those), make a list, present it on our Friday meeting and have the list finalized.
I am not surprised that some ETOF runs are selected despite my explicit instructions not to. LLM can only approximately follow orders so that’s why manual review of their results is warranted. That’s especially the case for this analysis since I deliberately use a not-so-sophisticated version of LLM. I can’t use ChatGPT or any other commercial LLM both because of security and BNL won’t pay for those services. Since the LLM must run it on my desktop, it uses can’t be as smart as ChatGPT.
If you don’t need ETOF, then I think it’s fine to keep those ETOF runs in. For those runs with no shift entries, the most correct way is to inspect the QA plots for all of them one-by-one. However, you have already ran your run-by-run QA code so perhaps if those runs are not flagged by the run-by-run QA, they’re fine? Since you are the QA worker for your run list, it’s your prerogative to decide what to do. Do you want to be safe and just reject all of them? Or do you think statistics is the most important consideration and you must keep them all? Or manually review all of them for a balanced run list? Any of those options work, but I think you need to decide and tell us on Friday. Afterall, you will work on those data, so you should be the one to make the call.
To summarize, you need to read the shift log for the 44 runs. If you believe there is a good enough justification for not including some runs in the bad run list, just take it out and present it on Friday. The remaining runs + what you got from run-by-run QA script will (hopefully) be the final official bad run list.
Best wishes, Tommy
From:
李东升 <erl@mail.ustc.edu.cn>
Hi Tommy,
Thanks for your nice study. I never realized that LLM can come into the QA process, so it looks very interesting to me.
I checked the 44 badruns listed in your slide 4. Actually I'm not familiar with the shift log and I don't fully understand what those texts really mean. Just based on my limited understanding, in general I agree most of these 44 badruns look suspicious, but a few of them maybe still look OK to me.
For example, if we look at run 22123007, the shift log says "BTOW: configuration failed -- STOP this run & restart", but they also say "Don't know if this is still what we are supposed to do". Then in run 22123012, they meet this problem again and they say "Was told not to stop the run for this error". So I guess this error message is not related to a major problem?
Another thing is, I find for some of these badruns, along with the error message, they say they mask out something. For instance, I notice run 22162015, 22168015 and 22166026 have this "mask" word. I don't quite understand this terminology, does that mean they hide the problem because it is not serious?
Third thing is, although you mentioned these 44 badruns don't consider ETOF errors, I still find a couple of them related to ETOF, such as 22163028, 22163034, 22163035, 22163036, 22165026 and 22165035(I'm not sure whether they only have ETOF issues). Also I don't know whether ETOF is necessary or not for centrality purpose QA, actually I didn't include ETOF variables in the run-by-run analysis.
Best regards, Dongsheng
|
-
RE: [[STAR-QAboard] ] Weekly QA Board Meeting - 09/Aug/2024 at noon 12 EDT (Dongsheng Li),
Tsang, Chun Yuen, 09/10/2024
-
RE: [[STAR-QAboard] ] Weekly QA Board Meeting - 09/Aug/2024 at noon 12 EDT (Dongsheng Li),
Tsang, Chun Yuen, 09/25/2024
-
Re: [[STAR-QAboard] ] Weekly QA Board Meeting - 09/Aug/2024 at noon 12 EDT (Dongsheng Li),
李东升, 09/25/2024
- Re: [[STAR-QAboard] ] Weekly QA Board Meeting - 09/Aug/2024 at noon 12 EDT (Dongsheng Li), ASHIK IKBAL, 09/25/2024
-
Re: [[STAR-QAboard] ] Weekly QA Board Meeting - 09/Aug/2024 at noon 12 EDT (Dongsheng Li),
李东升, 09/25/2024
- <Possible follow-up(s)>
-
RE: [[STAR-QAboard] ] Weekly QA Board Meeting - 09/Aug/2024 at noon 12 EDT (Dongsheng Li),
Tsang, Chun Yuen, 09/10/2024
-
Re: [[STAR-QAboard] ] Weekly QA Board Meeting - 09/Aug/2024 at noon 12 EDT (Dongsheng Li),
ASHIK IKBAL, 09/25/2024
-
Re: [[STAR-QAboard] ] Weekly QA Board Meeting - 09/Aug/2024 at noon 12 EDT (Dongsheng Li),
李东升, 09/25/2024
- RE: [[STAR-QAboard] ] Weekly QA Board Meeting - 09/Aug/2024 at noon 12 EDT (Dongsheng Li), Tsang, Chun Yuen, 09/25/2024
-
Re: [[STAR-QAboard] ] Weekly QA Board Meeting - 09/Aug/2024 at noon 12 EDT (Dongsheng Li),
李东升, 09/25/2024
-
Re: [[STAR-QAboard] ] Weekly QA Board Meeting - 09/Aug/2024 at noon 12 EDT (Dongsheng Li),
ASHIK IKBAL, 09/25/2024
-
RE: [[STAR-QAboard] ] Weekly QA Board Meeting - 09/Aug/2024 at noon 12 EDT (Dongsheng Li),
Tsang, Chun Yuen, 09/25/2024
Archive powered by MHonArc 2.6.24.