jeffersonlab / rcdb Goto Github PK

Shoud work to integrate CI server with RCDB github

We need to be able to specify some run-dependent conditions for standard search aliases e.g. "@is_production", so it would be nice if these conditions could be built into the aliases, or some other method.

For the future: it would be nice to have a page displaying the information in the Version_info table in the data_monitoring DB. [note that this information may move to EventStore in the future].

Maybe it would be good to keep summary information on different run periods too, or how the runs map to run periods?

David message:

I heard that you have now arranged your flight and will be here within the
week (yay!). Among the many, many things we’ll be asking you to do while
here, I wanted to request one more. I thought I’d put it in an e-mail now so
I don’t forget about it so feel free to flag this and look at it later.

We currently have a script that makes automatic entries into the e-log in
a special logbook called “HDRUN”. You can see this here:

https://logbooks.jlab.org/book/hdrun

It would be really nice to have a link in the RCDB pages pointing to the
log entry in HDLOG corresponding to the relevant run number. The
tricky part is getting the e-log entry number for a specific run number.
They do have a data API for the e-log that is accessible via web
query. This is described here:

https://logbooks.jlab.org/content/web-data-api

This returns data in JSON format which can then be parsed to figure
out this mapping. I don’t know if we want to setup a cron job to do this
occasionally and maintain our own DB of e-log entry <-> run number
or if this should be done every time the RCDB pages are accessed.
I’ll let you think about how best to approach it.

ALSO

On the home page of our main wiki there is a link called
“Run Info vers. 1”. I believe all of this info should be absorbed (if not already)
into the RCDB and this link replaced with one to the RCDB.

Sean message

Add conditions information to the RCDB at begin and end of run.
I have an example python script that adds the EPICS variables we've been using in the offline at the beginning of the run, if you're interested, at: /group/halld/Users/sdobbs/rcdb_scripts/update_rcdb_conds.py

Some information should also be updated at the end of the run (if we get to that), e.g. the low-energy beam current measurements aren't calibrated, so we need to average the measurement over the run to get a reasonable value. I can provide example commands if you want.

From me:
All commands and help towards integration of data into CCDB are welcome and very appreciated.

From Paul:

Hey guys, I get an error when I want to look at runs 11590 - 11600 in the web browser, with an empty search query. Some small ranges work, some don’t, and the cutoff seems to be around 35 runs or so. Is there a hard-coded minimum somewhere?

Trying to search runs with:

 'RETR' in radiator_type

gives error

Error in performing request: argument of type 'NoneType' is not iterable 

while

radiator_type and 'RETR' in radiator_type

works

For the offline monitoring, for some reason when I source environment.csh inside a script, I get an error telling me that I should source it, even though I already am.

For examples, see:
https://halldsvn.jlab.org/repos/trunk/scripts/monitoring/process/check_monitoring_data.csh
https://halldsvn.jlab.org/repos/trunk/scripts/monitoring/process/monitoring_env.csh

From Sean

Finish importing information (incl. run conditions) from the spring run into the RCDB.
We'd like to use the RCDB to drive the offline monitoring software, instead of the run conditions table that's currently being used, so this would allow us to start modifying our software to use the RCDB.

rcdb sel "'PS_TAC_m8' in run_config" "run_config event_count"

And it says

File "/lustre/expphy/work/halld/home/somov/devel/rcdb/python/rcdb/cmd.py", line 301, in <module>
    cli(prog_name="rcdb")
  File "/lustre/expphy/work/halld/home/somov/devel/rcdb/python/click/core.py", line 716, in __call__
    return self.main(*args, **kwargs)
  File "/lustre/expphy/work/halld/home/somov/devel/rcdb/python/click/core.py", line 696, in main
    rv = self.invoke(ctx)
  File "/lustre/expphy/work/halld/home/somov/devel/rcdb/python/click/core.py", line 1065, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/lustre/expphy/work/halld/home/somov/devel/rcdb/python/click/core.py", line 892, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/lustre/expphy/work/halld/home/somov/devel/rcdb/python/click/core.py", line 534, in invoke
    return callback(*args, **kwargs)
  File "/lustre/expphy/work/halld/home/somov/devel/rcdb/python/click/decorators.py", line 64, in new_func
    return ctx.invoke(f, obj, *args[1:], **kwargs)
  File "/lustre/expphy/work/halld/home/somov/devel/rcdb/python/click/core.py", line 534, in invoke
    return callback(*args, **kwargs)
  File "/lustre/expphy/work/halld/home/somov/devel/rcdb/python/rcdb/cmd.py", line 142, in sel
    click.echo("#! {}".format(" ".join(["run_num"].extend(conditions_to_show))))
