Access to FCL parameter comments
I think this was discussed before, but now that I look I can't find an issue for this - sorry if this is duplicated.
For interactive use, it would be very convenient to have access to the comment strings that accompany parameters in a FCL file. For example if I have:
hbarc: 197 # hbar * c in units of MeV-fm
It would be nice to be able to get access to the comment to display to users in an interactive environment using something like : pset.get("bharc").DocString() or some such.
Thinking a little further down the line, it would be nice if these comments (or some other related field) could be longer to instruct an interactive GUI how to build a dialog for the parameter. That might require support for longer/more varied document strings. Maybe something like:
''' User specified drawing methods
gui:PullDown opts:Color,Marker,Line Style
DrawingMethod : 1
This would provide enough information that a dialog window with the user could be constructed that would have a pull down menu which the choices "Color","Marker","Line Style" displayed. This would greatly enhance the user experience in interactive sessions (event display).
Hopefully this communicates enough of the idea that you could invent your own syntax that is consistent with FCL.
#1 Updated by Marc Paterno over 8 years ago
- Status changed from New to Feedback
I think we can identify a few different items to discuss here. We should probably take them up at one of our Stakeholders meetings.
So that we can start on the same page, I'll give a little of the rationale for the current behavior: the fhicl-cpp parser drops comments at parsing time.
The current reason that comments in FHiCL files are discarded during parsing is a result of the requirement that two FHiCL tables (the FHiCL name for what in C++ is represented by ParameterSet) that parameters with the same names, and for which the parameters values are equal, have the same id. We have also required that given the id, you can recover the C++ ParameterSet object. Since two tables that differ only by comments yield the same id, we dropped comments.
We are now storing ParameterSets in an internal database, and could extend the system to keep the comments, but still have a "parameter set hash" that reflects only the parameter names and values, and not the comments. The hash could be used for equality testing. This would allow us to store comments, and to give ParameterSet (the C++ class) an interface that allows their recovery.
This would require a considerable amount of change to the fhicl-cpp parser, to the ParameterSet class, and to the art code that stores parameter sets.
We have also, in the past, done some exploratory work on a FHiCL editor that would be able to manipule FHiCL files, and show them as ParameterSets, which could tie together the comments from the FHiCL with the results of the parsing. We do not have a production version of the tool, but we have some good ideas from the time a past summer student spent on the issue.
Please let us (Chris Green and me) know if you'd like us to put this on the agenda for our stakeholders meeting this week.
#2 Updated by Mark Messier over 8 years ago
Thanks for the feedback. I can dial into the stakeholders meeting tomorrow if you would like to discuss this further. I think this is something we want (this is functionality we had in our event display before we adopted ART) and I'd be curious to know what you think the time scale is. If it makes the problem simpler, I would accept having the hashes change if the comments change. Very often that's the right thing to do anyway since people change comments when behavior changes:
a : 1 # 1 says "Make a go up"
a : 1 # 1 says "Make a go down"
#4 Updated by Christopher Green over 8 years ago
- Category set to User Code
- Status changed from New to Resolved
Based on discussions with NOvA representatives at the stakeholdsrs' meeting, it was agreed that the desired behavior could be achieved by making some parameters into parameter sets, whose innards can be accessed easily using the "dot" notation, e.g.:
ps.get<string>("m1.name", "Configuration author did not provide a name");.