make_trapezoid() changes rise_time even if passed as input argument

[h3lg3]

Describe the bug
Creating a gradient using make_trapezoid(channel = 'x', area = 62, rise_time = 200e-6) results in a gradient event with a different rise_time than provided.

To Reproduce

import pypulseq as pp

grad_area = 62
dG = 200e-6

# Create a gradient with a given area and rise time
grad_y1 = pp.make_trapezoid(channel = 'x',  area = grad_area, rise_time = dG)

# Rise time got changed!
print(grad_y1.rise_time)
pe_duration = pp.calc_duration(grad_y1)

# Create a second gradient with the same area and duration triggers error
grad_y2 = pp.make_trapezoid(channel='x',  area = grad_area, duration = pe_duration, rise_time = dG)

Expected behavior
I would expect that if I provide a specific rise_time that it will not change.

Desktop (please complete the following information):

• OS: [e.g. Win11]
• pypulseq version: [e.g. 1.4.2]

[btasdelen]

For the first case, the combination of area + rise_time is not a valid combination of inputs. Valid combinations as per the documentation are:

    The user must supply as a minimum one of the following sets:
    - area
    - amplitude and duration
    - flat_time and flat_area
    - flat_time and amplitude
    - flat_time, area and rise_time
    Additional options may be supplied with the above.

That being said, wording of the documentation is as if any additional input to the area will be a valid combination, so at minimum, wording should be fixed. Also, these input pairs slipped from the input sanity checks, that should be fixed.

I see two problems:

1. There is a check if fall_time is provided, and rise_time is not provided, we return an error. But, there is no check for the vice versa. Input logic around this is very convoluted.

2. We have a check if flat_time or duration is provided, in both cases you shared, it is not. So we default to calculate the shortest grad from area:

            amplitude2, rise_time, flat_time, fall_time = calculate_shortest_params_for_area(area, max_slew, max_grad, system.grad_raster_time)

This function overrides the rise_time, hence the discrepancy.

For the second case, you provide 20 us for rise_time, and duration. fall_time = rise_time since you did not provide it. That makes the timing impossible. The logic here seems wrong, if we are provided duration and rise_time, fall_time=duration-rise_time. Also, we should check if duration > rise_time and throw an error, which is your case here.

I will address issues here and create a PR.