Calibration page

[SmithJK]

Can we include a web interface for loading a calibration to the ODB? We've written a script that will do this from the command line, but it's much more user friendly to have a web page where you upload a calibration file that is read and then implemented in the ODB. I suggest standardizing to the GRSISort calibration file style, detailed here: https://github.com/GRIFFINCollaboration/GRSISort/wiki/CalFiles.

[bkatiemills]

If this boils down to 'read a well defined file format and write things to the odb as a function of what we find there', then yes, absolutely. Let me know if there are any options / controls you'd like to expose on the web page. I'm thinking a two-stepper, where we read a file, parse it, display what's going to get written to the odb, then confirm to write.

[bkatiemills]

OK, this has finally floated to the top of my to-dos! So but if I understand what you want:

• the user has a plain text .cal file on their computer
• the dashboard presents a file upload dialog to ingest this file
• some javascript digests the .cal file and writes the whole thing to the ODB

Is that it? That hardly requires its own page; an 'Upload .cal' button in the status sidebar will do fine - unless there are buttons and knobs to twiddle that affect exactly how or what is written to the ODB. But if it's just the same write process every time, then yeah - probably just a button.

If that'll do it, I'll need:

• a .cal file
• some spec explaining what parts of the .cal file go where in the ODB.

Lastly, on a scale from 'never' to 'never ever', how hard would it be to rewrite the .cal file format to be proper JSON?

[SmithJK]

Yes, that's it. An upload cal button will be just fine.

Here's a cal file. The typical extension is .cal, but GitHub won't let me upload that.

47Ca_walk_corrected.txt

The mnemonic for the channel is followed by a set of values in brackets include the channel mnemonic name (again), the address, and calibration parameters. The only one's we are concerned about here are the energy calibration coefficients ("EngCoeff"). The numbers that follow are coefficients for a polynomial correction: the first one is the coefficient for the x^0 term (the offset), the second is the coefficient for the x^1 term (the gain). Any additional corrective terms (quadratic, quartic, etc.) will follow, but the offset and gain will always be the first two numbers. Everything else can be ignored.

To re-write the .cal file format that we use in GRSISort to be proper JSON? I very much doubt that will happen.

[bkatiemills]

To re-write the .cal file format that we use in GRSISort to be proper JSON? I very much doubt that will happen.

Sure, probably too much trouble now, I get it - but in future, there must be off-the-shelf C++ JSON parsers - standard file formats are your friend, make someone else do all that boring text parsing :)

Anyhow, sounds good, but:

• where do those polynomial terms go in the ODB? Probably /DAQ/MSC/gain and .../offset, at the indices corresponding to the channel name
• should we also set /DAQ/MSC/MSC from the .cal file's Address field, or are the .cal files not the primary source?
• what if you upload a cal file that doesn't include a channel that already exists in the ODB? Make the ODB match the .cal file exactly, or leave the old stuff as it lies?
• same question the other way: if we find something in the .cal file that's not in the ODB, what should we put for its /DAQ/MSC/datatype?
• All of the above will collide with the gain matching tool, which writes its calibration parameters to these same arrays in the ODB. Many ways to deal with this, let me know what makes sense from your end.

[SmithJK]

• Yes, they should go in /DAQ/MSC/gain and /DAQ/MSC/offset.
• The MSC table is set from the MSC builder on the Dashboard, yes? Let's leave it that way.
• Leave the old stuff as it lies. It's entirely probable we'll calibration the HPGe but not SCEPTAR.
• If something is in the cal file that's not the ODB, skip it.
• I think it's fine to let these over-write each other - the gain-matching tool requires someone to click a button to update the ODB, yes? I'm just looking at these as two different ways to write to the gain and offset arrays.

[bkatiemills]

oh yeah, the MSC builder... I definitely did not forget all about that :) - no problem, that is easily resurrected, too.

[bkatiemills]

@SmithJK done, see bottom of the status sidebar on any page for calibration writing, and /msc-builder.html for the MSC builder. Let me know if this works for you!

[AdamGarnsworthy]

Mike used this feature and it worked fine. Awesome!