 |
 |
Yes, just use run number 2000 for now in your steering. That should work fine in general for the current runs. Or if you load up the monitoring app in wait mode before the run starts, it should get the pre start event once you start the run in CODA. > On Dec 5, 2014, at 9:12 PM, Nathan Baltzell <[log in to unmask]> wrote: > > Hi Jeremy, > > Can you provide one xml/steering file that will permanently just work? > Or a command-line switch to override? Or anything that does not require > regular manual intervention? > > Expecting shift takers to edit a file just to adapt every time something > associated breaks in order to use this monitoring app is going to render > it effectively dead! > > -nathan > > > > > >> On Dec 5, 2014, at 11:42 PM, "McCormick, Jeremy I." <[log in to unmask]> wrote: >> >> You should already be able to do this by using ConditionsDriver in a steering file as the first driver in the list and specifying a run number with the freeze option. >> >> <driver name="ConditionsDriver" type="org.hps.conditions.ConditionsDriver"> >> <freeze>true</freeze> >> <runNumber>1234</runNumber> >> </driver> >> >> Let me know if you get that working and if the log shows the correct conditions. >> >> This would probably require using a steering file on disk that is modified in the fly as needed. >> >> I have been meaning to add a conditions/detector config wizard to the monitoring to solve this in a more user friendly way but haven't gotten around to it yet. Having too much fun looking at the data! >> >> >> >> >>> On Dec 5, 2014, at 8:06 PM, Nathan Baltzell <[log in to unmask]> wrote: >>> >>> Hi Jeremy, >>> >>> Will you implement a way for the monitoring app to not depend on reading the >>> run number from the data? A command-line switch would do. We are successfully >>> using the latest jar in the counting room, and while I think we all strongly agree that >>> our data format must and will have run number in every event, the fact is that it >>> currently does not. At least a short-term solution for this would be very helpful for >>> shift takers. >>> >>> Thanks, >>> Nathan > ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the HPS-SOFTWARE list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1