TypeError: can only join an iterable

CODA calls RCDB only on the beginning of the run and at the end. If it crashes, only information available at the beginning is stored in the DB.

Create a way to create an RCDB DB!!!

Justin pointed out that run 10389 doesn't show up when searching using @is_production. It looks like it should satisfy the criteria, though.

Run= 11553 Date: 2016-04-20 00:54:30 triggers= 137822845 current= 98 nA radiator= J1A50 50um PARA target= FULL & Ready = 17934 Hz coll= 3.4mm hole

Run= 11554 Date: 2016-04-20 06:08:39 triggers= 59821129 current= 154 nA radiator= J1A50 50um PERP target= FULL & Ready = 17155 Hz coll= 3.4mm hole
Run= 11554 Date: 2016-04-20 06:08:39 triggers= 59821129 current= 154 nA radiator= J1A50 50um PERP target= FULL & Ready = 17155 Hz coll= 3.4mm hole
Run= 11554 Date: 2016-04-20 06:08:39 triggers= 59821129 current= 154 nA radiator= J1A50 50um PERP target= FULL & Ready = 17155 Hz coll= 3.4mm hole
Run= 11554 Date: 2016-04-20 06:08:39 triggers= 59821129 current= 154 nA radiator= J1A50 50um PERP target= FULL & Ready = 17155 Hz coll= 3.4mm hole

Run= 11555 Date: 2016-04-20 07:14:44 triggers= 6389322 current= 47 nA radiator= J1A50 50um PERP target= FULL & Ready = 5199 Hz coll= 3.4mm hole

FYI, a recent run https://halldweb.jlab.org/rcdb/runs/info/10895 was the amorphous radiator but in RCDB is

radiator_type Undefined
polarization_direction PARA
radiator_index 0

Not sure if this is a lingering issue from what we saw before, or something new.

Can values for evio_last_file and evio_files_count be added for all of the 2016 runs? Runs early in the run period are missing this information.

(cc: @nsjarvis)

We need another field where post-run comments could be added. It would be very useful if this could be be implemented before the next run.

I created a tag v0.00 just to have something definite to download and build. This can be removed at some point in the near future.

With the query "daq_run and event_count>1000000 and @is_amorph_radiator":

https://halldweb.jlab.org/rcdb/runs/search?runFrom=0&runTo=&q=daq_run+and+event_count%3E1000000+and+%40is_amorph_radiator

there are 6 runs

10352
10368
10368
10390
10395
10416
10418

but some of these (eg. 10390) are diamond runs and some known amorphous runs (eg. 10389) do not appear in this list. So how is is_amorph_radiator defined? Or am I using it incorrectly?

Because nobody uses it, there is no use cases in current schema. But dropping it will greatly simplify API development

I'm running into problems connecting to the RCDB from offsite. I can connect to the database directly with mysql, but using the python rcdb connection doesn't seem to work. This command works fine at JLab, but produces the following error from offsite (confirmed by Sean):

python $RCDB_HOME/python/example_simple_queries.py mysql://[email protected]/rcdb

output:

