 |
 |
Sorry, forgot to mention that the file is empty..
Only the first line with description is present:
id ecal_channel_id crate number time_delay amplitude_high amplitude_low
On 12/03/2014 04:55 AM, McCormick, Jeremy I. wrote:
[log in to unmask]" type="cite">Sorry my initial explanation probably wasn’t all that clear...
The scary error message can be ignored and is being caught by the conditions manager. (There isn’t actually any SVT data in the JLab conditions db right now!)
I think it probably actually worked. Do you see the ecal_leds.txt file now? You can open it to see the LED conditions that are in the db. (The -f arg dumps to a file instead of screen.)
Remove the “-f ecal_leds.txt” part to print to the screen instead so it will be more clear if it works or not...
On Dec 2, 2014, at 7:48 PM, Andrea Celentano <[log in to unmask]> wrote:
After
svn update
and build,
I try:
java -cp ./hps-distribution-3.1-SNAPSHOT-bin.jar org.hps.conditions.cli.CommandLineTool print -t ecal_leds -r 2000 -f ecal_leds.txt
I get:
java.lang.RuntimeException: No conditions found with key: svt_channels
at org.hps.conditions.database.ConditionsObjectConverter.getData(ConditionsObjectConverter.java:69)
at org.lcsim.conditions.CachedConditionsImplementation.getCachedData(CachedConditionsImplementation.java:20)
at org.hps.conditions.database.DatabaseConditionsManager.getCollection(DatabaseConditionsManager.java:242)
at org.hps.conditions.svt.SvtConditionsConverter.getData(SvtConditionsConverter.java:34)
at org.hps.conditions.svt.SvtConditionsConverter.getData(SvtConditionsConverter.java:16)
at org.lcsim.conditions.CachedConditionsImplementation.getCachedData(CachedConditionsImplementation.java:20)
at org.hps.conditions.database.DatabaseConditionsManager.setupSvt(DatabaseConditionsManager.java:680)
at org.hps.conditions.database.DatabaseConditionsManager.initialize(DatabaseConditionsManager.java:344)
at org.hps.conditions.database.DatabaseConditionsManager.setDetector(DatabaseConditionsManager.java:274)
at org.hps.conditions.cli.PrintCommand.execute(PrintCommand.java:71)
at org.hps.conditions.cli.CommandLineTool.run(CommandLineTool.java:76)
at org.hps.conditions.cli.CommandLineTool.main(CommandLineTool.java:35)
Wed Dec 03 04:48:10 CET 2014 :: DatabaseConditionsManager :: SEVERE :: Error loading SVT conditions onto detector.
On 12/03/2014 02:38 AM, McCormick, Jeremy I. wrote:
[log in to unmask]" type="cite">
On Dec 1, 2014, at 3:06 PM, Andrea Celentano <[log in to unmask]> wrote:
Hi Jeremy,
yes, this test is there just to dump to the screen (or to a text file via redirection) LED information that is saved on the database. If there's a better way to do this, with the print command, we can proceed this way.
You can do the same thing with more flexibility by using the conditions command line tool in the following way:
java -cp ./hps-distribution-3.1-SNAPSHOT-bin.jar org.hps.conditions.cli.CommandLineTool print -t ecal_leds -r 2000 -f ecal_leds.txt
I just tried this from an ifarm node and it works fine (with the Java from our group area).
I’ll leave your test for now until you get this figured out.
Regarding point 2, I did even know that tests are performed in the automatic build.. and no, I do not know how to avoid this.
Yes, any Java class that you add to trunk/[module]/src/test which extends TestCase automatically runs with the build of that module unless you explicitly disable it. You can avoid this by adding a test exclusion. (See integration-tests module for example of this under the maven-surefire-plugin configuration.)
Finally, the LED conditions are not actually not used in any place (analysis or reconstruction): the slow control system is not interacting with the conditions database to determine how to run LEDs, but relies on its own data files (this is how it was designed.. and it is not trivial at all to change this). Therefore, I think that it is good to have them in the database, but this is just for reference.
We can leave the LED information in there if you think it is potentially useful in the future.
Also, I think I found some mismatches in the values that are there: It is fine for me to change these LED values in the database, however, you should instruct me how to do this.
It is probably best to simply drop the existing conditions set and load a new one with the corrections. That way you can do your work in a text file and then load it into the database. Otherwise, you’d need to execute SQL ‘UPDATE’ commands from a mysql client to do this, which I assume you don’t know how to do. If there are only a few changes to make then I can do the updates for you. If you need to correct something specific in a lot of records, it is probably best to simply make a whole new conditions set and drop the old, incorrect one from the database.
Bests,
Andrea
On 12/01/2014 04:40 PM, McCormick, Jeremy I. wrote:
Hi, Andrea.
A couple things here about this test you added...
1) You put me down for the author in the comments on a commit that you made. Your information should be listed here instead.
2) This test doesn't actually do anything, i.e. there aren't any assertions made so it questionable whether the test should even be in the code.
If you still want it in the conditions package for reference, then I believe it should not be run with the automatic builds. (e.g. it should be added to the test
exclusions in the pom file...do you know how to do this yourself?)
3) You can dump the LED conditions using the 'print' command line option, which I'm not sure you're aware of so if that's all that is needed here,
then let me know and I'll tell you how to do it. There doesn't need to be a test case if that's all you want to do here.
BTW, Nathan had indicated he wasn't sure why LED conditions needed to be in the database. Can you elaborate on how you might use these
in the LCSim code for analysis or recon?
(FYI, this message is not CC'd to software list.)
--Jeremy
-----Original Message-----
From: [log in to unmask] [mailto:[log in to unmask]] On Behalf Of [log in to unmask]
Sent: Monday, December 01, 2014 1:14 PM
To: hps-svn
Subject: r1604 - /java/trunk/conditions/src/test/java/org/hps/conditions/ecal/EcalLedTest.java
Author: [log in to unmask]
Date: Mon Dec 1 13:14:13 2014
New Revision: 1604
Log:
Added LED condition tests with database system
Added:
java/trunk/conditions/src/test/java/org/hps/conditions/ecal/EcalLedTest.java
Added: java/trunk/conditions/src/test/java/org/hps/conditions/ecal/EcalLedTest.java
==============================================================================
--- java/trunk/conditions/src/test/java/org/hps/conditions/ecal/EcalLedTest.java (added)
+++ java/trunk/conditions/src/test/java/org/hps/conditions/ecal/EcalLedTest.java Mon Dec 1 13:14:13 2014
@@ -0,0 +1,47 @@
+package org.hps.conditions.ecal;
+
+import junit.framework.TestCase;
+
+import org.hps.conditions.database.DatabaseConditionsManager;
+import org.hps.conditions.database.TableConstants;
+//import org.hps.conditions.config.DevReadOnlyConfiguration;
+import org.hps.conditions.ecal.EcalLed.EcalLedCollection;
+import
+org.lcsim.conditions.ConditionsManager.ConditionsNotFoundException;
+
+/**
+ * A very basic test to make sure ECAL LED information is
+ * readable from the conditions dev database.
+ * @author Jeremy McCormick <[log in to unmask]> */ public
+class EcalLedTest extends TestCase {
+
+
+ DatabaseConditionsManager conditionsManager;
+ public void setUp() {
+ conditionsManager = DatabaseConditionsManager.getInstance();
+ try {
+ conditionsManager.setDetector("HPS-Proposal2014-v7-2pt2", 0);
+ } catch (ConditionsNotFoundException e) {
+ throw new RuntimeException(e);
+ }
+ }
+
+
+
+ public void testEcalLed() {
+ DatabaseConditionsManager manager = DatabaseConditionsManager.getInstance();
+ EcalLedCollection collection = manager.getConditionsData(EcalLedCollection.class, TableConstants.ECAL_LEDS);
+ for (EcalLed led : collection) {
+
+ System.out.println(led);
+ //System.out.println("ECAL LED info ...");
+ //System.out.println("ecal_channel_id: " + led.getEcalChannelId());
+ //System.out.println("crate: " + led.getCrateNumber());
+ //System.out.println("number: " + led.getLedNumber());
+ //System.out.println("time_delay: " + led.getTimeDelay());
+ //System.out.println("amplitude_low: " + led.getAmplitudeLow());
+ //System.out.println("amplitude_high: " + led.getAmplitudeHigh());
+ //System.out.println();
+ }
+ }
+}
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
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