 |
 |
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