['/home/mstaib/builds/rcdb/python/example_simple_queries.py', 'mysql://[email protected]/rcdb'] Traceback (most recent call last): File "/home/mstaib/builds/rcdb/python/example_simple_queries.py", line 23, in <module> db = RCDBProvider(args.connection_string) File "/home/mstaib/builds/rcdb/python/rcdb/provider.py", line 58, in __init__ self.connect(connection_string, check_version) File "/home/mstaib/builds/rcdb/python/rcdb/provider.py", line 110, in connect if not self.is_acceptable_sql_version(): File "/home/mstaib/builds/rcdb/python/rcdb/provider.py", line 68, in is_acceptable_sql_version .filter(SchemaVersion.version == rcdb.SQL_SCHEMA_VERSION) File "/home/mstaib/builds/rcdb/python/sqlalchemy/orm/query.py", line 2724, in scalar ret = self.one() File "/home/mstaib/builds/rcdb/python/sqlalchemy/orm/query.py", line 2693, in one ret = list(self) File "/home/mstaib/builds/rcdb/python/sqlalchemy/orm/query.py", line 2736, in __iter__ return self._execute_and_instances(context) File "/home/mstaib/builds/rcdb/python/sqlalchemy/orm/query.py", line 2751, in _execute_and_instances result = conn.execute(querycontext.statement, self._params) File "/home/mstaib/builds/rcdb/python/sqlalchemy/engine/base.py", line 914, in execute return meth(self, multiparams, params) File "/home/mstaib/builds/rcdb/python/sqlalchemy/sql/elements.py", line 323, in _execute_on_connection return connection._execute_clauseelement(self, multiparams, params) File "/home/mstaib/builds/rcdb/python/sqlalchemy/engine/base.py", line 1010, in _execute_clauseelement compiled_sql, distilled_params File "/home/mstaib/builds/rcdb/python/sqlalchemy/engine/base.py", line 1146, in _execute_context context) File "/home/mstaib/builds/rcdb/python/sqlalchemy/engine/base.py", line 1341, in _handle_dbapi_exception exc_info File "/home/mstaib/builds/rcdb/python/sqlalchemy/util/compat.py", line 200, in raise_from_cause reraise(type(exception), exception, tb=exc_tb) File "/home/mstaib/builds/rcdb/python/sqlalchemy/engine/base.py", line 1139, in _execute_context context) File "/home/mstaib/builds/rcdb/python/sqlalchemy/engine/default.py", line 450, in do_execute cursor.execute(statement, parameters) File "/home/mstaib/builds/rcdb/python/mysql/connector/cursor.py", line 491, in execute self._handle_result(self._connection.cmd_query(stmt)) File "/home/mstaib/builds/rcdb/python/mysql/connector/connection.py", line 635, in cmd_query statement)) File "/home/mstaib/builds/rcdb/python/mysql/connector/connection.py", line 553, in _handle_result raise errors.get_exception(packet) sqlalchemy.exc.ProgrammingError: (mysql.connector.errors.ProgrammingError) 1146 (42S02): Table 'rcdb.schema_versions' doesn't exist [SQL: 'SELECT count(schema_versions.version) AS count_1 \nFROM schema_versions \nWHERE schema_versions.version = %(version_1)s'] [parameters: {'version_1': 1}]

Not sure what these are. If need be we can filter them out of the nightly build report. See attached file:
rcdb_warnings.txt

It seems to have a lot of repetative and possible inaccurate information in it?

For the record this is supposed to be an empty target run.

https://halldweb.jlab.org/rcdb/runs/info/11368

Querying the database is very slow and I think there are a few very common queries that get used (@is_production, status_approved etc). It would be great if we could do something, like indexing, to speed up these queries.

Tried running a python script that imported rcdb, however I see that I run into some issues just as I do "import rcdb". I'm running on a cluster with Red Hat 6.8, gcc 4.9.2, and Python 2.7.8. I successfully managed to git clone and source the environment.csh file.

Once I attempt to import I get the following message:
Traceback (most recent call last):
File "./GetRCDB_stuff.py", line 4, in
import rcdb
File "/gpfs/home/j/z/jzarling/Karst/gluex/gluex_build/rcdb/python/rcdb/init.py", line 109
all_types_dict = {t.name: t for t in db.get_condition_types()}
^
SyntaxError: invalid syntax

I'm unfamiliar with the rcdb source code, but I imagine this should be a simple fix for an expert.

An Idea have emerged that it looks easy to generate root file with "leafs" named after conditions.

How do I get date/time of a run on the command line (both start and length)?
I tried start_time and run_length, but they do not work for me.

Many production runs don't satisfy the @is_production requirements. For example run 10390: https://halldweb.jlab.org/rcdb/runs/info/10390

This is definitely a good production run, but it looks like it is missing because of the run_type:

run_type hd_all.tsg_ps

Where the is_production alias looks for hd_all.tsg.ps I guess?
https://halldweb.jlab.org/wiki/index.php/RCDB_Standard_Searches

There appears to be a problem building sim-recon under bash after setting up RCDB. See my blog post for details.

1. User can filter runs using readable search querries, like:

duration>300   event_count>10000 has_FDC

Or more sophisticated

4000-5000,50002,6000-6500   (duration>300 or event_count>10000)   has_FDC

1. Queries should work the same for GUI and cli
2. For WebGUI there should be a helper to build queries (autocompletion, list of available conditions, etc)
3. Search filters should be a part of the link, so the link could be shared between users.
4. User can choose a format of output (which columns to show, plain text or json or html, etc.)

Noticed that environment.csh does not work if the source command uses an environment variable, e. g.,

source $HOME/rcdb/environment.csh

The current script grabs a string that has not undergone variable expansion.

I checked in a change on branch ugly_tcsh_setup that solves the problem by writing a script to /tmp and sourcing that to get the expansion. Not pretty.

Am using it in release 0.00 since it works.

Use case 1:

RCDB web site should accept JSON object with request:

1. conditions name to get
2. query
3. run range

And get json object containing values with it:

Example request:

{
 "query": "@is_production and even_count>1M",
 "run_min": 20000,
 "columns_to_get": ["event_count", "target_name", "beam_current"],
}

Example of response:

{
"result":
 [
   {"run":20000, "event_count": 1873843563,   "target_name": "DIAMOND",     "beam_current": 100.2  },
   {"run":20001, "event_count": 3453497345,   "target_name": "DIAMOND",     "beam_current": 101.2  }
 ]
}

From Naomi:

I found a small RCDB error - the end time for 11363 is not correct. I
don't know the exact time but it should be closer to 23:52 on the 13th.
The last epics timestamp is at Wed 13 Apr 2016 11:51:51 PM EDT.

I'd fix it, but I'm not sure how to change the start/end time.

Sean message

The evio2db program is currently generating some information on each EVIO file that we also want to store in the RCDB. I think we want to save this information in a JSON blob, so some interface between the two programs should be worked out.

I can't seem to access RCDB from the ifarm or counting house.

I updated to the latest rcdb master, and get the following errors:

gluon108:
Traceback (most recent call last):
File "update_epics_adesh.py", line 242, in
db = rcdb.RCDBProvider("mysql://rcdb:@hallddb/rcdb")
File "/u/group/halld/Users/sdobbs/rcdb/python/rcdb/provider.py", line 58, in init
self.connect(connection_string, check_version)
File "/u/group/halld/Users/sdobbs/rcdb/python/rcdb/provider.py", line 113, in connect
raise rcdb.errors.SqlSchemaVersionError(message)
rcdb.errors.SqlSchemaVersionError: SQL schema version doesn't match. Probably RCDB is connecting with wrong, empty or older/newer DB

ifarm:
Traceback (most recent call last):
File "update_epics_adesh.py", line 242, in
db = rcdb.RCDBProvider("mysql://rcdb:@gluondb1/rcdb")
File "/group/halld/Users/sdobbs/rcdb/python/rcdb/provider.py", line 58, in init
self.connect(connection_string, check_version)
File "/group/halld/Users/sdobbs/rcdb/python/rcdb/provider.py", line 110, in connect
if not self.is_acceptable_sql_version():
File "/group/halld/Users/sdobbs/rcdb/python/rcdb/provider.py", line 68, in is_acceptable_sql_version
.filter(SchemaVersion.version == rcdb.SQL_SCHEMA_VERSION)
File "/gluonfs1/gluex/sim-recon/ccdb_1.06.01.Linux_RHEL6-x86_64-gcc4.9.2/python/sqlalchemy/orm/query.py", line 2559, in scalar
ret = self.one()
File "/gluonfs1/gluex/sim-recon/ccdb_1.06.01.Linux_RHEL6-x86_64-gcc4.9.2/python/sqlalchemy/orm/query.py", line 2528, in one
ret = list(self)
File "/gluonfs1/gluex/sim-recon/ccdb_1.06.01.Linux_RHEL6-x86_64-gcc4.9.2/python/sqlalchemy/orm/query.py", line 2571, in iter
return self._execute_and_instances(context)
File "/gluonfs1/gluex/sim-recon/ccdb_1.06.01.Linux_RHEL6-x86_64-gcc4.9.2/python/sqlalchemy/orm/query.py", line 2584, in _execute_and_instances
close_with_result=True)
File "/gluonfs1/gluex/sim-recon/ccdb_1.06.01.Linux_RHEL6-x86_64-gcc4.9.2/python/sqlalchemy/orm/query.py", line 2575, in _connection_from_session
**kw)
File "/gluonfs1/gluex/sim-recon/ccdb_1.06.01.Linux_RHEL6-x86_64-gcc4.9.2/python/sqlalchemy/orm/session.py", line 893, in connection
execution_options=execution_options)
File "/gluonfs1/gluex/sim-recon/ccdb_1.06.01.Linux_RHEL6-x86_64-gcc4.9.2/python/sqlalchemy/orm/session.py", line 898, in _connection_for_bind
engine, execution_options)
File "/gluonfs1/gluex/sim-recon/ccdb_1.06.01.Linux_RHEL6-x86_64-gcc4.9.2/python/sqlalchemy/orm/session.py", line 334, in _connection_for_bind
conn = bind.contextual_connect()
File "/gluonfs1/gluex/sim-recon/ccdb_1.06.01.Linux_RHEL6-x86_64-gcc4.9.2/python/sqlalchemy/engine/base.py", line 2039, in contextual_connect
self._wrap_pool_connect(self.pool.connect, None),
File "/gluonfs1/gluex/sim-recon/ccdb_1.06.01.Linux_RHEL6-x86_64-gcc4.9.2/python/sqlalchemy/engine/base.py", line 2078, in _wrap_pool_connect
e, dialect, self)
File "/gluonfs1/gluex/sim-recon/ccdb_1.06.01.Linux_RHEL6-x86_64-gcc4.9.2/python/sqlalchemy/engine/base.py", line 1405, in _handle_dbapi_exception_noconnection
exc_info
File "/gluonfs1/gluex/sim-recon/ccdb_1.06.01.Linux_RHEL6-x86_64-gcc4.9.2/python/sqlalchemy/util/compat.py", line 199, in raise_from_cause
reraise(type(exception), exception, tb=exc_tb)
File "/gluonfs1/gluex/sim-recon/ccdb_1.06.01.Linux_RHEL6-x86_64-gcc4.9.2/python/sqlalchemy/engine/base.py", line 2074, in _wrap_pool_connect
return fn()
File "/gluonfs1/gluex/sim-recon/ccdb_1.06.01.Linux_RHEL6-x86_64-gcc4.9.2/python/sqlalchemy/pool.py", line 376, in connect
return _ConnectionFairy._checkout(self)
File "/gluonfs1/gluex/sim-recon/ccdb_1.06.01.Linux_RHEL6-x86_64-gcc4.9.2/python/sqlalchemy/pool.py", line 713, in _checkout
fairy = _ConnectionRecord.checkout(pool)
File "/gluonfs1/gluex/sim-recon/ccdb_1.06.01.Linux_RHEL6-x86_64-gcc4.9.2/python/sqlalchemy/pool.py", line 480, in checkout
rec = pool._do_get()
File "/gluonfs1/gluex/sim-recon/ccdb_1.06.01.Linux_RHEL6-x86_64-gcc4.9.2/python/sqlalchemy/pool.py", line 1060, in _do_get
self._dec_overflow()
File "/gluonfs1/gluex/sim-recon/ccdb_1.06.01.Linux_RHEL6-x86_64-gcc4.9.2/python/sqlalchemy/util/langhelpers.py", line 60, in exit
compat.reraise(exc_type, exc_value, exc_tb)
File "/gluonfs1/gluex/sim-recon/ccdb_1.06.01.Linux_RHEL6-x86_64-gcc4.9.2/python/sqlalchemy/pool.py", line 1057, in _do_get
return self._create_connection()
File "/gluonfs1/gluex/sim-recon/ccdb_1.06.01.Linux_RHEL6-x86_64-gcc4.9.2/python/sqlalchemy/pool.py", line 323, in _create_connection
return _ConnectionRecord(self)
File "/gluonfs1/gluex/sim-recon/ccdb_1.06.01.Linux_RHEL6-x86_64-gcc4.9.2/python/sqlalchemy/pool.py", line 449, in init
self.connection = self.**connect()
File "/gluonfs1/gluex/sim-recon/ccdb_1.06.01.Linux_RHEL6-x86_64-gcc4.9.2/python/sqlalchemy/pool.py", line 607, in __connect
connection = self.__pool._invoke_creator(self)
File "/gluonfs1/gluex/sim-recon/ccdb_1.06.01.Linux_RHEL6-x86_64-gcc4.9.2/python/sqlalchemy/engine/strategies.py", line 97, in connect
return dialect.connect(_cargs, _cparams)
File "/gluonfs1/gluex/sim-recon/ccdb_1.06.01.Linux_RHEL6-x86_64-gcc4.9.2/python/sqlalchemy/engine/default.py", line 385, in connect
return self.dbapi.connect(_cargs, _cparams)
File "/gluonfs1/gluex/sim-recon/ccdb_1.06.01.Linux_RHEL6-x86_64-gcc4.9.2/python/mysql/connector/__init.py", line 179, in connect
return MySQLConnection(_args, *_kwargs)
File "/gluonfs1/gluex/sim-recon/ccdb_1.06.01.Linux_RHEL6-x86_64-gcc4.9.2/python/mysql/connector/connection.py", line 95, in init
self.connect(**kwargs)
File "/gluonfs1/gluex/sim-recon/ccdb_1.06.01.Linux_RHEL6-x86_64-gcc4.9.2/python/mysql/connector/abstracts.py", line 719, in connect
self._open_connection()
File "/gluonfs1/gluex/sim-recon/ccdb_1.06.01.Linux_RHEL6-x86_64-gcc4.9.2/python/mysql/connector/connection.py", line 210, in _open_connection
self._ssl)
File "/gluonfs1/gluex/sim-recon/ccdb_1.06.01.Linux_RHEL6-x86_64-gcc4.9.2/python/mysql/connector/connection.py", line 144, in _do_auth
self._auth_switch_request(username, password)
File "/gluonfs1/gluex/sim-recon/ccdb_1.06.01.Linux_RHEL6-x86_64-gcc4.9.2/python/mysql/connector/connection.py", line 177, in _auth_switch_request
raise errors.get_exception(packet)
sqlalchemy.exc.ProgrammingError: (mysql.connector.errors.ProgrammingError) 1045 (28000): Access denied for user 'rcdb'@'gluon108.jlab.org' (using password: YES)

I tried:

@is_production and @is_empty_target

and got the following error:

Error in performing request: sequence item 5: expected string or Unicode, int found

I am trying to print a value for a condition using the CLI as in

python $RCDB_HOME/python/rcnd.py 11445 evio_files_count

This results in the following error (as do attempts with other runs/conditions):

Traceback (most recent call last):
  File "/Users/nathansparks/Scripts/hdpm/pkgs/rcdb/python/rcnd.py", line 295, in <module>
    show_value(db, args.run_number, args.condition_name)
  File "/Users/nathansparks/Scripts/hdpm/pkgs/rcdb/python/rcnd.py", line 102, in show_value
    if ct.is_many_per_run:
AttributeError: 'ConditionType' object has no attribute 'is_many_per_run'

If I comment out the is_many_per_run condition in the show_value() method, it correctly prints 130.

Based on Justin's suggestion, I am adding this note to the issues list.

I find that some runs that are omitted in my rcdb query using "@is_production" are likely good runs. Below is a list of runs taken on Mar 9:

10906.0 2016-03-09 06:32:53 51770555.0 160.757 JD70-119 20um PERP FULL & Ready 14168.1869184
10907.0 2016-03-09 07:39:06 127444512.0 0.154851 3x10-4 RL AMO FULL & Ready 18883.465995
10909.0 2016-03-09 10:23:11 422420.0 97.2931 J1A50 50um PARA FULL & Ready 311.519174041
10911.0 2016-03-09 11:04:53 63904377.0 -1.0 J1A50 50um PARA FULL & Ready 16964.2625431

The fifth entry is the average beam current. Runs 10907 and 10911 have beam currents of 0.154851 and -1 nA. I believe this is why they fail the query. However, it seems we had relatively good beam during that period (see attached screen shot). Is there a failure in obtaining the beam current? Perhaps there is a better method of getting a list of good runs?

Is there a simple way to find out when the standard configuration file (FCAL_BCAL_PS_m7.conf) changed over the course of the run period? I can browse them for individual runs from the RCDB webpage, e.g. for run 11447 https://halldweb.jlab.org/rcdb/files/info/6250, but is there a way to tell at what time (or run number) the file was changed?

I do see the label "DB id=6250 Raw" which I guess indicates an index for this config file? Maybe thats incremented when the file changes? If so, how can I query the file DB id vs run number?

These runs are all labeled as PERP

For the TRD runs (11368-11380) the radiator_type=BLANK, so I'm not sure what radiator was used (if any)
https://halldweb.jlab.org/rcdb/runs/info/11369

For the next few runs (11380-11384) the polarization_direction is labeled as PERP but the radiator is amorphous so polarization_direction should be N/A
https://halldweb.jlab.org/rcdb/runs/info/11384

see post from Elton in logbook https://logbooks.jlab.org/comment/7676#comment-7676

polarimeter_converter is not showing up in the conditions list any more.
It was there for most runs before run 10644.

Hi Sean,

These 2 runs in the second priority group are labeled PERP in RCDB, but have the PARA phi modulation and are labeled PARA in the logbook.

11618: https://halldweb.jlab.org/rcdb/runs/info/11618
11620: https://halldweb.jlab.org/rcdb/runs/info/11620

Can you change them to PARA?

-Justin

Runs 11481 and 11508 are labeled as PARA, but the logbook and phi distributions for rho events show they should be PERP.

Run 11519 is labeled as PERP, but the logbook and phi distribution for rho events show it should be PARA.

When you try to put a single run in the search box on the top of the screen (which says "run or min-max"), it gives back an "Internal Server Error" page. Putting in a range of runs works fine.

It seems like some of the DAQ configuration files are not being stored in RCDB, or it's not clear where to find them. I ran into this problem when trying to find the "NPED" setting for the recent cosmic runs. These files should at least either be stored in RCDB or made more accessible. Maybe there is a better way to expose module configuration parameters.

Run 10895 the comment says "3x10-4 radiator", but it is labeled PARA, please change to N/A.
Run 10780 is labeled PERP but the run log says it's PARA https://logbooks.jlab.org/entry/3388565 and the phi modulation is consistent with PARA as well.

(Continue of the discussion in #15)
When we introduce a new condition type and a way to fill it for the next runs (parsing logs, calling EPICS), also we have a need to fill this value for the runs, that are already in DB.

For log files, the workflow in this case is to reparse the files. For the EPICS variables, as Sean says, it is trickier. Assuming you can't just run update_epics.py and give it the old run, what would be the workflow?

Introducing one more script like update_epics_for_existing_runs.py?

Examples: 11101, 11107

When the C++ API is ready, it would be nice to have an example of how to get the DAC settings for different crates.