Calculations not in correct order.

Joe Betzwieser reports that some inputs are read before they are calculated in a cycle.

model l1omc, l1omc.c value omc_readout_sum5 is written on line 3295 but read on 1516 and elsewhere when built against 4.2.5.

Illustrative transfer function attached. Both channels are in l1omc, and the transfer is purely digital. Phase should be flat, since all calculations should be made in one cycle, but measured phase matches exactly one cycle of latency, as you'd find with out of order calculations.

57971_20211122170609_dcpd_sum_vs_darm_in1_nov19_20.pdf

changed milestone to %4.2.6

assigned to @erik.vonreis

added priority label

I'm able to recreate the problem on the test stand.

changed the description

Parser is incorrectly ordering the entire LSC subsystem ahead of the OMC subsystem. A check on the links in question show that part of the calculation tree is correct, so the problem must be in the ordering code.

Input ports are being bypassed too early for top level subsystems, but I'm not sure where. These input ports are used to determine computation order between subsystems.

Inputs are routinely bypassed in feCodeGen.pl around 700.

Some global variables that used to be set in feCodeGen.pl were moved to another file, but they were accidentally made local. This nullified the writes, causing feCodeGen.pl to act as if all inputs to any subsystem had always been satisfied.

I will push patch to solve the problem and rebuild l1omc, but all models will need to be rebuilt.

closed

The rebuild of the l1omc model did not fix the calibration issues. https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=58008

There are operations out of order on l1calcs. I don't know how much they will affect calibration. I could not find any out of order operations in l1calex. l1caley looks similar to l1calex. l1calinj is in order.