-
Notifications
You must be signed in to change notification settings - Fork 6
Lv2 reads master #363
Lv2 reads master #363
Conversation
| functionManager.getHCALparameterSet().put(new FunctionManagerParameter<StringT>("GLOBAL_CONF_KEY",new StringT(GlobalConfKey))); | ||
|
|
||
| // RUN_CONFIG_SELECTED = LocalRunKey; CFGSNIPPET_KEY_SELECTED = MasterSnippet file of LocalRunKey | ||
| // CFGSNIPPET_KEY_SELECTED = LocalRunKey; RUN_CONFIG_SELECTED= MasterSnippet file of LocalRunKey |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The previous comment was wrong. Fixing this in the code to avoid further confusion.
| } | ||
| else { | ||
| logger.debug("[HCAL LVL2 " + functionManager.FMname + "] Did not receive a request to perform special actions due to central CMS clock source change during the configureAction().\nThe ClockChange is: " + ClockChanged); | ||
| logger.warn("[HCAL LVL2 " + functionManager.FMname + "] Did receive a request to perform special actions due to central CMS clock source change during the configureAction()."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see ClockChanged being used anywhere in the code. Keeping this warning message only in case we get a CLOCK_CHANGED from LV0
| if(!CommonMasterSnippetFile.equals("")){ | ||
| //parse and set HCAL parameters from CommonMasterSnippet | ||
| logger.info("[HCAL LVL2 "+ functionManager.FMname +"] Going to parse CommonMasterSnippet(partition specific) : "+ CommonMasterSnippetFile); | ||
| xmlHandler.parseMasterSnippet(CommonMasterSnippetFile,CfgCVSBasePath,functionManager.FMpartition); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Parse the commonMS and MS for the 2nd time, looking for only partition-specific elements
|
Hi @kakwok, in principle, would it be possible for the level1 to chop up the partition-specific info and send the level2s their specific command parameters? If not then I understand why the level2s all need to do their own parsing, but if the level1 could do that, then why did you choose this instead of that method? |
|
That will be tedious to implement because LV1 will have to conditionally attach different parameters into different commands and set the correct commands (with the parameters) to the right partitions. |
|
OK, that makes sense. The only comment I would make is that perhaps the code could be improved by refactoring such that the code added at line 522 of the levelTwoEventHandler does not duplicate the code at line 756 of the levelOneEventhandler. For example maybe that code could be moved into a method of the EventHandler and one could just use a one-line call to that method in both the level1 and level2 EventHandlers. This might eliminate needing to modify both spots if further improvements are made to what happens there. |
|
Fair point. CommonMS parsing could be absorbed into the |
|
Tested at P5.
Logs look normal during test. |
|
We may have the case that more than 1 partitions share the same need for specific settings. |
|
Hi @kakwok, I would suggest changing this line because at certain teststands, the convention for FM names is different from to something like |
|
PS: alternatively, you could just use the full FM name instead of a shortened version, since other things, e.g. the maskedFM xml parameter, use the full FM name instead of a shortened version. |
|
I will allow both full names and partitions then. The partition convention is only true for P5 FMs. This has been the case since the time we developed FEDmasking |
|
Also implemented |
Implements #285.
Partition-specific FM parameters can be set by adding an attribute like
Partition=Laserto the element in the xml.Instead of having LV1 reads MS and passes the results to the LV2s, LV2s will read MS and pick up the attribute specific to its partition if there are any.
The partition specific values (if any) will naturally override the settings directing to all partitions.
The partition specific values can live in both commonMS and main MS. Same MS-overrides-commonMS rule applies to them.
Example usage for HO's resync Bgo will look like this:
This change is back-ward compatible to current mastersnippets.
RunkeyCfg (aka CfgToAppend) is also parsed by LV2, although cannot be made partition-specific as is.