Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'split_gradient_at' function does not work well #25

Closed
opennog opened this issue Jan 6, 2020 · 4 comments
Closed

'split_gradient_at' function does not work well #25

opennog opened this issue Jan 6, 2020 · 4 comments
Assignees
Labels
bug Something isn't working

Comments

@opennog
Copy link

opennog commented Jan 6, 2020

Describe the bug
split_gradient_at function does not split the gradient defined as 'trap' correctly.

Expected behavior
For example, if the gradient maximum value is gy.amplitude=138888 and the rise and fall times are of 3xraster times, when you split in two equal parts the values of, ie., the fall part are array([115740.74074074, 69444.44444444, 23148.14814815]). See that the maximum values is not 138888 anymore, and that it does not end in zero either.

@sravan953 sravan953 self-assigned this Mar 7, 2020
@sravan953 sravan953 added the bug Something isn't working label Mar 7, 2020
@sravan953
Copy link
Collaborator

Could you please share code to reproduce this on pypulseq v1.2.0?

@opennog
Copy link
Author

opennog commented Apr 28, 2020

For example:
system = Opts(max_grad=32, grad_unit='mT/m', max_slew=150, slew_unit='T/m/s', rf_ringdown_time=20e-6, rf_dead_time=100e-6, adc_dead_time=10e-6, rf_raster_time=1e-6)

gy = make_trapezoid(channel='y', system=system, area=4.166666666666667)

gy_parts = split_gradient_at(grad=gy, time_point=6e-05 / 2, system=system)

Here, gy is:
namespace(amplitude=138888.88888888888, area=4.166666666666667, channel='y', delay=0.0, fall_time=3.0000000000000004e-05, first=0, flat_area=0.0, flat_time=0.0, last=0, rise_time=3.0000000000000004e-05, type='trap')

and gy_parts is:
(namespace(channel='y', delay=0.0005300000000000001, first=0.0, last=138888.88888888888, t=array([0.e+00, 1.e-05, 2.e-05]), type='grad', waveform=array([ 23148.14814815, 69444.44444444, 115740.74074074])), namespace(channel='y', delay=0, first=138888.88888888888, last=0.0, t=array([0.e+00, 1.e-05, 2.e-05]), type='grad', waveform=array([115740.74074074, 69444.44444444, 23148.14814815])))

As you can see, gy max is 138888.88888 then, even gy_parts says its first and last values (on the right and left parts, respectively) are of 138888.888888. However, the actual values of the arrays ([ 23148.14814815, 69444.44444444, 115740.74074074] and [115740.74074074, 69444.44444444, 23148.14814815]) are scaled differently. Probably because it changes the shape of the triangle.

As far as I understand it, this way we are loosing one raster time to construct the triangle with a desired area.

Thanks!
Óscar

sravan953 added a commit that referenced this issue May 4, 2020
- Round to 6 digits in multiple places for expected results
- Minor code reformatting
@sravan953
Copy link
Collaborator

Hello, can you please pull from commit 7ee6852 and let me know if the issue is fixed? You can download the ZIP from: https://github.com/imr-framework/pypulseq/tree/7ee685224962cfa5c500c6976a624fb6d09ff396

@sravan953
Copy link
Collaborator

Please reopen this issue if the bug is not fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants