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

UnivariateSpline not happy #8

Open
jcwright77 opened this issue Jul 13, 2020 · 3 comments
Open

UnivariateSpline not happy #8

jcwright77 opened this issue Jul 13, 2020 · 3 comments

Comments

@jcwright77
Copy link
Contributor

in the wham jupyter example,
running
write_eqdsk(R,Z,psi,plas_currents,"wham_eqdsk.txt","/content/WHAM_Mirror Equilib")
produces this error:


ValueError Traceback (most recent call last)
in ()
----> 1 write_eqdsk(R,Z,psi,plas_currents,"wham_eqdsk.txt","/content/WHAM_Mirror Equilib")

1 frames
/usr/local/lib/python3.6/dist-packages/scipy/interpolate/fitpack2.py in init(self, x, y, w, bbox, k, s, ext, check_finite)
180 else:
181 if not np.all(diff(x) > 0.0):
--> 182 raise ValueError("x must be strictly increasing if s = 0")
183
184 # _data == x,y,w,xb,xe,k,s,n,t,c,fp,fpint,nrdata,ier

ValueError: x must be strictly increasing if s = 0

The plot shows indeed that z is not monotonic.
The problem is lines 50/51 in write_eqdsk()

spl = UnivariateSpline(z,r,k=1,s=0)
fl_spl = UnivariateSpline(fl_dist,z,k=1)#,s=0)

Removing s=0 to use the default gets rid of the error.

scipy.version
1.4.1

@jcwright77
Copy link
Contributor Author

see
https://drive.google.com/file/d/1JcFNsz5Ao0NO7ABCphu8QQle1WVMqdar/view?usp=sharing
for a colaboratory notebook demonstrating the error and fix. Error is generated first time through, then monkey patch fixes error

@eepeterson
Copy link
Owner

@jcwright77 Almost everything in that function was created just to set the "vessel" locations to have the same shape as the flux surface and I would be happy if we got rid of it entirely since it's very finicky. I'm not quite sure what the R, Z pairs representing the vessel are for in an eqdsk, but it's my assumption that they're for vessel currents. We could get rid of this in favor of a user supplied vessel shape and a default behavior of finding the bounding box of the last closed flux surface. If WHAM has a 2D vacuum vessel profile spec'd out already we could implement that instead of relying on this shoddy code I wrote a while ago. Thoughts from @Jon-Pizzo would be appreciated too.

@Jon-Pizzo
Copy link
Contributor

I don't believe there is a 2D vacuum vessel specified in the eqdsk file, however I do have the coordinates for it as it was used in genray input files. I can email you a text file containing the R,Z pairs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants