Fix grad raster time typo. Make system rasters consistent with the defs.

[btasdelen]

Fixes the issue at #254.

[github-actions]

Coverage Report

File	Stmts	Miss	Cover	Missing
/home/runner/.local/lib/python3.12/site-packages/pypulseq
add_gradients.py	123	51	59%	44, 52, 58, 61, 75–86, 92, 120–123, 130–131, 150, 157, 162–241
add_ramps.py	36	36	0%	1–89
align.py	35	4	89%	41, 45, 69, 73
calc_duration.py	25	1	96%	37
calc_ramp.py	218	214	2%	45–353
calc_rf_bandwidth.py	27	20	26%	37–59, 63–67
check_timing.py	87	27	69%	72, 76, 101, 194, 201, 211–255
compress_shape.py	30	1	97%	28
convert.py	40	8	80%	42, 48, 66, 72–73, 82, 88–89
event_lib.py	96	14	85%	6–9, 48–51, 70–71, 205–210
make_adc.py	92	13	86%	63, 72–76, 79, 128, 131, 135, 141, 145, 184, 186, 188, 196
make_adiabatic_pulse.py	129	39	70%	196–200, 217–221, 229–230, 253, 259, 328–347, 451–460, 498–506
make_arbitrary_grad.py	37	7	81%	68, 71, 74, 77, 81, 83, 103
make_arbitrary_rf.py	66	55	17%	83–160
make_block_pulse.py	46	3	93%	112–116, 119
make_delay.py	9	1	89%	27
make_digital_output_pulse.py	16	2	88%	39, 47
make_extended_trapezoid.py	56	12	79%	67, 70, 76, 82, 85, 88, 91, 94, 116, 134, 136, 139
make_extended_trapezoid_area.py	93	3	97%	52, 227, 230
make_gauss_pulse.py	69	20	71%	127–131, 134–158, 165, 168
make_label.py	19	3	84%	36, 41, 43
make_sigpy_pulse.py	116	31	73%	12–13, 112, 115, 119, 154, 157–161, 165, 168–169, 172–173, 188, 195, 200, 212, 215, 240–250, 264, 267, 297–307
make_sinc_pulse.py	68	10	85%	94, 100, 127–131, 135, 138–139, 142–143, 165
make_trapezoid.py	111	7	94%	177, 190, 196, 214, 232, 237, 255
make_trigger.py	16	2	88%	44, 52
opts.py	66	9	86%	78, 83, 102, 142, 166–170
points_to_waveform.py	9	1	89%	27
rotate.py	69	14	80%	15, 55, 66–69, 85–90, 112, 119–120
scale_grad.py	14	4	71%	28–30, 33
sigpy_pulse_opts.py	26	7	73%	34–41
split_gradient.py	39	31	21%	46–103
split_gradient_at.py	70	27	61%	63–90, 110, 114, 118–120, 154–156
traj_to_grad.py	13	9	31%	26–40
/home/runner/.local/lib/python3.12/site-packages/pypulseq/SAR
SAR_calc.py	113	98	13%	33–40, 55–62, 89–108, 129–132, 168–212, 242–246, 264–306
/home/runner/.local/lib/python3.12/site-packages/pypulseq/Sequence
block.py	368	32	91%	59, 62, 70, 76, 91, 99, 105, 116, 119, 122, 130, 135, 144, 196, 245, 249, 265, 305–308, 337–338, 404, 410, 430, 499, 535, 541, 568, 606, 640
calc_grad_spectrum.py	81	76	6%	68–190
calc_pns.py	40	31	22%	45–96
ext_test_report.py	140	11	92%	23, 58, 61, 135, 227–233
install.py	75	42	44%	31, 52, 69, 71, 112–131, 148, 181–184, 200–212, 254–278
parula.py	4	2	50%	19–86
read_seq.py	316	68	78%	42–43, 94, 97, 109, 114, 120, 127, 136, 145, 150, 153, 161–163, 196, 201, 209–258, 288–291, 306–307, 336–353, 416, 419, 454, 462, 536, 578–582
sequence.py	737	224	70%	11–14, 101–111, 132–145, 183, 248–251, 298, 325, 342, 390, 418, 445–450, 487, 503, 594, 616, 657–660, 714, 752, 763–764, 770, 781, 787, 789, 797, 830–838, 859–881, 924, 926, 929, 955–956, 959–962, 998–1008, 1017–1019, 1063–1075, 1090–1091, 1127–1128, 1154, 1160, 1163, 1200, 1321–1334, 1357, 1385, 1407–1409, 1430, 1461, 1472–1485, 1497–1508, 1554–1555, 1564–1582, 1606, 1636–1644, 1676–1786, 1815, 1829–1839, 1851
write_seq.py	172	8	95%	41, 65, 68–75
/home/runner/.local/lib/python3.12/site-packages/pypulseq/utils
cumsum.py	14	1	93%	17
safe_pns_prediction.py	126	113	10%	50–87, 102–189, 197–214, 222, 244–250, 279–286, 310–336, 344–383, 396–411, 415
tracing.py	16	6	62%	33–34, 42, 54–55, 75
/home/runner/.local/lib/python3.12/site-packages/pypulseq/utils/siemens
asc_to_hw.py	58	53	9%	21–28, 48–106
readasc.py	48	45	6%	25–100
TOTAL	4376	1496	66%

Tests	Skipped	Failures	Errors	Time
1285	18 💤	0 ❌	0 🔥	2m 59s ⏱️

[FrankZijlstra]

Question: Why are system parameters read from the sequence file in the first place? While it is useful to know what system parameters were used to write the file, shouldn't the principle of Pulseq be that a .seq file can be shared and run on a different system? That is, system parameters should not be overwritten in the first place?

For example, if I have a hypothetical system with a 1 us gradient raster, I should have no problems reading a sequence with a 10 us gradient raster, but the sequence checks should still be done with with the user-specified system parameters.

It would make more sense to me to give a warning if the specified system parameters do not match with the ones in the file, to hint that the systems may be incompatible.

In addition, I think the system variable in Sequence is a reference, so I think this PR may end up making unexpected modifications, e.g.:

system = pp.Opts();
seq = pp.Sequence(system=system);
seq.read('test.seq')
print(system.grad_raster_time); # <-- May be changed?

[btasdelen]

@FrankZijlstra That is a good question. I think this behavior is consistent with what Matlab Pulseq does. Gradient raster times for extended trapezoids are used in plotting, and incorrect raster time causes weird looking waveforms. See #254.

I also found it confusing that, during object creation, we set self.grad_raster_time = self.system.grad_raster_time (and other system parameter), and use self.grad_raster_time internally when needed, but a couple of places we are inconsistent and use self.system.grad_raster_time instead, so now those two may not be the same if changed halfway. This PR attempted to fix that, but maybe I am misunderstanding the whole deal.

My questions are what do we expect when the user changes the Sequence.system after initialization, and what is the purpose of setting self.grad_raster_time, just a shortcut or to "fix" these definitions in a sense? If the latter, isn't it more confusing that even though the user changes parameters, most of the internal functions use old ones?

These are the functions I see that are using self.system.grad_raster_time, rest are using self.grad_raster_time:

pypulseq/src/pypulseq/Sequence/calc_grad_spectrum.py

Line 71 in 6915c67

dt = obj.system.grad_raster_time # time raster

pypulseq/src/pypulseq/check_timing.py

Line 87 in 6915c67

raster = seq.system.grad_raster_time